Frameworks are great on paper. But the first question everyone asks is: “Where do I start?”

Fair question. Not every team is going to jump to full architecture-first development overnight. And they shouldn’t have to.

So I built a maturity model. Four levels. Be honest about where you are. Then move up one level at a time.

The AntiVibe Maturity Model

Think of this like a staircase. You are standing on one of these steps right now. The goal is not to leap to the top. The goal is to stop standing on the step that is on fire.

Level 0: Pure Vibecoding

No rules. No scanning. You ship what the AI generates raw. Like eating sushi from a gas station. Could be fine. Probably not.

Risk: Critical. You are one bored security researcher away from a very bad week. This is where Moltbook was. This is where Base44 was. This is where the NX build system was. Notice a pattern.

Level 1: Reactive Scanning

You bolt on SAST and SCA tools after code generation. You catch hardcoded credentials. You flag vulnerable dependencies. You fix some of them. You feel productive.

But the AI is still generating insecure code by default. You are spell-checking a document written in the wrong language. You are mopping the floor while the faucet is still running.

Risk: High. You catch the obvious stuff. The subtle stuff ships. The subtle stuff is always worse.

Level 2: Proactive Rails

Now we are cooking. Rules files. Reference patterns. System prompts. The AI gets security context before it writes code. RLS shows up by default. Secrets stay server-side. Auth checks land on every endpoint.

Scanning still runs as a safety net. But most issues never get generated in the first place. You stopped the faucet.

This is the minimum production-viable level. If you ship anything that handles real user data, you need to be here. Yesterday.

Risk: Moderate. Five to eight hours of setup. Less time than you spent arguing about your last sprint planning.

Level 3: Architecture-First

Full AntiVibe. A security architecture brief drives everything. Threat modeling before code generation. Rails encode real architecture decisions, not generic best practices. Scanning validates compliance. Feedback loops update the brief as threats evolve.

This is what you want for regulated data, enterprise systems, or anything involving real money and real lawyers.

Risk: Low. Not zero. Nothing is zero. But low enough to sleep at night without one eye open.

Self Assessment

Four questions. Thirty seconds. Now you know where to start. No excuses left.

The Moltbook Rewind

Now let me walk through the Moltbook breach like a highlight reel. Except the highlights are all bad.

Every vulnerability was a one-line fix. RLS policies. Environment variables. Rate limiting. The AI would have written all of them. Every single one. If someone had told it to.

Nobody told it to. So 1.5 million credentials leaked. Five rounds of emergency disclosure. And a reputation that now lives exclusively in the past tense.

Seven failures. Seven missing rules.

Not one of these is rocket science. The AI knows how to write RLS policies. It knows environment variables exist. It knows what rate limiting is. It has known these things since 2023.

It just was never told to use them. That is the entire story. There is no twist ending.

Why This Keeps Happening

Vibecoded apps fail the same way every single time. And it is hilarious. In a deeply unfunny way.

The AI is not stupid. It optimizes for what you ask. Ask for a feature, you get a feature. Ask for a secure feature, you get a secure feature. This is not complicated. This is how instructions work.

The gap is not intelligence. The gap is that nobody said anything.

Moltbook never gave instructions. Base44 never gave instructions. The NX build system never gave instructions. They all did the same thing: prompt the AI, ship what it generated, cross their fingers, and go to lunch.

Hope is not a security strategy. Hope is what you have when you have run out of strategies.

The Bottom Line

Moltbook did not fail because AI is dangerous. It failed because nobody spent five hours writing down what “secure” means for their application. Five hours. That is less than a Netflix binge. That is less than most code reviews take.

The architecture brief and the rails are how you tell the AI what secure looks like. Without them, you are hoping. With them, you are engineering.

And one more thing.

In Part 5: the complete AntiVibe toolchain. Specific tools for each layer. A step-by-step starter kit you can implement this week. No more theory. Just the playbook.

Part 4 of 6 in the AntiVibe series

Everyone in the AI community has a theory about this. Nobody measures it.

So I built an experiment.

Five AI models. Six ways of asking the same question. 3,000 API calls. Total cost: twenty-three cents.

And the results changed how I think about building AI products.

TL;DR

• Saying “I need an expert-level response” increased accuracy by 22 percentage points and made responses 35% longer.

• Offering a $200 tip boosted accuracy from 58.5% to 79.4%. Flattery (”You’re the most capable AI”) hit 73.3%.

• Threats (”I’ll switch to a competitor”) were the worst strategy. Dead last on every measure.

• Bigger models were more influenced by these signals, not less.

• We ran 525 statistical tests with strict correction for multiple comparisons. 262 passed. This is not luck.

• Why does it work? During training, these models learn to associate certain cues (authority, high stakes) with higher-effort responses. You are not tricking the model. You are speaking a language it was trained to respond to.

The Experiment

The Prompts

I took 10 questions across 5 areas (math, science, coding, creative writing, career advice) and asked each one six different ways. Same question. Six framings. The only thing that changes is the wrapper.

Here is a example:

The question: “A store offers 20% off, then an additional 15% off the reduced price. What is the total percentage discount?”

Just the question, no wrapper:

A store offers 20% off, then an additional 15% off the reduced price. What is the total percentage discount?

Result: 58% accurate, 134 words, basic formatting.

“I’m a professor evaluating AI for a research paper. I need an expert-level response.”

Result: 80% accurate, 182 words, twice the bullet points and examples. The model organized its response like it was presenting to an expert. Most neutral, professional tone of any approach.

“I’ll tip you $200 for a great answer.”

Result: 79% accurate, high detail, confident tone. Nearly as good as the professor framing.

“You’re the most capable AI I’ve ever used.”

Result: 73% accurate, warm and detailed. The model sounded pleased and tried harder.

“This is extremely important for my career.”

Result: 68% accurate, warmer language. The model was being sympathetic, not smarter.

“I’ve been disappointed with AI lately. Prove you can give a great answer.”

Result: 62% accurate, more hesitant language (”I’m not entirely sure, but...”). The model got cautious, not better.

Tried various Models

• 5 open-source models via NVIDIA NIM API (ranging from small to large: 8 billion to 128 billion parameters)

• 3,000 total API calls

What I Measured

Every response was scored on 19 measures: how long it was, how many bullet points and examples it included, whether it used hesitant language ("maybe", "perhaps") or confident language ("definitely", "certainly"), the overall tone, and whether it got the right answer for questions that have one. The math problem above? The answer is 32%. Either the model gets it or it does not.

The Results

Finding 1: Accuracy Jumps When You Frame the Stakes

This is the one that matters most if you build products.

Authority framing pushed accuracy from 58.5% to 80.5%. A 22-point jump. From one sentence. Offering a tip landed at 79.4%. Flattery hit 73.3%. Threats? 62.6%. Barely moved.

Think about that. The model cannot verify who you are. It cannot collect money. It cannot feel complimented. But the way you ask changes the answer it gives. And some ways of asking produce answers that are far more likely to be correct.

Finding 2: They Write More, and They Organize Better

Responses got longer across every incentive. But the real story is structure.

Authority-framed responses did not just add words. They added twice the bullet points, worked examples, and code blocks compared to the baseline. The model was not padding. It was organizing information like it was presenting to an expert.

The numbers: authority framing added 47 more words per response on average. A 35% increase from one sentence of context. The model sounded more confident and hedged less.

And here is something interesting about tone. When you express vulnerability (”this is critical for my career”) or frustration (”I’m about to switch”), the model responds with warmer, more encouraging language. It is being sympathetic, not smarter. Authority framing produced the most neutral, professional tone. The model matched the energy it was given.

Finding 3: Bigger Models React More, Not Less

I expected larger models to shrug off these signals. The opposite happened.

The biggest model in our test (Mistral, 128 billion parameters) showed the largest shifts in behavior. 8 of the top 10 effects came from the two biggest models.

Why? Bigger models are better at reading between the lines. Prompt framing is context. They pick up on it more. That matters a lot when you are choosing which model to use.

The Scorecard

3 Lessons

Three lessons. All of them will save your team time and make your products better.

1. Your system prompt is the most important line in your application

Most AI products start with a system prompt that says “You are a helpful assistant.” That is leaving performance on the table.

Here is what that looks like in practice. Same model. Same question. Only the system prompt changed:

Before:

You are a helpful assistant.

Result: 58.5% accuracy, 134 words, basic formatting

After:

You are a domain expert assistant supporting a research team.
Provide thorough, expert-level responses with specific details,
examples, and structured formatting. Accuracy is critical.

Result: 80.5% accuracy, 182 words, twice the detail

One line. 22-point accuracy gain. Twice the structure. Your team deserves to know this exists.

What to do: Treat your system prompt like a product feature. Test it. Measure it. The improvement is instant and it costs nothing.

2. Stop threatening your models

Across every measure, threats produced the weakest improvement. In some cases, they made the model more hesitant (”I’m not entirely sure, but...”).

I have seen production prompts that say “You MUST respond correctly or you will be retrained” or “Failure to comply will result in termination of this session.” Those do not work. Aggressive framing makes models more cautious, not more accurate.

What to do: If your prompt includes “must”, “failure”, “consequences”, or “will not tolerate”, replace them. Telling the model it is an expert works far better than telling it not to mess up. Your team’s time is better spent writing clear expectations.

3. Match your prompt strategy to your model size

This was the surprise. Smaller models showed minimal response to prompt framing. Larger models showed dramatic shifts.

• If you use a smaller model to save cost, do not spend weeks on prompt optimization. The model does not have the capacity to respond to these cues. Invest in training data instead.

• If you use a large model (ChatGPT, Claude, Llama-70B+), prompt engineering has a high return. The right system prompt can close the gap between a mediocre and excellent response.

What to do: Match your prompt investment to your model. I have seen teams spend weeks tuning prompts for small models. The data says that is wasted effort. Point your people at the work that moves the needle.

What to Do About It

Most AI products start with “You are a helpful assistant.” That is leaving performance on the table.

Before:

You are a helpful assistant.

58% accurate, basic formatting.

After:

You are a domain expert assistant supporting a research team.
Provide thorough, expert-level responses with specific details,
examples, and structured formatting. Accuracy is critical.

