Coding isn't dead.
Coders are.
"Vibe coding" is a misleading term. We don't call creating a Google Doc "vibe text processing" and we don't call using a calculator "vibe mathematics". What's actually happening is bigger than a buzzword — the entire cost structure of building software has collapsed, and with it, every assumption about who builds it, how, and why.
The cost structure changed. Everything else follows.
Traditional development practices — sprints, scope documents, PRs, code reviews, separate environments — weren't invented arbitrarily. They exist because coding is expensive. Getting it wrong is expensive. Coordinating multiple people is expensive. The practices exist to manage that cost and risk.
When the cost structure changes, the optimal practices change with it.
A rough working prototype
20 minutes, not 2 days
Iterating on it
10 minutes, not a sprint
Fixing a bug the AI introduced
A prompt, not a PR review cycle
Trying a completely different approach
Almost nothing
When iteration is this cheap, the gates that exist to protect against expensive mistakes start creating friction instead of protection. You don't need to plan everything before coding — you can code to understand the problem, then plan the real solution.
Generating code vs. executing work
Most people's experience of "AI coding" is chatting with an AI and copying the output into a file somewhere. That's generating code — one request in, one response out. It's a smarter autocomplete.
Claude Code CLI is something fundamentally different. It's an autonomous agent installed on a server. It reads your project, makes changes directly, runs them, reads the errors, and fixes them in a loop. It plans, breaks work into sub-tasks, spins up multiple agents in parallel, and keeps going until the job is done.
Generates code for you to use
You ask a question, it responds with code. You copy it, paste it, run it, debug it. One turn at a time. The AI has no memory of your project between messages and no ability to act on the result.
Executes work autonomously
It reads your codebase, plans the approach, makes the changes, runs the code, reads the errors, fixes them, and loops until it's done. Sub-agents handle parallel tasks. It has full shell access — anything the command line can do, it can do.
Planning and execution collapse together
The traditional workflow is: plan, then code. That made sense when coding was the expensive part. But when you can generate a working prototype in the time it takes to write a scope document, the relationship inverts.
Want to build a scheduling interface? You could scope it out first — flows, data model, UI agreement. Or you could generate a rough working version in minutes and use that as the basis for discussion. People react better to something concrete than they plan from something abstract.
This already works in practice
A designer creates a UI mockup in Claude Chat. It gets handed to Claude Code with a one-line prompt: "build this, connect it to Supabase." The code becomes the documentation. The mockup becomes the spec. There was no formal scoping step — the artefact communicated intent more clearly than a written document ever could. When someone looks at the working result and immediately says "that field is wrong" — that's the process working. Build rough, react, refine.
Scope documents don't disappear — they change form. The codebase itself becomes the primary documentation, if you enforce the right habits: inline comments explaining the "why", README files in each directory, meaningful commit messages. Claude Code generates most of this automatically. The documentation stays in sync with the code because it lives in the same repository. The nightmare of maintaining a separate spec that's always three sprints behind doesn't apply.
"Coding" is no longer a coder's job
Coding is no longer an isolated activity done in daylight-starved bedrooms by technical specialists with control issues. Building apps now falls into the same category as creating a Powerpoint presentation — it's a general business skill, not a specialisation.
And it's easy to say, "of course only coders will be coding!" Really?
Consider this: a user selects an app in their sidebar and asks, "Why is the utilisation for Hervey Bay showing X?" Claude reads the code to understand the business logic, reads the raw data, reads any data the app has created, and answers the question. It can show a chart, generate an interactive presentation of that data, or even create a whole new mini-app the user saves to their own sidebar.
That user just "coded". They didn't know it. They didn't need to.
The Powerpoint test
Imagine if users in your organisation had to go to a specific URL, sign up for a specific subscription, or download a specific app just to create a Powerpoint file. That wouldn't work. So why would we want people having to go to claude.ai, sign up with a plan, or download the desktop app just to work with "apps" within the organisation? Like working with Powerpoint files, working with code should be factored into every business process moving forward.
The desktop is a dead end
The instinct to run Claude Code on your desktop app, connected to a local Git repo, feels like the obvious choice. It's real Claude Code, and it works. But it's a fundamentally siloed approach.
You're isolated from the rest of the team. The only way to collaborate is through GitHub comments and pull requests. Nobody else can see what you're working on until you push. Nobody can contribute to your conversation with the AI. You can't share context, you can't share progress, and non-technical team members are completely locked out.
When everyone — coders and non-coders alike — needs access to AI-driven development, the desktop model breaks down entirely.
Where collaboration actually happens now
GitHub is an excellent collaboration tool for humans coordinating code. It was designed for a world where collaboration meant: person A writes code, person B reviews it, they communicate through comments and PRs.
When AI is in the loop, collaboration happens earlier and faster. You're not reviewing finished code — you're iterating through half-formed ideas in a chat thread, generating rough versions, deciding what to keep. By the time anything hits GitHub, most of the actual decision-making has already happened in the conversation.
If you want two people collaborating with AI on the same problem, you need them to share the AI conversation, not just the code repository. GitHub doesn't give you that.
One chat, full power, everyone included
The eVA platform connects your chat UI directly to a managed Claude Code CLI session on a server. The same chat interface you'd use for talking to GPT, Gemini, or any other model becomes a direct interface to the full agentic engine — no terminal required.
Container per user
Every user gets their own isolated coding container. Multiple people can work on the same codebase simultaneously. Each person sees their own changes immediately on a browser refresh — no waiting for merges or deploys.
Two layers of orchestration
eVA's orchestration connects your chat to your live business data. Claude Code CLI's orchestration handles sub-agents, parallel tool calls, planning, and autonomous execution. Both layers work together in a single conversation.
Shared conversations
Multiple people can be in the same conversation with the AI simultaneously — seeing the same context, contributing to the same session. Collaboration happens in the chat, not in a PR comment thread after the fact.
Every change is still committed and pushed to Git, so full version history and rollback are available. But the "deploy to dev environment" step that traditional workflows require doesn't exist — you're coding directly on the server. Changes are live immediately.
Traditional vs. AI-centric development
Scope first, then code
Code early to understand the problem, then refine the plan
Documentation maintained separately from code
Documentation generated by Claude, lives in the repo, stays in sync
Collaboration via GitHub PRs and comments
Collaboration in shared AI chat threads
Planning and execution are distinct phases
Planning and execution interleave and inform each other
Bugs caught in a code review cycle
Bugs caught by Claude in real time, fixed in the same session
Each developer has their own local environment
Everyone codes against the same server, sees changes instantly
Sprint velocity measured in story points
Iteration measured in conversation turns
New developer briefed with a scope document
New context loaded from CLAUDE.md and README files in the repo
Only developers can build and modify apps
Anyone in the organisation can interact with and modify apps
Switching AI tools means rebuilding context
Context lives in eVA — accessible from any front-end
There is no "best practice" yet
The AI coding space is two years old and moving every few months. Traditional development frameworks built on solid instincts — version control, environment separation, structured planning — are a legitimate starting point. But treat them as living documents. What's optimal today will evolve as the tools do.
The most useful thing isn't a document or a framework — it's a live session. A rough idea, Claude Code navigating a real project, making changes, catching its own errors, shipping something visible. That tends to shift the mental model faster than any comparison matrix.
See it in action
Not a demo of a finished system — a real working session. A rough idea, Claude Code navigating the project, making changes, catching its own errors, shipping something visible. Using your own data, so it's immediately applicable rather than abstract.