The First Draft Is Not the Work

A lot of the conversation around AI and software development is focused on how quickly it can produce a first draft. That matters, but it is not the whole job. In real 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? Does it fit the system? Does it preserve the behavior people already depend on? Does it create operational risk? 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? Those questions are not solved by generating code faster. They are solved by engineering discipline.

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

That is where teams get into trouble. The code appears quickly, so people start treating the work as if it is almost done. A ticket moves, a pull request appears, the demo looks closer, and the output feels like progress. But the system has not accepted the work yet. The reviewer has not understood it, the tests have not proven it, the deployment path has not carried it, production has not absorbed it, and the customer has not lived with it. The first draft is not the work. It is the beginning of the work.

AI Rewards Clear Thinking

Good AI use usually starts before anyone writes a prompt. It starts with understanding the problem. What are we trying to change? What behavior must stay the same? What constraints matter, what systems are involved, and what risks are we trying to avoid? What would prove that the change works, and what should we absolutely not touch? That is not prompt engineering magic. That is engineering.

The reason some people get better results from AI is not that they found a secret phrase. It is that they know how to communicate the work. They can describe the boundary, explain the context, identify the tradeoffs, and tell the difference between a plausible answer and a useful one. AI rewards that.

A good engineer can ask AI to generate a first pass at a small helper function and quickly recognize whether the shape is right. They can ask for test cases and spot which ones are meaningful and which ones are just decorative. They can ask for a refactor and keep the change inside a safe boundary. The speed comes from judgment.

AI is useful because it removes friction from work the engineer already knows how to evaluate. It helps with typing, scaffolding, comparison, summarization, and exploration. It can get you unstuck and give you another angle, and it can make boring work less expensive. What it does not do is remove the need to know what good looks like, and that is the line people keep trying to cross.

AI Exposes Vague Requirements

If the requirement is mushy, AI will happily produce a mushy answer. That is not a defect in the tool. That is what happens when unclear intent meets a system designed to produce something that sounds reasonable.

Imagine asking AI to "add support for refunds" in a real product. That sounds simple until you ask the real questions. Who can issue a refund, and can it be partial? What happens after settlement? What systems need to be notified, and what gets logged? What happens if the payment provider accepts the refund but the local database update fails? What does customer support see, and what does finance need? What happens if the user retries, what permissions apply, and what audit trail is required? The hard part was never the syntax. The hard part was the missing context.

AI can generate code before any of those questions are answered, and that is exactly the danger. It can make incomplete thinking look like implementation, and it can turn an unresolved business problem into a pull request. Then the cost moves. It moves to the reviewer who has to find the missing assumptions, to QA if QA still exists as a separate checkpoint, to support when the edge cases show up, to the incident team when the failure mode hits production, and to the customer when the system behaves in a way nobody thought through. The cost does not disappear because AI produced the first draft faster. It just lands somewhere else.

AI Makes Small, Well-Bounded Work Faster

There are places where AI is genuinely useful, and we should not pretend otherwise. Small, well-bounded tasks are often a great fit. Generate unit tests for this function. Explain what this module appears to do. Convert this repetitive pattern into a helper. Draft documentation from this code. Suggest edge cases for this validator. Summarize this diff before I send it to review. Create a first pass at a migration script that I will inspect carefully.

Those are useful workflows because the boundary is clear and the validation path is close. The engineer can compare the output against the intent, the tests can run, the diff can be reviewed, and the blast radius is understandable. The result is not trusted because it came from AI. It is trusted because it passed through the same discipline as any other change.

That is where AI feels like real leverage, because it speeds up work without weakening ownership. The engineer is still thinking, still reviewing, and still deciding. They are using AI to move faster through known terrain, not to pretend unknown terrain is safe. That difference matters.

AI Makes Large, Vague Work Riskier

The larger the change, the more context matters, and that is where AI can become dangerous. Not because it is useless, but because it is confident. It will produce something, it will usually produce something that looks structured, and it may even produce something that compiles. None of that is the same as being correct.

Changing authorization logic is not the same as generating a helper function. Modifying a deployment workflow is not the same as formatting a response object. Refactoring legacy code nobody understands is not the same as renaming a local variable. Touching shared data contracts is not the same as cleaning up a private method. The more context the task requires, the more dangerous confidence becomes.

AI can give you a plan for a large change. It can help you identify areas to inspect, suggest tests to write before touching the code, and help you reason through risk. Those are good uses. But using AI to blast through a poorly understood system is not speed. It is gambling with better autocomplete.

Most fragile systems are fragile because they carry hidden history. There was a production incident. There was a customer commitment. There was a data migration that only half-finished. There was a dependency nobody wrote down, a vendor behavior that forced an ugly workaround, and a release night that went badly and left scar tissue still sitting in the code. AI does not automatically know that history, and if you do not know it either, you are not moving faster. You are moving blind.

The AI Did Not Merge the Pull Request

This is where accountability has to land. The AI did not merge the pull request. You did. That sentence needs to be uncomfortable, because it cuts through a lot of excuses.

It is easy to blame the model when AI-generated code causes problems. The model missed an edge case, misunderstood the architecture, invented an assumption, or wrote code that looked reasonable but did not fit the system. All of that may be true, and it also does not matter as much as people want it to. The AI did not approve the design, decide the tests were good enough, or skip the rollback plan. It did not ignore the strange diff in the authorization layer, and it did not decide that a large, hard-to-review pull request was acceptable because the ticket needed to move. A person did that.