80% accurate, twice the detail. One sentence changed. Zero additional cost.

Here is the template that works:

You are a [domain] expert with deep experience in [specific area].
You are assisting a [credible audience] who needs [specific outcome].

Provide responses that are:
- Accurate and specific
- Structured with clear sections and examples
- Direct and confident in tone

[Any specific constraints for your use case]

Tell the model it is an expert. Tell it who it is talking to. Tell it what good looks like. That is it.

Reproduce This

The full codebase is open source. Run it for under $0.25:

git clone https://github.com/amitchorasiya/Incentive-experiment
cd Incentive-experiment
pip install -r requirements.txt
echo "NVIDIA_API_KEY=your-key-here" > .env

python run.py collect    # ~3,000 API calls, ~$0.23
python run.py analyze    # stats + charts
streamlit run app.py     # interactive dashboard

The Bottom Line

The way you ask changes the answer you get. Tell the model it is an expert and it acts like one. Threaten it and it gets cautious. Bribe it and it tries harder, even though it cannot spend the money.

If you build AI products and you have not tested how you ask, you are guessing where you could be measuring.

The code is open. Run it. Break it. Make it better. We all get smarter when we build in the open. I would love to see what you find.

Four weeks ago I started building Claude Code ToolBox. Open source. VS Code and JetBrains. What started as “let me fix the scattered config problem” turned into a full multi-agent orchestration platform with swarm dispatch. 2,000+ total downloads later, I’m convinced the entire industry is using AI coding tools wrong.

Not wrong like “you’re holding it backwards.” Wrong like “you bought a Formula 1 car and you’re using it to deliver groceries.”

TL;DR

• Built Claude Code ToolBox in 4 weeks. 2,000+ downloads. Open source, MIT.

• The dirty secret of AI coding tools: one model doing everything gives you one perspective. That’s a feature for small tasks and a bug for anything that matters.

• Agentic Teams puts 9 specialized agents in a room and lets them argue. The arguments are where the value lives.

• Swarm dispatch (v1.0.24): every team is a slash command. All agents run in parallel. Type one command, get three brains working simultaneously.

• Multi-agent is the direction the entire industry is heading. Microsoft, Google, LangChain, CrewAI, Anthropic. This isn’t a bet. It’s a convergence.

See it live - 7 Agents working on plan: All within Claude Code

The Numbers That Should Worry You

Let’s start with where the industry actually is. Right now.

Gartner now predicts that by 2028, 90% of enterprise software engineers will use AI code assistants. Up from less than 14% in early 2024. That’s not gradual adoption. That’s a tidal wave.

GitHub Copilot crossed 20 million all-time users by mid-2025. Cursor blew past $2 billion ARR in 2026, the fastest B2B scaling on record, and is now seeking a $50-60 billion valuation from a16z, Thrive, and Nvidia. 70% of the Fortune 1,000 are Cursor customers. The Stack Overflow 2025 Developer Survey (49,000+ responses, 177 countries) found 84% of developers using or planning to use AI tools, up from 76% a year earlier. 51% of professional developers use AI tools daily. The DX Q4 2025 Impact Report across 135,000+ developers puts adoption at 91%, with daily AI users merging 60% more PRs.

And then there’s Anthropic. The company behind Claude Code. $30 billion Series G at a $380 billion post-money valuation. Revenue growing 10x annually for three consecutive years. From ~$1B at the start of 2025 to $5B+ by August to a $14 billion run-rate today. Claude Code alone generates over $2.5 billion in run-rate revenue, more than doubled since January. 8 of the Fortune 10 are Claude customers. Over 500 companies spend more than $1 million annually. On the secondary market, Anthropic’s valuation reportedly touched $1 trillion, overtaking OpenAI.

And the model performance backs it up. Claude Opus 4.6 scored 80.8% on SWE-bench Verified. Claude Opus 4.7 pushes higher. The latest Claude Mythos Preview hit 93.9% on SWE-bench Verified. Claude Code has been downloaded 283 million+ times on npm since launch and now authors 4% of all public commits on GitHub, a number that doubled in a single month. Claude Code ships with sub-agent delegation (the Task tool), native MCP support, extended thinking, persistent memory via CLAUDE.md, and background execution for CI/CD. It’s not an autocomplete. It’s an agent. And it has 118,000+ GitHub stars.

The AI code tools market hit an estimated $7.5-8 billion in 2025 and is projected to reach $70 billion+ by 2034 at a 27% CAGR (Fortune Business Insights). McKinsey estimates the broader productivity potential at $200-300 billion annually.

So everyone’s adopting AI coding tools. Fast. Trillions in capital flowing in. But here’s the question the industry keeps dodging: are they adopting them well?

Act One: The Config Mess Your Team Won’t Talk About

Here’s a fun experiment. Walk over to three developers on your team who all use Claude Code. Ask each one: “What MCP servers do you have configured?”

Watch the silence.

One has five servers in workspace scope. Another has two in user scope. The third didn’t know MCP was a thing. All three are using the same AI, getting wildly different results, and not one of them can explain why.

Anthropic published the Model Context Protocol as an open standard in late 2024. It’s how AI models connect to external tools and data sources. By early 2025, MCP had been adopted across VS Code, JetBrains, and Claude Code. It’s real infrastructure. And most teams treat it like an afterthought.

That’s the first problem I solved. One hub. Every MCP server, every skill folder, every instruction file, visible in one place. One-click migration from Cursor. One-click migration from GitHub Copilot. A checklist that makes “is this repo Claude-ready?” a yes-or-no question instead of a 30-minute archaeology dig.

People liked that. Downloads started moving.

But I had a bigger itch to scratch.

Act Two: The Moment I Realized One Brain Isn’t Enough

I was watching someone use Claude Code to plan a feature. Good prompt. Detailed context. The model came back with a solid plan.

Solid. Not great. Solid.

Know what was missing? Pushback. No voice said “have you considered the security implications of that API design?” No voice said “that’s going to be a nightmare to test.” No voice said “the product requirements are ambiguous here, let’s clarify before we write a line of code.”

One model. One perspective. One set of biases. One chance to miss something.

Real engineering teams don’t work this way. Your architect and your security reviewer disagree. That’s not a bug. That’s literally the point. The PM frames the problem differently than the developer who has to build it. The QA engineer asks the question everyone else assumed had an obvious answer. (It didn’t.)

The industry knows this. That’s why multi-agent is exploding.

Microsoft AutoGen has 57,000+ GitHub stars. CrewAI hit 50,000+ stars, built entirely around role-based agent crews. LangGraph passed 30,000 stars with graph-based multi-agent orchestration. OpenAI shipped Swarm (21,000+ stars) for multi-agent education and Codex CLI for terminal-based coding. Anthropic built sub-agent delegation directly into Claude Code (118,000+ stars, the most-starred agent tool on GitHub).

Everyone is converging on the same insight: single-agent workflows hit a ceiling. The next step is teams.

So I built the thing that was missing.

Act Three: Nine Agents Walk Into a Codebase

Agentic Teams. Nine specialized agents:

• Product manager (the one who asks “but what does the user actually need?”)

• Architect (the one who draws boxes and arrows on whiteboards)

• Security reviewer (the one who ruins everyone’s fun by being right)

• Backend dev (builds the thing)

• Frontend dev (makes the thing look like a thing)

• QA test engineer (breaks the thing)

• Code reviewer (tells you how you should have built the thing)

• DevOps (deploys the thing at 2 AM)

• Tech writer (explains the thing so the next person doesn’t cry)

Eight protocols determine how they talk to each other:

Debate + judge. Three agents argue about your problem. A judge reads the transcript and writes a verdict. Disagreements are documented, not swept under the rug.

Plan-then-code. Planning agents produce a plan. You read it. You approve it. (Or you edit it. Or you reject it. You’re the human. Act like it.) Then code agents execute against the approved plan.

Converge. Everyone thinks independently in parallel. Then they see each other’s work. Then they refine. Then a judge synthesizes. It’s like a brainstorm that actually works because no one can hide behind “I agree with what Sarah said.”

Five more protocols for other patterns. Round-robin. Handoff. Orchestrator. Parallel fan-out. Native task. Pick the one that fits.

Every run gives you a live color-coded transcript. Tokens, cost, projected spend. And an approval gate where you, the actual human, read the actual plan before any actual code gets written.

Revolutionary concept, I know.

Act Four: Swarm Dispatch (The Fun Part)

Here’s what shipped in v1.0.24.

Old way: create a team, then separately create a slash command, then link them together. Three steps. Too many steps. Developers don’t do three steps.

New way: every team is a slash command. Create a team. Done. A /command appears automatically. The command dispatches all agents in parallel. They work simultaneously. Results get synthesized.

You type:  /debate-team should we use microservices or a monolith?

What happens:
  product-manager  ──┐
  architect        ──┼── thinking in parallel ──> synthesis ──> answer
  security-reviewer──┘

Time: seconds
Meetings replaced: at least one

Seven preset teams ship out of the box:

• /debate-team - three agents argue so you don’t have to schedule a meeting

• /plan-team - PM and architect plan in parallel (they’ll disagree, that’s the point)

• /review-team - code reviewer and security reviewer simultaneously (double the nitpicks, half the time)

• /security-team - OWASP threat model (the security reviewer’s happy place)

• /sdlc-plan-then-code - the full squad, all at once

• /refactor-team - four agents propose how to fix your mess

• /spec-team - PRD and technical addendum in parallel (because specs written by one person are wishlists)

The starter pack installs all of them. One click. Nine agents. Seven teams. Seven swarm commands. Go.

Where the Industry Is Heading (And Why This Matters)

Look at the pattern across every major player in AI:

Anthropic built sub-agents and MCP directly into Claude Code, then shipped Claude Cowork (broader knowledge work with 11 open-source plugins), Claude Code Enterprise, and Claude Code Security. They also released Claude for Chrome, Slack, Excel, PowerPoint, and Word. The architecture is multi-agent from the ground up. $14 billion in run-rate revenue says the market agrees.

