Coding with AI, without becoming a developer.

For most people the barrier was never logic. It was everything around it: setting up an environment, remembering what a method is called, wiring a database, working out why the thing that ran on your laptop refuses to run anywhere else. That barrier has dropped a long way. You describe what should happen, the system writes and runs an implementation, you look at the result and adjust it in words.

What has not changed is the part that was always the hard part. Knowing what should happen. Knowing whether the result is right. Knowing whether it is safe to point at real data. Knowing what breaks, and who it lands on when it does.

The syntax barrier moved. The responsibility did not.

The practical consequence is a change in who holds the pen. Someone who understands the problem in detail used to have to brief somebody else and wait. Now they can attempt it themselves and bring a working thing to the conversation. That is a much better starting point than a document — including for the engineers who eventually get involved.

The realistic range is wider than most people expect and narrower than the marketing suggests. These are the categories that consistently work.

• →Internal tools. A form that validates its own inputs instead of a shared spreadsheet nobody trusts. A small view over one export that answers the question people keep asking in chat.
• →Simple workflows. Sorting an inbox of enquiries, drafting a response a human still reads and sends, producing the same summary every Monday without anyone assembling it by hand.
• →Prototypes. A version of an idea that actually runs, good enough to put in front of five people and watch them use it. This is the highest-value category by some distance.
• →Research and analysis. Reading the whole set of interviews, reviews or tickets and pulling out structure you then check yourself, rather than the three you had time for.
• →Operational utilities. The small conversions, checks and reformattings somebody does by hand every week and has stopped mentioning because it is “just how it works”.

What this is not is production-grade software in an afternoon. A tool used by one team, on data that is not sensitive, where a wrong answer is visible and recoverable — that is genuinely achievable in a day or two. Anything customer-facing, anything holding personal data, anything money passes through, and anything other teams depend on is a different undertaking involving different people. Being clear about which one you are doing is most of the skill.

One user. One task. One input. One verifiable output. Verifiable is the load-bearing word. Choose a job where you can tell, without asking anyone else, whether the answer is right. If you cannot check it, you cannot improve it, and you certainly cannot ask a colleague to rely on it.

A good first job usually looks like this:

• →It happens every week, and someone currently does it by hand.
• →You can describe it completely in two sentences.
• →You already have three real examples where you know exactly what the correct output is.
• →If it produces a wrong answer, somebody notices before it matters.

Bad first jobs share a shape too: “a CRM”, “an assistant for the team”, anything whose success is judged by someone else’s impression rather than a result you can check. Those are not too ambitious — they are simply unmeasurable, which means you will never know whether you are making progress.

The whole practice is one short cycle repeated until the thing behaves. It is worth knowing the shape of it, because almost every frustration comes from skipping a part.

Define

Write what it should do in the plainest language you have, including what it must refuse to do. Two clear paragraphs beat two pages of specification. If you cannot write it, the problem is not yet understood, and generating something will not help.

Generate

Let the system produce a first version. Expect it to be roughly right and specifically wrong: the overall shape is usually sensible, the details are where it invents things.

Run

Execute it on a real input. Reading what was generated and deciding it looks plausible is not running it, and plausible is exactly what a language model is best at producing.

Inspect

Put the output next to the answer you expected. If they match, immediately try a harder input — the awkward record, the empty field, the name with an apostrophe in it. Agreement on the easy case tells you very little.

Adjust

Change one thing at a time and say why. Rewriting the whole instruction because one behaviour is wrong tends to lose the three behaviours that were already correct, and you will not notice until later.

Verify

Before anyone else touches it, run your three known examples, plus an empty input and a deliberately malformed one. Keep those examples. Two weeks later, when you change something small, they are the only reason you will notice you broke it.

A generator will answer any question you put to it, including the ones it has no way of answering. These decisions stay with you.

• →Whether the problem is worth solving. Being able to build something quickly is not a reason to build it.
• →Whether the output is correct. Confidence is a writing style, not a signal. A wrong number arrives in exactly the same tone as a right one.
• →Whether the data may be used this way. Personal data, customer data and anything covered by an agreement have rules attached that no tool will remind you of.
• →What should happen when it is wrong. A visible failure is nearly always better than a silent wrong answer that someone forwards to a client.
• →Who owns it. The moment a second person depends on it, somebody has to be responsible for it on a bad day.

This is also where your expertise is the advantage rather than the gap. You know that the supplier codes beginning with a particular prefix are handled differently, or that a candidate record cannot be shared across those two teams. The model does not know that, and it will not tell you that it does not know.

There is a moment when a personal build becomes something else. The signals are consistent, and every one of them is worth acting on the first time you see it.

• →Other people have started to depend on it.
• →It needs to run on its own, on a schedule, when you are not there.
• →It touches customer or employee data, credentials, or payments.
• →It needs to survive change — new inputs, a new integration, somebody else editing it.
• →You can no longer explain what it does from beginning to end.
• →You are copying keys or passwords around to keep it working.

Involving an engineer early is not an admission of failure; it is the point of the whole exercise. What you hand over — something that runs, a real user, a set of examples with known correct answers — is a far better brief than any document. The same applies to security before it faces outwards, to privacy and legal before personal data is stored or sent anywhere, and to whoever owns the data before a number from your tool appears in a report.

The longer argument for that boundary, and what changes on each side of it, is in our guide to building products with AI.

Reading about this is a poor substitute for watching someone do it and asking why they made a particular call. At VibeConf 2026, Elena Avramenko runs a live workshop building the first working screens of a mobile app from an idea, with no code written by hand, showing the workflow between a person and an AI agent and how to redirect it when the build goes off course.

Outside the conference, the Vibe Coding Amsterdam community runs hands-on evenings, workshops and buildathons where people build in the same room and compare what happened. It is a useful way to find out which parts of your experience are shared and which belong to your particular setup.