This is for the engineers who care about the code they write.
For the ones who change a name because the old one lies. Who delete a clever abstraction because it will make the next person's job harder. Who read the error path, ask what happens on the third retry, and feel uneasy when the code works but the system does not make sense.
If the current conversation about artificial intelligence has made you wonder whether any of that still matters, I understand.
You are watching machines do in seconds what took you years to learn. They write functions, explain unfamiliar repositories, find bugs, generate tests, translate between languages, and produce a confident answer before you have finished describing the question. Meanwhile, the internet offers a daily referendum on whether software engineering remains an occupation.
That is uncomfortable. It should be. Something real is changing.
The fear is not imaginary
Some programming jobs will disappear. Some teams will become smaller. The traditional path into the profession will change because many of the tasks we once gave to junior engineers are exactly the tasks these systems handle well.
Anyone who promises otherwise is protecting an argument, not telling the truth.
But there is a mistake inside the question Can AI write code? It treats code production as though it were the whole job. It never was.
Code is the residue of a decision. It is not the decision itself.
AI is making code cheaper, faster, and more abundant. That threatens the scarcity of code. It does not make engineering judgment less valuable. In many systems, it makes the absence of judgment much more expensive.
Programming was never typing
The programmers I trust most are not valuable because they remember the most syntax. They are valuable because they can enter a confused problem domain, listen carefully, and discover what is actually happening.
People rarely arrive with coherent instructions. They arrive with symptoms, incentives, history, deadlines, and contradictions. The customer wants flexibility. Operations wants predictability. Compliance wants proof. Finance wants it this quarter. The existing system contains ten years of decisions that nobody wrote down.
The engineer's job is to decide which constraints are real, which trade-offs are tolerable, where the system should bend, and where it must refuse. Then the engineer has to express those decisions precisely enough that a machine can execute them.
> GENERATE FEATURE
FEATURE GENERATED.
> SHOULD WE SHIP IT?
INSUFFICIENT CONTEXT.That is not an insult to the model. It is a description of the business.
Even a system that executes instructions perfectly moves the bottleneck upstream. It does not remove the need to understand the problem, decide what correct means, and accept responsibility for the result.
Thinking remains a business
As long as companies make consequential decisions under uncertainty, thinking will remain paid work.
I am not interested in winning a semantic argument about whether a model thinks. Models already perform useful work that we once described as requiring thought, and they will cross more of those boundaries. Betting your career on a fixed list of things AI cannot do is a losing strategy.
The durable distinction is not between a thinking human and an unthinking machine. It is between capability and responsibility.
A model can propose an answer. An organization still needs someone to determine whether the question is real, whether the evidence applies, whether the solution belongs in this system, and whether the consequences are acceptable. When the answer fails in production, somebody has to understand why and decide what happens next.
That person should use AI. I do.
The more capable the models become, the more ambitious I can be. I can explore unfamiliar approaches, compare architectures, interrogate assumptions, and turn a sketch into an executable experiment while the context is still fresh. I can spend less time manufacturing the first version and more time learning from it.
That does not make knowledge less valuable. It gives knowledge leverage. Expertise is not an identity badge; it is the accumulated ability to notice what a plausible answer left out.
The discomfort is older than AI
Bring a new engineer onto a team whose responsibilities overlap with yours. If that person is faster, deeper, or simply better at something you consider part of your identity, the discomfort is immediate.
The defensive response is to protect territory. The useful response is to leverage, extend, and learn. I have always grown faster beside people who could do something I could not.
AI activates some of the same insecurity. It reveals the parts of our status that came from doing something other people could not easily do. Some of that status will disappear, and perhaps it should.
The analogy has a limit. A model is not a colleague. It does not earn trust, take the pager, argue for a trade-off, apologize to a customer, or live with the consequences of its recommendation. It has capability without responsibility.
But the wise response is similar: learn what the new capability makes possible. Use it to extend your reach. Let it expose the gaps in your understanding. Refusing a capable tool will not preserve the craft; it will only narrow what your craft can do.
Abundance makes care more important
When code was expensive to produce, friction placed a natural limit on how quickly a bad idea could spread through a system. That limit is disappearing.
A team can now generate functions, tests, documentation, migrations, and abstractions faster than it can understand them. The result can be a coherent-looking mess: locally correct, globally confused, and far too large for anyone to hold in their head.
This is where the engineer who cares becomes more important, not less.
What are we adding? What are we making true? Which invariant does this preserve? What will the next person infer from this name? What happens when the dependency is slow, the message arrives twice, or the customer does the thing the specification says they never do?
Could the system become better if we declined to build the feature?
The great engineer of the AI era may write fewer lines personally. More of the value may live in rejected branches, removed abstractions, sharpened requirements, and tests that catch the convenient lie. The work becomes less about producing code and more about maintaining the integrity of the system.
Care is not sentiment. It is operational discipline.
For the engineers who still care
Do not mistake the shrinking distance between an idea and its implementation for a shrinking need for engineers. The space available to your judgment just became much larger.
Do not cling to an identity built around typing things other people could not type. Hold on to the deeper parts: curiosity, taste, precision, the ability to make a problem clear, the courage to say no, and the insistence that a system remain understandable after you leave it.
Learn the tools. Use the strongest models you can. Let them surprise you. Let the discomfort show you where your identity became attached to the mechanics of the work instead of its purpose.
But do not hand over responsibility.
The machine may become extraordinarily good at producing an answer. You still have to decide whether that answer deserves to become real.
Thinking is still the job.
So is caring what happens after.