Vibe coding: building without being a developer

This website was also created through vibe coding: describe an outcome, build a first version with AI-assisted tools, observe it, correct it and repeat. I am not a developer. That is precisely why I learned that building without being one does not mean giving up control or responsibility.

The opportunity is clear. An idea that would once have remained in a document can quickly become a navigable prototype. You can test a structure, see whether content works inside a page, try a flow and show it to other people before investing in full development. For someone coming from communication, product or business, this reduces the distance between imagining and verifying.

But the distance does not disappear; it changes shape. Without knowledge of code, it is harder to understand why something works, which dependencies it creates and how expensive it will be to maintain. The risk is confusing the ease of producing a first version with the solidity of the underlying system. A prototype answers ‘can we see it?’, not yet ‘can we use, protect and maintain it?’

Iteration is the real tool

Vibe coding is often presented as obtaining an application from a single prompt. My experience is the opposite: its value lies in iteration. The first request produces an interpretation, not a final solution. You must inspect what was built, identify the difference from the intention, formulate a precise correction and verify that it did not break something else.

Building this site required many such sequences across copy, hierarchy, images, responsive behaviour and page connections. Every local change could affect another area. The initial speed is real, but it should be invested in control rather than used as a reason to skip it. Results improve when a prompt stops being a generic wish and becomes a verifiable specification.

Controlling what you cannot write yourself

Not being a developer does not prevent control; it changes the kind of control available. I can test interface behaviour, content consistency, paths, visible errors and correspondence between request and result. I can require tests, read automated reports and ask for decisions to be explained. I cannot pretend these checks replace technical review when security, data or reliability become critical.

Responsibility also means recognising the boundary. A personal prototype and a product used by customers do not carry the same risk. An editorial page and a system handling payments or sensitive data need different safeguards. Vibe coding expands what I can explore independently, but it does not automatically turn exploration into professional development expertise.

Maintenance begins before the end

Every feature adds something to maintain. When built without understanding where it lives, what it depends on and how it is tested, a project accumulates invisible complexity. At first everything feels fast; later, one change breaks a distant behaviour and nobody knows why. Maintenance is not a future problem. It is a quality of the decisions made while building.

Reducing that risk requires discipline: change one thing at a time, preserve a comprehensible structure, verify each step, avoid unnecessary dependencies and document choices that are not obvious. These are working principles before they are technical principles. Tools can write code quickly, but they cannot decide which complexity is worth introducing.

From experiment to product, when needed

Vibe coding is especially useful for experiments. It allows an assumption to be tested without immediately turning it into an expensive project. If the experiment demonstrates value, parts can be consolidated or rewritten and developers involved. If it does not, it can stop after producing useful knowledge at a lower cost. This prevents every prototype from becoming the compulsory beginning of a business.

I used the same approach for this website and other prototypes: build enough to make a question tangible. Some remained experiments; others needed greater care. The new ability was not ‘being able to develop’, but being able to discuss development through something observable, formulate better requests and understand the consequences of decisions more clearly.

Building without being a developer is therefore possible and useful as long as it does not become an excuse. AI can accelerate production, but it does not assume responsibility for the outcome. That remains with whoever puts it online, lets people use it and maintains it. Control does not require writing every line; it requires knowing what is being requested, how to verify it and when to involve people with the missing expertise.

The quality of the request is another boundary. AI tends to fill gaps with plausible choices, but plausible does not mean appropriate. Without stating audience, priorities, constraints and edge cases, it is easy to obtain something that appears complete while concealing decisions never made. The work remains editorial and strategic: decide what not to build, preserve coherence and recognise when an answer matches the prompt’s form but not the actual need.