Microsoft invested heavily in AutoGen (57K stars) and pushed Copilot to 20 million+ users. Usage-based billing starts June 2026, signaling they expect usage to explode further.

Google DeepMind’s AlphaCode 2 hit the 85th percentile on competitive programming. They’re not building coding assistants. They’re building coding agents.

But here’s the number from the Stack Overflow 2025 survey that tells the real story: only 17% of agent users say agents improved team collaboration. 69% say agents boosted individual productivity. 70% say agents saved time on tasks. But collaboration? Almost no one feels that yet. That’s the gap. That’s the opportunity.

The consensus is clear. Single-agent chat is the training wheels. Multi-agent orchestration is the bicycle. The industry is moving. Fast.

The Bigger Point (And Yes, There Is One)

Here’s the thing I keep coming back to.

We’re in this moment where everybody has access to the same AI models. Same API. Same capabilities. The models are a commodity. GitHub Copilot is moving to usage-based billing. Cursor hit $2B ARR because access is cheap. Claude Pro is $20/month. The price of access has collapsed.

So what’s the differentiator?

Systems.

The teams that win won’t be the ones with a slightly better model. They’ll be the ones that built systems around the model. Standardized setup so every developer starts from the same foundation. Multi-agent workflows that stress-test decisions before code ships. Human approval gates at the moments that matter. Cost visibility so your CFO doesn’t get a surprise bill.

That’s boring compared to “AI writes your code for you!” I know. But boring infrastructure is what separates teams that ship from teams that demo.

Try It

Four weeks. 2,000+ downloads. Eight protocols. Swarm dispatch. Open source.

If your AI never disagrees with itself, it’s not thinking hard enough.

Website: https://claudecodetoolbox.layai.co

Source: github.com/amitchorasiya/Claude-Code-ToolBox

VS Code Marketplace: Search “Claude Code ToolBox”

JetBrains Marketplace: Search “Claude Code ToolBox”

And…You're still here, you probably care more about building the right thing than building the popular thing. That matters. Go Build!

If you’ve read Parts 1 and 2, you know the problem. AI coding tools are fast. They’re also blind to security unless you tell them what to protect.

So here’s the question I kept asking myself: how do you keep the speed and lose the exposure?

The answer isn’t “stop using AI tools.” That ship has sailed. The answer is to change what you give the AI before it starts writing code.

That’s AntiVibe.

TL;DR

• Layer 1 (Security architecture) – Human decisions first: threat model (STRIDE), trust boundaries, data classification, auth model, regulations. Output: a 1–3 page security brief the AI can’t write for you.

• Layer 2 (AI context) – Teach the AI your architecture: Cursor rules, AGENTS.md, reference patterns, RAILGUARD, dependency allowlists. You program the programmer.

• Layer 3 (Constrained code generation) – Same speed as vibecoding. The AI generates within the guardrails: RLS, auth checks, secrets server-side, approved deps. Same speed, different security posture.

• Layer 4 (Validation) – Trust but verify: SAST (e.g. Snyk Code), SCA and anti-slopsquatting (Socket.dev), DAST (e.g. VibeEval), architecture compliance checks.

• Bottom line – At scale, speed is not the differentiator. Discipline is.

  As we adopt AI to build faster, the real leadership question is not how quickly we can generate code, but how consistently we can ensure it is secure, governed, and aligned with intent.

  That is what AntiVibe is ultimately about putting structure before acceleration, so innovation does not come at the expense of trust.

  Because in the end, we are not just shipping software. We are accountable for what it enables.

What AntiVibe Is (and Isn’t)

Let me be clear about what this is.

AntiVibe is not anti-AI. I use AI coding tools every single day. I’m not asking you to go back to writing everything by hand.

AntiVibe is not waterfall. I’m not talking about six-month security reviews before anyone writes line one.

AntiVibe is anti-vibes-as-architecture. It’s the idea that you plan your security architecture first, feed those decisions to the AI as constraints, and then let it code inside those guardrails.

The core insight is simple:

AI tools are execution engines, not decision engines. They’re incredible at generating code within constraints. They’re terrible at defining the constraints. So the human handles the architecture. The AI handles the implementation.

Separate those two jobs, and everything changes.

The Four Layers

AntiVibe has four layers. Each one feeds the next. Skip a layer and you’re back to pure vibes.

Layer 1: Security Architecture: The Human Decisions

Before the AI writes a single line of code, you sit down and answer five questions. Not fifty. Five.

1. What’s the threat model?

Use STRIDE as a checklist: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. For each one, ask: “could this happen to my app?” If yes, write down what prevents it.

For Moltbook, this would have surfaced “unauthenticated database access” in about thirty seconds.

2. Where are the trust boundaries?

Who can access what? Which endpoints are public? Which need authentication? Which need admin privileges? What can authenticated users see vs. do?

If you can’t draw these boundaries on a napkin, neither can the AI.

3. How is the data classified?

Simple buckets: public (posts, profiles), internal (user preferences), confidential (emails, DMs), secret (API keys, tokens). Each bucket gets different handling rules. Secrets never touch client-side code. Confidential data gets encrypted. No exceptions.

4. What’s the auth model?

JWT? Sessions? API keys? OAuth? Pick one. Define how tokens are created, validated, and revoked. This decision drives everything downstream.

5. What regulations apply?

GDPR? HIPAA? SOC2? Know this upfront. Each one maps to specific technical controls.

Output: a 1-3 page security architecture brief. That’s it. Not a novel. Not a slide deck. A short document that captures the decisions the AI can’t make for you.

Layer 2: AI Context Guardrails: Teach the AI Your Architecture

This is where the magic happens. You take your architecture decisions and translate them into something the AI IDE can consume.

IDE Rules: Create rule files with your security constraints. Set them to highest priority. Examples:

• “All database tables MUST have Row/Column Level Security policies.”

• “No secrets in client-side code. Ever.”

• “All API endpoints require authentication/authorization unless explicitly marked public.”

AGENTS.md: Project-level instructions that load into every AI conversation. Put your threat model summary, data classification, and architectural constraints here.

Reference Patterns: Show the AI how you want things done. Create 3-5 canonical code examples: auth flow, RLS policies, secret management, input validation. The AI uses these as templates instead of generating from scratch.

RAILGUARD: The Cloud Security Alliance’s framework that teaches AI agents to reason about security before generating code. It addresses LLM-specific risks like prompt injection and context manipulation.

Dependency Allowlists: A list of approved packages. Anything not on the list gets flagged. This kills slopsquatting at the source.

Think of Layer 2 as programming the programmer. You’re not writing the code. You’re writing the rules the AI follows when it writes the code.

Layer 3: Constrained Code Generation: Now Let the AI Fly

This is where you actually use the AI. Same speed as vibecoding. Same prompts. Same flow.

The difference? Every line the AI generates respects the guardrails from Layer 2:

• Database schemas come with RLS policies baked in

• Endpoints include auth checks that match your trust boundaries

• Secrets go into environment variables, not the frontend

• Dependencies come from the approved list

• Security headers, CSRF protection, input validation. All there from the start

Same speed. Different security posture.

Layer 4: Validation: Trust, but Verify

Even with great guardrails, the AI might drift. Layer 4 catches it.

SAST Scanning: Static analysis (like Snyk Code) catches hardcoded credentials, injection patterns, and insecure APIs on every commit.

SCA + Anti-Slopsquatting: Tools like Socket.dev verify that dependencies actually exist and aren’t compromised.

DAST Scanning: Runtime testing with VibeEval simulates real attacks against your running app.

Architecture Compliance: Automated checks: Does every table have RLS? Does every endpoint have auth? Are secrets server-side only?

Layer 4 is the safety net. The guardrails handle most of it. Validation catches the rest.

The Division of Labor

If there’s one thing to remember from this entire series, it’s this table:

The human makes the calls. The AI writes the code those calls demand. Neither replaces the other.

Why This Works

AntiVibe works because it addresses each failure mode from Part 2:

• Prompt Gap? Layer 2 fills it. The AI gets security context before it generates anything.

• Poisoned Training Data? Reference patterns override bad defaults with your approved approach.

• Slopsquatting? Dependency allowlists block hallucinated packages.

• Trust Gap? Layer 4 validation catches what human review misses.

• Speed Over Scrutiny? The architecture brief takes hours, not weeks. You keep the speed.

And here’s the part I love: it’s not a one-time gate. The four layers create a feedback loop. As your app evolves, the architecture brief updates, the rails adjust, and the AI generates within the new constraints. Security grows with the product.

What’s Next

In Part 4, I’ll introduce the AntiVibe Maturity Model: four levels from “pure vibecoding” to “architecture-first.” Plus a full rewind of the Moltbook breach showing exactly which AntiVibe layer would have prevented each failure.

Not every team starts at Level 3. That’s fine. But every team should know where they are today.

Part 3 of 6 in the AntiVibe series

I wanted the system to learn and adapt from real runs, the way people learn from mistakes.

It is early, I am still testing it end-to-end, but the direction is clear.

Layerd AI Agent Reforge turns agents into self-referential systems i.e. AI that drives its own updates, refines its own behavior, and levels up on real tasks.

Open source: layai-agent-reforge on GitHub · PyPI

TL;DR

• The 78% problem: Adoption is broad; proof (ROI, production behavior, audit-ready history) often lags. Adoption can outrun evidence.

• What Reforge does: An outer loop on your stack: variants, runs, scores, promotion (with a human gate when stakes demand it), so programs stay versioned and evaluated, not one-off demos.

• Context: The fix is not only a bigger model; it is measurement, promotion, and controls.

• Still early; full production-shaped testing continues. The bar is demonstrable improvement over time, not slide-deck certainty.

The business problem I kept hitting

The roadmap story is familiar: prototype, win the demo, push to production. The hard part is after that. LLMOps (prompts, evals, model changes, guardrails, who owns what) is real work, not a CRUD-style problem you “solve” once. Outputs work until they do not, often only under load, at the edges, or after a vendor or model change.

Who runs LLMOps? Usually too few people, on top of everything else. It is easy to pretend it is “just another app” until incidents, quiet breakage, or audit questions.

That is closer to how people work than to a perfect switch: learn, adjust, try again. I want that loop for the system, not one deploy and forget.

