If you read the headlines, you would think the engineering job evaporated sometime in the last two years and got replaced by a person typing prompts into a box. That is not what happened for me, and I would be misrepresenting the work if I pretended otherwise. AI did not write my product. It did something more useful and more subtle. It moved where I spend my hours, changed what a code review is actually for, and collapsed the time between an idea and a thing you can click on. The job is still engineering. It just rebalanced.
I want to give an honest account because the honest version is more helpful than either of the two stories you usually hear. One story says AI changed nothing and it is all hype. The other says AI changed everything and engineers are obsolete. Both are wrong in the same way: they treat coding as if it were the whole job. Coding was never the whole job. AI is very good at the part that was always the smallest part, and that turns out to matter more than the optimists or the skeptics expected.
Where the hours actually moved
The first thing that changed was the distribution of the working day. Before, a meaningful slice of every task was mechanical: writing the boilerplate, wiring up the obvious plumbing, translating a known pattern from one part of the codebase to another, looking up the third argument of a function you use twice a year. None of that was hard. It was just slow, and it sat between you and the part of the problem that needed a brain.
That mechanical layer is where AI coding tools earn their place. I now hand off most of the rote translation work and spend the recovered time on the things that were always the real job: deciding what to build, designing the interface between systems, reasoning about failure modes, and reading enough of the surrounding code to know whether a change is safe. The work got harder on average, not easier, because the easy parts got automated away and what remained was the dense middle. I consider that a good trade. I would rather spend my hours thinking than typing.
The number I watch is not lines of code, which is a terrible metric that AI makes worse. It is the time from a well-specified task to a reviewed, merged, shipped change. For a certain class of work, the well-understood, pattern-following changes, that time drops noticeably. For the genuinely novel work, the new subsystem nobody has built before, it barely moves, because the bottleneck there was never typing speed. It was understanding, and understanding does not come from a model that has not seen your problem.
What reviews catch now, and what they have to catch harder
The second real shift is what a review is for. When you write every line yourself, reviewing is partly about catching mistakes you already half-knew you might have made. You had the context. You had wrestled with the code, so the review is a second pass over a problem you already understood.
AI-generated code breaks that assumption in a specific way. The code often looks confident and reads cleanly, because models are good at producing fluent, plausible code. Fluent and correct are not the same thing. So the review shifts from style and obvious bugs, which the tools and linters now handle, toward harder questions. Does this code actually do what the task needed, or what the model assumed the task needed. Does it handle the edge case that only matters in production. Is it subtly wrong in a way that passes the happy-path test. You have to engage more deeply now, not less, because it is easy to accept code from a suggestion without ever fully internalizing it.
One rule I hold to and it has held up well: you own the code you merge, regardless of who or what wrote it. If a model produced a function and you approved it into the codebase, it is yours. You are the one who gets woken up when it breaks, and "the AI wrote it" is not an explanation. That single principle keeps the productivity gains honest, because it forces you to read and understand what you accept rather than treating generated code as someone else's problem.
Example: imagine a generated data-migration helper that looks perfect, passes every test, and reads clean. It assumes a timestamp is always present. In your data it usually is, which is why the tests pass. But in a rare record it is null, and that path silently drops rows. A person writing that code might have paused to ask whether the field was guaranteed, because they would have felt the uncertainty. The model does not feel anything. It produces confident code over an assumption it never surfaced. The only thing that catches a bug like that is a reader asking the question the code did not raise. That is the new shape of the job.
Prototyping got fast in a way that genuinely changed product
The place AI helped most was not the part people expected. It was prototyping. The distance between "I think this interaction would feel better" and "here, click on it" used to be a day or two of someone's time, which meant most ideas never got built far enough to be evaluated honestly. People argued about mockups instead of trying things.
Now you can stand up a working, throwaway version of an idea in an afternoon, with real interactions, and react to the thing instead of to a description of the thing. That changed how I decide more than it changed the codebase. The call gets made in front of a working prototype instead of in the abstract, and prototypes are far more honest than slides. A good share of what I build now starts as a quick AI-assisted prototype thrown together to test whether an idea is any good, and a fair number of those end with me realizing the original idea was wrong, which is exactly what prototypes are for.
The discipline that keeps this from turning into a mess is that prototype code is prototype code. It is built to be thrown away, and we throw it away. The danger with fast generation is that something that works gets quietly promoted into production because deleting it feels wasteful. We treat the prototype as an argument, not an asset. The understanding it produces is what we keep. The code goes in the bin.
What did not change, and why that matters
It would be easy to write only the optimistic half of this, so here is the part that did not move. AI did not improve our judgment about what to build. It did not understand our users. It did not make architectural decisions, because architecture is about tradeoffs across years and constraints a model cannot see from inside a file. It did not take ownership, debug a gnarly production incident from first principles, or know which of two correct-looking designs would age badly. The hard core of engineering, the part that was always the point, is untouched.
There is also a real failure mode I have watched at other companies, and we work to avoid it. When generation is cheap, teams produce more code, and more code is more liability, not more value. The temptation is to measure output by volume because volume is now easy. We measure it by whether the system got simpler and more reliable, which is a much harder thing to fake. AI makes it trivially easy to add. It does nothing to help you decide what to remove, and deciding what to remove is most of good engineering.
The other quiet risk is to how people learn the craft. The mechanical work that AI now absorbs was, for a long time, how new engineers built their instincts. You wrote the boilerplate badly, someone corrected you, and you internalized the pattern. If the tools do all of that, you can prompt your way to working code without ever building the mental model underneath it, and that model is exactly what you need on the day the code breaks. It is why I still do some of the rote work by hand, not for speed, but because the struggle is where the understanding comes from. That is a deliberate choice, and I think more people will arrive at it.
The skills that got more valuable, not less
One of the more interesting effects, and one I did not predict, is which engineering skills became more valuable rather than less. The conventional fear is that AI flattens the value of skill, that if a model can write the code then knowing how to write code matters less. In our experience the opposite happened. Certain skills got dramatically more valuable, because they are the skills required to direct and check a fast, confident, occasionally wrong assistant.
The first is the ability to specify precisely. AI is only as good as the problem you hand it, and a vague request produces fluent code that solves the wrong problem. The engineers who get the most out of these tools are the ones who can state, exactly, what they need and what the constraints are, which is the same skill that makes a good engineer good at everything else. Sloppy thinking used to produce sloppy code slowly. Now it produces sloppy code fast, which is worse, and the only defense is clarity about what you actually want before you ask.
The second is reading code well. We have always undervalued reading relative to writing, and AI inverts the ratio. You now read far more code than you write, because you are evaluating generated code, understanding unfamiliar systems with AI assistance, and checking work where whoever accepted it may not fully grasp what they accepted. The person who can read a piece of code and quickly see what it actually does, including what it fails to do, is worth more than ever. That is a teachable skill, and worth practicing deliberately rather than assuming it comes for free with writing experience.
The third is taste about simplicity. When adding code is nearly free, the scarce judgment is knowing what not to add and when the simplest solution beats the clever one the model offered. Restraint is the skill AI cannot supply, and it keeps a codebase alive over years. The engineers I value most are not the ones who produce the most with these tools. They are the ones who produce the least code that does the most.
How we actually run it day to day
Practically, AI sits in three places in how I build. It assists in the editor for the rote and pattern-following work. It helps me explore and understand unfamiliar parts of a large codebase by answering questions about code rather than writing it. And it powers product features for the people who use Atlas, which is a different discipline with much higher reliability requirements, the kind of work I tend to write about most because shipping models you can rely on in production is harder than shipping a coding assistant for yourself. Each of those is held to a different standard, and conflating them is where a lot of teams get into trouble.
The thing I would tell anyone leading engineering is to stop asking whether AI will replace engineers and start asking where it moves their time, because that is the question that has an actionable answer. Aim the recovered hours at the parts of the job that were always undervalued: understanding, design, review depth, and removing complexity. Do that, and AI makes strong engineering stronger. Use it instead to produce more code faster and call that progress, and you will get exactly what you measured, which is a larger, more confident, harder-to-maintain pile of plausible code. I have tried to build the kind of consolidated, reliable product in Atlas that demands the first approach, and the practices followed from the product, not the other way around.
So no, AI did not write my software, and the people predicting that engineers are finished have, I think, never been close to the actual work. What it did was take the slowest, least interesting part of the job and shrink it, which left more room for the part that was hard all along. That is a real change. It is just not the change the headlines promised, and the honest version is the one worth planning around.