AI Won't Replace Engineers. Bad Engineers Will.

I was managing a team when I watched a good engineering debate die in a single sentence.

Two engineers were arguing about how to structure something in React. I don't remember the exact question anymore, and that's the point: it was an ordinary, everyday disagreement, the kind that happens a dozen times a week on any team that's actually building things. What I do remember is that both of them were right. Not partially right, not right-in-spirit. Each one had a piece of the answer the other didn't have, and if either of them had stopped talking long enough to hear it, the best solution was sitting in the middle, waiting to be assembled from parts.

They never got there. One of them pulled out his phone, typed for a few seconds, and said: "Well, I just asked ChatGPT and it said..."

And that was it. The debate was over. Not because anyone was convinced. Because a third party with no context, no stake in the codebase, and no idea what either engineer actually knew had handed down a verdict, and the room accepted it as the tiebreaker.

I've thought about that moment more than almost anything else that happened on that team. Because that engineer wasn't lazy. He wasn't dumb. He wasn't even wrong about what the model said. He just fundamentally misunderstood what the tool in his hand was for. He thought it was there to end the thinking. It was there to extend it.

That misunderstanding is going to sort this profession into two groups over the next decade, and it has nothing to do with who's better at writing code.

We've been here before

Every generation of engineers gets a tool that makes the previous generation's hard part trivial, and every time, the same argument breaks out about whether the job is over.

Early in my career there was a guy on the team, I'll call him Dennis, who was the human documentation. If you needed to know why a particular socket call behaved differently on one platform, or what the undocumented flag on some vendor library actually did, you walked over to Dennis. He'd lean back, close his eyes for a second, and tell you. He wasn't the best designer on the team. He wasn't the fastest. But he was indispensable, because he remembered things, and remembering things was scarce.

Then Google got good, and Stack Overflow showed up, and inside of about two years Dennis was just a guy. Everything he knew was a search away. The kids who couldn't have recited a single system call were suddenly matching him, because they didn't need to recite anything. They needed to know what to type.

The old guard grumbled that these kids couldn't write code without an internet connection. They were right, and it didn't matter.

What mattered was what happened next. Once the answers were free, the value moved to the questions. I watched one junior engineer paste an error message into Google, take the top answer, apply it, and break something else, because the top answer was for a different version of the library and she didn't know enough to notice. I watched a senior engineer take the same kind of error, ignore Google entirely for ten minutes, stare at the stack trace, and then search for something completely different, a phrase that didn't appear anywhere in the error, because he'd figured out what was actually going wrong. Both of them had the same tool. One of them knew what to ask.

Google didn't make the job easier. It made memory worthless and understanding priceless. It took the mechanical part off the table and left the creative part exposed.

AI is doing the same thing, one level up. Stack Overflow gave you the answer to a question. AI gives you the implementation of a design. And once the implementation is nearly free, the only thing left to compete on is the design. Which is to say: the thinking. Which is to say: the art.

Computer science is an art

That word makes engineers flinch, so let me be precise about it.

The things we celebrate in this field were never acts of repetition. Nobody remembers the person who implemented the ten-thousandth CRUD app cleanly. We remember the people who saw something nobody had seen before. The insight that you could treat a program as data. The realization that a network could route around damage if you gave up on central control. The idea that a spreadsheet cell could hold a formula and recompute itself. None of those were answers to existing questions. They were new questions, asked by people who looked at the same problem as everyone else and noticed something different.

But it doesn't have to be famous to be art. The best example I ever saw was small.

We had a reporting system that was falling over. Nightly jobs that used to take an hour were taking six, then eight, then not finishing before the business day started. The team had a plan: shard the database, add a queue, rebuild the aggregation layer. Three months of work, maybe four. Everyone had agreed. The design doc was written. We were a week from starting.

Then a mid-level engineer, quiet, not someone anyone would have called a star, asked in a planning meeting: "Who actually reads these reports?"

Silence. Somebody said the finance team. She asked which ones. Nobody knew. She spent an afternoon pulling access logs. Of the forty-some reports the nightly job generated, six had been opened in the last quarter. The other thirty-plus were being computed every night for an audience of nobody, left over from teams that had reorganized twice and features that had been retired.

We deleted them. The job went back to forty minutes. The shard project was cancelled. Four months of engineering evaporated because one person asked a question that wasn't on the whiteboard.

