AI didn’t change the important questions.
It changed how quickly we have to answer them.
A post by Tim Toole about AI-assisted software engineering got me thinking. He describes three emerging camps: the purists who love the craft of programming and worry AI is taking something important away, the force multipliers who see AI as an incredibly capable pair programmer that helps them move faster, and the agentic camp, who increasingly view software development as directing autonomous systems rather than writing code themselves.
I think he’s right.
What struck me, though, wasn’t the differences between those camps. It was what they all have in common.
They’re all focused on how software gets built.
I’m increasingly interested in what happens after it’s built.
Whether code is handwritten, AI-assisted, or entirely agent-generated, the questions I care about haven’t changed. Does this make the architecture stronger or weaker? Does it increase or reduce cognitive load? Does it make the system easier to evolve? Does it improve survivability? What unintended consequences are we creating today that someone else will inherit six months from now?
Those questions existed long before AI, and they’ll still exist long after today’s coding models are obsolete.
AI didn’t repeal Conway’s Law.
It didn’t eliminate coupling.
It didn’t make distributed systems less distributed.
It didn’t make complexity disappear.
It simply made it dramatically cheaper to create software.
Unfortunately, it also made it dramatically easier to create complexity.
Every engineering decision creates consequences: performance, reliability, security, cloud cost, maintainability, developer experience, cognitive load, and even carbon emissions. We often treat these as separate problems with separate solutions, but they’re frequently different expressions of the same architectural decisions.
The more I work with AI, the less I think the bottleneck is writing code.
The bottleneck is engineering judgment.
AI didn’t make architecture less important.
It made architecture easier to ignore.
When code can be produced almost instantly, every architectural decision has the potential to spread farther and faster than ever before. Good decisions compound. So do bad ones.
Anyone can ask an AI to generate another service. Far fewer people ask whether another service should exist.
Anyone can ask for another abstraction. Far fewer people ask what that abstraction will cost the next engineer trying to understand the system.
Performance, reliability, cloud cost, security, maintainability, cognitive load, and even carbon emissions aren’t independent problems. They’re often different consequences of the same architectural decisions.
Engineering judgment is the ability to recognize consequence chains before the system becomes difficult to change.
The engineers who create the most value won’t necessarily be the ones who produce the most code. They’ll be the ones who consistently make better decisions—decisions that lead to systems that are simpler, more resilient, easier to understand, and easier to change.
AI may have changed how software gets written.
It didn’t change the important questions.
It changed how quickly we have to answer them.
AI made code abundant. Engineering judgment is still scarce.
No responses yet