From IDEs to AI Agents with Steve Yegge (Agents column)
I saw it. release Gergely Orosz podcast "The Pragmatic Engineer" with a cool guest, Steve Yegge, a famous engineer ex-Google, ex-Amazon, ex-Grab, who has a special name. 40+ years in development. He loves and can write provocative lyrics about the industry, recently co-authored the book Vibe Coding, and created an open-source agent orchestrator. Gas Town. The guys discussed how the unit of engineering work is changing in our time. The main thoughts that I remember are:
1The main skill shifts from writing code to managing agents Yegge describes 8 Levels of AI use range from complete abandonment to orchestration of dozens of agents. His thesis is sharp but useful: to be stuck at the level of “sometimes asked IDE and watched diff very carefully” is to underutilize the new model of work. For us, that means teaching teams to decompose work, to create protective barriers. (guardrails)How to evaluate work (evals)Pipeline reviews and multi-agent processes and so on. This is something I wrote about in an article.From PDLC to AI-native development"
2IDE becomes not an editor, but a dispatcher One of the central ideas of the release is that the new IDE can turn into an interface for talking to agents and monitoring their work, rather than a place where an engineer manually stuffs code. For us, this is a shift in focus from coding to task setting, working with resolutions, sandboxing, observability and embedding agents in SDLC.)
3AI harshly highlights architectural debt Monolithic codebases are a serious blocker for enterprise AI-adoption: agents need a visible and well-retrievable context. For technical managers, this is a practical signal: modularity, clear boundaries, responsibility and code ownership, documentation and AI-friendly repositories become not an “architectural aesthetic”, but a direct factor in speed.
4AI changes not only the development, but also the operating model of the team Yegge emphasizes several times that AI is about augmentation, not just replacement: small AI-enhanced teams can move faster than large organizations whose bottlenecks are no longer in coding, but in alignment, prioritization, and a company’s ability to digest output. Even if you do not take literally his thesis about "dead big companies", the conclusion is practical: you can write code faster, but make decisions and bring to production - not a fact. This is something I wrote about in an article.From AI-native development to AI-native organization"
5Increased productivity easily translates into increased burnout Steve talks about the Dracula effect, or vampire AI, which is the idea that AI automates the easier part of the job and leaves people with the most energy-intensive decisions. In an interview, Yegge says that at maximum AI speed, a person may have only about 3 productive hours a day; the same idea he separately develops in his essay on AI Vampire. For techlids, this is perhaps the most important piece: you can't turn a 10x tool into a 10x wait from people.
A couple of interesting thoughts. SaaS without API and platform thinking risks losing to AI-native players: if the product is poorly embedded software, it will be bypassed or replaced Prototyping becomes almost a production model: according to Yegge, teams make a lot of quick choices and choose the best one, rather than polishing one implementation for months. I talked about the popularity of this approach when I talked about it. LovableProduct from this category
In general, listening to Steve was interesting - he knows how to think about the current and future in broad strokes, over which it is interesting to reflect and compare with his thoughts.
#AI #Management #Future #Software #Engineering #Productivity