Vibe Coding vs AI-Assisted Software Engineering
Vibe coding vs AI-assisted software engineering: who owns the decisions, how the work is checked, and what must be proven before customers depend on the result.
Vibe coding and AI-assisted software engineering both use AI to create software quickly. The difference is not whether a person or a model typed the code. The difference is who owns the decisions, how independent checks work and what must be proven before customers, data or money depend on the result.
Vibe coding is the mode where you prompt an AI platform towards a working result and move on with limited review of the generated code - the boundary Simon Willison draws between vibe coding and AI-assisted programming. AI-assisted software engineering keeps a named human accountable for product decisions, architecture, tests, security and release. At Code23 we call our controlled version of that second approach orchestrated AI engineering.
Vibe coding is excellent for exploring an idea and creating a working prototype. Orchestrated AI engineering is the process we use when that prototype needs to become software people can depend on. It combines specialist agents, independent models, experienced engineering judgement, source control, automated tests, security review and an explicit release gate.
The first method creates possibility. The second creates accountable delivery.
The short comparison
| Question | Vibe coding | Orchestrated AI engineering |
|---|---|---|
| Who directs the work? | A founder or maker prompts one platform towards the desired result | A lead engineer turns the outcome into bounded work for specialist agents and reviewers |
| What is the main goal? | Make the idea tangible and iterate quickly | Ship and operate software against defined product, quality and risk requirements |
| How much context is controlled? | Usually the current conversation, connected files and whatever the platform retrieves | Repository rules, product evidence, architecture, issue scope, source material and acceptance tests are assembled deliberately |
| Who checks the code? | Often the same model or platform that wrote it | Deterministic tests plus an independent reviewer that did not author the change |
| How are models used? | Usually one product chooses and routes the model | Different models can be selected for research, architecture, implementation, challenge and review |
| How are changes isolated? | Checkpoints or platform history | Git branches, worktrees, commits, pull requests and reversible deployments |
| What happens before release? | The preview works and the maker decides to publish | The agreed tests pass, risks are triaged, the rendered product is checked and a named human authorises release |
| Who owns a failure? | Often unclear once the prompt sequence becomes complex | Code23 owns the delivery process, evidence and decision to ship |
This is not a claim that every professional build must be slow or surrounded by meetings. Our process is agent-led precisely because we want the speed. The control layer exists so that speed survives contact with a real product.
"Our website needs have been looked after by Code 23 for many years. We have successfully developed a number of websites together and we have always found Code 23 to be excellent to work with. I would highly recommend Code 23 to anyone looking for a professional, efficient and friendly website designer."
Why one AI never has the complete answer
Frontier models are extremely capable, but each answer is produced from a bounded context. The model sees the files, instructions, tools and evidence available in that moment. It does not automatically know every earlier product decision, hidden operational constraint or future consequence.
Four problems follow:
- Context is incomplete. A model can implement the visible requirement while missing a business rule in another system or a decision that was never written down.
- Output is probabilistic. The same model can take different paths on the same task. Fluent code is not proof that the trade-offs were considered.
- Strengths differ. One model may be better at repository-wide implementation, another at research, another at adversarial review or visual reasoning.
- Self-review is weak evidence. Asking the authoring model whether its own work is correct often repeats the same assumptions in a more confident form.
That is why we do not ask one frontier model to plan, implement and approve its own work. Separation of responsibilities is the point.
Industry writing is moving the same way. Martin Fowler’s note on agentic programming stresses that useful agent work still needs human direction, review and ownership of the result. The 2025 DORA research treats AI as an amplifier: the surrounding system decides whether the gains land. Google Cloud’s DORA announcement summarises the same point. Teams with automated testing, mature version control and fast feedback loops are better placed to absorb AI-assisted change than teams that only add a prompt box. That is evidence about conditions, not a promise that any one toolchain guarantees better outcomes.
How Code23 uses orchestration
Orchestrated AI engineering is AI-accelerated software engineering with human ownership. It is not unattended vibe coding.
Our engineers remain responsible for product decisions, architecture, security, quality and release. Agents and models increase how much careful work one experienced person can direct. They do not replace the judgement about what should exist, what risk is acceptable or whether the evidence is strong enough to ship.
The working principle
We separate the jobs that create blind spots when they sit with one model:
- Someone defines the outcome and the bounded task
- Someone implements the change
- Someone who did not author the change challenges it
- A named engineer resolves trade-offs and decides what ships
The exact model roster can change by task. A typical pass may have Codex lead and define the work, Grok implement, and Claude Code or Gemini review independently. Another task may use a different combination because the work needs research depth, visual reasoning or a sharper security challenge. The principle is separation of responsibilities and independent challenge, not loyalty to a fixed vendor stack.
Models are chosen for the role. Not every named model is used on every task. The constant is independent challenge plus a human release call.
What sits around the models
The models are only one layer. Around them we keep the controls that make production work survivable:
- Inspectable work. We start from the customer outcome, then turn it into bounded tasks with acceptance criteria rather than one giant prompt.
- Deliberate context. Agents get the repository rules, product notes, architecture and tests they need for the job. More context is not automatically better if the important rule is buried.
- Isolated, reversible changes. Work happens in version control, on branches and pull requests, so another person or model can inspect it and we can roll back. Platform history helps while exploring; Replit’s Agent docs still expect plan, review and checkpoints before you treat a change as settled.
- Tests as part of the build. Unit, integration, contract, browser, accessibility and security checks are selected according to risk. A green preview is not enough.
- A human at the release boundary. Agents can build, test and review. A named person still owns the decision when customers, money, sensitive data or hard-to-reverse actions are involved.
For important architecture, risk or review decisions we can ask several frontier models for independent assessments. Each gets a defined question. One may inspect migration risk. Another may challenge the security boundary. Another may look for product or usability gaps. The lead reconciles the evidence, records disagreements and chooses the path. Three models can share the same missing context, so a minority finding backed by the code or a failing test matters more than four confident opinions.
Why this matters for clients
This process exists to improve outcomes, not to decorate the delivery story:
- Fewer blind spots, because the builder is not also the only reviewer
- Stronger QA, because tests and independent challenge are part of the work
- Better architecture, because product and engineering judgement stay in charge of the hard trade-offs
- Safer changes, because access, data handling and release authority are deliberate
- A product that can keep evolving, because decisions are recorded in code, tests and reversible releases rather than lost in a prompt history
Client proof
They didn't just deliver screens to a spec. They pushed back on flows we'd normalised, refined the UX in ways we hadn't considered, and brought a level of UI craft that lifted the entire product above what we'd scoped.
How security changes when the prototype becomes a product
Security is not a final scan added after the product looks finished. It starts with what the software can access and what a mistake would do.
Our production pass considers:
- Authentication and server-enforced permissions
- Separation between customers, roles and organisations
- Secret storage and removal of exposed credentials from history
- Personal-data collection, minimisation and retention
- Input validation and safe output handling
- Dependency and supply-chain risk
- Payment webhooks, retries, limits and duplicate actions
- Logging that is useful without leaking confidential data
- Backups, recovery, monitoring and ownership after launch
- Human approval around customer communication, money and irreversible actions
AI can help inspect each of these areas. It cannot set the acceptable risk on behalf of the client, and it cannot prove a control merely by describing one.
What happens to client code and data?
Code23 does not use client code, private project material or customer data to train our own AI models. Repositories stay private, access is limited to the work being done and client material is only supplied to approved tools where it is needed for the task.
We use business or API access with the relevant provider data controls rather than treating a public consumer chat as a development environment. Provider choice can vary by task, so the tooling and data boundary should be confirmed for the project rather than hidden behind a blanket “AI-powered” claim.
We also minimise what each agent receives. A content reviewer does not need production credentials. A visual QA agent does not need a customer export. A model checking a migration plan may need the schema and constraints, not the confidential records inside it.
If a client has a stricter provider, location or retention requirement, that becomes an architecture constraint before the work starts.
What Code23 engineers still do
AI changes the amount of software one experienced person can direct. It does not remove the work of deciding what should exist and taking responsibility for the result.
Our engineers still:
- Challenge the product and commercial assumptions
- Choose the architecture and decide where complexity is justified
- Define what evidence is needed before more money is committed
- Decide what generated code can stay
- Resolve conflicts between models and between requirements
- Own security and data decisions with the client
- Review the working product, not only the source files
- Decide whether the release evidence is strong enough to ship
- Support, monitor and improve the product after launch
This is where twenty years of product and engineering experience compounds with AI. The agents create far more implementation capacity. Experience directs that capacity and spots when a fast answer is solving the wrong problem.
Can a founder’s existing code enter this process?
Yes. That is now one of our preferred ways to receive a brief.
We do not begin with the assumption that vibe-coded code must be discarded. We audit the product and the repository, then give important areas a clear decision:
- Retain: sound enough to continue with normal review and tests
- Refactor: the behaviour is useful, but the structure or controls need work
- Rebuild: the risk, lock-in or hidden assumptions make replacement safer
- Defer: not needed for the first release or not supported by evidence yet
The founder’s guide to vibe coding explains how to build and hand over that first artefact. Our prototype vs MVP guide helps classify what you have actually built. If you already have a working product, Vibe Coding Cleanup is the assessment and production-build route.
Where AI consultancy fits
Some businesses want the delivery system, not only one product. They want teams using AI across sales, operations, support, knowledge and software development without everybody inventing their own rules.
That is an AI consultancy question. Our AI Implementation Workshop is £750 + VAT, runs for four hours with up to four attendees and produces a written 90-day plan within five working days. The plan covers people, processes, tools, data, responsibilities, costs and success measures. It may recommend training, existing software, workflow changes, automation or custom development. It does not force every problem into a bespoke AI build.
For a founder with one working prototype, a product and code audit is usually the more direct conversation. For a leadership team that wants this way of working across the company, start with the workshop.
FAQ
Is orchestrated AI engineering just agentic coding?
Agentic coding is part of it. The orchestration also controls context, task ownership, independent review, test evidence, data access, release authority and the handover between agents and people.
Does every change go to several models?
No. That would add cost without improving every decision. We use multiple models when independent perspectives materially reduce uncertainty, such as architecture, security, unfamiliar systems or final review. Simple deterministic work should stay simple.
Are AI-generated tests trustworthy?
They are useful evidence, not automatic proof. A test can repeat the same misunderstanding as the implementation. Important acceptance criteria come from the product and risk, and independent review checks whether the tests cover the real failure modes.
Is this slower than using a single app builder?
It adds controls, but specialist agents can research, build and test in parallel. For production work it is usually faster than repairing a growing product after unreviewed assumptions have spread across the codebase.
Can Code23 work with Lovable, Bolt, Replit or v0 code?
Yes. We have used the main prompt-to-app platforms and can assess exported repositories from them, including Lovable projects synced through GitHub and v0 full-stack app workflows. The platform is less important than access to the code, connected services, product evidence and the ability to test the result.
Does Code23 train models on client work?
No. We do not use client code, private project material or customer data to train our own models. We still confirm the external provider and data controls appropriate to each project because “not training a model” is only one part of protecting client information.
What kind of AI software does Code23 build?
Client platforms with AI built into the product, not bolted on. Recent examples include an audit platform where AI drafts cited responses for a person to approve, an operations platform whose AI chat answers questions across a firm’s documents with citations, and a machine learning engine that prices carriage at checkout. We’ve helped 50+ businesses implement AI.
Does Code23 have reviews or case studies for this kind of work?
Yes. We’ve got 60+ five-star Google reviews from 20+ years of client work. For AI work specifically, read our case studies: Oditable, an AI audit platform where a person approves every response, ESHP, an operations platform with AI search across the firm’s documents, and Plastor, machine learning that prices carriage at checkout.
How do I know when a vibe-coded prototype needs orchestrated engineering instead of more vibe coding?
If customers, real payments or personal data are about to depend on it, that’s the signal. Keep vibe coding for exploring the idea. Once you need tests checked by someone who didn’t write the code, a security review and a named engineer who decides whether the release evidence is strong enough, you’ve moved into production. That needs orchestrated AI engineering, not another prompt.
What does it cost to move from a vibe-coded prototype to something Code23 will put its name behind?
It depends on what the assessment finds. Some prototypes need light refactoring and tests; others need core pieces rebuilt. We price a Production Readiness Assessment against the size and risk of the product. It gives you a written retain, refactor, rebuild and defer decision, then a fixed scope and price for the first production release before any build starts.
Sources
- Simon Willison: Not all AI-assisted programming is vibe coding (19 March 2025)
- Martin Fowler: Agentic Programming
- DORA: 2025 State of AI-assisted Software Development report
- Google Cloud: Announcing the 2025 DORA report
- Replit documentation: Plan, review, test and use checkpoints with Agent
- Lovable documentation: GitHub sync and external development workflows
- v0 documentation: Incremental full-stack development
- v0 documentation: Branches, commits and pull requests
Next step
If you already have a working AI-built prototype, start with Vibe Coding Cleanup. We’ll challenge the product, inspect the code and map what should be retained, refactored, rebuilt or left out of the first production release.
If you want this way of working across your whole team, start with the AI Implementation Workshop instead. We’ve helped 50+ businesses implement AI, and the workshop ends with a written 90-day plan covering people, processes, tools and data.
Move beyond the demo
Turn your AI-built prototype into software people can depend on.
We'll review the product and code, then tell you what can stay, what needs work and what should be rebuilt before you launch.
