Over the summer, I’ve had the opportunity to reimagine product development processes with “agentic engineering”—using agents for coding, requirements, testing, and design. Not since the embrace of Agile and full-stack Web frameworks over a decade ago has the way in which we produce software changed so radically. This isn't a step change like earlier AI-assisted development represented by tools Github Copilot, but a complete remaking of the team and processes.

For all the hopeful prose online about the "transformative power of AI™," one of the few places that promise is realized is in software development. Driven in large part by the launch of two tools riding on frontier models – Anthropic's Claude Code and OpenAI's Codex – we've been able to put "agents on the team" and see massive increases in throughput. This embrace of AI in software development also proves that to see the benefits, a complete overhaul is required. Just making code creation faster does little.

Sharing five lessons learned in implementing AI agents across existing Product and Engineering teams.

1| Swapping Agents for Humans

For as long as I've written code, testing is the activity everyone talks about but rarely invests in. I've been the "it works on my machine" guy; I've built teams of human testers and seen the wisdom of test-driven development ("TDD") and automation. But software quality always seems to sit behind raw feature development and other technical investments, which in most companies creates a crisis point that ultimately forces testing to the top of the priority list.

Earlier in the summer, I was asked by a company if it was possible to find a firm to do a one-time review of a critical part of the platform – more comprehensive than a smoke test – because customers kept finding issues and it was a drag on satisfaction and a risk to retention. My reflexive response was, "Yeah, there are firms we can call." But then I began to wonder if human testing was necessary at all. So I enrolled my new friend Claude in a project to find out. It went like this:

  • First, read every ticket – open or closed – about that part of the platform and understand the issues.
  • Second, read log data on failures (400 and 500 errors).
  • Third, connect to the codebase and see how features were implemented for tracing. Once that was done, I had it build a series of Playwright scripts for UI and some TypeScript modules to hit endpoints and run them on a loop, continually expanding its knowledge of how the app worked and separating true defects from false positives.
  • Fourth, run the entire suite and produce a detailed report. As a bonus, add tickets for what it found.

Working on and off for five days, the suite was done, and the company had an assessment they could trust plus about 9 high-priority defects that the agents found before customers. In the past, that would have been hundreds of hours of test engineering time. Now it's part of one human's time...and 24x7 work for multiple agents.

A few roles are ready to swap humans for agents. Test automation is a clear one. Other roles, like foundational usability testing and accessibility, also lend themselves to an agent-driven approach. It's faster, the output is more comprehensive, and it can be significantly cheaper if models and tokens are used smartly.

2| No more Tower of Babel

There are two quasi-holy wars in Tech: One is Star Trek vs. Star Wars (in my view, only one is the logical choice). The other is in the choice of coding languages. Engineers form deep emotional attachments to their favorite languages to the point of quite cultish behavior at times. If you don't believe me, find someone who loves Ruby or Rust and tell them another language is better. For added fun, make that other, better language something absurd like Smalltalk (the nine Smalltalk developers out there just flipped a table).

The result of that is we live in a polyglot world in software development. Some of it follows natural lines like iPhone apps in Swift, and Android apps in Kotlin. Some of it is legacy, like the massive COBOL codebases in insurance and banking. And some is just preferences amongst engineering teams. If a company or a software platform lives long enough, it will have modules written in more than one programming language. M&A activity supercharges this, since the odds of buying a company with exactly your tech stack are pretty low.

For a long time, this United Nations of technologies reality had bedeviled teams. It limited resource fungibility because skills didn't transfer cleanly between projects using different languages. It delayed using valuable features from one application in another. And it delayed critical refactoring because teams feared new engineers wouldn't understand the old codebase. I saw this firsthand at FTD, where the system that handled every order ran on a mainframe in MASM assembler; it was only rewritten once the remaining engineers announced their intention to retire (we did it, but it was nail-biting).

