Stop Writing More Code. Start Designing Better Systems.

For most of my career, writing software was expensive. Not simply because typing code took time, but because every meaningful feature required design, implementation, testing, debugging, and then years of living with the consequences. That cost forced a certain amount of discipline. Good engineers learned to think before they built because poorly considered software had a way of becoming somebody's permanent problem.

AI has changed that equation dramatically. We can now generate working code in minutes that would once have taken days or even weeks. That is an extraordinary improvement in productivity, but it also creates a new engineering problem: the cost of producing code has fallen much faster than the cost of understanding the systems that code creates.

This distinction matters. A coding agent can take a relatively simple problem and produce thousands of lines of plausible, compiling, test-passing software. It can add abstractions, services, helper classes, state machines, interfaces, retries, wrappers, and configuration layers with almost no resistance. The result may work perfectly well today while quietly making the system much harder to understand tomorrow.

That is why I believe one of the most important lessons of AI-assisted development is that code is becoming cheap, while complexity remains expensive.

Every new component creates another thing that must be understood. Every abstraction introduces another boundary. Every source of state creates another opportunity for disagreement. Every new path through the system creates another failure mode. AI may be able to generate all of this instantly, but engineers still have to reason about how those pieces interact when something goes wrong at two o'clock in the morning.

The Development Cycle Has Changed

For decades, implementation was one of the major constraints on software development. We spent considerable effort deciding what to build because actually building it was expensive. By August 2026, that relationship has almost reversed. AI can implement an idea so quickly that it is increasingly possible to generate complexity faster than a human engineer can properly evaluate it.

The development process therefore needs to change with the economics of software creation.

The old process was certainly imperfect, but its natural friction acted as a governor. Writing another thousand lines of code meant somebody had to spend considerable time writing them. There was an economic reason to think before doing so.

The emerging AI workflow removes that governor. A developer can describe a desired outcome, allow an agent to modify the system, run the tests, and discover that 2,700 lines have been added and 1,200 removed. The change may even be technically correct. The deeper question is whether anyone still understands what happened to the architecture.

The ideal process puts intentional friction back into the place where it belongs—not in typing code, but in making engineering decisions.

Code Is No Longer the Scarce Resource

For decades, much of the software industry was focused on helping programmers produce more code. We built better editors, languages, frameworks, libraries, generators, and development environments. AI represents the extreme conclusion of that effort: we now have machines capable of creating software faster than humans can comfortably review it.

Once that happens, maximizing code production is no longer a particularly useful goal.

The more interesting question becomes:

How little software can we write while still solving the problem correctly?

That changes what productivity means. If two solutions accomplish the same thing, but one introduces five new services and 8,000 lines of code while another requires a carefully designed change to three existing components, the second solution may represent far more engineering productivity even though dramatically less code was produced.

The traditional measures of software activity—commits, pull requests, story points, lines changed, features completed—become increasingly questionable in an environment where a machine can manufacture activity almost without limit.

Architecture Becomes More Important, Not Less

There is a temptation to believe that increasingly capable AI will eventually eliminate the need for software architecture. I believe exactly the opposite is happening.

Someone still has to decide which component owns a responsibility, where state belongs, what constitutes the authoritative source of truth, how failures are recovered, where transactional boundaries exist, and which operations must be idempotent. Someone has to recognize when two seemingly different problems are actually manifestations of the same architectural flaw. Someone also needs to recognize when a new abstraction genuinely simplifies a system rather than merely moving complexity somewhere else.

These decisions become more important as implementation becomes easier because a poor architectural decision can now be amplified at machine speed.

A well-designed system also gives an AI agent something extraordinarily valuable: boundaries. Instead of asking an agent to "fix the printing system," we should be able to tell it that one component owns scheduling intent, another owns execution, another owns durable state transitions, and another owns communication with the physical printer. The implementation task then takes place inside an architecture rather than becoming an opportunity to accidentally invent a new one.

This is an important distinction. AI should work within the architecture much more often than it should be allowed to create the architecture implicitly through implementation.

The AI Has No Fear of Complexity

I have started to think of AI coding agents as extraordinarily capable engineering collaborators that have almost no natural fear of complexity. They do not get tired of adding another class. They do not have to maintain a service for the next ten years. They are perfectly willing to solve a 200-line problem with a 2,700-line refactor if that path appears reasonable from the immediate context.

