Context
I come from a platform engineering and cloud background, so a lot of my work starts the same way: take a moderately complex pattern, bootstrap it into something real, and see whether it can survive contact with implementation.
That usually means some infrastructure as code, some application wiring, a basic test harness, and enough operational shape to know whether the idea is solid or just a nice diagram.
Over the last while I have been using AI hands-on and paying attention to one practical question: if I build the same kind of MVP under different modes of working, what actually changes?
To make it concrete, think about a moderately complex proof of concept that would have taken me around 4 to 6 weeks in the old loop of docs, Google, Stack Overflow, trial and error, and a lot of glue work.
The answer, at first, looked simple: AI makes that faster.
But after a while I realised that is only half the story.
Assisted: Faster, But Still Human-Driven
In Assisted mode, AI is mostly there to help me move through the friction.
I ask for a snippet, a helper function, a config skeleton, or a quick explanation of an unfamiliar API. Then I still do the real assembly work myself: wire it into the repo, make it compile, make it deploy, make it behave.
That already helps a lot. The blank-page penalty drops. The pointless tab-hopping drops. I get to spend more time moving and less time searching.
For me, that kind of work can pull a 4 to 6 week MVP down to something closer to 4 weeks.
That is meaningful, but the overall shape of the work is still the same. I am still the one implementing end to end. AI is helping, not really driving.
Integrated: Interactive Co-Execution
Integrated mode is where things started to feel different.
For me, that was Codex CLI. Instead of asking for isolated snippets, I was working interactively in the repo itself. Changes were proposed in context, diffs were applied, errors were fixed in sequence, and the iteration loop became much tighter.
This is the point where the long tail starts disappearing. The problem is no longer "I know what to do, but it will take forever to get there." A lot of the repetitive glue work can now be carried in the same session while I stay focused on the intent and constraints.
That shift was dramatic. The same category of work that once felt like a month-plus problem started looking more like 4 to 5 days.
That is not just "faster autocomplete". It changes the feel of the work. Less context switching, fewer broken half-steps, and a much more direct line from idea to running system.
Validated: Agentic Roles, Evidence, And Repeatability
Validated mode is where I stopped thinking of AI as a tool and started thinking of it as a system that needs to be governed.
I used a framework that let AI take on distinct roles across a cycle: planning, implementation, testing, review, and an audit-style summary of what changed and why.
The difference here is not just that it goes faster. It is that the work becomes more structured and more inspectable.
When the loop is working properly, I end a cycle with:
- a plan that matches the intent
- a set of code changes that map to that plan
- tests and verification output
- a review narrative you can audit later
That is the moment where AI starts to feel less like a typing assistant and more like a delivery engine.
For the kinds of platform and cloud MVPs I build, that can take the same category of work down again, to roughly 2 days of active engineering time, plus some finalisation at the end to make sure the requirements are genuinely met and there is no design flaw hiding behind a successful demo.
That is the part that gets people's attention. It should.
The Catch: You Also Spend Tokens
But this is also where the story gets more interesting.
When I talk about the acceleration, I am mostly talking about the engineer's time.
There is another resource being consumed in parallel, and it is easy to ignore for longer than you should: tokens.
That meter is not visible in the codebase. It does not show up in the architecture diagram. It often does not feel real until the invoice, the usage cap, or the weekly limit gets in the way.
What I found across the modes was fairly consistent:
- In Assisted mode, token usage is almost negligible. A free tier on ChatGPT or Claude is usually enough.
- In Integrated mode, usage goes up, but it is still manageable. A personal or Pro tier on Codex was enough for me, while some other models burned through allowance much faster.
- In Validated mode, token use becomes a real operating factor. I had to move up to Codex Business, use up allowances across two seats, and wait for the weekly limit to roll over.
That is the hidden meter.
The acceleration is real, but so is the spend. In my experience, Validated mode can consume something like 5 to 10 times the tokens of lighter workflows.
That is not a reason to dismiss it. It is simply the cost side of the same curve.
Why This Matters To A Business
From the engineer's perspective, this feels incredible. Less grind, faster iteration, more continuity, and much less time lost to low-value work.
From a business perspective, the conversation has to be wider.
If governance is weak, runaway AI does not just risk producing mediocre output. It also risks producing a very large bill while doing it.
That is why I think the real maturity test is not whether a team can make AI go fast. It is whether they can make AI go fast inside boundaries they actually understand.
Validated workflows are powerful precisely because they start to look like a real delivery system. Once that happens, they need to be managed like one.
Practical Guardrails That Help
A few controls started to matter a lot more once I moved from "AI helps me" to "AI executes with me":
- Put explicit budgets around agentic runs (per task, per day, per repo).
- Require evidence outputs for validated cycles (tests run, results summarized, diffs linked).
- Treat model choice as an engineering decision, not a default (cost and reliability vary).
- Add kill switches. If a loop is drifting, stop it quickly and fall back to human-driven repair.
- Log the workflow. Not for surveillance, but for traceability and learning. Sure, we could implement another AI layer to guide and correct this workflow, but that's a different story.
Outcome And Next Step
The main thing I have learned is that both sides are true at the same time.
AI is genuinely compressing work that used to take weeks into days. I have seen that directly enough times now that I no longer think of it as hype.
But the mature version of the story is not "AI makes us faster."
It is "AI makes us faster when we can bound the system, the cost, and the failure modes."
My next step is to make those controls more explicit in the workflow itself: token budgets, cycle-level evidence, and clearer escalation rules. If I can keep tightening that layer, then I can keep pushing up the gradient without turning speed into risk.