I keep wanting a better phrase than vibe coding.
Not because the phrase is useless. It describes a real change: you can now sit with an AI coding tool, describe what you want, and watch software appear faster than it used to.
But it is too loose for the kind of building I care about.
The interesting version is not a person prompting their way through an app they do not understand. It is a person who understands the work very well, using AI to keep the software close to that work as it changes.
That is what I mean by organic software.
It starts small. It grows through use. It gets pruned when it becomes messy. It keeps a memory of why decisions were made. It is dynamic, but it is not careless.
The app changes while I build it
Most useful software does not reveal itself all at once.
You build the first version. You use it. Something feels clumsy. A field is missing. A step appears in the real workflow that was invisible in the plan. A user does something sensible that the interface did not expect.
The old response was to collect those observations for the next sprint, next release, or next rebuild. Now you inspect the code, describe the change, ask an agent to help, review the diff, test the behaviour, and keep going.
That can look casual from the outside. It is not casual when done well.
The builder is making continuous product and engineering judgements: which changes are real, which are noise, which shortcuts are safe, and which parts of the app need to remain stable.
Why vibe coding is too soft a label
Vibe coding has become the popular shorthand for natural-language software creation. It is useful as a cultural marker, especially now that the phrase has moved beyond developer circles and into mainstream discussion.
One version is exploratory prompting: describe a thing, accept a thing, keep poking until the result looks close enough.
The other version is expert-led building with AI in the loop. The expert may still use plain language. They may still move quickly. But they are not outsourcing judgement. They are using AI to compress implementation time while keeping responsibility for the system.
Organic software belongs to the second category.
AI does not remove the need for expertise. It increases the amount of change a person can attempt, which means it also increases the surface area of judgement.
A better metaphor is gardening
Organic software is closer to gardening than magic.
A seed is the smallest useful version. Soil is the domain context around it: users, constraints, examples, data, policies, habits, edge cases. Pruning is the discipline of removing features, flows, abstractions, and screens that looked promising but made the app weaker.
Grafting is when a new capability can attach to the existing trunk without breaking it.
Seasons matter too. A personal tool can be rougher. A team tool needs clearer copy, better empty states, stronger error handling, and more stable expectations. The same app can move through those phases, but it should not pretend they are the same phase.
This is where organic software differs from loose improvisation. A garden changes constantly, but it still has structure. If everything grows everywhere, you do not have a garden. You have weeds.
The operating loop
The loop is simple enough to write down:
- observe the work
- build the smallest useful change
- use it in the real workflow
- capture friction
- ask the agent to implement within constraints
- review the diff and behaviour
- add tests, examples, notes, or guardrails
- repeat
The important part is not the speed. It is the inspection.
A faster loop without inspection only produces faster drift. The app accumulates features without a spine. The codebase starts reflecting every recent request. The interface becomes a record of indecision.
Keep the change small enough to judge
Organic building works when the next change can be reviewed against the work, not just accepted because the agent produced it.
Observe the real workflow
Name the friction before asking the agent to change anything.
Ship one bounded change
Keep the diff small enough that a human can still hold the intent.
Review, test, and prune
Decide whether the change strengthens the app or only adds motion.
This is the same reason AI does not automatically give you time back. Faster output can make the work denser unless the surrounding loop changes.
Where expertise enters
Expertise enters in four places.
First, domain taste. You know what the app should refuse to do. You can tell when a feature request is really a workflow problem. You can see when a technically impressive answer would make the actual work worse.
Second, technical judgement. You know when a shortcut is fine for a personal prototype and when it is creating debt that will slow every future change.
Third, product judgement. You can distinguish a missing capability from a missing explanation. You can decide whether the next change should be a new screen, a better default, a clearer empty state, or no change at all.
Fourth, evaluation judgement. You know what would count as better. Without that, AI-assisted building becomes a sequence of plausible changes with no reliable measure of improvement.
That is why this is not just a tool question. The same coding agent can produce very different outcomes depending on the operating behaviour around it. I made the AI Proficiency Self-Assessment for that reason: the product label matters less than how much context, action, autonomy, and verification the workflow actually has.
The discipline that keeps it alive
Organic software needs a product spine.
The spine is short:
- who the app is for
- what work it supports
- what the smallest useful version is
- what it should not become
- what evidence would justify the next change
The questions that stop the app from sprawling
A short spine gives both the builder and the agent something to check against.
It also needs a living decision log. Not a huge document. Just enough memory that future-you, or an AI coding agent, can see why the app took its current shape.
Tests and examples act like roots. They keep the system attached to behaviours that should not break. Notes and constraints act like labels in the garden. They stop the next change from trampling the last good decision.
The working posture is: let the app grow, but do not let it sprawl.
A companion planner
I want to turn this into a small tool: an Organic Software Planner.
The planner would help a builder write the product spine, growth loop, pruning rules, AI build packet, and release rings before opening a coding agent.
The useful output would not be a giant specification. It would be a compact brief you can paste into a coding agent, plus a review checklist that keeps you in control of the result.
That feels like the right companion to the idea. The article explains the posture. The tool helps someone practise it.
Software closer to the work
The promise of organic software is not that AI makes software effortless.
The promise is that a good builder can keep software closer to the work. They can make smaller changes sooner. They can learn from use while the idea is still alive. They can prune before the system hardens into something awkward.
It is dynamic software, but it is not vibe-only software.