The limit was always that you had to find either people who know both languages to do the rewrite, or you had to find a way to get the people who knew the codebase for Language A to work closely with the people working in Language B, which is much harder than it seems at the surface. It's not as simple as swapping, say, C for Ruby syntax:

printf("\n Hi"); puts "Hi"

Each language comes with its own syntax... and supporting technologies. And what is optimized code in one language may look very different in another. This translation of commands and meaning, along with underlying implementation differences, is damn hard. Well, it was at least until LLMs arrived, all trained with huge volumes of code and technical design from nearly every language, including (even) Smalltalk.

The LLMs supplied in Codex, Gemini, Claude code can do this refactoring with a speed and accuracy we never had available before. No more finding engineers who know a specific language – your coding agent of choice knows it. No more weighing the time and cost of the refactor when (again, subject to managing tokens) AI makes that cost a fraction of what it was with human engineers.

Working this summer with a company that needs to refactor an ancient .NET codebase, we did some experiments on refactoring with coding agents. Given enough context, the agents did their work, and the result was akin to magic. The refactored code worked, caught defects we didn't know existed, and was performant. One sample, but now we know the project is no longer a daunting, high-wire activity but one we can confidently add to the roadmap.

3| Roles are blurry

In the before times of 2022, a typical pod or Scrum team had some number of engineers, at least one product manager, and at least one UX designer. A team, but loosely coupled, with each role working in their own artist's medium: engineers in code, product managers in documents, and UX designers in tools like Figma. Each taking feedback from the others and translating it back into their respective medium.

It worked, but we lost some things in the interface points – engineers would interpret a PRD differently than how Product intended it; screens would not work exactly as the designers envisioned them once they were rendered into working code. A nontrivial amount of every Scrum team's work was sorting out these differences as the software was developed and refined. It was lost time since it was just rework born of the different ways each role expressed its ideas.

Today, there's no Word or Google Docs, no Figma, no code IDE. There's just working prototypes built by agents. Vibecoding – which produces a range of emotions in Product and Tech folks – is one example where everyone is just focused on building working software to express their ideas. This is a huge leap in productivity and understanding. Gone are the meetings that start with "that wasn't what I thought it would be," replaced by "that's cool, let me prompt the agent to make these changes." And who is prompting the agent? Well, if you squint, you might make out that it's a product manager and not an engineer. But it doesn't matter because all three roles in the "triad" can create working prototypes to realize their vision.

This isn't to say that everything that makes the roles unique has collapsed into an all-encompassing AI-powered development role. While we probably won't make many screens in Figma anymore, having a robust design system (entirely the province of UX Design) is critical. While PRDs increasingly look as anachronistic as the BRDs of the Waterfall era, the rules for how functionality is meant to work are vital. And, while the IDE gathers dust, technical design and architectural context for the coding agents ensure the software works and scales.

AI development tools boost productivity in two dramatic ways: One, they sweep away rework and interface mismatches that weigh down every Scrum team everywhere. Two, they make the cost of feature decisions very low. It's hard to look at a static screen or document and decide if it fits the market. But working software that people can touch and explore? That requires no imagination to fill in gaps. Not sure how to build a feature or even build it at all? Have agents build the prototype and decide. We've never had the power to ship the right thing the first time that we do today.

4| Pods are smaller


The past year, we've had the unique chance to see what happens when we 4x-6x code throughput because every engineer now directs multiple coding agents. The short answer is we get to tasks that were never in reach before. The slightly longer answer is that we moved the bottleneck to other parts of the SDLC. We also shine a very bright light on deficiencies in taste and market fit in the org, which I explore more here: "Throughput Scales...Taste Doesn't. "

The traditional Agile Scrum team or pod is about 8 people – this is the famous "two pizza team" from Amazon.com lore. The usual construction of that team was

  • Engineering Lead
  • Product Manager
  • UX Designer
  • 5 Engineers (which might be front-end, backend, fullstack, test, or all of the above)

