Same IDE, Two Developers: One Shipped A Month Of Front-End In An Afternoon. The Other Wiped The Drive.

Two weeks after Google launched Antigravity in November 2025, a developer asked the agent to clear a project cache. Turbo mode issued an rmdir against the root of the D: drive instead of the project folder, and the deletion bypassed the Recycle Bin and the data was unrecoverable. It wasn't an isolated incident. Months earlier, a prominent vibe coding agent famously deleted a user's production database and then reportedly fabricated data to cover it up.

The distance between either compressing a month of work into an afternoon or wiping an entire drive isn't the model, the IDE, or the protocol. It entirely depends on the assumption that the person driving the pipeline knows what's underneath it.

Damian Matthews didn't do either of those things. But he watched both ends of the spectrum play out from the same office.

The pipeline that shouldn't have worked this fast

Matthews is a Senior Software Developer at CBOS, a software and digital transformation firm based in South Africa. Self-taught, he came up through support technician roles at Spinnaker Software, moved into test engineering at Autedi Digital Transformation, and worked his way through senior dev positions at Exclr8 Business Automation before landing at CBOS.

Recently, Matthews' CTO needed a fresh UI for a client. Rather than assigning the work to a dedicated front-end team, the CTO wired up a local MCP server, connected Google's Stitch to it, piped the same MCP instance into Antigravity, and linked the whole chain to Figma. When the CTO noticed the app lacked a login screen, he prompted Stitch, and the pipeline pulled design context through MCP, generated a cohesive login screen matching the existing app's look and feel, and pushed the result back into the IDE.

"What he accomplished in a late afternoon would have probably taken a team that's skilled and proficient in the front end two to four weeks," Matthews told The Read Replica.

Matthews didn't build the pipeline. But he understood immediately why it worked, and why it wouldn't have in most people's hands. The CTO already knew the architecture from a full stack perspective. He understood which layers needed to talk to each other, what the existing app's design language was, and where the AI output would slot into the broader system.

The CTO's relatively simple pipeline is a case study in what most organizations can't do yet. And if the setup seems obvious, you're likely ahead of the adoption curve by an order of magnitude.

Why 10 percent gains stay at 10 percent

Bain's 2025 Technology Report puts the productivity gain from AI coding assistants at 10-15%, but writing and testing code accounts for only 25-35% of the enterprise development process. Speed up that slice alone, and the returns are marginal across the board. Companies pairing AI with end-to-end process transformation see 25-30% gains, Bain found, but those companies are redesigning workflows, not just bolting on autocomplete.

Matthews' CTO wasn't using AI to just write code faster, but to orchestrate a multi-tool pipeline that collapsed weeks of cross-functional effort into a single session. That tracks with Bain's own conclusion: real payoff comes from applying AI across the lifecycle, not just code generation.

Meanwhile Faros AI's data across more than 10,000 developers tells the same story from the other direction. High AI adoption correlates with over 150% larger pull requests and around 10% more bugs per developer. Developers on those teams completed more tasks and merged almost double the amount of PRs, but review time ballooned on the back end. The throughput is real. Whether anyone is reviewing what ships is a different question.

The volume claims are getting louder. When one prominent venture figure recently claimed 37,000 lines of code per day across five agentic projects, a senior engineer who inspected the output found bloat and rookie mistakes visible without touching the back end. "Right now we're in a moment where AI lets you generate code faster than any human can review it," the engineer told Fast Company, "and the answer [from leaders] seems to be 'so stop reviewing.'"

The JSON jigsaw

Matthews isn't surprised by any of this. The core problem, as he sees it, is architectural. Modern applications span a front end, an API layer, and a data store, and AI tooling still operates within one surface at a time.

"AI can assist in debugging in certain aspects, but it will usually be in a very granular sense where one thing is not working as expected," Matthews said. "It's not going to have the context of, 'Well, your front end layer is expecting this and your API is just returning results with a different JSON object.'"

The code compiles. The function returns data. But the serialization format between layers doesn't match, and the front end can't deserialize what the API sends. In a decoupled architecture, that mismatch lives in the seam between services where AI's context window runs out. The CTO's pipeline worked precisely because it bridged those seams through MCP, giving the AI chain visibility across tools that normally can't see each other. But someone had to know which seams existed in the first place.

The ecosystem is starting to catch up to this problem at the protocol level. Most of the major DX platforms have shipped MCP server implementations that let AI tools connect directly to the database layer, standardizing how LLMs talk to backend services instead of leaving developers to wire those connections by hand. But the tooling only works when someone understands the architecture it's connecting to.

DIY debugging in the age of agents

"What really drives progress in this industry is grit," Matthews said. "The ability to stick with something and figure it out no matter what." But his concern is that AI-generated implementations let junior devs skip the reps that build those instincts. DevTools, Postman, console logs at each layer, tracing the data until the divergence shows up. That's the work that determines whether the app actually functions in production.

"Doing the heavy implementation yourself ingrains it," he said. "Use AI to help write the code, but make sure you understand exactly what it's doing, and never commit anything you wouldn't write yourself."

He's not anti-AI. He's anti-skipping. The distinction matters because the failure mode isn't AI-generated code that doesn't work, but code that fails in the real world because nobody understands how the layers connect in prod. A junior developer running the same tools without that literacy might generate output that looks correct in isolation and breaks at every integration point.

Mind the seam

Modern applications span a front end, an API layer, and a data store. AI tooling still operates within one surface at a time. The code compiles, the function returns data, but the serialization format between layers doesn't match and the front end can't deserialize what the API sends. That mismatch lives in the seam between services, exactly where any single tool's context window runs out.

"Until you can give AI access to this IDE running that, that IDE running the other thing, and then your database," Matthews said, "it's going to struggle to figure out what the moving parts are in between."

It's why the CTO's pipeline worked. Someone who already understood the full stack wired them together through MCP and knew which seams to bridge before the AI touched a line of code. The major DX platforms are shipping MCP implementations that standardize those connections. But standardizing the plumbing doesn't eliminate the need to understand what's on either side of it.

Matthews sees AI closing the context gap eventually. "It will get there, without a doubt." Whether the developers using it will still know what "full context" means by then is a different question.