The AI is usually trying to be helpful. If a problem appears to require additional machinery, it will happily build the machinery. If the next problem then requires machinery to manage the machinery, it will happily build that too.

Humans behave this way as well, but humans eventually experience the pain they create. We have to navigate the code, debug it, explain it to other developers, deploy it, upgrade it, and respond when it breaks. That pain gradually teaches experienced engineers a healthy suspicion of unnecessary complexity.

AI does not yet accumulate that scar tissue in quite the same way.

That makes one of the senior engineer's most valuable responsibilities surprisingly simple: knowing when to say no.

No, we do not need another service. No, we do not need another source of truth. No, this behavior does not belong in the user interface. No, we should not create a second state machine to compensate for problems in the first one. No, we should not add an abstraction whose only purpose is to wrap another abstraction.

Sometimes the best contribution an engineer can make is stopping more software from being written.

Composition Matters

Large systems rarely become difficult because programmers forget how to write individual functions. They become difficult because responsibilities blur over time. A module that originally had one job gradually acquires five. Transport logic starts making business decisions. User-interface code begins managing durable workflow state. Database models accumulate behavior. A utility class slowly turns into the center of the application.

AI can accelerate that decay because it tends to see the immediate problem presented to it. If fixing that problem requires adding behavior to an existing class, doing so may be entirely reasonable locally even though the class is already carrying too many responsibilities globally.

This is where an engineer has to maintain the larger mental model.

The antidote is not less AI. It is stronger architectural discipline: clear ownership, small components, explicit state transitions, stable interfaces, understandable failure modes, and a system model that another engineer can explain without opening fifty source files.

A good architecture makes individual changes boring. That is a feature, not a weakness. If adding a capability requires the entire system to be reconsidered every time, the architecture is not providing enough structure.

The Engineer Becomes the Conductor

The role of the software engineer may therefore be changing in a fundamental way. For much of our profession's history, the visible output of an engineer was code. Increasingly, the highest-value output may be decisions.

The engineer understands the problem, creates the system model, establishes constraints, identifies invariants, chooses tradeoffs, defines component ownership, and decomposes a large problem into small coherent changes. AI can then implement, test, analyze, document, and refine those decisions at enormous speed.

This does not diminish engineering. It places more value on the parts of engineering that were always the hardest to automate.

Knowing how to implement a linked list was once an important programming skill. Knowing whether the system needs another queue, who owns that queue, what happens when a message is processed twice, how failures are recovered, and whether a queue is even the right abstraction is a different level of reasoning.

That judgment increasingly becomes the engineer's contribution.

An experienced engineer equipped with AI can now accomplish work that once required a much larger team. But the leverage comes from combining machine productivity with human judgment. Without that judgment, AI may simply give us the ability to create technical debt faster than we ever imagined.

Perhaps Productivity Should Mean Less Code

We may also need to rethink what a successful development session looks like.

The best change to a system may delete thousands of lines of code. The best architecture may eliminate an entire service. The best API may replace dozens of special cases with one coherent model. A productive afternoon may consist of discovering that three supposedly different mechanisms should actually be one mechanism.

Sometimes the best solution is discovering that the proposed component never needed to exist at all.

This creates an interesting inversion in software development. Historically, programmers were expensive and code represented visible output, so producing more functionality usually meant producing more software. In an AI-assisted environment, code production is practically unlimited. Restraint becomes valuable.

The engineer who understands the system well enough to avoid unnecessary implementation may contribute more than the engineer—or AI agent—that generates thousands of lines of technically competent code.

Design First. Generate Second.

At Balke Associates, this is the direction I find most interesting. AI gives us remarkable new tools for building software, and I have no interest in going backward. The productivity gains are too significant, and the ability to investigate, prototype, test, and implement ideas at machine speed is extraordinary.

But we should use that power deliberately.

The development cycle I want is not prompt → generate → test → ship.

It is:

Understand → model → constrain → decompose → generate → verify → simplify.

AI belongs in that process, and it belongs there extensively. What changes is that AI generation should occur after we have decided what kind of system we are trying to create.

The goal should not be to see how much code these tools can produce. The goal should be to use them to create systems that are smaller, clearer, more reliable, and easier to reason about.

In the age of machine-generated software, the competitive advantage may no longer be the ability to write more code.

It may be knowing when not to write it.

---

Balke Associates, Inc. — Systems engineering, software architecture, embedded systems, automation, and AI-assisted development.