You know the moment. The app works. You described it in a sentence, watched it appear, clicked through it, and it does the thing. Then you ask for one more change — add roles, or make the export respect the filters — and something three screens away quietly breaks. You fix that. Something else breaks. An hour later you are reading generated code you have never read before, trying to work out what it thought the data model was.

That moment is not a failure of the tool. It is the moment the tool changed jobs without telling you.

Vibe coding is a real technique, not a slur

Vibe coding is conversational. You describe, it builds, you look, you adjust. The loop is fast because nothing is written down between turns — no spec, no schema you approved, no tests. The model holds the whole thing in its head, and so do you.

That is exactly why it is good. When you do not yet know what you are building, writing it down is premature. You are not trying to produce software; you are trying to find out whether the idea survives contact with a screen. Three throwaway versions in an afternoon beats one carefully planned version in a week, because two of them were wrong and you needed to see them to know that.

Vibe coding is right when the cost of being wrong is one more prompt. Demos. Spikes. Interfaces you are still arguing about. Anything you would be happy to delete.

Agentic development writes things down

Agentic development looks slower at the start because it produces artefacts before it produces code. A requirements document. A schema. An architecture note. A task list. Then code — generated against those artefacts rather than against a chat history.

The word "agentic" gets used loosely enough to mean nothing, so here is the concrete version: separate agents do separate jobs, each producing something the next one depends on. A requirements agent turns your description into a BRD. An architecture agent turns that into a data model. Code generation runs against the schema rather than inferring one from the screens. A testing agent writes tests against the requirements. A security agent reviews what was built against what was intended.

None of that is magic. It is the same discipline a team applies by convention — write it down, agree it, build to it — with the writing-down automated.

The real difference is what survives the conversation

The speed comparison is a distraction. Both approaches produce a working app quickly. The difference shows up on the fifth change, not the first.

Vibe coding produces output. When the session ends, you have code, and everything else — why the schema looks like that, what you decided about permissions, which behaviours were deliberate — lives in a chat log or in your head. Ask for a change six weeks later and the model re-derives all of it from the code, which means it re-derives it differently. That is the wall. Not that the code is bad, but that nothing constrains the next change to agree with the last one.

Agentic development produces artefacts. The schema is a file. The requirements are a document. The tests encode the behaviour you asked for. When you request a change, it is checked against those, and a change that contradicts them shows up as a conflict rather than as a bug three screens away.

That is the whole argument, and it is not about AI. It is the same reason teams write specs and tests without AI. AI changes the economics — writing the spec used to cost a day — but not the logic.

Both approaches fail, differently

Vibe coding fails by accumulation. Every change is locally reasonable and globally unmoored. You do not notice until the app is large enough that no single person, and no single context window, holds all of it.

Agentic development fails by ceremony. If the plan is wrong, you have now generated a BRD, a schema and a test suite that all faithfully encode the wrong thing — and you are more committed to it than you would have been after an afternoon of vibe coding, because it looks official. Planning is only worth its cost once you are reasonably sure what you are building.

Which is the actual insight: these are not competing philosophies. They are phases. Almost every real project wants the first one, then the second, and the expensive part is the transition.

Where CodeSky sits

We built CodeSky around that transition, because it is the part that normally costs you a rewrite.

You start conversationally. Describe the app, watch it build, click through it, change it — the vibe coding loop, unmodified. Nothing about the early stage asks you to write a specification for something you might abandon.

When the idea holds, you turn on Planning Mode instead of starting over. The BRD agent turns what you have already described into requirements. The architecture agent derives a data model. Generation becomes staged rather than single-shot: intent, then schema, then API and interface built against that schema — so the three cannot drift apart, because two of them are generated from the third.

From there the specialised agents are the ones you would hire for: documentation, unit tests, QA runs, security audit, performance analysis, accessibility audit, refactoring. The production-readiness checklist tells you what is still missing rather than declaring you done.

And the output is real code in your own GitHub repository — a frontend, an API, migrations, auth, background jobs. Not an export. The same code whether you spent the whole project vibe coding or moved to Planning Mode on day two.

The claim is not that agentic is better. It is that you should not have to choose at the start, when you have the least information, and you should not have to rebuild to change your mind.

How to tell which mode you are in

A question that works: if this were deleted tonight, would you rebuild it or re-decide it?

Rebuild it — you know what it should do, you just need it to exist again — and you are past vibe coding. Write things down. The plan will pay for itself on the next change.

Re-decide it — you would probably build something different, because you have learned something — and you are still exploring. Keep vibing. A specification now would be a specification for the wrong product.

Most teams are in the second phase for longer than they admit, and stay there for longer than they should. The trick is noticing when it changes, which is usually a few weeks before the fifth change breaks something three screens away.