The Scope Pendulum: How Much Can We Truly Delegate to AI?

The question pops up in every hallway chat, every LinkedIn thread, and every client meeting after someone reads a headline: is AI going to replace software development as a profession? I don't have the answer, and I'm skeptical of anyone who claims to. What I do have, after months of working this way daily, is something likely more useful than a prediction: a pattern. A cycle I repeat, that I see colleagues repeat, and that I haven't yet learned to break. 

The Beginning: When Trust Builds Bit by Bit

At first, you're skeptical, and rightly so. The initial delegations are minimal: a regular expression, a parsing function, the boilerplate for a unit test, converting a JSON payload into a type. Things you can verify at a glance. I used to read every single line of generated code with the same scrutiny you'd apply to a talented but unknown junior engineer. And it worked. It almost always worked. Every success chipped away at that initial skepticism. Increasing my trust wasn't a conscious decision; it was the cumulative result of dozens of small, successful verifications.

When Scope Outpaces Review

The next step is inevitable. From the function to the module. From the module to the full endpoint—complete with validation, error handling, and tests. From there to "implement the entire CRUD following the pattern in this other folder." What’s interesting isn't how fast the delegated task grows in size, but how quietly the code review degrades. First, I read every line. Then, I skim looking for anything unusual. Next, I only check method signatures. Finally, I just run the tests, see green, and move on. The shift from "reading code" to "verifying it works" seems like a minor process detail, but it's a profound shift: I stopped evaluating the code itself and started evaluating only its observable behavior, which is a much smaller fraction of what actually matters.

The Real Problem Isn't That It Works

At some point in the cycle, an uncomfortable feeling sets in—one I took a while to put a name to. It isn’t that the code is bad. It works. The tests pass. The feature demos properly. The real problem lies elsewhere: I’ve accumulated a volume of work whose value I can no longer estimate. Code isn't written to be defended; it's written to work and deliver value. The point is that I can no longer judge how much value it actually delivers. I don't know whether that class solves a real business need or one the model inferred by analogy. I don't know if the three layers of abstraction that appeared address genuine complexity or just a pattern that crept in because it was statistically average for what the model deduced.

And there is a more uncomfortable corollary. When the business inevitably asks for changes, I have no way to anticipate the actual cost: what breaks, what depends on what, or where the risk lies. Sure, I can delegate the modification again, but that's just doubling down on the bet, not managing it. The question is no longer "does the code work?" but rather "is this worth anything?"

The Pendulum of delegate to AI Swings Back 

The correction is always the same: I scale back again. I shrink the scope of what I delegate down to a size I can genuinely review once more. I regain control over progress, even if it moves slower. And for a while, the work feels solid again. Here is the most honest part to share: it isn't a learning curve. It's a pendulum.

A new model comes out. A tool arrives with better context, tighter repository integration, or better handling of long-context tasks. I get emboldened. I try something a bit larger, it goes well, so I try something larger still. And at some point—without fail—I end up back in the same spot: I'm producing more than I can review. The scope of what I delegate is elastic, stretching every time the tool improves. But the ceiling isn't set by the model. It's set by my capacity to review, which remains constant.

What Has Truly Become Indispensable

If review is the bottleneck, and review doesn't scale, then the only thing that scales is the harness. To me, this is the most critical shift in perspective that all of this has brought about. Automated testing ceased to be a best practice to be negotiated against the schedule and became the sensor alerting me when something I didn't read broke something I didn't look at. Architecture stopped being an aesthetic discussion and became the mechanism that limits the blast radius of a change I don't fully understand. Quality attributes—observability, traceability, coupling, testability—stopped being just a chapter in a design document and became the very infrastructure allowing me to work fast without working blind.

It is a productive resignation: I accept that I will not review everything, and in exchange, I invest in having the system protect me from myself. Curiously, everything the industry spent twenty years trying to justify to impatient clients has now become a prerequisite for viability.

From Experimentation to Accountability

I don't know how to break out of the cycle. I keep stretching and shrinking the scope, and I suspect I’ll continue doing so every so often. But there is one distinction I have learned to hold onto. When I’m exploring, playing around, or testing an idea on a Saturday night, the cycle is free: I absorb the cost of overreaching myself, in my own time, and the learning justifies the waste. When it's professional work for a client, the cost of overreaching is paid by someone else—often on a timeline that neither of us will see until it gets expensive.

In the first case, the pendulum is an experiment. In the second, it’s an accountability. I still can't stop the oscillation, but at least I know who holds the rope.