The Expensive Part Is Knowing Whether It's Right

The AI conversation mostly fixates on the first draft. In engineering work, the first draft is rarely the expensive part. The expensive part is knowing whether the draft is right.

Does it solve the right problem and fit the system? Does it preserve the behavior people already depend on? Can it be tested, reviewed, and rolled back? Will someone understand it six months from now, when production is broken and the original author is on vacation? Answering those takes engineering discipline, whatever speed the first draft arrived at.

AI can help with that discipline, but it can't create it for you. It can generate test cases, summarize a diff, or propose a safer implementation path, and used well it tightens the loop between intent, implementation, and validation. Used poorly, it hands you a bigger pile of work to trust too early.

Teams get into trouble right at that point. The code shows up fast. People start treating the work as almost done, a ticket moves, a pull request appears, and it all feels like progress. The first draft is not the work, though. It is the beginning of the work, and at that moment the reviewer hasn't understood it, the tests haven't proven it, and production hasn't absorbed it, never mind the customer who will eventually have to live with it.

AI Rewards Clear Thinking

Good AI use usually starts before anyone writes a prompt, with understanding the problem. What are we trying to change, and what behavior has to stay the same? Which constraints matter, and what would prove the change works? What should we absolutely not touch? Asking those questions is ordinary engineering, and the people who ask them tend to write better prompts without trying.

The engineers who get better results from AI are usually the ones who can communicate the work, which means describing the boundary of a change, explaining the context, and telling a plausible answer from a useful one.

AI is useful because it removes friction from work the engineer already knows how to evaluate. It helps with scaffolding, summarizing, and getting unstuck, and it makes boring work cheaper. It does nothing about the need to know what good looks like, and people keep trying to skip that part. A good engineer can ask AI for a first pass at a small helper function and see quickly whether the shape is right. They can ask for test cases and spot which ones check something and which ones are decorative, or ask for a refactor and keep it inside a boundary they can review.

AI Exposes Vague Requirements

If the requirement is mushy, AI will happily produce a mushy answer, which is what you get when unclear intent meets a system built to produce something that sounds plausible.

Imagine asking AI to "add support for refunds" in a product that takes payments. It sounds simple until you start asking questions. Who can issue a refund, and can it be partial? What happens after settlement? What happens if the payment provider accepts the refund but the local database update fails, or the user hits the button twice? What does customer support see, what does finance need, and what audit trail is required? Every one of those is missing context, and none of it is in the ticket.

AI can generate code before any of those questions are answered, and that is the danger. It makes incomplete thinking look like implementation and turns an unresolved business problem into a pull request. Then the cost moves, first to the reviewer who has to find the missing assumptions, then to support when the edge cases show up, and eventually to the customer when the system does something nobody thought through.

AI Makes Small, Well-Bounded Work Faster

AI is useful in plenty of places, and small, well-bounded tasks are often the best fit. Generate unit tests for this function. Explain what this module appears to do. Convert this repetitive pattern into a helper. Summarize this diff before I send it to review. Create a first pass at a migration script that I will inspect carefully.

Those work because the boundary is clear and the validation path is close, so the engineer can hold the output up against the intent, run the tests, and review a diff that fits on one screen. The result earns trust the same way any other change does, by getting through the tests and the review.

AI works as a multiplier here because it speeds things up without weakening ownership, since the engineer is still thinking, still reviewing, and still deciding, and the AI is only helping them cover terrain they already know at a faster pace.

AI Makes Large, Vague Work Riskier

The larger the change, the more context matters, and that is where AI gets dangerous, mostly because it is confident. It will produce something structured, it may even produce something that compiles, and none of that tells you whether it is correct.

Changing authorization logic is a different job from generating a helper function. So is modifying a deployment workflow, refactoring legacy code nobody understands, or touching a shared data contract, and the more context a task requires, the more that confidence costs you.

AI can still help with a large change. It can suggest areas to inspect, point out tests to write before touching the code, and help you reason through risk. Using it to blast through a poorly understood system is something else, closer to gambling with better autocomplete.

Most fragile systems are fragile because they carry hidden history. There was a production incident, or a customer commitment, or a data migration that only half finished. There was a vendor behavior that forced an ugly workaround, and the workaround is still sitting in the code. AI doesn't know any of that, and if you don't know it either, you are moving blind.

The AI Did Not Merge the Pull Request

The AI did not merge the pull request. You did.

