Vibe coding means building software by describing what you want to an AI and steering the result rather than writing it line by line. Norml does it daily, ships it to production, and knows exactly which parts still need an engineer. This page explains both.
A few clients we’ve worked with
Something was built in a weekend, it works, and nobody can safely change it now.
The prototype convinced everyone, and the production version is still six weeks away.
There are no tests, so every change is a gamble and nobody wants to touch it.
Credentials sit in the code, and the person who generated it did not notice.
It works for the person who built it and breaks on the second user.
We agree what is being built, how fast it needs to exist, and what happens to it afterwards. A throwaway prototype and a system that will carry real users need different treatment, and pretending otherwise is where this approach earns its bad reputation.
Build the thing quickly so the decision is made against something real instead of a document. On Stevens Industries the prototype settled the core flow — upload a drawing, get an estimate — before production work started.
Take a generated codebase to something maintainable: structure, tests, error handling, secrets out of the source, and a deployment that is not someone's laptop.
An engineer reads the generated code. Models produce confident, plausible code with real security and data-handling mistakes in it, and the mistakes are not obvious from the output working.
Inherit something vibe-coded that now matters, and make it changeable without a rewrite. This is increasingly the job people actually call us for.
A written standard for what your people may generate, what must be reviewed, and what must never be automated, so the speed survives without the liability.
Your repository, your accounts, documented limits, and a session with whoever will maintain it.
The agreed scope identifies which of these deliverables your project needs.
A working prototype, fast, when a decision needs something real to look at.
A production-ready codebase with tests, structure and secrets handled.
An engineer's review of generated code, with the findings written down.
A refactor plan where you are inheriting something that already exists.
A written standard your team can follow without us.
Repository and accounts in your name, plus a handover session.
Our process
Throwaway prototype, internal tool, or a system real users will depend on. Everything else follows from this answer, and it should be given honestly.
[ 01 ]Generate and steer to something that runs. This part genuinely is much faster than it used to be.
[ 02 ]An engineer reads it. Security, data handling, error paths. This gate does not move.
[ 03 ]Tests, structure, deployment, monitoring — proportional to the lifespan agreed at step one.
[ 04 ]Documentation of what it does and what it must not be trusted with, and the accounts in your name.
[ 05 ]
