As implementation effort falls, specification and verification absorb more of the engineering effort.

The thesis

Software development today is mostly the work of humans converting intent into code. The next shift is software that can increasingly observe, modify, test, and improve itself. The point of this comparison is not to argue that engineering effort disappears. It is to show how that effort moves.

The engineering problem stops being producing each implementation. It becomes designing and governing the loop that produces implementations. "harnesses"

Implementation stops being the scarce resource

Historically, turning an idea into working code consumed a large amount of engineering capacity. If implementation becomes dramatically cheaper, engineering effort does not disappear. It moves toward deciding what should be built, what must never change, how success is measured, and how changes are proven safe.

The traditional loop

Humans are responsible for interpreting most of the feedback and deciding what happens next.

The self-improving loop

The engineering problem shifts from producing each implementation to defining an environment the software is allowed to change itself within.

Tests change their role

In human-developed systems, tests verify the code developers wrote. In self-improving systems, tests help define the boundary of what the software is allowed to become.

This expands testing beyond unit and integration tests into security invariants, compatibility guarantees, performance budgets, cost budgets, data-access policies, regulatory requirements, and product outcome metrics. Tests become executable policy or constitutional law.

Observability becomes an input, not just an output

Testing

The traditional model is software, then telemetry, then a human deciding what to do. In a self-improving system, logs, metrics, traces, user behaviour, cost, and business outcomes feed directly back into the agent that proposes the next change.

Telemetry

Observability moves from operational tooling to a core development interface. Telemetry is no longer just how you diagnose. It is how the system learns.

Architecture defines safe optimization surfaces

Good architecture is no longer only about maintainability for humans. It also determines which parts of the system may change independently, what permissions an agent needs, what contracts must remain stable, and how much damage an incorrect change can cause.

Modularity becomes a mechanism for bounded autonomy. Contracts, blast-radius control, and ownership boundaries become the way you give an agent freedom without handing it the whole system.

Where the effort shifts

The development process does not get simpler. Each step changes what is asked of the people on the team.

Defining the problem shifts toward making intent explicit and machine-readable. Requirements shift from shared human understanding to explicit specification. Design shifts toward creating safe modification boundaries. Planning implementation matters less; defining the search space and its constraints matters more.

Review shifts from inspecting every change toward reviewing the change-generation system itself: the evaluation suites, the constraints, the permissions, the telemetry quality, the rollback behaviour, and the boundaries a change is allowed to cross.

CI becomes less a gate and more an experimentation platform where alternatives are generated, tested, and compared. Deployment gains far more emphasis on safe, progressive rollout and bounded autonomy. Recovery must be predictable, automatic, and heavily tested.

Product metrics become part of the control loop rather than retrospective reporting, automatically deciding whether a change is kept, rolled back, or iterated on. The whole development lifecycle becomes a continuous feedback loop.

Code review becomes system review

Today the question is often "is this PR correct?" With self-improving software, the higher-level question becomes: is the system that generated, tested, evaluated, and deployed this change trustworthy?

The most important engineering work in a self-improving system may not be writing the next version of the software. It may be defining the environment in which the software is allowed to write its next version.