From vibe coding to dependable software

The important distinction in AI-assisted software is whether someone can explain and verify the behavior people will rely on. Who typed the code tells you little about that. A manually written system can be poorly understood; an AI-assisted one can be carefully engineered.

“Vibe coding” often describes prompting, trying the result and continuing without closely examining the implementation. That can be an effective way to explore. The risk changes when an experiment becomes a dependency: the ability to produce another version is not the same as knowing what the next version might break.

For an individual, learn what the prototype proves

An AI-built report can demonstrate a useful interface and reveal which questions you actually care about. That is real progress. It does not yet establish that every total is correct or that unusual records are handled sensibly.

The valuable boundary is between learning about the idea and relying on its output. A prototype can prove that people want a capability while leaving substantial questions about its implementation open. Keep both conclusions visible.

For a personal tool, the consequences may be small and easily checked. Once it becomes the authoritative record, handles customer information or supports other people’s work, the responsibility changes. The code may be identical the day before and the day after that transition. Its role in the world is what makes further engineering worthwhile.

For a team, make the work reviewable

When several people depend on the same tool, the team needs a shared account of what it should do. Keep the source in version control, divide changes into manageable pieces and name the person who reviews and accepts them. Test the important user journeys, including permissions and failed requests.

AI can help produce those tests and explain unfamiliar code. Review the tests against the intended behavior: a test that repeats the implementation’s mistake offers little reassurance. For a browser application, Playwright can exercise a journey such as submitting a request and checking the resulting state. It is useful evidence for the behavior you actually test.

Avoid turning faster generation into a queue of changes nobody has time to review. Match the amount of work underway to the team’s review and release capacity. A small accepted change is more useful than a large unfinished branch.

For an organization, build the conditions for good work

An organization needs a way for people to experiment without each team inventing its own rules. Provide approved tools and data settings, clear access boundaries, reusable project instructions and a route from experiment to supported service. Decide who pays for usage, who responds when something breaks and who can authorize a release.

Give teams working examples of good practice. A maintained starter project with useful tests and a clear deployment process can remove repeated setup work. Shared instructions can capture architectural decisions and review expectations. Make those instructions easy to update as the tools and the organization change.

DORA’s 2025 research describes AI as amplifying the strengths and weaknesses of the surrounding organization. Our practical reading is that buying access is only the beginning. The delivery process must be able to absorb the additional capability.

Ask what the faster build makes possible

AI-assisted delivery can change the economics of a focused internal tool or integration. Exploring an approach and producing an initial implementation may take less effort, making a previously impractical project worth revisiting. Review, migration, adoption and maintenance still belong in the budget.

Compare time to an accepted result, the corrections required and the cost of operating it. The answer will vary with the task, the team and the condition of the existing system. Measuring value helps turn that comparison into a useful business decision.

In October 2026, David Heinemeier Hansson argued for putting down the pencils and embracing coding agents. It is a clear statement of the shift in how software gets made. It is an industry perspective, not a measurement of what your project will save.

Before you put it into service

• Can someone explain the important decisions and change the system without guessing?

• Have you tested the behavior that matters, including access, failures and recovery?

• Are the accounts, code and data under the right ownership?

• Is there a named maintainer and a practical way to stop or reverse a release?

A prototype can be worth keeping without being ready to operate. The design insight, examples and discovered requirements may survive even if some implementation changes. A specification preserves that learning so the next stage improves on the experiment rather than simply repeating it.