The Engineer in the Age of AI: Why Judgment Is the New Craft

I have been hearing a lot recently the argument of “Just ship it. AI can change it later. Quality is secondary now” and I wanted to take a moment to think and answer that.

It sounds pragmatic on the surface. It sounds modern. It almost sounds like the natural next step. If the machine writes the code, then why would I spend an afternoon agonizing over a function name or a data model? Just ship and let the machine handle the next iteration.

But the more I sit with this argument, the more I think it gets the equation backwards. AI hasn’t made quality less important. It has made understanding the only thing left that’s actually scarce. And I want to walk through why I believe that.

The Cheap-Code Assumption

The “just ship” argument rests on a simple idea: if generating code is cheap, then any individual piece of code is cheap, and therefore disposable. Regenerate it if it breaks. Move on.

The problem is that code was never the expensive part. The expensive part has always been the decisions encoded in the code. The data model that has to live for five years. The abstraction that thirty other modules will depend on. The API shape that becomes a contract you can’t break without breaking customers. AI lowers the cost of typing. It does not lower the cost of being wrong about those decisions. If anything, it raises it, because wrong decisions now propagate faster and accumulate in larger volumes than they used to.

Shipping fast was always a virtue when it meant learning fast. It becomes a vice the moment it means not understanding what you shipped.

What I’ve Seen Happen When Quality Slips

I’ve watched this pattern play out enough times to recognize the shape of it.

A feature ships quickly. It works for the happy path. Two weeks later, a bug shows up in production. Something subtle, a race condition or a state update firing twice. The engineer asks the AI to fix it. The AI produces a plausible patch. The patch works for the reported case. But the engineer doesn’t actually understand the original code well enough to know whether the patch fixed the root cause or just suppressed the symptom. So they ship the patch anyway.

A month later, a related bug surfaces. Then another. The codebase now has three layers of AI-generated patches sitting on top of an AI-generated foundation that nobody fully understands. Not the original author, not the team, not the AI on its next pass. Refactoring becomes terrifying because no one knows what depends on what. Every change becomes a coin flip.

This isn’t hypothetical. This is what “quality doesn’t matter that much” actually buys you in month six.

The Quiet Risk: Becoming a Proxy

The more dangerous version of this drift isn’t technical, though. It’s cognitive, and I think it’s worth talking about openly because it creeps in slowly.

When you stop reading the code carefully, when you stop asking why is it written this way, when you accept the first plausible suggestion because it compiles and the tests pass, something quiet happens: you stop being the author. You become a proxy. A conduit. Someone who routes prompts into a model and routes its output into a repository, without the responsibility of judgment passing through you in either direction.

To make this concrete, let me tell you something I saw recently. A developer dropped environment variables straight into the window object, inside index.html of a React app. Someone pointed out the actual problem. Anything you paste into window gets served alongside the HTML to every browser that loads the page, so API keys, tokens, internal service URLs, all of it sits one DevTools open away from any visitor, indexable, cacheable, and out of your control the second the response goes out. And he didn’t stop to think. Didn’t open the docs. Didn’t go dig into why. He just went back to the AI, framed the question in a way that already carried the answer he wanted to hear, something along the lines of “this is fine, right?”, and the AI, being the AI, found a way to validate it. Problem “solved.” Except the problem was never the code. The problem was that his judgment had turned into an automatic rubber stamp, outsourced to a machine that won’t be sitting in the post-mortem when that ships as a security incident.

And it’s worth spending a paragraph on what “security incident” actually means here, because it’s easy to read this as purist nitpicking and move on. It isn’t. If that blob of variables contained an API key for an AI provider or a payment processor, somebody running a basic scanner finds it within minutes. There are bots crawling GitHub, CDNs, the Wayback Machine, archive.org, looking for exactly this kind of thing, and they start burning your quota before you’ve finished breakfast. You wake up to a five-figure bill and no clean way to prove it wasn’t you who used it. If it contained an internal service token, an attacker now has a map of your infrastructure and a way into it: endpoint, hostname, URL pattern, sometimes service version. If it touched anything customer-facing, congratulations, you’ve just entered breach-notification territory, with legal involved, compliance involved, and that very uncomfortable customer conversation that nobody wants to have. And the worst part, the one that actually hurts: you can’t “undo” it. You can rotate the key tomorrow morning, but every browser that downloaded that HTML, every CDN that cached it, every crawler that indexed it, they all have the old version, and you have zero control over what gets done with it. The secret stopped being a secret the moment the first user loaded the page, and that’s irreversible.