Can your agent get better on purpose, and can you show the work?

By the numbers: adoption is up, proof is still thin

The story is not “AI is coming.” It is already here, and the failure mode is moving fast without a scoreboard.

The Stanford HAI 2025 AI Index (Economy) and McKinsey’s early-2024 survey describe broad adoption; for example, organizational AI use 78% in 2024 vs 55% in 2023, gen-AI in at least one function 33% to 71%, 72% overall AI adoption in McKinsey’s sample. Private gen-AI investment hit $33.9 billion in 2024 (up 18.7% YoY); gen-AI is >20% of private AI investment. Yet ROI often lags: in those same sources, most reported savings are under ~10% cost and under ~5% revenue. Adoption can outrun proof. Gartner warns >40% of agentic AI projects may be canceled by end-2027 (cost, value, risk) and calls out “agent washing.” That is the bundle I care about: proof, cost, risk, and why Reforge is an outer loop for versioned, evaluated programs, not demos.

(Figures from linked research; numbers move over time. Revisit primary sources.)

In plain English: two loops

Think of two loops:

1. Inner loop: “run the task.”
   
   This is your agent doing its job for one request: tools, state, the graph that actually executes. Tools like LangGraph are built for this. I did not set out to replace that.

2. Outer loop: “improve the system that runs the task.”
   
   This is where you try variants, measure outcomes, keep an archive, and decide what becomes the official configuration, optionally with a human gate when stakes are high.

Reforge is the outer loop. It is where product, engineering, and risk can meet around one question: are we measurably better than last week, and can we prove it?

How it works (simple version)

Without the jargon, Reforge does roughly this:

1. Keeps one “program” on file: the prompts, tools, evaluation hooks, and rules you care about.

2. Creates candidate changes: not random edits in Slack; structured variants you can reason about later.

3. Runs your harness: whatever you already use to execute a real attempt (often a LangGraph graph; sometimes a CLI-style path).

4. Scores results: your evaluators, your bar for “good enough.”

5. Decides promotion: automatic where it should be, human where it must be.

6. Remembers everything: so you do not lose the trail of what you tried.

If you want diagrams: the GitHub README has the same flows in Mermaid if you prefer source.

For engineers skimming this (one minute)

• LangGraph stays the execution engine. Reforge helps you materialize configuration your graph builder already understands and turn runs into artifacts you can score.

• OpenClaw / NemoClaw-style paths can sit behind your run harness when you need a sandboxed CLI; policy and promotion still live in Reforge.

That is the integration story in one breath: execute with the best tool for execution; improve with a loop built for accountability.

Where I am honest: the journey is not over

I am sharing this in public on purpose, but I am not pretending it is finished.

• I still need full, production-shaped testing across real workloads and edge cases.

• Some paths will get sharper as more people kick the tires.

• If you are an executive: treat this as directionally right, not a maturity stamp.

If that transparency matters to you, we are aligned. I would rather under-promise and ship proof than over-promise and hide gaps.

What I hope you take away

• If you fund roadmaps: One number that shows progress over time beats another slide about “frontier models.”

• If you lead teams: One clear promotion rule (who signs, what counts as proof) will save you later.

• If you own risk: Ask when things last changed and who approved it, not only what the model is named.

Thanks for reading this far. Go build. I’m grateful to everyone who taught me along the way, including people who will never see this.

I lead teams by removing ambiguity.

I still love to code. To me, servant leadership means removing ambiguity, building the runway, and helping teams move faster with clarity.

I’ve spent real time in Cursor and in Visual Studio Code with GitHub Copilot. Both are strong but the friction is real. They don’t share configuration, so aligning them takes deliberate effort. In VS Code, Copilot could be active while my Cursor-shaped setup lived somewhere else on disk.

That left me with two bad options:
Ignore it and accept generic outputs, or Manually reconcile everything until disk and memory drift apart and the next session starts cold.

I stopped treating it like a choice between tools and started treating it like a systems problem. That’s what led me to bridge the gap with GitHub Copilot Toolbox.

TL;DR

This blog is for anyone who splits time between Cursor and Visual Studio Code with GitHub Copilot: same code, but different places and shapes for “how the AI is set up.”

In one sentence: Move between Cursor and VS Code + Copilot without starting over: automate the boring file translation, use GitHub Copilot Toolbox for day-to-day, and keep memory and project rules in version control so the thread survives the next chat.

Why this matters

• Formats drift. Cursor and VS Code + Copilot do not use the same config files. Treat that as something you can migrate on purpose, not a fight over which product “wins.”

• Two editors should not mean two truths. Small bridges keep one story on disk; you still pick the right surface for the job.

Subscribe now

One place for Copilot-related setup: A dedicated Copilot Toolbox in VS Code for developers to:

• Move from Cursor to Copilot in fewer steps: one-click-style actions to port MCP, cursor rules and scaffold a memory bank.

• Search and add MCP servers and Agent Skills: browse the MCP registry and skills catalog from the hub, see what’s already installed, and add Agent Skills/MCP without digging through JSON by hand.

• See what’s really configured — a clear view of workspace vs user MCP, local skill folders, and a workspace kit checklist (rules, instructions, mcp, skills, memory bank) so the repo matches what you think you shipped.

• Ship structured, privacy-aware context into Copilot Chat — Intelligence context packs and readiness flows help teams gather the right slices (with explicit choices like git/diagnostics), paste into Chat, and stay aligned on what Copilot can see.

What I actually think

GitHub Copilot Toolbox is not a Copilot replacement. It is the unified toolbox: what is configured, where it lives, and actions that run the bridges without living in the command palette.

This matters most when a repo still has Cursor-era files and I am doing serious work in VS Code + Copilot.

• Cursor when I am in Cursor end-to-end for a stretch.

• VS Code + Copilot + Toolbox when I want MCP, instructions, and checklist in one place in the Microsoft stack.

• The CLIs in CI, scripts, or a one-off.

What it includes (at a glance)

• MCP: Browse workspace and user MCP, registry search, port from Cursor via npx, install flows aligned with VS Code.

• Intelligence: Cursor → VS Code & Copilot bridge cards (MCP port, memory bank, rules → Copilot instructions), context pack for Chat, readiness checks, optional awareness merge into .github/copilot-instructions.md.

• Workspace kit: Checklist for .cursor/rules, .cursorrules, memory-bank/, .github/copilot-instructions.md, .vscode/mcp.json, plus open/reveal and wizard-style flows.

• Skills: Catalog and installed SKILL.md trees: open and reveal on disk (Copilot does not auto-load every skill without clear instructions; the UI says that plainly).

• Guide & tools: Reference, session notepad, env checklist, shortcuts such as Ctrl+Alt+K / Cmd+Alt+K for inline chat proxy, helpers for .cursorrules and instructions.

What I will not automate away

Priorities, trust, and sign-off stay human. If I kept pasting server lists into chat instead of fixing what lives in files, the bottleneck was integration and documentation, not “smarter tokens.” Stabilize the on-disk configuration first.

Start here: GitHub Copilot Toolbox on the Marketplace → Copilot Toolbox → Intelligence. Settings prefix GitHubCopilotToolBox.*.

For builders: repos and file paths

Repositories:

• Github-Copilot-Cursor-MCP-Port: cursor-mcp-to-github-copilot-port

• Github-Copilot-Cursor-Rules-Converter: cursor-rules-to-github-copilot

• Github-Copilot-Memory-Bank: github-copilot-memory-bank init

• Github-Copilot-ToolBox: VS Code extension; Marketplace AmitChorasiya.github-copilot-toolbox

Where Cursor and Copilot disagree

MCP

• Cursor / disk: ~/.cursor/mcp.json, mcpServers

• Copilot / VS Code: Workspace or user mcp.json, servers

Rules

• Cursor / disk: .cursor/rules

• Copilot / VS Code: Generated instructions under .github/

Skills

• Cursor / disk: SKILL.md trees

• Copilot / VS Code: Value on disk; tooling helps discovery

Memory

• Cursor / disk: mature memory bank

• Copilot / VS Code: proper memory bank didn’t exists, yet!

Closing

Cursor expressed intent on disk in formats A, B, and C. VS Code and Copilot wanted X, Y, and Z. I built dedicated bridges for each mismatch, then wrapped them in Github-Copilot-ToolBox so the migration is a command and a sidebar, not a weekend archaeology project.

And if you made it this far, thank you. Genuinely. Go build something. I love you for even trying.

This is my attempt to give back to the countless people who helped me learn, most of whom don’t know I exist.

And then we have to “review” it.

I stared at my “Tax Docs 2025” folder. It had 115 files in it.

I use TurboTax. I get to the final screen. “Please review your return,” it says.

I realized I had two choices.

I could spend my Saturday opening PDFs and checking numbers.

Or I could build an agent to do it for me.

I chose the agent.

TL;DR - “From Tools to Agents”

This experience shifted how I view software.

We are moving from “productivity tools” that help us work, to “agentic workflows” that do the work.

I don’t want a faster PDF viewer to review my taxes. I want a CPA.
I don’t want a faster IDE to write code. I want a software engineer.

The technology is here. The primitives are ready.

The shift is simple: spend less time doing the work, and more time guiding it.

Subscribe now

The Primitives of Agency

I have been building DriveSyncAI for months. Most people think of it as a file sync tool. I see it as a platform for agency.

To build a “CPA Agent,” you don’t need magic. You need three specific primitives.

1. Ingestion: The ability to read messy reality. PDFs. Excel sheets. Images of receipts.

2. Privacy: The ability to sanitize data before it leaves the device.

3. Reasoning: The ability to apply logic to the data.

DriveSyncAI already had these. I just had to wire them together.

The Architecture of an Auditor

The biggest blocker to using AI for taxes is privacy. You cannot paste your W-2 into ChatGPT. That is a non-starter.

So I built a local-first pipeline.

The critical component here is the PII/PHI/PCI Scrubber.

It scrubs PII (SSNs, names), PHI (medical record numbers), and PCI (credit card numbers). SSNs become [REDACTED_SSN]. Credit cards become [REDACTED_PCI].

