I’ve been meaning to write this up because it’s been surprisingly repeatable, and I wish someone had described it to me earlier.
Over the last year or so, my development speed relative to my own baseline from ~2019 is easily 20x, sometimes more. Not because I type faster, or because I cut corners, but because I changed how I use AI.
The short version: I don’t use AI inside my editor. I use two AIs in parallel, in the browser, with full context.
Here’s the setup.
I keep two tabs open:
One AI that acts as a “builder”. It gets a lot of context and does the heavy lifting.
One AI that acts as a reviewer. It only sees diffs and tries to find mistakes.
That’s it. No plugins, no special tooling. Just browser tabs and a terminal.
The important part is context. Instead of asking for snippets, I paste entire files or modules and explain the goal. I ask the AI to explain the approach first, including tradeoffs, before it writes code. That forces me to stay in control of architecture instead of accepting a blob I don’t understand.
A typical flow looks like this:
1. Paste several related files (often across languages).
2. Describe the change I want and ask for an explanation of options. Read and summarize concepts, wikipedia, etc.
3. Pick an approach. Have extensive conversations about trade-offs, concepts, adversarial security etc. Find ways to do things that the OS allows.
4. Let the AI implement it across all files.
5. Copy the diff into the second AI and ask it to look for regressions, missing arguments, or subtle breakage.
6. Fix whatever it finds.
Ship.
The second AI catches a lot of things I would otherwise miss when moving fast. Things like “you changed this call signature but didn’t update one caller” or “this default value subtly changed behavior”.
What surprised me is how much faster cross-stack work gets. Stuff that used to stall because it crossed boundaries (Swift → Obj-C → JS, or backend → frontend) becomes straightforward because the AI can reason across all of it at once.
I’m intentionally strict about “surgical edits”. I don’t let the AI rewrite files unless that’s explicitly the task. I ask for exact lines to add or change. That keeps diffs small and reviewable.
This is very different from autocomplete-style tools. Those are great for local edits, but they still keep you as the integrator across files. This approach flips that: you stay the architect and reviewer, the AI does the integration work, and a second AI sanity-checks it.
Costs me about $40/month total. The real cost is discipline: always providing context, always reviewing diffs, and never pasting code you don’t understand.
I’m sharing this because it’s been a genuine step-change for me, not a gimmick. Happy to answer questions about limits, failure modes, or where this breaks down.
Here is a wiki-type overview I put together for our developers on our team: https://community.intercoin.app/t/ai-assisted-development-playbook-how-we-ship-faster-without-breaking-things/2950
I architect of it and go through many iterations. The machine makes mistakes, when I test I have to come back and work through the issues. I often correct the machine about stuff it doesn't know, or missed due to its training.
And ultimately I'm responsible for the code quality, I'm still in the loop all the time. But rather than writing everything by hand, following documentation and make a mistake, I have the machine do the code generation and edits for a lot of the code. There are still mistakes that need to be corrected until everything works, but the loop is a lot faster.
For example, I was able to port our MySQL adapter to PostGres AND Sqlite, something that I had been putting off for years, in about 3-5 hours total, including testing and bugfixes and massive refactoring. And it's still not in the main branch because there is more testing I want to have done before it's merged: https://github.com/Qbix/Platform/tree/refactor/DbQuery/platf...
Here is my first speedrun: https://www.youtube.com/watch?v=Yg6UFyIPYNY
Use my abstract factory factories and inversion of control containers. With Haskell your entire solution is just a 20-line mapreduce in a monad transformer stack over IO. In J, it's 20 characters.
I don't see how AI differs. Rather, the last study of significance found that devs were gaslighting themselves into believing they were more productive, when the data actually bore the opposite conclusion [0].
[0] >>44522772
Nobody's taken me up on this offer yet. [0]
[0] >>46325469
https://github.com/Qbix/Platform-History-v1
https://github.com/Qbix/Platform-History-v2
And you can see the latest code here:
Documentation can be created a lot faster, including for normies:
https://community.qbix.com/t/membership-plans-and-discounts/...
My favorite part of AI is red-teaming and finding bugs. Just copypaste diffs and ask it for regressions. Press it over and over until it can't find any.
Here is a speedrun from a few days ago:
This was done in about 3 hours for instance: https://github.com/Qbix/Platform/tree/refactor/DbQuery/platf...
You can see the speed for yourself. Here is my first speedrun livestreamed: https://www.youtube.com/watch?v=Yg6UFyIPYNY
I really appreciate that he is up-front about "Yes. Vibe coding has lots of dangerous problems that you must learn to control if you are to go whole-hog like this."
Has anyone read his Vibe Coding book? The Amazon reviews make it sound like it's heavy on inspiration but light on techniques.
Citation: https://stackoverflow.com/a/6188624