AI Coding's Babysitting Problem Has a Structured

The most revealing thing about the current AI coding moment isn't what these tools can do. It's how much hand-holding they still require.

That's the argument at the center of a recent BMad Code live session featuring Alexey Verkhovsky, a thirty-year software veteran and a key contributor to the open-source BMAD Method project. Verkhovsky and host Brian walked through QuickDev — a workflow tool that tries to automate the babysitting, not the coding itself. The distinction matters more than it might sound.

Think of it this way: most people using AI coding assistants today are acting less like managers and more like supervisors on a job site who can't step away for five minutes. Every few seconds, the assistant wanders off-script, invents requirements nobody asked for, or simply needs to be told to stop. The promise of tools like QuickDev is that you hand over a clear brief, walk away, and return to something reviewable — the same relationship a good contractor offers, rather than an intern who needs constant redirection.

Whether that promise holds is the more interesting question.

What QuickDev Actually Does

For readers who don't spend their days in code editors, here's the plain-English version of the problem QuickDev is trying to solve.

AI coding assistants work within what's called a "context window" — essentially, the amount of information the model can actively hold in mind at once. Think of it as working memory. The larger the task you hand it, the more of that memory fills up, and once it's full, the model starts forgetting what it was told at the beginning. For casual brainstorming, that's tolerable. For precise code changes in a large, complex codebase, it's a serious liability.

The older BMAD approach handled this with three separate steps — create the story (plan the task), develop the story (write the code), review the story (check the work) — each run manually, in sequence. Verkhovsky described that workflow as requiring around thirty back-and-forth exchanges with the AI per task. "You could only realistically run one stream of that and you were basically steering it all the time," he said.

QuickDev collapses those three steps into one automated loop. You provide an intent — a brief, focused description of what you want done, capped at roughly 300 words — and the system handles the planning, the coding, and the review in sequence, only surfacing for human attention at the beginning and the end. The intervening work happens while you're doing something else.

This is the part that sounds like marketing copy, and I'd be cautious about it if the underlying mechanism weren't more interesting than the pitch.

The Mechanism Worth Understanding

What makes QuickDev more than a workflow shortcut is the way it handles the review step — and specifically, who it assigns the review to.

Here's a problem anyone who's used AI assistants has run into: if you ask the same model that just wrote something to check whether it's correct, it will almost always tell you the work is fine. The model reasons from the same context that produced the original output and arrives at the same conclusions. It's not lying; it's just consistent in all the wrong ways.

QuickDev's review layer addresses this by spinning up separate review agents — independent sessions that receive only the code changes, with no knowledge of why those changes were made or what the original intent was. One reviewer is explicitly told to find at least ten things to fix or improve. Another checks whether the changes actually satisfy the stated acceptance criteria. A fourth, added more recently, asks a different question entirely: not "is this code correct?" but "if this code were broken, would our existing tests actually catch it?"

Verkhovsky called the information asymmetry intentional. "If you give it the reason and the more you give it of the context of the original coding session, the more it tends to fall into basically doing the same reasoning with the same weights and coming to the same conclusions and making the same mistakes."

The adversarial framing here is old. It's how code review has worked in good engineering teams for decades: the person who didn't write the code is better positioned to critique it. What's new is automating that structural separation at the model level, and using it to filter noise before a human ever looks at the output. The spec-driven development discipline that underlies this approach has been gaining traction precisely because structure, not raw model capability, turns out to be the lever that matters.

The Part I Find Genuinely Skepticism-Worthy

There's a real tension in this session that neither Verkhovsky nor Brian fully resolved, and it's worth naming.

Verkhovsky described the core constraint clearly: the usable context window — the working memory — hasn't improved as dramatically as the headline numbers suggest. Models now advertise million-token windows, but in his experience working on large, existing codebases, performance degrades meaningfully well before that ceiling. "By the time it racked up 300, 400k tokens," he noted of one experiment, "it's doing some version of generic just make it better. It pretty much completely forgot what I asked it to do."

His solution is disciplined scope management — keep each task small enough that the coding session fits within a reliable working window. That's sound engineering practice. It's also, if you squint, just the discipline of writing small, focused requirements that Agile practitioners have been preaching since the early 2000s. The BMAD team seems aware of this. Brian noted that LLMs are good at slicing tasks into appropriately sized units partly because they've been trained on decades of software development writing that emphasizes exactly that discipline.

What I can't tell from the outside is whether QuickDev is genuinely automating the hard parts, or whether it's wrapping good software practice in tooling that makes practitioners feel like they're doing something new. Verkhovsky's honest answer to "will we ever reach the point of pure automation — spec in, working code out?" was refreshingly direct: "I honestly see absolutely no evidence that we're even getting there. We've taken care of a bunch of accidental complexity. But there is still fundamental complexity that the models have no bloody idea how to deal with."

That's a useful admission from someone who clearly believes in the method. It's also the kind of thing that gets lost when tools get hyped. Microsoft's move toward autonomous coding agents in Visual Studio Code is the logical extension of this direction — and it raises the same unresolved question about where automation ends and human judgment becomes non-negotiable.

Who This Is For, and Who Should Stay Skeptical

The BMAD Method and QuickDev are open-source, which means you can examine what's actually happening rather than taking anyone's word for it. Verkhovsky said he uses it on real production codebases — large, existing systems with all the complexity that implies — and the session focused heavily on that brownfield context rather than greenfield toy projects.

If you manage software teams, the operational implication is straightforward: the bottleneck in AI-assisted development is shifting from "can the model write code?" to "can a human keep up with reviewing what the model produces?" QuickDev is an attempt to push that bottleneck later in the process. Whether it succeeds depends on how much you trust automated triage of automated review findings — which is a compounding of AI judgment that deserves more scrutiny than either host gave it.

If you're evaluating AI coding tools for your organization, the questions this session surfaces are worth asking of any vendor: Does the tool treat review as a separate, adversarial process — or does it ask the same model to check its own work? Does it manage scope actively, or does it let sessions balloon until the model starts hallucinating? Does it assume you can trust the output, or does it assume you can't?

The teams building with healthy skepticism about their own tools tend to be the ones worth watching.

Bob Reynolds is a Senior Technology Correspondent at BuzzRAG.