Your inbox, upgraded.
Receive weekly engineering insights to level up your leadership approach.
Estimated reading time: 5 minutes
What are the most popular conversations around AI right now, and how are engineers weathering the hype cycle?
In the last few years, software engineering has changed dramatically. Part of that is economics: the end of the zero-interest-rate regime has shifted the balance of power away from engineers and towards their employers, making layoffs much more common. But the other sea-change has come from AI.
Tech companies have embraced AI faster than any trend in the history of the industry. The market for AI-driven developer tools is so intense that the most successful companies are breaking all-time records (like Cursor, which has reached $500 million in annual revenue). Tech CEOs are publicly bragging about the extent of their developers’ AI use – the CEO of Google, Sundar Pichai, famously claimed that over 25% of Google’s code is written by AI.
While personal skepticism is still common, company execs are moving quickly to jump on the trend – internally and externally. This adoption has come with an assumption that AI tooling will make their engineers ten times faster. This puts their engineers in a tough spot when the reality doesn’t quite match up to the hype.
Not quite a 10x speedup
Can AI make engineers ten times faster? In my experience, AI tooling can be really helpful, and in use cases where it’s a perfect fit, can sometimes really deliver close to that kind of speedup.
For instance, AI tooling is great for line-by-line suggestions, as a conversation partner or search engine, and as a quick sanity check on plans and pull requests. In terms of generating code, it’s at its strongest when I’m working on small codebases that don’t use a lot of custom libraries: in other words, codebases that match its training data.
However, it doesn’t speed up the hardest parts of the job.
Being productive at a large tech company requires mastering a million pieces of context: the design of your service, the overall design of its neighbouring services, the networking setup of the company’s edge layer, the database schema and topology, all the different types of user and states they can be in, and so on. An experienced engineer can build up that kind of knowledge over time at a company. But you can’t teach all of that to an AI model, because it simply won’t fit in the model context window (the amount of user input it can track at one time).
Because AI lacks context on the whole system, it’s liable to produce sensible-looking code that just doesn’t work in practice. For instance, it might assume that it can join two tables that in fact live in different database shards, or it might try to write its own authorization code instead of integrating with your company’s bespoke authorization layer. I’ve seen both of those examples in practice.
Overall, my throughput is 1.5x of what it would be without AI tools. While this is still a huge deal, it puts me at only 15% of the speedup that many CEOs expect.
More like this
Vibe coding expectations
The increasing accessibility of “vibe coding” (a programming style where you let the AI write and read all the code for you) is making leadership expectations worse. In most cases, the part of a project that you can vibe code for is the easiest part. As any experienced engineer knows, the last ten percent of a project is where ninety percent of the work is.
But that’s also the part of the work that’s the least visible to non-engineers, because it comes down to having the right context to fit new features into existing systems. For instance, if your company supports five different user types and three different deployment environments, that makes fifteen interactions to think about for every new feature. With good design, each new feature won’t have to actively handle all of these interactions, but somebody at least needs to think about them (and there are usually three or four that become edge cases and need active attention).
None of these decisions can be vibe coded, at least today. That means that an engineer trying to take a vibe-coded prototype to production will need to handle all of that complexity themselves, often rewriting much of the prototype in order to do so.
AI skeptics, early-adopters, and engineering leaders
Those engineers who are reluctant to adopt AI will most likely find themselves fighting a battle on two fronts: against managers and directors who see AI as the next big thing, and against early-adopter engineers who are enthusiastic about AI and trying to merge lots of AI-generated code.
AI skeptics should pick their battles carefully. For better or for worse, many tech companies are making a big bet on the power of AI, and are unlikely to be convinced to back out. If you’re right that AI-assisted engineering is mostly hype, you may be better off riding out the wave and pushing for a few common-sense approaches. This can include things like careful human review of AI-generated code before pushing to production, or introducing a principle whereby you can’t vibe-code an end-to-end enterprise feature.
Engineering leaders should try to be patient with their engineers. The new frequency of layoffs is making it difficult to relax and do our best work. We’re being asked to work twice as hard in order to keep up with unrealistic expectations about AI-driven productivity. And it’s no help that these new tools are being hyped as eventual replacements for our jobs, which is a looming source of long-term stress for even the most enthusiastic AI adopters. Avoid heavy-handed enforcement of AI tools on those who err on the skeptical side. If the tooling is truly transformative, those using it will outperform those who don’t – and that should convince the skeptics by itself.
Meanwhile, the early-adopter engineers who are most enthusiastic about AI should aim to be extra conscientious about their AI-generated code. Even if you’re carefully reviewing every line, it’s still harder to think through all the edge cases in someone else’s code than in your own. Your AI-skeptic colleagues are already under a lot of pressure because of their reluctance to use the tooling. Be careful that you’re not burying them under a deluge of code review.
Nobody knows exactly what AI-assisted coding will look like in ten years, but there’s a good chance it looks very different from traditional software engineering. For now, at least, it looks as though the skill of writing code may not be a part of the job forever.
Berlin • November 3 & 4, 2025
Charity Majors, Sam Newman, and Humera Noor confirmed for LeadDev Berlin! 🙌
Final thoughts
All in all, the current landscape has left software engineers in an unpleasant position. The good news is that (unlike some previous tech fads), at least AI tooling works.
Current-generation language models are surprisingly effective as programming assistants. Even if they fail to totally transform the software industry, they’ll likely wind up as a core tool for software engineers: like IDEs, type checkers, debuggers, and other everyday parts of the engineering workflow. In the meantime, we’ve just got to weather the hype as best we can.
