AI Coding & Agentic Engineering Mastermind Summary

On April 8, Patrick Van Staveren and I hosted a mastermind with 53 SaaS founders, CTOs, engineers, and technical leaders on AI coding and agentic engineering. The conversation was one of the clearest signals I’ve seen that software development has entered a different era. Not a marginally better era. A different one.

Patrick said something on the call that really stuck with me: “This is the fastest kind of transformation I’ve ever seen. I was a cloud guy at my last company, and that was fast in terms of tech. This is another order of magnitude.” That feels exactly right. Cloud was a meaningful platform shift. This is that, plus compression. The distance between idea and production has collapsed, and the companies that internalize that first are going to move at a speed that is very hard to compete with using old workflows.

The Adoption Range Is Wider Than Most People Think

What made the session useful was that it was not theoretical. We had people on the call who are already deep into AI-first development, others who are experimenting in selective parts of the stack, and some who have not adopted it at all yet because they are rightly worried about blowing up fragile production systems with real customers on them. That spread was helpful because it showed this is not an ideology question. It is a workflow, risk tolerance, and leadership question.

The adoption range was wider than I expected. A few participants are already at 80 to 90 percent AI-assisted development in specific contexts. Lukas Kosina said he is around 80 percent for data science work. Daniel Burge described himself as 90 percent AI-first. David is using the Agent OS framework to inject context and discover patterns inside legacy systems. Others said they are at maybe 40 percent, mostly on front-end development and internal tooling. And then there were people at effectively zero, especially on back-end systems where the blast radius of a mistake is high.

That distribution matters because it tells you where the market really is. We are not in a world where everyone has already standardized on one method and one toolchain. We are in the phase where smart teams are building muscle at different speeds depending on their use case. Front-end and prototypes are moving first. Internal tools are moving first. Greenfield products are moving first. Mission-critical back-end systems with lots of users are moving more cautiously. That is rational. But it also means there is now a widening performance gap between teams who are learning this fast and teams who are still mostly observing it.

The Productivity Shift Is Real

I shared on the call that, with one developer and myself acting as product owner, I’m now building at a pace that would previously have required something like 20 engineers under the old iContact-style hand-coding model. I do not mean that as hype. I mean that the throughput difference is now large enough that old planning assumptions are broken. “With one developer and myself as product owner, I’m now developing at a pace that would be equivalent to about 20 engineers previously at iContact under the old hand-coding model.” That is the magnitude of change we are talking about.

And I was not the only one hearing this. James told a story about his brother-in-law at a large insurance company in Ireland who said they no longer even have a backlog. Five engineers are sitting there reviewing overnight pull requests because the coding gets done while they sleep. James also had the best analogy of the session when he said it feels like we were all in a bike race and then suddenly everyone got handed a motorbike halfway through. You can choose not to get on it, but you are still racing against humans who did. That is exactly the strategic frame founders should have.

Why This Is Becoming a Competitive Imperative

I also said something on the call that I believe even more strongly after hearing everyone’s examples: “Any teams that are still doing the majority of their coding through hand coding—you’re going to be out of business in a year, in 18 months. You won’t be able to keep up with the pace of feature development of your competition if you’re not doing AI-first development.” That does not mean you recklessly pipe AI into production without controls. It means your default development model has to change now, while you still have time to build competence before your competitors fully do.

The Bottleneck Has Moved

What became very clear in the mastermind is that the bottleneck in software development has moved. For a long time, teams treated coding as the primary throughput constraint. That is becoming less true by the month. Multiple people reported the same pattern: the code can now be generated faster than the organization can properly specify, review, and validate it. So the real bottlenecks are shifting upstream and downstream.

The New Constraints

• product teams cannot write enough clear user stories fast enough
• QA becomes the main choke point
• code review becomes the real quality gate
• engineering leadership has to decide where AI autonomy stops and human judgment begins

That is a very different organizational problem than “how do I make developers type faster?” It means if you only adopt the tooling and do not redesign the development system around it, you will still hit a wall. You will just hit it later in the workflow.

The Models Themselves Have Crossed a Threshold

Patrick did a nice job on the call of explaining how fast the models themselves have improved. He traced the progression from the early ChatGPT phase, where the model could produce code that looked plausible but often broke on execution, to today’s more agentic systems that can iterate, run tests, evaluate output, and refine their own work. He pointed to Claude Opus 4.5 in November 2024 and 4.6 in February 2026 as key moments when it became much more realistic to use this for production workflows rather than pure experimentation. The group clearly felt that shift. We are not just talking about autocomplete anymore. We are talking about a system that can increasingly function like a junior-to-mid-level implementation engine if the surrounding process is well designed.

Legacy Code Is No Longer an Excuse to Wait

One of the most valuable parts of the discussion was around legacy code. A lot of founders and engineering leaders are not building on clean greenfield stacks. They are sitting on 10-, 12-, 15-year-old codebases with uneven documentation, fragile architecture, and years of accumulated business logic. Patrick’s advice here was excellent: do not start by prescribing solutions. Start by understanding. Use AI to reverse-engineer the architecture, extract specifications, and map the current system so you know what the software actually does before you decide whether to rewrite, refactor, or retrofit guardrails.

That is a much better way to think about modernization than the classic “big bang rewrite” fantasy. Existing code is implicit documentation, even when it is ugly. AI is now surprisingly good at reading that documentation if you feed it enough context and structure the problem the right way. Patrick’s point was that this changes the economics of legacy migration. You can spend $200 on tokens to understand a codebase well enough to make a smarter strategic decision instead of committing a team for six months just to get oriented. James validated that approach with a 14-year-old Rails app, where improving the API documentation became the bridge to redesigning the mobile experience much faster.

