Are "trusting engineers on outcomes" and "trusting a model on outcomes" comparable things?
In Demon in White, Hadrian Marlowe can see countless parallel outcomes at once and choose the one where he doesn't get burned. He doesn't fully understand how he does it. Ask him to explain it and the honest answer is I just knew.
Experienced engineers have a version of that ability. Not science-fiction mysticism — compression. Pattern-matching built from hundreds of prior cycles, fast enough to feel like instinct. It only works in domains they've actually cycled through: a senior engineer's gut is reliable on a well-trodden architecture decision because they've watched that specific failure mode play out before. The same gut is far less reliable on something genuinely novel, because there's nothing underneath the confidence except the confidence.
As a CTO or VP of Engineering, you already run on a version of this trust, and it's more radical than it sounds when you say it plainly: you sign off on outcomes for code you have not personally read a line of. You didn't write it, you didn't review every diff, and you still put your name behind it. That's not negligence. It's a functioning trust structure — built on the engineer's track record, the review process around them, and the fact that being wrong has consequences for the person who was wrong.
That trust was never free. It was built the slow way, over years, by engineers who first wrote bad code, watched it fail, and developed the pattern-matching to catch failure before it shipped. It's far more difficult to go the slow way in the current development routine, so naturally, we're bound to run out of engineers with that gut instinct defined as above — and with them, the supply of people whose track record is what the trust was actually built on.
Now, what about a model. Isn't it extremely good at pattern recognition? Yes — it has the well-trodden paths very well covered, which is exactly where trust is easiest to extend, because there's a track record to check it against. The more difficult question is trust on the paths that aren't well-trodden: how does a model earn the same confidence a senior engineer earns on unfamiliar ground, when it has no track record there to point to and no consequence if it gets it wrong?
Trusting an engineer on outcomes works because of three things that aren't really about the code: accountability, a checkable history, and the ability to answer the question "why did you do it this way". A model, today, has none of those by default. It has no stake in being wrong, no track record you can look up, and its explanation for its own output is generated after the fact — often a plausible story rather than a real account of what happened, which is a different failure mode than an engineer being mistaken.
The operational shape this is taking is the development of better harnesses. A harness is the scaffolding around the models: what tools it can call, what procedures it follows, what it can execute and check, how its output gets verified before anyone relies on it, and who — or what — reviews it before it ships.
Add a harsh automated review layer on top — tests that fail loudly, checks that flag simplification and hardcoding, not just syntax errors — and you get something closer to a small team than a single author: a builder, an independent reviewer running in its own session with none of the builder's context, and a set of standing checks that don't care who wrote the code. The independence is worth the cost. A reviewer sharing the builder's session inherits the builder's blind spots; a genuinely separate session, given only the artifact and the stated requirement, has to reconstruct intent from evidence rather than from memory of its own reasoning. Whether that's equivalent to an engineering team with real judgment and real accountability is the open question, and "no worse than a human team" needs a specific domain and a specific failure rate attached to it before it's worth believing, not a general statement of confidence.
This won't move at one speed. Most organisations will keep a human in the review seat for a long time, not out of caution alone but because building a harness rigorous enough to replace that seat is a process change, not a technology change. The model access is already commoditized. The harness is an operating discipline: who reviews what, on what cadence, with what authority to block a release. Process change is slower than technology change almost everywhere, and this won't be the exception. The organisations that get to fully autonomous, end-to-end development first will be technology-first, engineering-led organisations that treat the harness itself as the product of an engineering effort, not a policy memo. Everywhere else, a person stays in the loop, correctly, because the process work hasn't been done yet.
What's changed in the last twelve months is how far that harness now reaches. Fully autonomous, end-to-end development — spec in, working system out, with no engineer touching the intermediate steps — is already happening in production for specific, bounded categories of application. My own position is that most or all systems will be built fully autonomously within another year as harness-building itself becomes standard practice at the engineering frontier. Even though a proportion of organisations will trail past that timeline for the process reasons above.
In 2016, a development team was a fixed unit: a number of engineers, a backlog, a release cadence measured in weeks. Expertise was concentrated in people, and the main lever you had as a leader was who you hired.
In 2025, the team is a hybrid: engineers directing models, reviewing output, still doing the parts that require judgment about what shouldn't be built, not just what can be. The bottleneck has partly shifted from typing code to verifying it — which is a different skill than a lot of engineering hiring still selects for.
By 2027, the transitional shape is a small number of people functioning less like builders and more like the second, independent review session in the harness described above — holding a fast, occasionally-confident system accountable to outcomes it has no stake in getting right. That role exists mainly because most organisations haven't yet done the process work to trust removing it. By 2027, the models and the harness around them are likely already good enough for a lot of that trust to transfer.
Past 2027, both sides of the lag close. The technology keeps improving — better separation between building and checking, sharper automated adversarial review, tighter feedback loops on the checks themselves. Adoption starts catching up too: the process work — who reviews what, on what cadence, with what authority to block a release — stops being novel and starts being a known playbook other companies can copy rather than invent. The technology lead compounds early. The process lag closes later, once the harness stops being something you have to design from scratch and becomes something you adopt.
Most human review gets squeezed out of the software development loop eventually. It means the trust question this piece opened with resolves in the model's favour: the harness around it becomes good enough that the difference between a model and an engineer stops mattering for the outcome.
Trust in an engineer was never trust in their code. It was trust in the structure around them — accountability, a checkable history, and consequences for being wrong.
A model has none of that by default. But with such fast development of both model capabilities and the harness around them, we are bound to eventually extend our full trust to models, albeit based on a different set of principles than the trust we place in humans.