That sentence should be uncomfortable, because it cuts through a lot of excuses. Blaming the model is easy. Maybe it missed an edge case, invented an assumption, or wrote code that looked fine and didn't fit the system. All of that may be true, and it matters less than people want it to. A person approved the design and decided the tests were good enough. A person saw the strange diff in the authorization layer and let a large, hard-to-review pull request through because the ticket needed to move.

AI can generate work, but it can't own the consequences. The engineer still owns the change, the reviewer owns the review, and the team owns the system and what it does to customers. Accountability matters more once code arrives this fast.

When a person writes bad code, we expect tests, review, and rollback paths to limit the damage. AI-generated code shouldn't get a weaker standard because it appeared quickly, and I'd argue it deserves a stronger one. Fast drafts are useful. Fast merges of changes nobody understands are how incidents start.

Bad habits get loud here too. A team that already treats pull request review as a rubber stamp will rubber-stamp more code, a team that tolerates vague requirements will turn them into implementation faster, and a team that avoids tests will ship untested code with more confidence than before. Those are ownership problems the team already had, now with better tooling.¹

The Review Burden Changes

Review matters more once AI is in the loop. A reviewer looking at AI-assisted work has to do more than check whether the code is clean, because they also have to decide whether the change belongs in the system at all and go looking for invented assumptions, unnecessary scope, and tests that don't test much.

That is especially true when the pull request is bigger than it should be. AI makes a lot of code cheap to generate, and none of it gets any cheaper to review, because a reviewer still has limited attention and limited time. When AI turns a small task into a kitchen sink pull request, the work has moved from the author to the reviewer, and calling that productivity is generous.

Good AI use should make review easier. It should help the author produce smaller changes, clearer tests, and a pull request description that shows their work. Bad AI use produces a pile of plausible code and asks the reviewer to be the safety net for every assumption the author never checked.

Tests Matter More Now

The faster code appears, the more important it is to know whether it works, so automated validation matters more now. Contract tests, security scans, and rollback practice all earn their keep, and none of them become obsolete because AI can write code.

Boring production is still a feature.² A team that uses AI well should be investing in stronger guardrails, because AI increases the volume and speed of change, and more change moving faster through weak validation is more risk. The fix is to improve the system rather than slow everyone down by hand, which means shorter branches, smaller pull requests, and observability that tells you whether a change is behaving in production.

Local Speed Can Become System Drag

The easy mistake with AI is measuring the wrong thing. If an engineer finishes their part faster, it feels like a win, because the code was generated in minutes and the first draft showed up before lunch. What matters is what happened to the rest of the system. Did review get harder, or rework go up? Did support get more noise? Does the team understand the change less than it would have? Local speed can become system drag.

Software has a long history of this. One part of the process optimizes for itself and pushes cost downstream, so development moves faster while QA absorbs the pain, or release dates get hit while support inherits the mess. AI can make that pattern worse, because the individual feels faster while the team gets slower.³

So the useful question is where the time went. When AI takes repetitive effort off the table and the work is still easy to test and support, it helped. Sometimes, though, the effort only moved to the reviewer and the on-call engineer, and somebody downstream is paying for time that just looked saved.

AI Is a Discipline Test

I am not anti-AI. I use it, I think it is useful in software work, and I expect it to become a normal part of engineering. I also think a lot of teams are going to learn the hard way that AI exposes weak discipline instead of making up for it.

A team that already has clear ownership, good testing habits, and short-lived branches can let AI multiply all of it, because the work has structure around it. On a team that runs on tribal knowledge, giant pull requests, and hero engineers who know where the bodies are buried, AI just pushes more change into a system that was already struggling to absorb it.

That is the mental model I keep coming back to. AI is a test of engineering discipline, and it will make you faster at whatever you already are. If you are sloppy, it will help you create sloppy work faster than your team can clean it up.

None of that is an argument for avoiding AI. Use it to explore, to draft, and to make the boring parts cheaper, and don't use it to skip understanding, tests, or review.

The Work Is Still Yours

The code will keep showing up in seconds, and each time it will look a little more finished than it is. AI will speed you up either way, so the thing to watch is what it is speeding up, and on a team with vague requirements, giant diffs, and shallow review, the answer is the bad habits.

The tool can help you move, but it can't tell you whether the movement is progress, and it won't be the one on the incident call trying to explain why nobody understood the change they approved.