A few weeks ago I revisited a conversation between Simon Willison and Lenny Rachitsky about AI assisted software development. What struck me wasn't that the ideas were new. It was how familiar they already felt.
A year ago, a lot of AI coding still felt probabilistic. You'd ask for something, get 70% of the way there, then spend the rest of the session fighting the model. Sometimes the generated code worked. Often it only looked like it worked.
Recently, the ratio changed. Not perfectly, not magically, but enough that my workflow changed around it.
Building became cheap
A small feature that once took a day might now take an hour. A weekend project becomes an evening project. Framework exploration becomes low-risk enough that you actually try things.
The effect compounds because the cost of experimentation collapses alongside implementation. Instead of carefully choosing one direction before committing, you can explore several.
Compare quickly. The workflow shifted from "build carefully" to "generate multiple versions and evaluate." That sounds minor, but it changes the texture of engineering work.
I increasingly find myself generating different UI structures, different abstractions, different data flows, and occasionally different frameworks entirely. A few years ago, building three approaches to compare them would've felt wasteful. Now it often feels faster than overthinking the first decision.
The strange part is that implementation effort used to act as a natural brake. You'd avoid speculative work because rewriting was expensive. AI weakens that constraint.
Evaluation is the bottleneck
The hard part now isn't producing software artefacts. It's deciding which ones deserve to survive.
That's a different skill.
You can generate polished documentation, typed APIs, tests, architecture diagrams, deployment configs, and convincing UIs very quickly. What AI is very good at producing is software that looks complete. What it still struggles with is trustworthiness.
I've had projects where the first generated version felt almost suspiciously polished. Everything compiled. The README looked professional. The UI felt coherent. The tests passed. Then I actually used the software for a few days. That's when the cracks appear: awkward flows, brittle abstractions, hidden complexity, edge cases no one thought about, architecture that technically works but resists change.
The confidence problem becomes subtle because the generated output increasingly resembles production ready software.
"Looks finished" and "is trustworthy" are no longer closely correlated.
Work changed shape
I still spend most of my time thinking. Possibly more than before. Just differently.
The work increasingly looks like steering, evaluating, narrowing options, defining constraints, correcting direction early, and deciding when something is good enough. Less directly translating thoughts into syntax.
That doesn't make engineering easier. In some ways it makes it more cognitively dense. Running several agents in parallel sounds productive until you actually do it for hours. You end up context switching between partial implementations, reviewing divergent approaches, trying to remember which branch solved which problem.
There's also a strange optimisation trap. Because generating another version is cheap, it's easy to keep iterating: one more architecture pass, one more refactor, one more prompt, one more UI variation. At some point, the limiting factor stops being typing speed and becomes mental stamina.
The exhaustion isn't from writing code anymore. It's from continuously evaluating possibilities.
Estimation became weird
One thing I didn't expect was how much AI would distort effort estimation. Tasks don't scale linearly anymore. Something that would've previously taken 2 weeks might suddenly collapse into 30 mins because the model happened to align perfectly with the problem shape. Meanwhile a supposedly simple task can spiral because the generated abstraction drifted slightly off-course 20 prompts ago.
Variance exploded. That makes planning harder, not easier.
Traditional estimation assumed implementation cost was relatively stable. But once generation becomes probabilistic and iterative, timelines become much noisier. The frustrating part is that you often don't know whether a task is "easy now" until halfway through attempting it.
Judgment scales
The common framing is that AI reduces the importance of engineering skill. I don't think that's quite right. What seems to matter more now is judgment.
Senior engineers often benefit disproportionately because they already have architectural instincts, debugging heuristics, product judgment, and experience recognising fragile systems. The AI amplifies those instincts. Meanwhile, repetitive implementation work compresses hardest.
That doesn't mean junior engineers are obsolete. Onboarding into unfamiliar stacks is easier than it's ever been. But the value shifts away from producing code quickly toward evaluating quality, directing systems coherently, recognising hidden problems, and deciding what matters.
LLMs don't really have goals. They don't care whether the software becomes maintainable 6 months later. They don't notice when a product direction subtly stops making sense. Humans still provide intent.
AI reduces the cost of producing software. It does not reduce the need for judgment.
Still improvising
That's probably the part I feel most uncertain about. The tooling improved faster than the workflows around it.
We don't really have settled conventions yet for evaluating AI generated systems, deciding when generated tests are meaningful, managing multiple agents coherently, or balancing speed against trust. A lot of current practice still feels improvised. The workflows themselves are changing in real time.
The real shift
I don't think software engineering disappeared. I think implementation became less scarce.
For years, the dominant constraint in software was the cost of turning ideas into working systems. AI lowered that cost dramatically. The scarce things moved: judgment, taste, trust, validation, prioritisation, responsibility. The engineering work didn't vanish. The centre of gravity shifted.
Testing, evaluation, judgment, taste, direction: those were always important. They just used to be partially hidden underneath implementation effort. Now they're exposed.
That's also why software engineers are an unusually important early case study for AI disruption. Code is relatively easy to verify: either the system works or it doesn't. Other professions don't always have feedback loops that clean. If engineering already feels cognitively noisy despite strong validation mechanisms, I suspect other industries will experience even stranger transitions.
And I suspect that's the part that will last.