That's the art. Not the aesthetics of clean code, though those matter. The art is in seeing. It's in looking at a system and perceiving a shape in it that isn't visible to anyone who's just following the established pattern. Everyone in that room was fluent in sharding and queues. Everyone knew the right answer to "how do we make this job faster." She was the only one who noticed that it was the wrong question.

Most engineering education, and most engineering culture, trains the opposite instinct. Learn the patterns. Apply the patterns. Don't reinvent the wheel. There's wisdom in that, and there's also a trap. Patterns are compressed answers to old questions. They're enormously useful right up until the question changes, and then they become the thing preventing you from seeing that it changed.

The engineers who have real impact know the patterns well enough to know when to abandon them. They're fluent in the old answers and not loyal to them. When they hit a problem, their first move isn't to reach for the matching pattern. It's to look at the problem long enough to understand what it actually is, and to ask whether the obvious question is even the right one.

That skill has always been the rarest and most valuable thing in this profession. It was rare when knowledge was scarce. It was rare when Google made knowledge free. And now that AI has made implementation nearly free too, it is the onlything left that's rare.

What AI actually changed

AI didn't make engineering easier. It moved the bottleneck.

For the whole history of this field, an engineer's time went mostly into the mechanical translation of ideas into working code, and an engineer's value came from the ideas. The most expensive mistakes were never typos. They were bad data models, wrong abstractions, unexamined assumptions about how the system would be used, edge cases nobody imagined until production imagined them for us. Every experienced engineer has a story about a project that was doomed before the first line was written. The code was fine. Sometimes the code was great. It was great code implementing a bad idea, and great code implementing a bad idea is just a well-organized failure.

We tolerated that inversion because typing was the constraint. A human can only write so fast, so the hours went where the hours had to go, and the thinking got squeezed into what was left.

Now the constraint is gone. Hand a model a clear, finished design and it will implement it faster and often more cleanly than a tired human at the end of a sprint. The translation step, the thing that ate most of the calendar, collapsed. And that means the leverage on every hour of thinking just went up by a multiple it has never had before.

I felt this for the first time on a project of my own. I'd spent the better part of two days on the design: what the system needed to do, what it explicitly wouldn't do, how it fit with what already existed, where it would break under load, what the interfaces looked like. I wrote all of it down, more for myself than anyone else, because writing a design is how you find the holes in it. By the time I was done I had maybe four pages.

Then I handed those four pages to a model and asked it to build the thing.

It took about forty minutes, including my review. Forty minutes for what I would have budgeted a week and a half to write by hand. And the code was good, not because the model is a genius but because there was nothing left for it to guess. Every decision had already been made. It was doing translation, and translation is what it's for.

That was the moment I understood what had actually changed. Not that the tool was fast. That the two days of thinking were now worth ten times what they'd been worth before, because they were no longer followed by a week and a half of typing that diluted them.

This is where the profession splits.

One kind of engineer looks at this and sees relief. Finally, something to take the grind off my plate. They keep doing the job the same way, just faster. Same shallow requirements, same half-formed design, same "we'll figure out the edge cases when we hit them," except the code arrives in seconds. They ship more. They feel productive. And they are producing, at volume, exactly the well-organized failures I described, because the tool faithfully implemented a design that nobody bothered to finish.

The other kind of engineer looks at the same shift and sees an opening. If the coding is nearly free, the entire job is now the part that was always the interesting part. The seeing. The questioning. The design. They don't do less work. They do the work that was always the most valuable, and they let the tool handle the translation.

The first engineer's job got easier. The second engineer's job got bigger. Only one of those is a career.

"Easier" is the tell

I want to be careful about who the villain is here, because it's not who people expect.

It's not the lazy engineer. Lazy engineers have always existed and have always been managed out, or promoted somewhere they can't touch the code, or both. AI doesn't change that story much.

The engineer I'm worried about is the one who's trying. Who shows up, cares about the work, wants to be good at it, and has absorbed the idea, from marketing, from management, from the ambient hype, that AI exists to make their job easier. That framing sounds harmless. It's poison.

Because "easier" means: I get to skip steps. "Easier" means: I don't need to understand this as deeply, the model does. "Easier" means: when two smart people disagree, I can ask a machine and go with whatever it says.

I watched the full cost of that play out a few months after the React debate. A different engineer, same team, got a ticket to add rate limiting to an internal API. He asked a model how to implement rate limiting, got back a clean, textbook token-bucket implementation, dropped it in, tested it, shipped it. The code was correct. It was well-structured. It had unit tests. It was, by every measure a code review would catch, good work.

