Your Team Is Using AI Four Different Ways. You're Only Managing One.

A few months ago I was a Vibe Coder.

Andrej Karpathy named it in February 2025 — "a new kind of coding where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." Two weeks in, I hit a wall: a level of complexity where the prompts started producing outputs I couldn't evaluate, where failures were silent rather than loud, and where the vibes had stopped working. What I didn't do — and this turned out to matter — was go back. I discovered Spec-Driven Development: writing a precise, detailed specification first and using it to constrain what the AI builds. Everything changed. The question shifted from "how do I use AI better?" to "how do I build a system that uses AI and knows when it's going wrong?"

While making that shift, I kept reading — articles, studies, conference talks — and started recognising my own past stages everywhere. Everyone uses the phrase "coding with AI" and describes completely different activities. Karpathy's vibe coding sits at one end of a spectrum most people don't know exists. Simon Willison — creator of Django, one of the most careful observers of AI-assisted programming — sits at another: "If an LLM wrote every line of your code, but you've reviewed, tested, and understood it all, that's not vibe coding — that's using an LLM as a typing assistant." (LLM: large language model — the technology behind AI coding tools.) Between them, a whole ecosystem of people building virtual software squads, orchestrating AI agents the way a manager orchestrates a team. And a smaller group — mostly quiet, mostly in engineering leadership — building something else entirely.

Four mental models. Most people don't know which one they're operating with — or that it can change.

The Tool Trap

Every week, some combination of Gartner, McKinsey, and your most enthusiastic vendor is telling you that AI-assisted development is the future of software. They're right. What they're not saying is that "AI-assisted" means something fundamentally different depending on who is doing the assisting — and that those differences compound quietly until they become expensive.

The typical response is to pick a tool, run a rollout, measure adoption. This produces a metric — the percentage of developers who touched the assistant at least once this quarter — that tells you almost nothing about what is actually happening to your software.

What determines the outcome isn't the tool. It's the mental model the person brings to it before they open it. And most organizations have four of those models running simultaneously, often on the same codebase, with no governance structure connecting them.

The Four Mental Models

Let me name them. Naming things is the first step to managing them.

The Vibers

They don't think of AI as a coding tool. They think of it as a direct translation layer between intention and output. You describe what you want, it appears, you iterate until it looks right, you ship. Karpathy described it from the inside: "I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works."

The Vibe Coder's output can be impressive — especially for prototypes and internal tools. The problem isn't the speed. The problem is that this mental model has no mechanism for knowing when something is wrong. The Vibe Coder cannot distinguish between code that runs and code that is secure, maintainable, or aligned with your architecture. Not because they're careless, but because the mental model doesn't include that question.

McKinsey estimates that generative AI could add $4.4 trillion annually to the global economy, with software development among the highest-impact domains. What nobody is tracking is how much of that value will be destroyed by code that runs but was never understood. For every 10 hours of development time saved by AI generation, research estimates 4–6 hours are spent on rework, debugging, and incident response for issues that governance would have caught — meaning the net gain is 40–60% of the headline number, before the first breach. Apiiro analysed Fortune 50 enterprises and found that AI coding tools generated 10x more security findings per month within six months of adoption — with privilege escalation vulnerabilities jumping 322%. The average data breach costs $4.88 million, according to IBM's 2024 report. Code that ships fast without review isn't a productivity gain. It's a liability deferred.

The Skeptics

At the other extreme are experienced developers who adopted AI tools without changing how they review. Willison has articulated this position clearly: "If an LLM wrote every line of your code, but you've reviewed, tested, and understood it all, that's not vibe coding — that's using an LLM as a typing assistant." They read every function the model generates. They treat the assistant like a confident junior developer — talented, but capable of convincing errors.

The instinct is right. The economics are brutal. A 2025 controlled study by METR — tracking 16 experienced open-source developers across 246 real tasks — found that developers using AI while maintaining full review completed tasks 19% slower than without AI at all. The overhead of prompting, waiting, reviewing, and correcting cancelled the generation speedup entirely. Faros AI research tells the same story from the team level: organisations with high AI adoption merged 98% more pull requests — the formal submissions developers make to add code to the shared product — but review time increased 91%. The Skeptic didn't get faster. They just got more to review.

The Skeptic's instinct is correct. The application of that instinct needs to evolve.

The Orchestrators

Nobody predicted this group — and yet in hindsight it was inevitable.

Experienced IT managers and directors looked at AI agents and immediately recognized something familiar. They didn't see a coding tool. They saw a staffing model.