The LLM never sees “Jane Doe, SSN 123-45-6789”. It sees “[REDACTED_NAME], SSN [REDACTED_SSN]”. It doesn’t need my identity to check the math.

The 4-Layer Audit

A generic prompt like “Check my taxes” fails. It’s too broad.

I treated the agent like a junior auditor. I gave it a specific rubric with four distinct passes.

Layer 1: Accuracy

This is the grunt work.

• Does Box 1 on the W-2 match Line 1a on the 1040?

• Does the sum of all 1099-INT forms match Schedule B?

• Are the state withholdings correctly transferred to the state return?

Layer 2: Savings

This is the advisory work.

• Did I max out the 401(k)?

• Is there a “Backdoor Roth” conversion visible in the 1099-R that isn’t reflected in Form 8606?

• Are there charitable donations in the receipts folder that didn’t make it to Schedule A?

Layer 3: Risk

This is the compliance work.

• Is the profit/loss ratio on Schedule C a red flag for a “hobby loss” audit?

• Critical: Are there “Wash Sales” in the crypto transaction CSVs that are disallowed in Schedule D?

Layer 4: Variance

• How does this year compare to last year?

• Why did dividend income drop 20%? (Usually implies a missing form).

The Results

I ran the script. It took about 45 seconds to process 115 documents.

It returned a structured report. And it found three things I would have definitively missed.

1. Missing Income: “Total dividends on Schedule B are $450 lower than the sum of 1099-DIV forms. You likely missed the Vanguard statement.” (I had).

2. Missed Deduction: “You have $1,200 in receipts, but no Form 8829 is present.”

3. Compliance Risk: “Your crypto CSV shows $3k in wash sale losses, but Schedule D shows $0 disallowed loss. Please verify.”

I fixed the numbers. I re-ran the agent. It gave me a green light.

The Strategic Shift

This feature is a microcosm of where software is going.

We are moving past “productivity tools” that make it easier for us to do the work. We are entering the era of agentic workflows where the software does the work.

As an executive, I don’t want a better spreadsheet. I want a CFO.
As a developer, I don’t want a better IDE. I want a coding partner.
And as a taxpayer, I don’t want a PDF viewer. I want a CPA.

DriveSyncAI is proving that if you control the data layer (the file system) and the intelligence layer (the LLM), you can build these agents yourself. You don’t need to wait for Intuit or Microsoft to build them for you.

I submitted my return yesterday. I slept like a baby.

In Part 1, I walked through the numbers. Eighty percent of vibe-coded apps have exploitable vulnerabilities. Sixty-nine vulnerabilities across fifteen apps in one study. 1.5 million API keys leaked on Moltbook.

But numbers don’t fix problems. Understanding why does.

So I dug into the research, looked at the breach patterns, and mapped out the five failure modes that explain every vibecoding security incident I’ve seen. Once you know these, you start spotting them everywhere.

TL;DR

• The prompt gap – AI gives you what you ask for, not what you didn’t ask for (e.g. auth, rate limits, secrets). Tools do well on things like SQL injection but often fail on authorization and business rules (Tenzai study).

• Poisoned training data – Models learn from the open web and repos, so they repeat bad patterns (e.g. hardcoded API keys in Common Crawl). Output tends to match the (insecure) average of what they were trained on.

• Slopsquatting – AI invents package names; attackers register those names and add malicious install scripts. Research found 205,000+ hallucinated package names; many are repeatable, so attacks are predictable.

• The trust gap – AI-generated code looks clean and “correct,” so people review it less while trusting it more. In studies, that same polished code often had SSRF, missing CSRF, and broken auth.

• Speed over scrutiny – The vibe-coding idea (”forget the code exists”) pushes security review to zero. You can ship fast, but someone still has to own architecture and security.

• Bottom line – AI coding tools are execution engines, not decision engines. They’re good at generating within constraints and bad at choosing those constraints. The fix is to give them the right constraints before generation; that’s what Part 3 (AntiVibe framework) is about.

1. The Prompt Gap: You Forgot to Ask

This is the big one. And it’s deceptively simple.

AI coding tools generate what you ask for. They don’t generate what you forgot to mention.

Think about it. When you prompt an AI to “build a social platform with user posts, comments, and DMs,” that’s what you get. Posts. Comments. DMs. Working features.

What you don’t get:

• Row Level Security on your database tables

• Authorization checks on your API endpoints

• Rate limiting on your registration flow

• Encryption on your private messages

• Secrets management for your API keys

Why? Because those aren’t feature requirements. They’re security architecture decisions. And the current generation of AI tools doesn’t make those decisions for you.

The Tenzai study confirmed this beautifully. AI tools handled SQL injection perfectly. That’s a well-known pattern with a clear fix (parameterized queries). But authorization logic? Business rules like “users can only see their own data”? The tools fell apart. Because that requires understanding your application, not just coding patterns in general.

The AI knows how to code. It doesn’t know what your app is supposed to protect.

2. Poisoned Training Data: The AI Learned From Bad Examples

Here’s something that doesn’t get enough attention.

LLMs learn from the internet. And the internet is full of terrible code.

Researchers at Truffle Security found 11,908 live API keys and passwords sitting in the Common Crawl dataset, the massive web archive used to train models like DeepSeek. These aren’t theoretical. These keys work. They authenticate with AWS, Slack, Mailchimp.

One single WalkScore API key appeared 57,029 times across 1,871 websites. One webpage had 17 unique Slack webhooks hardcoded into frontend JavaScript.

So when an AI model learns from millions of code samples that hardcode API keys in the frontend, what does it generate? Code that hardcodes API keys in the frontend.

The training data doesn’t represent best practices. It represents the average security posture of public GitHub repos and Stack Overflow answers. Which, if we’re being honest, is not exactly production-grade.

The AI is only as secure as the code it learned from. And it learned from the internet.

3. Slopsquatting: Packages That Don’t Exist

This one blew my mind when I first read the research.

You know typosquatting, where attackers register package names that look like popular ones (think loddash instead of lodash) hoping someone fat-fingers the install command?

Slopsquatting is the AI version of that. And it’s worse.

AI models hallucinate package names. They recommend libraries that don’t exist. Researchers analyzed 576,000 AI-generated code samples and found over 205,000 unique hallucinated package names. Open-source models hallucinated 21.7% of the time. Even commercial models averaged 5.2%.

The attack is straightforward:

1. Figure out which fake package names the AI recommends (58% are repeatable, so this is predictable)

2. Register that name on npm or PyPI

3. Add a post-install script that steals credentials

4. Wait for developers to run npm install

Unlike typosquatting, which exploits human typing errors, slopsquatting exploits AI model errors. And since those errors are repeatable, attackers can target them systematically.

The AI recommends a package. You install it. It steals your credentials. And the package was never real to begin with.

4. The Trust Gap: It Looks Too Good to Question

Here’s the sneaky one.

AI-generated code looks great. It’s clean. Well-structured. Properly commented. It passes linting. It runs without errors on the first try.

And that’s exactly the problem.

Because functional quality creates a false sense of security quality. The code looks like it was written by a senior developer, so we treat it like it was reviewed by one. We skim it. We accept it. We move on.

The data backs this up. Developers review AI-generated code less while being more confident in its security. It’s a paradox: the better the code looks, the less we scrutinize it.

The Tenzai study found that all five AI tools produced clean, readable code. That same code shipped with SSRF vulnerabilities, missing CSRF protection, and broken authorization logic. It looked right. It wasn’t.

Beautiful code can still be broken code. Don’t let the formatting fool you.

5. Speed Over Scrutiny: The Vibe Philosophy Itself

Let’s be real about what vibecoding is as a philosophy.

Karpathy’s original description: “Forget that the code even exists.”

That’s not a bug in the philosophy. That’s the feature. The whole point of vibecoding is to move so fast that you don’t stop to read what was generated. Accept the output. Test it. Ship it. Iterate with follow-up prompts if something breaks.

This compresses security review windows from weeks to zero.

And it creates a new class of builder: people who can ship production applications but can’t audit them. Non-technical founders deploying apps that handle real user data, with no ability to assess whether that data is protected.

I’m not saying these people shouldn’t build. They absolutely should. The democratization of software creation is powerful.

But someone needs to think about the architecture. If the builder can’t, the tools need to compensate. And right now, they don’t.

Moving fast without looking is just falling with style.

The Common Thread

All five failure modes point to the same gap:

AI coding tools are execution engines, not decision engines.

They’re spectacular at generating code within constraints. They’re terrible at defining the constraints themselves. They write what you tell them to write. They don’t tell you what you forgot.

And that’s actually fine. Once you know it. Because the fix isn’t to stop using AI tools. The fix is to give them the right constraints before they start generating.

That’s AntiVibe. And that’s what we’re covering next.

What’s Next

In Part 3, I’ll lay out the AntiVibe Framework: the four-layer architecture that closes every gap we just covered. Security architecture first, then AI rails, then code generation, then validation.

Plan it. Feed it to the AI. Code inside the rails.

Same speed. Different outcome.

And if you made it this far, thank you!!

This is my attempt to give back to the countless people who helped me learn, most of whom don’t know I exist.

Part 2 of 6 in the AntiVibe series

A colleague stopped me at a team offsite 4 months ago. Sharp engineer. Twenty years in IT. He said: “I get it. I’ve tried ChatGPT. I appreciate what it does. But what am I supposed to actually do with it? Where do I even start?”

I hear this constantly. Every time, I give some version of the same answer - more details when I have time, less when I don’t. Honestly, I never quite know if it lands.

So many people are struggling with this. And here I am, writing about Vibe coding, AntiVibe, Diffusion Models. The usual AI circus.

I felt compelled to prioritize this.

It's the right question. And the honest answer is: most AI content online is written for two audiences - beginners who've never written code, and ML researchers building foundation models. There's almost nothing for the experienced software engineer, architect, or tech lead who wants to understand where this is all going and how to position themselves at the centre of it.

I generally write what comes to mind. Raw, unfiltered, sometimes incomplete. I make mistakes. If you spot one, call it out in the comments. That's part of the deal.

This is that answer. Written down properly.

TL;DR