This is comfortable for a while. It feels productive. But it’s a transfer of agency, and with agency goes responsibility, and with responsibility goes the part of the job that actually grows you. The senior engineer five years from now won’t be the one who shipped the most AI-generated tickets in 2026. It’ll be the one who, while using AI heavily, still read every diff with intent, still pushed back when something felt wrong, still asked is this the right abstraction before accepting the one the machine offered.

If you outsource thinking, you don’t get to keep the parts of the job that depend on having thought.

Why “Knowing What’s Good” Matters More, Not Less

Here’s the part I think is easy to miss. The skill of recognizing good code is harder and more valuable now than it used to be, not easier.

When code is hand-written, you can usually trust that the author had a reason for each choice. The reason might be wrong, but it exists, and you can interrogate it. When code is AI-generated, every choice is statistically plausible by construction. It looks like code that has worked before, because it was trained on code that has worked before. But “plausible” and “correct for this system” are not the same thing. The AI doesn’t know that your team decided last quarter to stop using useEffect for data fetching. It doesn’t know that this particular component is rendered inside a virtualized list and can’t hold expensive state. It doesn’t know your domain.

You do. That knowledge, the accumulated context of your team, your codebase, your users, your constraints, is what makes a diff actually good rather than merely plausible. And the only way to bring that knowledge to bear is to read carefully, think slowly, and refuse to accept output you don’t understand.

Good practices haven’t become obsolete. They’ve become the filter between the AI’s surface plausibility and your system’s actual needs. Naming, separation of concerns, small functions, explicit dependencies, deliberate error handling. These aren’t rituals from a slower era. They’re what lets a human read a thousand-line diff and notice the one place where the model misunderstood the domain.

So What Does the Engineer Actually Do Now?

Most of what we always did, honestly, just at a different altitude.

We still design systems. We still decide which problems are worth solving and which are distractions. We still negotiate with product and design about scope. We still own the consequences when something breaks at 2 a.m. We still write the small handful of lines where the model would have produced something almost-right-but-not-quite, and those lines are often the ones that matter most. We still mentor, review, and shape the taste of the people around us.

What changes is the proportion. Less time typing boilerplate. More time reading, deciding, refusing, refining. Less mechanical, more editorial. And critically, the work of understanding, the patient effort of building a mental model deep enough that you can predict how a system will behave, has not been automated. It cannot be. The AI can describe code to you, but it cannot do the understanding for you, any more than reading a summary of a book can replace having read the book.

A Few Things I Try to Hold On To

If I had to compress this into the practical habits I try to keep, it would be these:

Read every line you commit. Not skim, read. If you don’t understand why a line is there, either learn until you do, or delete it.

Treat AI output as a draft from a fast but context-blind collaborator. It’s a useful starting point. It’s not the final answer.

Keep your craft sharp on purpose. Write something from scratch, by hand, every now and then. Solve a problem with the autocomplete off. The muscle atrophies fast and quietly, and you won’t notice it’s gone until you need it.

Push back on the “quality doesn’t matter” argument when you hear it on your team. Not as a purist, but as a realist. Ask what the codebase will feel like in two years if everyone operates that way. Then ask who is going to be expected to fix it.

And remember: you are the part of the system that holds the responsibility. The AI doesn’t get a support call at 8 p.m. in the middle of dinner with your family. The AI doesn’t deal with the customer who keeps pushing the same point. The AI doesn’t have to own the post-mortem. Whatever ships under your name ships with the stamp of your judgment on it, whether you actually exercised it or not.

That responsibility isn’t a burden AI is taking from us. It’s the thing the job has always been about, and now, more than ever, it’s the thing only we can do.