The number of engineers reflected how much of the labor in building a project was in coding and testing. But that was when humans working in an IDE or a command line were writing code and building automations..."The Engineering Dark Ages," as I'm sure the 2030s will remember it. Now, a single engineer can put many coding agents to work, directing them as if they were human engineers on the team. So that same coding and testing that used to take a lead plus five engineers? Now it's one or two.

I've seen this play out live in the companies I work with, where a single product person, a single designer, and two engineers are covering multiple product surfaces and applications. The two pizza team is down to one pizza...with a side of tokens. That smaller team is more efficient than the larger team, but as I said, we pushed the bottleneck elsewhere. The faster we create code, the more we need someone to tell that human/agent hybrid team what to build and what design language to use. It doesn't just put pressure on the human product and UX design folks; it pushes us to find ways to accelerate their work (see point 3 above) with AI, and to ensure the supporting work (customer research, design system, solid architecture) exists. But the day of the four-person pod is here.

And what do the engineers liberated from the shift away from larger squads do now? They're free to do the incredibly important work of building harnesses for the coding agents, rendering technical design and architecture into context files, building test automation, and getting to things like security remediation tasks that often got pushed scarily far down the list. AI works when it has the unique context for your platform and how you build software. That all requires engineers.

5| SAFe is Dead


To recap: agents are on the team, coding is faster, pods are smaller. Now the question is: how do we manage the SDLC in this world? And, related: will agents come to standups? The second question is easy – they'll come, but their report-out will always start with "I have to be direct about something..."

For larger software development teams, SAFe (Scaled Agile Framework) has been the methodology for nearly 20 years. A union of Agile principles (small teams, two-week sprints, iterative development) and more traditional project management (quarterly planning, organizing work across multiple Agile teams). It worked when software development was human-centered and ran at human speeds. Organizations recognized that SAFe brought more bureaucracy – and was often at odds with the Agile Manifesto's "people over process" – but were willing to take that governance tax in the name of predictability. To be fair, SAFe was under scrutiny before AI, as many companies slipped deeper into a slow-moving "Agilefall" (a strange sort of Agile-Waterfall hybrid).

In the age of agentic engineering, the assumptions underlying SAFe no longer hold. Code creation is so much faster, and none of the ways we used to estimate effort apply anymore. ARTs (Agile Release Trains) exist in SAFe because often one or two Scrum teams couldn't build the entire application. But now, with the ability to deploy 10s or 100s of coding agents against a project, and with AI tools for product and design, a single team can build complex functionality. The overhead of coordination between many teams is no longer needed.

Probably the biggest challenge to SAFe is that the bureaucracy it brings is no longer compatible with the incredibly rapid pace of discovery, building, and the ability to try many variants of something. PI planning, PMO review, engineer-product-design syncs, even estimation are useless in a world where a product manager can build an app in an hour. Knowing that it will take a team of human engineers two weeks to build something doesn't translate to a world where parallel development is bounded only by the number of agents. SAFe is like trying to fit the Pony Express communication model into the email era. SAFe's bureaucratic abuses brought it into question; AI will kill it.

I saw this play out over the summer as well with a massive rebuild (not port) of a legacy application. The original estimates for completion involved a third of the team and a year of work to create 20 separate modules for the app. One engineer and one product person plus Claude Code did the first module in three weeks. It forced the team to rethink (in a positive way) what was possible, but it also meant all the existing project management tools and measures were useless.

There will still be an SDLC, of course. Companies still need to plan a roadmap of releases and coordination – especially with teams like marketing and sales- which remains essential to commercial success. But we have to rethink how those plans are created and how AI processes fit into conceiving and building software. That SDLC probably reaches back to the Agile Manifesto's roots: iteration, people (and agents) over process, in-the-moment interactions. It can also help us more fully realize the last Agile value: customer collaboration. When we can build working software quickly to decide on features and requirements, we can show it to our customers, too.