The Workflow Patterns That Are Emerging

A few workflow patterns are starting to emerge from teams that are doing this well.

My Current Pulse.bot Workflow

On pulse.bot, my current process is fairly simple and very fast. I prototype in Google AI Studio. I send the concept to a developer who builds in Cursor with Claude Code. We deploy on Vercel and Supabase. We track changes in Google Docs instead of JIRA. And we are moving through roughly 40 user stories a week this way. That is not because the tools are magic. It is because the whole pipeline is being optimized around speed of iteration.

A Product-Led Prompting Pattern

Daniel Tullio described something similar from the product side. Product owners write in plain English. Claude turns that into development stories and executable plans. Then the review process filters what is actually production-ready. That sequence is important. It suggests one of the highest-leverage uses of AI is not just writing code, but translating messy intent into structured implementation work.

QA Is Still the Biggest Unsolved Problem

The hardest unresolved issue, in my opinion, is still QA. David raised the most important challenge on the call: how do we automate acceptance testing for complex applications, especially ones with admin workflows, permissioning, and multi-step business logic? That is the right question. Because if the code generation side scales 10x and your validation side only scales 1.5x, you do not actually get a 10x development organization. You get a bigger QA bottleneck. Patrick recommended using separate context windows for testing, not necessarily separate models, so the same context that created the code is not the one certifying it. That is a good principle. But the broader point remains: this is where the next wave of innovation needs to happen.

There was also a side discussion in the notes afterward about whether AI should write tests at all, with some strong opinions against it because tests encode human intent. I think the real answer is more nuanced. AI can absolutely help generate tests, but the human team still has to define what matters, what constitutes acceptance, and what edge cases are truly business-critical. That distinction is going to matter a lot.

The Cultural Shift Is as Important as the Technical Shift

The cultural side of this transformation is easy to underestimate. David said he spent a lot of effort helping engineers lean into AI without fearing for their jobs. That is not a minor management issue. It is one of the central leadership tasks right now. If your team hears “AI can do 80 percent of this now,” and the only translation they hear is “you are replaceable,” adoption will stall or go underground. The better framing, and I think the more honest one, is that developers are moving up the stack. The implementation floor is dropping. That means more leverage, more system design, more review responsibility, more product fluency, and more pressure to think like owners rather than keyboard operators.

That transition still needs to be managed well. Founders and CTOs need to be explicit. Celebrate wins. Make the standards clear. Explain where human review is non-negotiable. Give people training. Show them how their role gets better, not just faster. If you do not do that, you will get resistance that looks like technical skepticism but is actually just fear.

The Tool Landscape Is Still Volatile

We also talked a lot about the tool landscape. Right now it really does feel like a Cambrian explosion. Claude Code, Cursor, Windsurf, GitHub Copilot, Replit, OpenAI Codex, Agent OS, Google AI Studio, MCP, Playwright MCP, Vercel, Supabase. There are a lot of options, and they are changing fast. David’s concern was that it feels hard to commit to anything because the methods themselves may look totally different 18 months from now. Patrick agreed that this is the fastest-moving tool transition he has seen. I think that is true, but it does not mean you wait. It means you anchor on stable primitives and stay flexible on interfaces. Git will still matter. Testing will still matter. CI/CD will still matter. Clear specs will still matter. Human review will still matter. Build around those, not around loyalty to one shiny tool.

Tools Participants Mentioned

• Claude Code
• Cursor
• Windsurf
• GitHub Copilot
• Replit
• OpenAI Codex
• Agent OS
• Google AI Studio
• MCP / Model Context Protocol
• Vercel
• Supabase
• Playwright MCP

The Economics Still Favor Speeding Up

Cost was another interesting thread. David worried that token prices may rise once teams become dependent on them. I pushed back on that because I think the economics are heading the other way. Anthropic is already at $30B ARR, according to the discussion in the notes, now ahead of OpenAI, and compute costs continue to fall. My expectation is that the tools get both better and cheaper from here. I said on the call that I think we will see something like 20x capability improvement at one-tenth the cost over the next 36 months. Whether the exact ratio is right or not, the direction feels very clear. If you are delaying adoption because you think this will get more expensive and less accessible, I think you are betting against the basic economics of the market.

What the Winning Teams Will Actually Do

If I had to summarize the teams that are likely to win from here, it would not just be the teams with the best prompt engineers or the most tokens. It will be the teams that redesign their entire development operating system around the new reality.

In Practice, That Means

• strengthening product management so the pipeline of user stories and specs can keep up
• redesigning QA so testing can scale with output
• building code review systems that treat AI like a fast junior developer, not a self-certifying expert
• helping engineering teams adapt culturally so trust and morale rise rather than collapse
• modernizing legacy systems incrementally, using AI first to understand before deciding what to rebuild

The Biggest Takeaway

The most important takeaway for me is that this is not really about replacing engineers. It is about expanding what a small, well-led team can do when human taste, judgment, and creativity are paired with machine-speed execution. That combination is now powerful enough that old organizational designs are going to look obviously inefficient in hindsight.

Patrick said, “Spending tokens is not a bad thing. It’s actually the proxy for your own journey and your own progress.” I think that is a useful mindset. There is a learning curve here. Teams are going to spend money discovering what works. They are going to experiment with tools that disappear. They are going to make mistakes. That is normal. The key is to start learning while the advantage still compounds.

Final Thought

And the final point is the one founders should care about most: this is not a five-year horizon conversation. This is an 18- to 36-month advantage window. The teams that figure out AI-native development, AI-scaled QA, and AI-compatible product workflows now are going to be very hard to catch later.

That is why this matters.