Nothing New In Software Yet
Yeah, crazy proclamation in mid-2026, but it's something I'm increasingly sure that a minority of people understand. The more online you are, the more you might believe that the very foundations of engineering have been turned to sand, and that achieving the legendary velocities (how many X's do you have on your output?) requires some sort of "LLM-whisperer."
Let me assure you, things have not changed that much. Formerly cracked devs? Yeah, still cracked. Junior engineers? Yes, they still exist. Formally verifiable, human-quality code-output at a scale once inconceivable? Yes, that's the main thing that has changed. Let me explain what I mean, and then I will go on to tell you a magic secret: how to succeed in this scary new world (hint, it's actually not new advice, or magic, or a secret).
The Ways of Old Are Not Actually Going Away
Almost every single practice that led to an efficient dev shop is still in play. Almost every single process or culture that sabotaged a 'shop is still grinding them to a halt. It is basically still the case that organizations variously succeed and fail from all of the same modes of success and failure.
Things are Going Faster
What is different is pace, and I'm open to the idea that enough of a change in pace really does constitute a change in the substance of what we're really doing. However, this isn't a philosophy piece. Instead, let me explain exactly what kinds of things I observe unchanging.
These Things Work with AI Even Better
Do these things with AI, the same way you did them as a human, and it is a magic recipe for success. (Ok, it's actually just the recipe for success that we can observe in hindsight for all the notable players, with some notable examples.)
A Culture of High Quality
Yep. Believe it or not, you don't have to sacrifice this very straightforward principle. It isn't necessarily code quality, although that one too. It's the quality of your processes, principles, talent, et cetera. AI, used with principle, is a really effective tool at amplifying the quality of existing inputs.
Being Cracked
Yeah, so, the difference between a junior and a senior engineer using a harness is becoming pretty absurd. If you don't believe me, go ask a junior engineer to create and deploy a production stack with AI. See how it goes. Then find a backend engineer that is 'pilled, and see what they make. It will take both folks about the same amount of time, only one will have something that can be used. Being already-cracked makes your output with AI significantly better (maybe even than your own code would have been, if we account for fatigue).
TDD(ish) and QA experts
Again, pretty much all of the big players adopted TDD principles into the dev cycle a long time ago, though rarely purely. Turns out it is really useful to a human to see when their changes are breaking other things built by other people, and without them, no reasonable output pace can be expected. Crazy (I know), it turns out to be really useful to the AI as well. You might notice the theme here soon.
All The Normal Stuff
Code organization. Architecture documents. Clear variable names. Documentation that isn't stale. Clear, self-documenting code. Et cetera. All the normal stuff. People have this idea that AI solves these problems. I mean, kind of? But the problem is, one agent doesn't know what the last agent was doing. You leave indelible traces of disorganization that accrete over time when you do not build code for the future. This, miraculously, applies to AI harnesses too. Sometimes, these kinds of things become absurd when you reverse the statement. Do you think that AI is not worse when it is working in a disorganized codebase? Yeah, your team's project's file structure still matters.
Good Process, Quarantined from Developer Autonomy
We've all worked on teams that deal with our own or other teams' poorly-thought-out features. We've also worked on teams where dictatorial authority about tech-solutions stifled the growth of the organization and stack as a whole. Turns out, finding a good balance of these two things is still critical. You don't need to yolo CC features into prod. You also don't need to ban developers from using a harness. No one wants your source-code, least of which, Anthropic.
Finding The Best And Paying Them The Most
The recent high-profile talent acquisitions prove my point. The smart players aren't shedding talent right now, they're greedily scooping it up. One might argue that this was always the way to play the game. The coaster on your team has become an existential risk, and the dedicated engineers have become indispensable. There might not ever be another generation of polyglottal, low-to-high-level, well-rounded and business-adjusted engineers. The "time to come" involves dealing with education in the post-AI world and I don't have great things to report from my scouting mission. Surprise surprise: it was always really difficult-to-impossible to train juniors up to a senior level on a single team within even years. That hasn't changed. The appetite for doing it has, though, because the required methodology involves locking them in a Faraday cage and asking them to write an express server, and stuff like that, possibly illegal. (Feel free to steal my idea. It's not as though juniors were ever an investment in current velocity. They were always an investment in people, and potentially, future velocity.)
Having a Tight Product Vision.
Last but maybe most relevant: perhaps I once thought that code generation, music, and modal logic would be difficult or impossible for the transformer architecture to do rigorously. Oops. Hindsight is 20-20. If I had to fall back to a new goalpost for "difficult or impossible," it's taste. Really, there's no accounting for it. Having an idea and the expertise to execute it makes you really valuable. Having good ideas makes you invaluable, now that the barrier to creating them is shrinking.
Master these pieces of arcane wisdom (that were being shared and copied before AI to great effect by the wise), and you too can achieve the fabled N(...)X output.