The Skills That Matter
The skills that a developer needs now — if they want to be an engineer — are the same skills engineers have always had. It's first-principles thinking. There was a time, before Agile, before Scrum, and before SAFe, when software engineers owned their stack. We weren't gatekeepers. We did research. We understood the full domain of what needed to be built. That's what product engineering means. And what we're seeing now is a return of that type of thinking.
For enterprises, it's not necessarily about the skills you hire for. It's about asking a more fundamental question: how do you structure your organization in a way that doesn't hide the best business context from your best engineers? If they have to pull from a Jira ticket queue and all the PMs have all the context in their heads, you're not going to get a great outcome.
Nobody Knows What Engineering Orgs Will Look Like
If anyone says they know how engineering organizations will look in a year or two, they're selling absolute bullshit. What I can say is: remember the Spotify Agile video? Squads, tribes, leads, guilds...it sounded beautiful on paper. And every company cargo-culted that into their organization without considering whether it was the right thing to do. Spotify was on a journey of figuring out what works. Everyone else just copied the destination without doing the experimentation.
Companies like Shopify and Block are now in the front seat of figuring out AI engineering. When one of those companies figures out the right thing and publishes a case study, everyone is going to copy it, rightly or wrongly.
What we've got right now is a bunch of companies taking huge risks. That could make them wildly successful or could kill them.
You Can't Skip the Journey
The people who are on the journey toward using autonomous agents successfully are the same ones who started thinking about containerization early. All that prep work from ten, twelve years ago—reproducible environments, proper testing—that's the precursor work to making coding agents work. There are many people who haven't even started that path, and they're going to try to skip straight to slapping an agent on it. If you run an agent without some form of verification, without backpressure in the inferencing loop, you get slop in, slop out.
By the time the company that just wants to do what Block did actually does it, Block is two years ahead. They've got the knowledge of what works, and what doesn't that they don't talk about publicly. You can't just bake a cake instantly.
The Problem with Dark Factories
People want dark factories — fully automated software production with no humans in the loop. To solve that, you have to solve the autonomous verification of software. And that is a hard problem.
The next issue is that enterprises will want to customize the dark factory to how they specifically do software. And if "how they do software" means they don't write tests, they've never heard of formal proofs — you're just going to get garbage in, garbage out. We call that a slop factory. And there will be plenty of vendors rolling software factories into enterprises, and we're going to hear a lot of noise saying AI doesn't work.
A software factory is essentially a CNC machine. Without training, many people will cut off their hands.
Programming Languages Will Converge, and the Next One Won't Be for Humans
I deeply suspect there will be a convergence of programming languages. And what comes next is not designed for humans. Programming languages are specs for machines; let's be clear about that. Markdown is not a spec.
All existing languages have been designed for human ergonomics, dumbed down because humans have to be able to adopt them. We don't need to do that anymore.
What comes next is either an old language that was considered too hard for humans but is good in the verifiability domain or an entirely new programming language designed for machines. And the spirit of that language is different: you can make breaking changes. You can do Python 2 to 3 and get everyone upgraded within a month because you can ship a migration agent that autocodes the upgrade overnight. You wake up, and it's done. You can just do things now at an intense pace.
Code Review Is Mostly Broken
Code review is not a binary thing. The nuanced take is reducing the need for human intervention as a framework. If you're changing billing logic, you should force a conversation about code reviews. If you're changing a database schema, same thing. But if it's a marketing copy update on your website, why are you asking for a human pull request review?
We've always said code review is for mentoring and knowledge sharing. But go ask a junior, go ask a woman in engineering how they feel about that. In most companies, it's mainly used for bullying. It's very rarely used for uplifting coaching conversations. The reality is you create a pull request, you DM on Slack asking for a review, and then you get a pile of comments about whitespace and tabs. That doesn't make sense anymore.
What still makes sense is using code review as a synchronization event for the team to know what's in the codebase as it evolves. That's valuable. But you can get there with a living, breathing architecture document that an agent maintains. The architecture side can be automated.
The human still has to decide what the architecture should be, but the burden of maintaining that vision in your head, the pain of teaching people, and ensuring it holds, that's automated now.
Agent Maintainability Is the New Code Quality
Why is one company having outlier success running agents against their codebase while another company using the same model is not? I think we're going to develop a new notion of maintainability: not maintainability by a team of people, but maintainability by the agent. These LLMs love to copy and paste patterns throughout the codebase. If you've got junk in your codebase, it will produce a lot more junk.
Code hygiene matters because agents are drunk, they will copy and paste bad patterns everywhere, the exact same way a junior would without understanding the why. Good hygiene is how you stop that.
Designing for agent maintainability over human maintainability will be essential going forward.
The Craft Is More Important Than Ever
A lot of the human capital toil is gone. The burden of being a principal engineer: having to repeat yourself again and again, the education, the teaching the why, not just the how, a lot of that toil is gone. But the craft is still very alive. The craft has never been about typing code into an IDE. And now these power tools, held the wrong way, will chop off your hand. It's way more important than ever to actually know what you're doing.
I find myself getting back to the old days and starting the day by reading the code, planning at a meta level, not just prompting but thinking about how to prevent a whole class of things from happening again. That's the real work now.
The next model will not fix this. I always assume the AI is going to be fairly unintelligent, and we need to engineer our way to create intelligence in the system itself. If you do it right, as the models get better, that only accelerates you faster.