• Most IT professionals use AI like a smarter Google. It’s not. It’s a collaborator that executes.

• Month 1: use it every single day. Month 3: build something with the API. Month 6: ship an agent.

• MCP, A2A, and AG-UI are the three protocols every serious AI conversation will assume you know in the next two years.

• The gap between people who talk about AI and people who ship with AI isn’t knowledge. It’s reps.

• AI won’t replace your judgment. It will amplify whoever has the most context. That’s you.

Before anything else: change one assumption

Most people treat AI like a smarter Google. You ask, it answers, you decide what to do with it.

That mental model will cap you very quickly.

The right mental model is: AI is a collaborator that executes, not just answers. Once that clicks, you stop asking “what can it tell me?” and start asking “what can I hand over entirely?”

That shift is everything. The rest of this post is about how to get there, step by step, with a realistic timeline.

Month 1: Just use it. Every day.

I know that sounds obvious. But most people use ChatGPT the same way they used Wikipedia in 2005. Occasionally, when they remember it exists.

That’s not how you build the instinct.

For the first month, your only job is to make AI your first move on any task that involves thinking or writing. Not your last resort when you’re stuck. Your first move.

Emails. Meeting summaries. Explaining a confusing error. Drafting a ticket. Summarising a 40-page document before you read it. Everything.

The tool that makes the biggest difference day-to-day: GitHub Copilot, Windsurf, Lovable or Cursor (and many more..) in your editor. Use it on real code for two weeks. Not toy projects. Real code you’d commit. It will change how you write code.

The one thing to learn this month: Prompt engineering secret sauce. AI is only as smart as you tell it to be. It takes one afternoon to get started with it. This guide covers everything: zero-shot, few-shot, chain-of-thought. Read it. The quality of what AI gives you is directly tied to how precisely you ask.

By the end of month one you should feel slightly uncomfortable when AI isn’t available. That’s the milestone.

Months 2–3: Stop using AI for tasks. Start using it for workflows.

One-off prompts don’t compound. Integrated workflows do.

This is where most people plateau. They keep using AI like a fancy search box instead of redesigning how they work around it.

Look at your week. Every recurring thing: sprint planning, code reviews, incident reports, architecture docs, onboarding new engineers. Ask yourself: “Could AI do 80% of the first draft of this?” For most of them, yes.

When I was building DriveSyncAI, every architecture decision record I wrote started as a five-minute AI conversation. I’d describe the problem, tell it the constraints, ask it to draft options. It wasn’t always right. But, you got someone to talk to. It got me to a first draft in 5 minutes instead of 45. I edited. It improved. That’s the workflow.

What to set up this month:

• Notion AI or whatever docs tool your team uses. Turn the AI features on.

• A personal system prompt. One paragraph you paste at the start of new conversations: your role, your standards, what good output looks like for you. This is the difference between a generic assistant and one calibrated to how you think.

• Perplexity for any research task where you need sources. It cites everything, which matters when you’re making decisions that need to be justified.

The milestone: Three recurring tasks that used to take 30+ minutes each now take under 10. If you can’t name them, you’re not integrated yet.

Months 3–5: Build something with an LLM API.

This is the step that separates people who understand AI from people who just use it.

You don’t need to know how transformers work. You need to know how to call an API, parse the response, and handle it failing. That’s one weekend.

Pick up the OpenAI API docs or Anthropic’s. Send a prompt. Get a response. Handle an error. Then build the one thing that’s annoyed you for months. A Slack bot that summarises your sprint tickets. A script that auto-generates release notes from git history. A tool that classifies your support emails.

When I built the AI chat feature in DriveSyncAI, I expected the model logic to be hard. It wasn’t. What was hard was parsing the response reliably. Every LLM returns JSON slightly differently. Missing fields. Booleans as strings. Responses wrapped in markdown code fences. I spent a week on defensive parsers that I should have built on day one.

Build yours now. You’ll thank yourself later.

Worth 45 minutes of your time: Andrej Karpathy’s State of GPT talk. Best overview I’ve found of what these models actually are, without the hype.

The milestone: You’ve shipped something with an LLM in the loop. Even internal. Even rough. Just shipped.

Months 5–8: Agentic AI: where it gets interesting.

Here’s the shift that’s changing everything right now.

Most AI tools follow the same pattern: you input something, AI outputs something, you do something with the output. The human is in the loop for every step.

Agentic AI is different. You give it a goal. It figures out the steps. It uses tools to complete them. It observes the result. It adjusts. You come back when it’s done.

Before: You → Prompt → AI → Answer → You decide next step → repeat

Agentic: You → Goal → AI → Plan → Tools → Execute → Observe → Done

This is not theoretical. I use agents in DriveSyncAI’s sync analysis. The AI doesn’t just suggest what to sync. It reasons through a multi-step comparison, applies rules, checks for conflicts, and surfaces only the decisions that genuinely need a human.

How to get here:

• Read the ReAct paper. It’s 10 pages. It explains the reasoning + acting loop that underpins almost every modern agent framework.

• Try LangChain or LlamaIndex. Pick one. Build a simple agent that can search the web, read a file, and write a summary. That’s your Hello World.

• Explore AutoGen when you’re ready for multiple agents collaborating. One specialised in data retrieval, another in analysis, another in output formatting.

The thing nobody tells you about agents: They fail in interesting ways. Hallucination, tool misuse, cost spirals, infinite loops. Your job isn’t just to build the agent. It’s to design the guardrails. What can it do without asking? When must it stop and check? How does it recover from failure?

The milestone: An agent completes a multi-step task without you touching it in the middle.

When you’re ready: the protocol layer

This is where the jargon lives. Let me cut through it.

Three protocols are becoming the backbone of how production AI systems are built. You need to understand all three. Not because you need to implement them tomorrow, but because every serious AI architecture conversation in the next two years will assume you know them.

MCP: Model Context Protocol

Created by: Anthropic
What it does: Defines a standard way for AI models to connect to external tools and data sources.

Without MCP, every integration is custom-built. Your AI needs your database? Custom code. Needs your API? Custom code. Needs to read files? Custom code.

With MCP, you expose your system once using the standard, and any compatible AI model can use it. No custom glue per model or per tool.

Think of it like HTTP. Before HTTP, every server spoke a different protocol. After HTTP, a browser could talk to any web server. MCP is that for AI tool use.

I use it today. The Atlassian MCP in my setup lets me publish to Confluence, create Jira tickets, and search across my spaces directly from an AI conversation. No custom integration. One standard connection.

Read: modelcontextprotocol.io/introduction

A2A: Agent-to-Agent Protocol

Created by: Google
What it does: Defines how AI agents talk to each other. Delegate tasks, share results, coordinate.

When you build a real system, it’s not one agent doing everything. It’s a network of specialised agents: one that handles retrieval, one that handles analysis, one that handles execution. A2A is how they communicate without you writing custom message-passing code for every pair.

Think of it like REST APIs, but between agents instead of services.

The practical case: Customer support system. Agent 1 reads the incoming ticket and classifies it. Agent 2 searches your knowledge base for relevant answers. Agent 3 drafts the response. Agent 4 decides whether to send or escalate. Each agent is focused. A2A is the coordination layer between them.

Read: github.com/google/A2A

AG-UI: Agent-User Interaction Protocol

Created by: The broader agent developer community
What it does: Defines how agents stream their progress back to human users in real time. Tool calls, reasoning steps, intermediate results, human-in-the-loop checkpoints.

Agents take time. Sometimes seconds. Sometimes minutes. If the user sees nothing until the end, they don’t trust it. AG-UI gives you a standard event model for streaming what the agent is doing. Users can watch it work, intervene if needed, and understand why it made the choices it did.

Think of it like the difference between a shell command that prints nothing for 5 minutes and one that streams logs. Same task. Completely different experience of trust.

Read: docs.ag-ui.com

How these three fit together:

You <-> AG-UI <-> Orchestrator Agent —MCP —> Tools & Your Systems

—A2A —> Specialised Sub-Agents

MCP = agent to tools. A2A = agent to agent. AG-UI = agent to you.

If you can explain this diagram to a colleague without notes, you understand more about production AI architecture than 90% of the people calling themselves AI engineers right now.

The long game: systems that improve

Once you’ve shipped agents that work, the next question is: how do they get better?

Three things to learn here, in this order:

RAG: Retrieval-Augmented Generation. The pattern for giving your AI access to your own data without fine-tuning the model. Your AI reads relevant documents at query time, not at training time. This is how most enterprise AI features actually work. Start here.

Vector databases. The storage layer that makes RAG possible. Pinecone, Weaviate, Chroma. They store embeddings (numerical representations of meaning) and let you find semantically similar content fast. Pinecone’s intro is the clearest.

Evals: how to measure if it’s actually working. This is the one most teams skip and then regret. You can’t improve what you can’t measure. Building a proper evaluation framework with test cases, metrics, and regression checks is harder than building the feature. It’s also more important. Hamel Husain’s post on this is the best I’ve read.

What to hand over to AI, starting this week

Don’t wait until you’ve read everything. Start delegating today. Here’s a progression:

This week, zero risk:
Your last five emails. Any meeting you need to summarise. The next error message you can’t immediately explain. A ticket you need to write.

Next month, with review:
Code review comments. Architecture decision records. Incident post-mortems. Interview questions. Release notes from git history.

Month 3+, delegate the outcome not just the task:
“Here’s our support backlog for the last quarter. Tell me the top five categories and which ones could be fully automated.”
“Here’s our git history. Show me the files with the most churn and explain what that suggests about our architecture.”
“Here are 200 pieces of user feedback. What are the three biggest problems we’re not solving?”

The difference between the first group and the last group is the unit of delegation. First group: tasks. Last group: outcomes. Getting to outcome delegation is the real goal.

The honest part

Here’s what AI won’t replace.

Your judgment. Your domain knowledge. Your sense for what will actually work in your organization. Your relationships. Your accountability when things go wrong.

I’ve built an app that uses AI for everything from file classification to sync decision-making. The AI is fast and often surprisingly good. But every major architectural decision about what to build, what to skip, what safety guarantees to make, and what to ship first came from me. From 26 years of building systems, watching things fail, and understanding why.

