Introduction

Pieter Levels recent assertion that software is mostly dead sent ripples through the tech community, sparked by a Y Combinator batch dominated by harness and hardware startups. At the heart of the debate lies a fundamental question: as frontier models absorb more functionality, what remains for engineers to build? The conversation isnt just about survival its about which parts of the software stack are becoming generic mechanism, and which deserve to be owned as durable policy.

What Happened

In July, the European Space Agency posted an opening for a Harness Engineer at its technology center in the Netherlands, defining the term in its original sense: a bundle of wires carrying power and signals between spacecraft components. Months later, Levels surveyed Y Combinators latest cohort and concluded the batch was nothing but harness and hardware startups, declaring software largely obsolete. The essay argues that most harness code isnt worth building, and that the useful question isnt whether software survives, but which part of it does. The article surveys a range of YC companies, drone fleets, autonomous CNC factories, robotics, voice-first hardware interfaces, coding agents, and visa-processing bots while unpacking the definitional tension between application software and the harness layers that surround AI models.

Why This Matters

The strongest argument Levels makes isnt about the batch composition its that the harness itself may not survive model improvement. Evidence from Anthropic, Google DeepMind, and industry observers shows that as models grow more capable, much of the scaffolding around them becomes redundant. Googles Antigravity harness, Anthropics generator-evaluator loop, and Anthropics own post-strip-down conclusions all point toward a future where frontier labs ship what was once custom harness code as default features. Yet the article counters that harness value persists where absorption falls short: behavior matching intent, organizational authority, contextual data semantics, and distinctive taste all remain deeply specific to the builders organization. The shoreline metaphor frames each model release as a tide that reshapes what is left standing.

Key Takeaways

  • Mechanism vs policy: Frontier labs will own the mechanism; the policy is yours to define. Run every component through the Absorption Test: if a better model or lab default can replace it, rent it and delete it.
  • PACT framework: Proof, Authority, Context, and Taste are the four pillars that survive absorption. Proof verifies behavior matches intent; Authority governs permissions and sign-off; Context anchors your systems of record and codebase conventions; Taste ensures output isnt generic.
  • Harness longevity: Generic harness layers task decomposition, context compaction, evaluator loops, sandboxes, tool connectors face absorption by model upgrades or platform defaults. What remains are human-centered capabilities: permissions, identity, trust, and organizational policy.
  • Actionable shift: Engineers should pivot from producing code to producing proof. Investors should back policy-heavy domains like finance, health, and industrial operations. Technology buyers should rent the labs harness and build a versioned, tested PACT layer.

Conclusion

Software isnt taking its last breath its evolving into something held together by intentional policy rather than generic mechanism. The harness will always exist at the waterline, marking where the tide of model capability recedes and what remains visible underneath. Engineers who learn to distinguish absorbable mechanism from irreplaceable policy, and who build robust evals, permission schemas, and taste-driven rubrics, will shape the next era of software. As the article closes: code is cheap, but evidence of what it does, within the limits you set, is what endures.