Why Software Development Still Feels Slow

Why the biggest barriers to AI-powered velocity aren't technical, and where to start.

Software development has never seen a shift like the one we're going through right now. The generative AI tooling is so good, so why do so many companies still seem slow to turn ideas into new features and products ready to ship?

Many legacy SaaS incumbents are still struggling to increase their velocity. AI-native software companies aren't facing the same problem; they have different DNA. And the companies that depend on software to run their business, both off-the-shelf and custom apps, are caught somewhere in between.

So what have I noticed? Two things. They relate mostly to software companies, but they spill over into any company developing software in-house.

One: The process hasn't caught up to the tools. The software development lifecycle (SDLC) hasn't evolved to match what AI tooling can do. In any software company of scale (100+ employees), there are still so many gated processes in place. Yes, they're well-intentioned, but they are also now antiquated.

Two: The people are in flux. The teams building software apps (product managers, UI/UX designers, software engineers, quality assurance, and release managers) are all watching their roles change in real time.

The AI Process Problem

While most SaaS companies are using AI tooling today, one observation that I have is the disjointedness in the various tool chains that still exist.

UX and Design, long fans of Figma, Adobe, and similar tools, are using their AI of choice within their own realm, but that work isn't streamlined into the same toolchain and pipeline that Dev and Engineering are using. So while they may be gaining productivity within the UX swimlane, their deliverables still need to be refactored before they can make it into the product or platform. The same thing is happening with product management and QA tools and processes.

Look at what you can do today with Claude Code and Claude Design integrated into GitHub. There's enough of a common system there to allow product managers, developers, QA, and UX to share the same toolchain and pipeline. I'd even extend that to Marketing, especially product marketing.

To get there, the entire SDLC has to be reframed:

• Product managers become spec-driven, for example, using PRD.md files to define feature sets.
• Engineers work from those specs, building alongside their AI developers.
• QA is baked in across the traditional gate stages. Test suites and execution are automated, with human inspection and approvals built in.
• UX mocks and designs are created in the native language the product requires.

No refactoring. No porting. ONE swimlane.

I don't want to underestimate the change management this requires – People love their tools, and their identities are often tied to them. The good news is that nobody has to abandon those tools overnight. Claude, as one example, has a wide array of connectors and built-in knowledge, so a designer can keep working in Figma and still generate final outputs in a shape and syntax that match everyone else's. That's how teams graduate into a single swimlane.

One important lesson here, learned from a prior mistake: This unified toolchain doesn’t magically generate more velocity once the licenses are doled out. Take the time upfront to build your brand styling, technical spec choices, and UI/UX styles into your shared SDLC context. Capture them as .md files, like Brand.md and Technical-Specs.md. This ensures everything the AI builds looks and behaves the same. It's critical to getting the most out of a common toolchain.

The AI People Problem

Dovetailing off the above, the disjointed use of different tools across roles is a product of our history. Collaboration in software companies has usually been solved with tools like Jira, Teams, and Slack. That approach preserved the role delineation we've had for decades.

But to improve velocity, we don't just need a shared toolchain and process, we need to rethink the role boundaries.

Take product management. Given how these new AI tools work, the traditional boundary of focusing on the what and why is in question. Yes, answer those questions, Ms./Mr./Mrs. Product Manager, but follow it up with three quick 10-minute iterations that bring it to life as a prototype. We've tried to emulate this for years with time-expensive handoffs to the next downstream team. Now that work can be absorbed.

This begs the question, “whose job is it?” In a world of blurred responsibilities and disciplines, the answer varies. But the times and tools call for a different organizational structure.

The emerging consensus right now is that smaller, cross-functional teams, often called "AI pods," should drive software development. The makeup will vary by product or need, but a pod might include:

• An AI Orchestrator. This could be a redefined product manager or senior developer, someone with a broader view who can represent market, customer, and product needs, with an instinct for go-to-market.
• Full-stack developers who can drive the AI tooling the right way, including data, front-end development, back-end development, and everything in between.
• QA and UX, with roles that are shifting rather than disappearing, QA moves toward owning test strategy and the human approvals built into an automated pipeline. UX designs directly in the shared toolchain to minimize refactoring but is still committed to designing the best user experience possible.

Thanks to AI augmentation, the pod will be smaller than a traditional development team, with fewer handoffs but more ownership for each person on it. Human judgment is still required and the traditional disciplines must be represented.

For this to actually increase velocity and deliver a market-viable product, the process has to be solid and the single swimlane has to be robust. That's best handled by an AI platform engineer who owns the DevOps pieces, so every pod stays consistent and benefits from the shared toolchain.

Good Enough to Start

The tools have already changed. What's slowing most companies down isn't the technology, it's the gates we built for a different era and the role lines we drew around them. Rethink those, and the speed AI promised starts to show up.

At the heart of it, this is a people shift. It's the product manager learning to prototype, the designer bringing their work into a shared pipeline, and the developer learning to orchestrate AI instead of writing every line of code. Getting it right means bringing those people along, not just rolling out new tools.

It's still early days, but the AI tooling is good enough now to begin redefining your processes and tools. Don't look for perfection, start iterating with incremental improvements until you find your best fit.

If your team is wrestling with where to start, we'd love to help. As an AI transformation partner, Tonic works alongside teams to reframe how software gets built, from the process to the people.