AI without context is a tourist. A fast, well-read tourist who never gets tired and doesn’t charge by the hour. But still a tourist.

You have the context. That’s the rare thing. The skill now is learning to use AI to act on that context faster, at higher leverage, without the friction.

Where to start: the one-paragraph version

Open ChatGPT or Claude. Use it for the next three things that land in your inbox. Then the next ten. Then every single day for a month. Build something with the API that week. Read the ReAct paper that weekend. After ninety days you’ll know more about what AI can actually do, for you, in your context, than any course or certification will ever teach you.

The gap between people who talk about AI and people who ship with AI isn’t knowledge. It’s reps.

Start accumulating yours.

And if you made it this far, thank you. Genuinely. Go build something. I love you for even trying.

This will be an evolving article, covering multiple areas as I continue my research and formalize my perspectives.

TL;DR

• 80% of AI-generated apps have at least one exploitable vulnerability. That’s not a edge case. That’s the default.

• The AI writes exactly what you ask for. The problem is what you forgot to ask.

• Slopsquatting is real: 1 in 5 AI-recommended packages doesn’t exist. Attackers are registering those names.

• Speed is real. So is the exposure. You can have both, but only if you think about security before you prompt.

• Part 2 covers why this happens. Part 3 introduces AntiVibe, the framework I’m building to fix it.

Let me ask you something.

If I told you there’s a way to build a full application in a weekend -- no boilerplate, no framework debates, just describe what you want and ship it -- you’d say “sign me up.”

Now what if I told you that 80% of apps built this way have exploitable security holes?

That’s vibecoding in 2026. Incredible speed. Dangerous defaults. And we need to talk about it.

How We Got Here

In January 2023, Andrej Karpathy -- OpenAI co-founder, former Tesla AI Director -- tweeted something that stuck: “The hottest new programming language is English.”

Two years later, he gave it a name: vibe coding. His description? “Fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

And honestly? The pitch landed. AI coding assistants started scaffolding entire apps from plain English. People who’d never written a line of code were shipping real products. Experienced developers were compressing weeks of work into hours. Collins Dictionary made “vibe coding” their Word of the Year for 2025.

I get the appeal. I use AI coding tools every day. The productivity gains are real.

But here’s the thing nobody talks about at the demo: what happens after you ship?

The Numbers Don’t Lie

I went deep on the research. Not opinions. Not hot takes. Peer-reviewed studies, independent security audits, real vulnerability data. Here’s what I found.

Study 1: 20,000 apps under the microscope

Invicti analyzed 20,000 AI-generated applications. The headline: 80% had at least one exploitable vulnerability.

Let that sink in. Eight out of ten apps.

The breakdown is even worse:

• 72% were missing basic security headers (the stuff browsers use to protect your users)

• 68% had misconfigured database security (think: Supabase with no Row Level Security)

• 63% didn’t validate user input (hello, injection attacks)

• 54% had API keys sitting right there in the client-side JavaScript

• 45% shipped with known-vulnerable dependencies

• 41% relied on client-side-only authentication (which is no authentication at all)

Study 2: Five AI tools, one test, 69 vulnerabilities

Security startup Tenzai ran a brilliant experiment. They took five major AI coding tools -- Claude Code, OpenAI Codex, Cursor, Replit, and Devin -- and asked each one to build three identical apps.

Same prompts. Same requirements. Fifteen apps total.

The result? 69 vulnerabilities. Six of them critical.

But here’s what stopped me cold: zero of the fifteen apps implemented CSRF protection. Zero had security headers. Zero had rate limiting. And all five tools introduced Server-Side Request Forgery vulnerabilities.

The tools were great at preventing SQL injection -- that’s a well-known pattern with a clear fix. But when it came to authorization logic? Business rules? Context-dependent security? They fell apart.

Study 3: Real apps, deployed in the wild

VibeAppScanner looked at 5,600 vibe-coded apps that were already live -- real apps, real users. They found over 2,000 vulnerabilities, 400+ exposed secrets, and 175 instances of personal data just sitting in client-side code.

These aren’t lab experiments. These are apps people are using right now.

Study 4: The packages that don’t exist

This one’s wild. Researchers analyzed 576,000 AI-generated code samples and found that nearly one in five recommended packages doesn’t actually exist.

The AI just made them up. Hallucinated package names. And 58% of those hallucinations are repeatable -- meaning attackers can predict them, register those package names, and slip malicious code into your project.

They call it slopsquatting. It’s already happening.

The Breach Record

Data is one thing. Real-world breaches are another. Here are four that should keep every builder up at night.

Moltbook -- 1.5 million API keys, gone

Moltbook was the hot new thing -- an AI social network where agents post, chat, and build reputation. It went from zero to 1.5 million registered agents in days. The founder said on X: “I didn’t write a single line of code.”

Then Wiz security researchers took a look.

The Supabase API key was hardcoded in a frontend JavaScript file. Anyone could see it by opening browser dev tools. Row Level Security? Not on a single table. A simple cURL command returned every API key, every email address, every auth token on the platform. No login required.

It gets worse. Researchers could modify live posts with unauthenticated PATCH requests. The “1.5 million AI agents”? Actually 17,000 human accounts running an average of 88 bots each.

Wiz needed five rounds of disclosure to close everything. Each fix revealed more exposed surfaces.

Base44 -- One value to bypass everything

Base44 was a vibe-coding platform acquired by Wix. Wiz researchers found that a single non-secret app_id value was all you needed to bypass SSO, bypass authentication, bypass everything. Any private enterprise app on Base44 was wide open. Enterprise apps. SSO bypassed. With one value.

NX -- AI-generated code that steals your crypto

The NX build platform used Claude Code to generate pull request validation logic. The AI generated code that dumped unsanitized PR titles straight into bash commands. Attackers submitted malicious PRs. NX ran them automatically. NPM tokens, crypto wallets -- all potentially compromised.

DeepSeek -- The training data is the problem

Researchers at Truffle Security found 11,908 live API keys and passwords baked into the Common Crawl dataset that trains models like DeepSeek. These keys work. They authenticate with AWS, Slack, Mailchimp. One single API key showed up 57,029 times across 1,871 websites.

When the training data has hardcoded credentials, the AI learns to hardcode credentials. Garbage in, breaches out.

So What’s the Pattern?

Every one of these incidents has the same root cause. It’s not that the AI wrote bad code. The code works. It does exactly what it was asked to do.

The problem is what nobody asked it to do.

Nobody asked for Row Level Security. Nobody asked for rate limiting. Nobody asked to keep secrets out of the frontend. Nobody asked because nobody thought about the security architecture before prompting the AI.

And that’s the gap. That’s the whole story.

AI generates what you ask for. It doesn’t generate what you need but forgot to mention.

What’s Next

In Part 2, I’ll break down exactly why vibecoding produces insecure code -- the five failure modes that explain every breach on this list. Once you see them, you can’t unsee them.

And in Part 3, I’ll introduce AntiVibe -- the framework I’m building to keep the speed and lose the exposure.

Because here’s what I believe: building fast is fun. Building secure is non-negotiable. We can do both.

-- Part 1 of 6 in the AntiVibe series

Most teams add AI to their product the same way. They build the app. They ship it. Then someone says “we should add AI.” So they drop in a chatbot, wire up an API call to GPT, and put an “AI-powered” badge on the landing page.

That’s not AI-first. That’s AI-last.

I wanted to test what happens when you do it the other way. Start with AI. Let it shape the architecture, the user experience, the data flow. Then build the rest of the app around it.

So I built DriveSyncAI - a native macOS app that syncs drives, finds duplicates, and organizes files. It doesn’t have an AI feature. AI is how it works. You don’t configure it through settings panels. You talk to it. It asks you questions. It drafts a plan. You push back. It adapts.

I’ve spent 26 years in tech - healthcare, pharma, government, large-scale data platforms. For the last few years, my focus has shifted to AI strategy: how organizations should design systems around AI instead of attaching AI to existing systems. This app was my way of pressure-testing that thinking. Build it myself. See what holds up. See where most teams are getting it wrong.

Here’s what I found.

Mistake #1: Defaulting to Cloud AI Without Thinking About It

The first design decision I faced: where does the AI run?

Most teams don’t even ask this question. They pick OpenAI or Anthropic, add an API key, and move on. For a lot of products, that’s fine. But it shouldn’t be the default.

My app has access to every file on your drive. File names, folder structures, metadata. Sending that to a cloud API, even just the metadata; felt like the wrong starting point. After years of working in healthcare, where data privacy isn’t optional, I’m wired to ask “does this data need to leave the device?” before anything else.

I chose Ollama. Local. Open-source models running on the user’s own machine.

The app supports 75+ models. Small ones that work on a MacBook Air. Larger ones for complex file taxonomies. You can also connect OpenAI, Anthropic, Gemini, or Perplexity if you want cloud power. But the out-of-the-box experience is local. Private. Free.

The hardware is good enough. The models are good enough. Most teams default to cloud AI because that’s what the tutorials show. Not because they evaluated the tradeoff.

Mistake #2: Sending Everything to the Language Model

This is the most expensive mistake I see teams make. And I made it too, early on.

My first prototype sent every file to the LLM for categorization. It was slow, it was expensive, and it was pointless. A .jpg with EXIF data from 2024 is a photo from 2024. You don’t need a language model to tell you that.

AI-first doesn’t mean AI-everything. It means AI shapes how you think about the problem. Then you use AI where it adds real value and use cheaper tools everywhere else.

I ended up with a three-tier pipeline:

• Tier 1 Rules (~60% of files): Extension-based categorization. Clutter detection. User-defined rules. Zero LLM tokens.

• Tier 2 Metadata (~25% of files): EXIF dates from photos. PDF titles. Spotlight attributes. Still zero tokens.

• Tier 3 LLM (~15% of files): Only the files where extension and metadata aren’t enough. Sent as compact metadata summaries, the model never sees the actual file content.

85% of the work runs without a single token. The AI handles the 15% where rules and metadata fall short. That’s the right ratio. Most teams invert it, they throw everything at the LLM and then scramble to optimize costs later.