Orchestrators build pipelines. They assign roles — one agent writes, one reviews, one tests, one documents. They define escalation paths. They draft SOPs. Addy Osmani has written about this as "the code agent orchestra" — a conductor model where specialized agents each handle a distinct part of the development lifecycle. GitHub's Squad formalizes exactly this: coordinated AI agents running inside a repository, handling routine tasks autonomously while escalating exceptions to humans.

This mental model is exciting and dangerous in equal measure. It's exciting because the Orchestrators are the first group to think seriously about AI governance — they understand that agents need protocols, just as people do. It's dangerous because agents fail differently than people. People fail visibly, loudly, with explanations. Agents fail silently, confidently, and at scale. An agent producing plausible-but-wrong output passes every review process designed for human failure modes — because reviewers are looking for effort and logic, not for the specific ways AI models produce confident but incorrect answers.

The Orchestrator's framework is right. The failure model needs updating.

The Architects

The smallest group. The most consequential.

They're not asking "how do I use AI to build software?" They're asking "how do I build a system that uses AI to build software — and knows when it's going wrong?"

The distinction sounds academic. It changes everything. A developer using an AI assistant is still a developer who happens to have a fast tool. An Architect who has built an AI-assisted development pipeline has built a factory. The factory has quality gates. It has a constitution — versioned architecture decisions and design constraints that the pipeline checks programmatically: the same judgement a senior architect would apply in a review, encoded as executable rules. And the factory monitors itself.

In practice, it looks like an automated checkpoint in the build process that passes every AI-generated function through an architectural review before it can be accepted — checking outputs against a documented system constitution, flagging violations rather than just logging them. Or a feedback mechanism that captures friction from every specification cycle and feeds it back into improving the system itself. Not just correcting the last error — evolving the rules that prevent the next one.

Chris Argyris called this double-loop learning — the ability to not just correct errors within a system, but to question whether the system's own rules are generating the right corrections. The Architect builds AI pipelines that do exactly this. The governance layer isn't a checklist bolted on at the end. It's an executable structure embedded in the pipeline, continuously monitoring outputs, catching architectural violations before they calcify into technical debt — the accumulated cost of shortcuts that become harder and more expensive to fix the longer they sit in production.

This is how software gets faster, safer, and compliant at the same time. Not by reviewing more carefully. By encoding the review into the system that does the building.

Which Mental Model Is Running Your Organization?

These four groups are not rungs on a skill ladder. They're different orientations to the same technology — and most organizations don't know which ones they have, in what proportion, on which projects.

Mental Model	Sees AI as	Output quality	Hidden risk
The Vibers	A magic interpreter	Variable, fast	Ships code nobody understands
The Skeptics	A powerful but untrustworthy junior	High, slow	19% slower than without AI; becomes the team's bottleneck
The Orchestrators	A virtual team	Scalable, uneven	Agents fail silently; human delegation playbooks don't apply
The Architects	A component in a self-improving system	High, fast, auditable	Requires governance authority most organizations haven't granted

The practical question isn't which mental model is correct. It's which one is running your most important projects right now — and whether that's a choice you made or one that happened by default. Two signals you can read without a survey: look at how long your team spends reviewing AI-generated code before accepting it into the product — a high ratio of review time to actual output is a Skeptic fingerprint. And ask developers directly in a 1:1 what they do with AI output before they submit it. The answer reveals the mental model within two sentences.

Most organizations are accidentally Vibe Coding their critical systems while their Architects are blocked from implementing governance because they haven't been given the cross-team authority to enforce it. That is not a technology problem. It is a leadership problem.

Formula 1 teams don't just race. Between every Grand Prix they analyse telemetry, adjust the car, and return to the track faster, safer, and more consistent than before. The race isn't the unit of improvement — the race generates data. Building software with AI works the same way, but most organisations treat every sprint as a race in isolation: the friction disappears when the sprint ends instead of feeding back into a system that gets better because of it.

The question every technology leader needs to answer before their next planning cycle is not which AI tool to standardise on. It's which mental model their organisation is going to operate at — and who has the authority to enforce it. That is a leadership decision, not a procurement decision. The organisations that reach the Architect stage compress delivery cycles, reduce breach exposure, and — in regulated industries — produce software that can be audited. That last point is not a competitive advantage. It is a licence to operate. Giving the Architect cross-team governance authority is the single move that unlocks all of it: the Vibe Coder gets guardrails they didn't build themselves, the Skeptic gets a certification system to point their instincts at, and the Orchestrator gets a failure model worth trusting. Without that authority explicitly granted, all four mental models keep running in parallel — each optimising for a different definition of done, and the organisation absorbs the cost without ever seeing it on a single line item.

The Tool Trap

The Four Mental Models

Which Mental Model Is Running Your Organization?

References