Three weeks later we found out the API was being called from a batch job that had been running fine for two years and was now silently failing halfway through every night, because the rate limiter was doing exactly what it was designed to do. Nobody had asked who called the API. Nobody had asked whether "rate limiting" was even the right framing, or whether the actual problem was one badly-behaved client that should have been fixed at the source. The model answered the question it was given, perfectly. The question was wrong, and the polish of the answer is what kept anyone from noticing.

That's the React debate again, in a different costume. The engineer who reached for ChatGPT wasn't being lazy. In his mind he was being efficient. Why spend twenty more minutes arguing when you can get an authoritative answer in twenty seconds? But the model's answer wasn't authoritative. It couldn't be. It didn't know our codebase, our constraints, the reasons behind the existing patterns, or the specific tradeoff those two engineers were circling. It gave a generically reasonable answer to a generic version of the question.

More than that: it answered the wrong question. The engineers weren't really arguing about React. They were arguing about a tradeoff that lived in our system, and neither of them had fully named it yet. The debate was the process of naming it. Another ten minutes and one of them would have said the thing that reframed the whole disagreement, and both of them would have seen the better third option. That reframing, that moment of seeing what nobody had seen, was the entire value of the conversation. The model can't do that, because it doesn't know what it doesn't know about your situation.

What we lost wasn't just the better solution. We lost the practice of holding two valid ideas in tension until something new emerges. That's not a soft skill. That's the muscle that produces every real insight this field has ever had. And he'd just taught himself, and everyone watching, that you don't need to build it anymore.

The question is the work

Here's the thing Google taught us that most people forgot: it was never about knowing the answer. It was about knowing what to ask.

A junior engineer with a search engine and a senior engineer with a search engine have access to the same information. The senior engineer gets ten times more out of it, because they know which question will actually unlock the problem. They know that "why is this slow" is a useless query and "why does this allocation happen inside the loop" is a precise one. They know when the top-voted answer is a trap. They know when the right move is to close the browser and go look at the problem again, because the question they've been asking is the wrong shape.

AI raises the stakes on this enormously. The model will answer any question you ask it, instantly, confidently, and with the same polish whether the question was good or terrible. It will design the architecture if you ask it to. It will decide the requirements if you ask it to. It will tell you which side of the React debate wins. And every one of those answers will look finished. That's the danger. Google at least made you do the work of reading and evaluating. AI hands you something that looks done.

So the entire craft now concentrates in one place: before the prompt. In the looking. In the part where you sit with the problem long enough to notice that the obvious framing is wrong, that the requirement everyone accepted is actually two requirements in conflict, that thirty of the forty reports have no readers, that the API has a caller nobody remembered. That's where the leverage lives. That's the only part the tool can't do, because that's the part that requires seeing something nobody handed you.

The engineers who understand this are about to have the best decade this profession has ever offered. Everything that used to stand between a good idea and a working system is dissolving. The mechanical grind that consumed most of a career is becoming a footnote. What's left is the art: seeing clearly, asking precisely, and imagining what should exist.

The engineers who don't understand it will have the same tools and get the opposite result. They'll produce more code than anyone in history and less of it will matter. Their mistakes will be implemented at the speed of light. Their unexamined designs will ship on time. And because everything looks finished, nobody will notice until it's expensive.

The debate should have continued

I keep coming back to that React argument because it's such a small, unremarkable moment and it contains the whole thing.

Two people with real expertise, disagreeing in good faith, each holding a piece of something neither of them could see yet. The right move was to keep going. To listen harder. To find the parts of the other argument that were true and build a solution that honored both. That's the highest-leverage thing an engineer can do, and no tool on earth can do it for them, because no tool on earth is standing where they're standing.

Instead the tool got used as an off-switch for the thinking. And the worst part is that it felt like the smart move. It felt modern. It felt like using AI the way you're supposed to.

It wasn't. Using AI the way you're supposed to means doing the seeing first, harder and more carefully than you ever had to before, precisely because the seeing is now the only part that's scarce. It means treating the model as an extraordinary implementer of ideas you are responsible for having. It means understanding that when someone says AI will make your job easier, they're describing a trap.

Computer science was always an art. We just buried the art under so much typing that most people forgot. The typing is gone now. Everyone's about to find out who was doing the art all along.