This is the part of AI-assisted engineering that teams need to get serious about. AI can generate work, but it cannot own the consequences of that work. The engineer still owns the change, the reviewer still owns the review, the team still owns the system, and the organization still owns the customer impact. AI does not remove accountability. It makes accountability more important.

When a human writes bad code, we expect the engineering process to catch it. We expect tests, review, deployment discipline, observability, and rollback paths to reduce the blast radius. AI-generated code should not get a weaker standard just because it appeared quickly. If anything, it should get a stronger one. The faster code appears, the more careful we need to be about what we accept. Fast drafts are useful, but fast merges are dangerous when nobody understands what changed.

This is where AI makes bad habits louder. If you already treat pull request review as a rubber stamp, AI will help you rubber-stamp more code. If you already tolerate vague requirements, it will turn vague requirements into implementation faster. If you already avoid tests, it will help you produce untested code with confidence. That is not an AI problem. That is an ownership problem with better tooling.¹

The Review Burden Changes

AI does not remove review. In many cases it makes review more important. A reviewer looking at AI-assisted work has to do more than check whether the code is syntactically clean. They have to understand whether the change belongs in the system, and they have to look for invented assumptions, unnecessary scope, missing edge cases, weak tests, and subtle behavior changes.

That is especially true when the pull request is larger than it should be. AI makes it easy to generate a lot of code, but that does not make the code easy to review. A large diff is still a large diff, a scattered change is still a scattered change, and a reviewer still has limited attention, limited context, and limited time. If AI turns a small task into a kitchen sink pull request, it has not helped the team. It has shifted work from the author to the reviewer, and that is cost transfer, not productivity.

Good AI use should make review easier, not harder. It should help produce smaller changes, clearer tests, better explanations, and cleaner boundaries, and it should help the author show their work. Bad AI use does the opposite. It produces a pile of plausible code and asks the reviewer to become the safety net for every assumption the author did not check. That is a bad bargain.

Tests Matter More Now

The faster code appears, the more important it is to know whether it works, which means automated validation becomes more important, not less. Unit tests, integration tests, contract tests, static analysis, type checks, security scans, deployment checks, feature flag validation, and rollback practice all matter. None of them become obsolete because AI can generate code. They become more valuable.

A team that uses AI well should be investing in stronger guardrails, not because AI is uniquely bad, but because AI can increase the volume and speed of change. More change moving faster through a weak validation system is not progress. It is risk. The answer is not to slow everything down by hand. The answer is to improve the system: shorter branches, smaller pull requests, better tests, better CI, clearer ownership, safer deployments, real rollback paths, feature flags where they make sense, and observability that tells you whether the change is behaving in production. Boring production is still a feature.² AI does not change that. It makes it more obvious.

Local Speed Can Become System Drag

One of the easiest mistakes to make with AI is measuring the wrong thing. If an engineer completes their part faster, it feels like a win. Maybe the code was generated in minutes instead of hours, maybe the ticket moved sooner, maybe the first draft appeared before lunch. But engineering is not measured only by how fast code appears. The question is what happened to the whole system.

Did review get harder? Did rework increase? Did defects go up? Did support get more noise? Did the deployment become riskier? Did the team understand the change less? Did the customer feel more pain? Local speed can become system drag.

This is a familiar pattern in software. One part of the process optimizes for itself and pushes cost downstream. Development moves faster, but QA absorbs the pain. Feature work moves faster, but platform teams absorb the operational risk. Release dates get hit, but support inherits the mess. AI can make that pattern worse if we are not careful, because the individual may feel faster while the team gets slower.³

That is why the better question is not whether AI saved time. The better question is where the time went. If AI reduces repetitive effort and keeps the work understandable, testable, deployable, and supportable, then it helped. If it moves the effort to reviewers, testers, operators, incident responders, or customers, then it did not save time. It hid time, and hidden cost is still cost.

AI Is a Discipline Test

I am not anti-AI. I think it can be incredibly useful in software work. I use it, 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 does not compensate for weak discipline. It exposes it.

If your team already has clear ownership, good testing habits, short-lived branches, reliable deployment paths, and a culture of careful review, AI can give you leverage. It can help you move faster through work that already has structure around it. If your team depends on tribal knowledge, manual testing, giant pull requests, fragile deployments, and hero engineers who know where the bodies are buried, AI may just make the whole thing noisier. It will push more work into a system that was already struggling to absorb change safely.

AI is not a substitute for engineering discipline. It is a test of engineering discipline, and that is the mental model I keep coming back to. AI will make you faster at whatever you already are. If you are careful, it can help you move carefully at higher speed. If you are sloppy, it can help you create sloppy work faster than your team can clean it up.

That does not mean people should avoid AI. It means they should use it with ownership. Use it to explore, to draft, to test your thinking, to find edge cases, to explain unfamiliar code, to make the boring parts cheaper, and to improve the work before another human has to review it. But do not use it to skip understanding, to skip tests, to skip review, or to skip accountability. When the code ships, the model is not on call. You are.

The Work Is Still Yours

AI will speed you up. That is not the question. The question is what it is speeding up. If it speeds up clear thinking, careful implementation, useful tests, smaller pull requests, better documentation, and safer delivery, then it is real leverage. If it speeds up vague requirements, weak validation, giant diffs, shallow review, and production surprises, then it is not making you better. It is making your bad habits louder. That is the line.

The tool can help you move, but it cannot decide whether the movement is progress. It cannot own the consequences, it cannot care about the customer, and it cannot sit in the incident call and explain why nobody understood the change they approved. The AI did not merge the pull request. You did.