From Writing Lines to Defining Outcomes

The Instinct for Friction

I originally started thinking about a manual first approach after spending time around developers who clearly learned their craft through repetition, failure, and long exposure to real systems. These are people who understand code not because they memorized patterns, but because they’ve seen what breaks when those patterns are applied carelessly.

As I automated more of my own workflow, I started noticing a subtle shift in how I related to the code. Things were faster, and often correct, but they were also easier to accept without fully understanding. Reviewing code manually before asking an AI to do it became my way to counteract that drift. The goal wasn't to reject automation, but to make sure I was still exercising judgment rather than just outsourcing it.

In that context, manual first felt less like a rule and more like a safeguard. It was a way to stay engaged with the problem instead of becoming a passive consumer of output.

The Level Up Argument

But that logic hit a wall after a broader conversation about the future of development. The argument wasn't that manual skills are useless, but that they’re no longer central. As AI absorbs more of the execution layer, the real value of a developer shifts toward higher-level concerns like system design, architecture, and problem definition.

From that perspective, spending time preserving low-level skills for their own sake looks like misplaced effort. If the tools are good and getting better, the responsible move is to follow the value upward rather than anchoring yourself to work that’s being steadily automated away.

There’s a certain clarity to that view. Industries evolve, and roles evolve with them. If the target is moving and the direction is positive, chasing it isn't reckless. It’s practical.

It wasn't the argument that unsettled me. It was the endpoint.

The Multi-Agent Promise

If we’re meant to think in systems while AI handles execution, the natural outcome is a largely automated feedback loop. One model writes code, another reviews it, another checks security, and another evaluates performance. Human involvement becomes more about intent and approval than inspection.

On the surface, this looks like progress. Review still exists, but without the cost of human time. Errors are caught, standards are enforced, and the system continuously improves itself. In theory, the loss of manual review is offset by redundancy and scale.

This is where the idea starts to feel complete. It’s also exactly where it starts to feel fragile.

The Echo Chamber Trap

The risk in a fully automated review system isn't that the agents will fail to communicate. It’s that they’ll converge too easily. Agreement between models isn't the same thing as correctness, especially when those models are trained on similar data and optimized in similar ways.

Human review benefits from disagreement rooted in experience. Different people notice different things because they’ve been burned by different failures in the past. When a human challenges a piece of code, they’re often reacting to something that once broke in the real world, not just something that violates a formal rule.

AI systems don't have that kind of grounding. If one model confidently infers a pattern that’s statistically likely but contextually wrong, another model is often inclined to accept it. Over time, this creates an echo chamber where internal consistency replaces external validation.

The code passes review. The system agrees with itself. And yet the solution drifts further away from the reality it’s meant to operate in.

Defining the Laws of Physics

This realization reframed my original concern. I thought the risk was losing the ability to write good code. What actually seems more dangerous is losing the ability to define what good means in the first place.

As automation improves, the most important human contribution shifts away from execution and toward constraint. Writing tests that reflect real-world expectations. Defining invariants that must never be violated. Creating adversarial conditions that force systems to confront reality instead of reasoning in the abstract.

In that sense, moving up the stack doesn't remove responsibility. It concentrates it. We may write fewer lines of code, but the lines we do write define the boundaries within which everything else operates.

Remaining the Anchor

We don't need to be involved in every detail, and we shouldn't try to be. Automation isn't the enemy, and resisting it outright is neither realistic nor productive. But there’s a difference between stepping back and letting go entirely.

The target will continue to move, and it should. Tools will get faster, more capable, and more convincing. The question isn't whether we follow, but what we carry with us as we do. Someone still has to decide what problem is being solved, what failure looks like, and when a solution is unacceptable even if it passes every internal check. That role is defined by context, intent, and consequence. It requires a human anchor to keep the system from drifting.

As we move further up the stack and focus more on constraints than lines of code, we have to ask ourselves: are we steering the system toward a real world solution, or are we just watching it agree with itself?