It Still Takes a Software Engineer to Point the Gun

Why AI turned the boring fundamentals into the highest-leverage skill on your team, and why your crustiest legacy service benefits more than your shiny new repo

The discourse around agentic coding has collapsed into two loud camps. One says the profession is over and you should update your resume to say “prompt whisperer.” The other says it’s all hype and the models can’t do anything real. I sit in a third seat, and it’s a boring seat, and I think it’s the correct one: the tools are genuinely powerful, and they made the least glamorous part of my job the most important part of my job. That part is architecture. Not the diagram-on-a-whiteboard kind. The kind where you decide what talks to what, what stays stable, and where the code is allowed to flex.

AI Is a Lever, and Levers Have No Opinions

A lever multiplies force. It does not pick a direction. If you brace it against solid ground, you move the world. If you brace it against mud, you go into the mud faster and with more leverage. That’s the thing people keep missing when they talk about AI writing code. The risk was never that the model writes obviously bad code. The risk is that it writes code that looks right, at volume, against whatever structure you hand it. Give it a clean seam and it fills it well. Give it a four thousand line god object and it will cheerfully add function number ninety one, with a passing test, and hand it back to you like a golden retriever with a stick. It works. It also just welded another steel plate onto a thing you already couldn’t get out the door of the shop. The model amplifies the sign of your architecture. Positive stays positive, negative stays negative, and both happen faster.

Your Architecture Is the Context Window

Here is the reframe that changed how I work. The prompt is not the sentence you type into the chat box. The real prompt is the code around the cursor: the interfaces, the tests, the names, the conventions the model can see. That is the context it predicts against, and it will imitate it faithfully. Which means prompt engineering, at the level that actually matters, is just architecture wearing a hat. A tight interface is a narrow, unambiguous prompt. A leaky abstraction is a vague one, and you get vague results back. Think of the model as an apprentice standing at your workbench. If the bench is clean and every tool is where it belongs, the apprentice hands you the right thing on the first try. If the bench is a pile of half finished parts, the apprentice hands you a stapler and looks proud about it.

A concrete scenario. Two repositories, same request: add retry with backoff to the outbound HTTP client. Repo A has one HttpClient interface with an injected transport. Repo B calls http.Get directly in forty places. Same model, same prompt, same afternoon. In Repo A the model edits one seam and it's done. In Repo B it sprays forty near identical edits, misses three of them, and now you have a codebase where retries are mostly a thing that happens. The difference in outcome had nothing to do with the model. It was decided months earlier by whoever drew the boundary, or failed to.

Why Your Legacy Monolith Beats Your Greenfield Repo

The common wisdom is that AI shines brightest on greenfield work. I think that’s backwards for anything you actually intend to keep. Greenfield has no constraints, so the model invents them. And it invents them differently every time you ask. A blank repository is a cold start problem: nothing to imitate, nothing to check against, so you get plausible looking architecture that quietly unravels on the third feature when two of the model’s improvised patterns disagree with each other.

Mature software carries something precious that a fresh repo simply does not have. It has established patterns to copy. It has naming conventions. It has boundaries that already survived contact with reality. And, if you’re lucky, it has a test suite that answers one deterministic question very fast: green or red. That combination, rich context plus a hard pass or fail signal, is exactly the environment where these models do their best work. They are excellent at reading a failing test or a compiler error and correcting themselves. They are terrible at deciding, from nothing, what “correct” should even mean.

To be fair to the other side: AI is fantastic for the “good enough” throwaway. Prototypes, one off scripts, glue code, the demo you’ll delete on Friday. Go wild. But the moment you want the thing to live for years, the fundamentals reassert themselves, and the codebases that already have them pull ahead. The old, well kept monolith is a better dance partner than the empty folder.

The Blast Radius Got Bigger

A bad abstraction used to spread at human speed. One copy paste at a time, one tired afternoon at a time. There was natural friction, and that friction bought you chances to notice and stop. That friction is mostly gone now. If your boundary is wrong, the model will replicate the wrongness faithfully across the whole codebase before you get back from lunch, and it will do it with consistent formatting and full coverage, which somehow makes it worse. The cost of a bad architectural decision did not stay flat. It scaled with throughput. This is the actual reason the fundamentals matter more now, not merely the same as before. The lever got longer. A longer lever is wonderful when you’ve braced it well and genuinely frightening when you haven’t.

What Actually Changed in How I Work

I stopped asking the model to design and started asking it to fill. Interface first, then generate. I shape the seam myself: the types, the function signatures, the test names that describe what “done” means. Then I let the model write the bodies. I lean hard on a red and green loop, because a failing test is the cleanest possible instruction for these tools. “Make this specific thing pass” beats “build me a payments system” every single time. Then I put deterministic gates around it. Linters, type checkers, contract tests. The model can read those outputs and fix itself in a loop, which is where a lot of the real magic actually lives. It is not reasoning its way to a solution. It is bouncing off hard walls I built until it stops hitting them. So I spend my human hours where the machine is weakest: naming things well, drawing boundaries, and deciding what has to stay stable versus what gets to bend. The model is a tireless junior who has read every book on software design and retained absolutely none of the wisdom. It will follow your architecture straight off a cliff with tremendous enthusiasm and excellent test coverage. Your job is to make sure the architecture doesn’t point at a cliff.

The Skills That Compound Now

Notice that none of this is new. Draw clean boundaries. Manage cognitive load. Name things so the next reader predicts the right meaning. Make it testable. Make it observable so you can actually see what got built. Every one of these was already in the book. What changed is the payoff schedule. These skills used to be a tax you paid now for the benefit of some future maintainer you might never meet. That’s a hard sell in a sprint planning meeting. Today they are the input that determines the quality of the code you get back this afternoon. The future maintainer you’re subsidizing is you, at 2 p.m., today. The abstraction is no longer a favor to strangers. It’s the setting on the machine.

The Fundamentals Were Never the Bottleneck. Now They’re the Multiplier.

None of this is nostalgia for hand carving every function like an artisan loaf of bread. I use these tools every day and I have zero interest in giving them back. The point is that the tool rewards, loudly and immediately, the exact thing we always claimed mattered and rarely got budget to do properly. The engineers pulling ahead right now are not the ones with the cleverest prompts. They’re the ones who already knew how to make software that fits together, and who now have a very fast, very literal, very eager partner to build it with. So pick your abstractions carefully. The machine is listening, it does not have opinions of its own, and it will build precisely what your architecture tells it to.

This piece is part of what I’m building at **leestack.dev** — a space where I get obsessive about system design, architecture, and engineering strategy. Interactive labs are in the works. Probably worth a tab you won’t close.

https://leestack.dev

If you enjoy this article: you’ll also like:

[embed]Stop Reading the Code An agent just wrote three hundred lines in forty seconds. You open the diff, start reading line by line, and somewhere…medium.com

[embed]The Rules NASA Uses to Write Code That Can’t Fail. Your AI Tools Break All of Them. In 2006, a NASA engineer wrote ten rules for writing code where lives depended on correctness. They still apply. And…medium.com