Presentation: Engineering at AI Speed: Lessons from the First Agentically Accelerated Software Project
Our take
Adam Wolff's presentation on Engineering at AI Speed offers a compelling glimpse into how AI is fundamentally reshaping software development practices. As coding costs approach zero, the traditional bottlenecks in the software development lifecycle are shifting from implementation to architectural decision-making, a transformation discussed in When product managers ship code: AI just broke the software org chart. This paradigm shift demands new approaches to development, where the ability to rapidly experiment, learn, and iterate becomes paramount. Wolff's insights align with the broader trend toward AI-first software delivery, as explored in Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices, which emphasizes that agentic workflows require careful balancing between innovation and established practices.
The most striking revelation from Wolff's analysis is the diminishing importance of traditional coding skills in the face of AI capabilities. When implementation costs approach zero, the competitive advantage shifts to teams that can make faster architectural decisions and learn more rapidly from their experiments. This explains why Wolff advocates for practices like dogfooding and rapid unshipping—not as mere development techniques, but as strategic imperatives for organizations navigating the AI-powered development landscape. The ability to build, test, and discard features without significant resource investment creates unprecedented opportunities for innovation, but only if teams are structured to capitalize on this agility.
The "war stories" Wolff shares illuminate the practical challenges of this new development paradigm. They demonstrate that while AI can automate implementation, the human element remains crucial in guiding architectural decisions and learning from outcomes. This human-centered approach ensures that AI tools augment rather than replace the judgment and experience of development teams. The key insight here is that successful AI-native development isn't about writing code faster—it's about making better decisions faster. This requires organizations to rethink not just their tools, but their entire approach to knowledge sharing, decision-making, and learning from both successes and failures.
As we look toward the future of software development, Wolff's presentation raises a critical question: How will organizations adapt their cultures and processes to thrive in an environment where implementation is nearly costless but strategic decision-making becomes the primary competitive advantage? The answer likely lies in developing new metrics for success, fostering environments that encourage rapid experimentation, and building teams that can effectively translate AI-powered capabilities into business value. The organizations that master this shift won't necessarily be the ones with the most sophisticated AI tools, but those that can learn fastest and apply those learnings most effectively to solve real-world problems.
Adam Wolff discusses the evolution of Claude Code, explaining how AI shifts the SDLC bottleneck from implementation to architectural decision-making. He shares three "war stories" to show why dogfooding and rapid unshipping are vital. He explains that when coding costs drop to zero, the speed of learning becomes the only competitive advantage.
By Adam WolffRead on the original site
Open the publisher's page for the full experience
Related Articles
- When product managers ship code: AI just broke the software org chartLast week, one of our product managers (PMs) built and shipped a feature. Not spec'd it. Not filed a ticket for it. Built it, tested it, and shipped it to production. In a day. A few days earlier, our designer noticed that the visual appearance of our IDE plugins had drifted from the design system. In the old world, that meant screenshots, a JIRA ticket, a conversation to explain the intent, and a sprint slot. Instead, he opened an agent, adjusted the layout himself, experimented, iterated, and tuned in real time, then pushed the fix. The person with the strongest design intuition fixed the design directly. No translation layer required. None of this is new in theory. Vibe coding opened the gates of software creation to millions. That was aspiration. When I shared the data on how our engineers doubled throughput, shifted from coding to validation, brought design upfront for rapid experimentation, it was still an engineering story. What changed is that the theory became practice. Here's how it actually played out. The bottleneck moved When we went AI-first in 2025, implementation cost collapsed. Agents took over scaffolding, tests, and the repetitive glue code that used to eat half the sprint. Cycle times dropped from weeks to days, from days to hours. Engineers started thinking less in files and functions and more in architecture, constraints, and execution plans. But once engineering capacity stopped being the bottleneck, we noticed something: Decision velocity was. All the coordination mechanisms we'd built to protect engineering time (specs, tickets, handoffs, backlog grooming) were now the slowest part of the system. We were optimizing for a constraint that no longer existed. What happens when building is cheaper than coordination We started asking a different question: What would it look like if the people closest to the intent could ship the software directly? PMs already think in specifications. Designers already define structure, layout, and behavior. They don't think in syntax. They think in outcomes. When the cost of turning intent into working software dropped far enough, these roles didn't need to "learn to code." The cost of implementation simply fell to their level. I asked one of our PMs, Dmitry, to describe what changed from his perspective. He told me: "While agents are generating tasks in Zenflow, there's a few minutes of idle time. Just dead air. I wanted to build a small game, something to interact with while you wait." If you've ever run a product team, you know this kind of idea. It doesn't move a KPI. It's impossible to justify in a prioritization meeting. It gets deferred forever. But it adds personality. It makes the product feel like someone cared about the small details. These are exactly the things that get optimized out of every backlog grooming session, and exactly the things users remember. He built it in a day. In the past, that idea would have died in a prioritization spreadsheet. Not because it was bad, but because the cost of implementation made it irrational to pursue. When that cost drops to near zero, the calculus changes completely. Shipping became cheaper than explaining As more people started building directly, entire layers of process quietly vanished. Fewer tickets. Fewer handoffs. Fewer "can you explain what you mean by..." conversations. Fewer lost-in-translation moments. For a meaningful class of tasks, it became faster to just build the thing than to describe what you wanted and wait for someone else to build it. Think about that for a second. Every modern software organization is structured around the assumption that implementation is the expensive part. When that assumption breaks, the org has to change with it. Our designer fixing the plugin UI is a perfect example. The old workflow (screenshot the problem, file a ticket, explain the gap between intent and implementation, wait for a sprint slot, review the result, request adjustments) existed entirely to protect engineering bandwidth. When the person with the design intuition can act on it directly, that whole stack disappears. Not because we eliminated process for its own sake, but because the process was solving a problem that no longer existed. The compounding effect Here's what surprised me most: It compounds. When PMs build their own ideas, their specifications get sharper, because they now understand what the agent needs to execute well. Sharper specs produce better agent output. Better output means fewer iteration cycles. We're seeing velocity compound week over week, not just because the models improved, but because the people using them got closer to the work. Dmitry put it well: The feedback loop between intent and outcome went from weeks to minutes. When you can see the result of your specification immediately, you learn what precision the system needs, and you start providing it instinctively. There's a second-order effect that's harder to measure but impossible to miss: Ownership. People stop waiting. They stop filing tickets for things they could just fix. "Builder" stopped being a job title. It became the default behavior. What this means for the industry A lot of the "everyone can code" narrative last year was theoretical, or focused on solo founders and tiny teams. What we experienced is different. We have ~50 engineers working in a complex brownfield codebase: Multiple surfaces and programming languages, enterprise integrations, the full weight of a real production system. I don't think we're unique. I think we're early. And with each new generation of models, the gap between who can build and who can't is closing faster than most organizations realize. Every software company is about to discover that their PMs and designers are sitting on unrealized building capacity, blocked not by skill, but by the cost of implementation. As that cost continues to fall, the organizational implications are profound. We started with an intent to accelerate software engineering. What we're becoming is something different: A company where everyone ships. Andrew Filev is founder and CEO of Zencoder.
- Presentation: AI-First Software Delivery: Balancing Innovation with Proven PracticesWes Reisz discusses the shift toward AI-first software delivery, emphasizing that agentic workflows are not one-size-fits-all. He explains a strategic two-by-two model based on code longevity and automated verification to decide between supervised and unsupervised agents. He shares the RIPER-5 framework - Research, Innovate, Plan, Execute, Review - to amplify engineering discipline. By Wes Reisz