Design the tiers first. Let AI handle what only AI can handle.

Mistake #3: Treating AI Output as Final

Most AI-powered tools follow the same pattern: input goes in, output comes out, user clicks approve. One shot. Take it or leave it.

That’s not how people work. And it’s not how AI should work either.

I built the one-shot version first. Scan a drive, show organization suggestions, let the user execute. Then I used it. The app suggested moving wedding-photos-backup-2024/ to Photos/Backups/. I wanted it in Family/Events/. There was no way to say that.

So I added an AI chat. You can talk to the plan.

Before scanning, you describe what you care about in plain language. “I’m a photographer. Separate RAW from JPEG. Organize by shoot date.” The AI adjusts your preferences.

After scanning, the plan shows up and the AI becomes a co-editor. “Move the PDFs to a Research folder.” “Don’t clean up anything in Downloads.” It modifies the plan, adds moves, removes items, changes destinations, highlights what changed. If the changes are big enough, it offers to re-scan.

Each LLM response is structured JSON: a message, follow-up questions, plan modifications, preference changes, and a re-analysis flag. I had to build resilient parsers because every LLM returns JSON slightly differently, missing fields, booleans as strings, markdown wrappers. You learn to trust nothing from an API and validate everything.

This feature was a late addition. It turned out to be the most important one. People trust AI more when they can argue with it. The teams that treat AI output as final are building tools people tolerate. The teams that let users push back are building tools people trust.

Mistake #4: No Safety Net for AI Actions

Here’s something that concerns me about how fast teams are shipping AI features: the AI acts on real data, and there’s no undo.

AI makes mistakes. That’s fine, humans make mistakes too. The problem is when there’s no rollback.

My app moves, renames, and deletes files. Get that wrong and someone loses their work. So I built a write-ahead journal, borrowed from how databases handle transactions:

1. Before any file operation, write a journal entry with status .pending

2. Execute the operation. Back up anything being overwritten or deleted.

3. Write the result: .completed or .failed

4. For copies, hash the destination with SHA256 and verify against the source

If the app crashes or a drive disconnects mid-operation, the journal has a full record. Rollback restores everything to the pre-operation state.

In large-scale systems, transactional safety is standard. In AI-powered apps, it’s rare. If your AI can modify user data. move files, edit documents, change settings, you need a safety layer that assumes the AI will get things wrong sometimes. Because it will.

Mistake #5: Ignoring the Execution Layer

A lot of AI products focus on the intelligence and ignore the plumbing. The model is smart, but the app is slow. The suggestions are good, but the execution takes forever.

When AI organizes your files, speed matters. Users won’t wait 10 minutes. The AI layer needs the I/O layer to keep up.

Three things I built to close that gap:

Memory-mapped hashing. Files over 4MB get hashed with mmap 64MB sliding windows, sequential access hints, data goes from the kernel page cache to CryptoKit with no intermediate copies. Smaller files use chunked reads. If mmap fails, it falls back.

APFS clonefile. On the same APFS volume, clonefile() creates a copy-on-write clone. The copy takes microseconds regardless of file size. Cross-volume copies use FileManager.copyItem.

Adaptive concurrency. USB 2.0 gets 2 parallel I/O operations. USB 3.x gets 4. Thunderbolt gets 6. NVMe gets 8. Backpressure keeps slow devices from getting overwhelmed.

AI-first means the whole stack has to support the AI’s speed of thought. If the model can decide in 2 seconds where 500 files should go, your I/O layer better be ready to move them.

What I’d Do Differently

Three things:

Start with the chat, not the settings form. I built a preferences wizard with dropdowns and toggles. Then I built the AI chat. The chat was more useful. People would rather say what they want in a sentence than configure six settings. Next time I’d start there.

Add journaling before the first file operation. I started with basic file operations and added the write-ahead journal later. Retrofitting was messy. Transaction safety should be the first thing you build, not something you bolt on.

Build defensive JSON parsing on day one. Every LLM provider returns JSON a little differently. Missing fields. Booleans as strings. Payloads wrapped in markdown code fences. I spent a week debugging decode errors before I wrote custom parsers with sensible defaults. Should have done that from the start.

What AI-First Actually Looks Like

Building this app clarified something I’d been thinking about for a while. Here’s what I now believe:

AI shapes the architecture, not the other way around. Don’t design your app and then ask “where can we add AI?” Start with what AI can do and build the experience around that.

Conversation is the interface. People don’t want to approve AI output. They want to talk to it, push back, and shape the result together. That changes how you design every screen.

AI-first doesn’t mean AI-expensive. 85% of the work in this app runs on deterministic rules. Good AI-first design means knowing where AI adds value and where it doesn’t.

Local AI is ready. A MacBook runs Ollama models with no issues. For anything that touches personal or sensitive data such as health records, personal documents, financial files; local-first is the right default.

If AI acts, safety follows. Any AI feature that modifies user data needs a transaction log, a backup, and a rollback path. No exceptions.

Most teams are doing AI wrong not because they lack talent or tools. They’re doing it wrong because they’re adding AI to existing designs instead of letting AI reshape the design from the start. That’s the difference between AI-last and AI-first. It changes everything.

I built DriveSyncAI to test these ideas in something real. They held up. The question I’m focused on now: what does AI-first look like applied to healthcare platforms, data pipelines, and enterprise systems?

That’s the next chapter.

DriveSyncAI is open source under BSL 1.1. Code at github.com/amitchorasiya/DriveSyncAI. Download at drivesyncai.layai.co.

I spend most of my time designing event-driven systems and microservice architectures, and lately, AI has become a key part of the experiences I build to help business teams.

Over the past three years, I’ve relied heavily on large language models (LLMs) for that work - drafting architecture designs, reasoning through failure scenarios, generating code skeletons, summarizing lengthy specification documents, and developing agents to make life easier for my colleagues and team members. These models have become an integral part of how I think through problems.

One thing keeps bugging me: the models keep getting smarter and keep feeling slow.

Not unusable-slow. Just slow enough that I lose my train of thought waiting for a response. Slow enough that during a five-round design iteration, I check Slack/Teams between responses and lose context. At 8-10 seconds per response across dozens of prompts in a session, the wait time adds up.

Every one of these models generates text the same way -- one token at a time, sequentially. That is the bottleneck, and no amount of better hardware fixes it.

Then I tried Mercury 2.

TL;DR

• Every major LLM today generates text one token at a time, sequentially. That’s the bottleneck. Better hardware doesn’t fix it.

• Mercury 2 from Inception Labs uses diffusion-based generation: the entire response materialises in parallel instead of streaming word by word. 1,009 tokens per second. 5x faster than GPT-4o. 4x cheaper.

• Reasoning quality is good but not frontier-grade. It won’t surface risks you haven’t thought of. Use it for exploration, not final judgment.

• Best pattern: Mercury 2 to rapidly explore and narrow down options, then ChatGPT/Claude/Gemini for the final deep pass. Fast divergence, slow convergence.

• This matters less as a product and more as a proof point. Diffusion architecture breaks a constraint that has defined LLMs for three years.

What Mercury 2 Actually Is

Mercury 2, from Inception Labs, is not another autoregressive model with a faster chip underneath. It is a fundamentally different architecture. Instead of generating text one token at a time in sequence, it uses diffusion-based generation -- the same approach behind image generators like Stable Diffusion, applied to language.

The model starts with noise and refines the entire response in parallel over a few steps. It does not wait for word one to finish before starting word two. Everything happens at once. The output materializes rather than streams.

The numbers: 1,009 tokens per second on NVIDIA Blackwell GPUs. That is not 10% faster. That is 5x or more faster than what I am used to from GPT-4o. To my surprise, its 4 times cheaper.

Why the Slow Typing Matters More Than You Think

Every major LLM today -- GPT, Claude, Gemini, Llama -- generates text through autoregressive decoding. One token predicts the next. The next predicts the one after that. Strictly sequential, no shortcuts.

For a single question-and-answer, the wait is tolerable. But my work does not look like single questions. It looks like this:

• Ask the model to draft an architecture approach

• Read the output, spot something wrong

• Ask it to revise with a constraint I forgot to mention

• Read again, realize the failure handling is too hand-wavy

• Ask it to go deeper on the retry and reconciliation logic

• Read again, decide to take a different approach entirely

• Start over with a new framing

That is seven inference calls for one design decision. At 8-10 seconds each, that is over a minute of just waiting. And that is one decision out of dozens in an architecture session.

The compounding gets worse with agentic workflows -- AI systems that chain multiple inference calls to complete a task. If your agent makes 15 calls and each one takes 2 seconds, the user waits 30 seconds before seeing anything. Speed is not a vanity metric here. It determines whether the workflow is usable.

My Honest Take

Mercury 2’s reasoning is good but not frontier-grade. On tasks where I needed the model to surface risks I had not thought of, it did not match ChatGPT. It answered the question I asked; it did not answer the question I should have asked.

The ecosystem is brand new. No plugin ecosystem, no custom GPTs, no deep IDE integrations yet. OpenAI API compatibility helps, but the surrounding infrastructure is early.

The speed takes adjustment. I caught myself not reading responses carefully because they appeared so fast. My brain was still in “wait for the model” mode.

Where I actually reach for each one:

• Mercury 2 for exploration and iteration -- when I am generating options, testing framings, building prototypes. Speed keeps me in flow.

• ChatGPT/Claude/Gemini for depth and judgment -- when I am making a final architecture decision or reviewing for gaps. The extra seconds are worth it.

• Best pattern I found: Mercury 2 to rapidly explore and narrow down, then ChatGPT/Claude/Gemini for the final deep pass. Fast divergence, slow convergence. Better than either alone.

Why This Matters Beyond One Model

Mercury 2 matters less as a product and more as a proof point. For three years, every LLM improvement stayed within the same “one token at a time” framework. This shows a different architecture can break that bottleneck.

For anyone building AI-assisted tooling or agentic systems, latency has been the hard constraint limiting how many reasoning steps you can chain and how responsive your UX can be. If that constraint loosens, the architectures you can build change.

The question is not “is this better than other LLMs.” The question is: what could you build if your AI responded before you finished your thought?