AI from Zero: How to Become a Vibe Coder and Stop Fearing the Terminal

Let me start with the distinction that matters more than anything else I'll say. When someone says "I use AI", they almost always mean a chat. You open a window, type a question, get text back. The text can be excellent. But then you have to do something with it yourself. Copy it, paste it, check it, run it, fix it, come back and ask again. The AI here is a very well-read conversation partner behind glass. It sees exactly what you told it, and all it can do is talk.

An agent is what you get when the glass is removed. It has hands. It opens files, reads them itself, changes them itself, runs what it built, looks at the result, sees the error, goes back and fixes it. And it comes back to you not with text, but with finished work. The difference between those two words is the whole difference.

Here is an everyday picture. A chat is a phone helpline. You describe the drip under your sink, and they say: probably the nut, tighten it with a twenty-two wrench. Good advice. But you are the one crawling under the sink. And if you don't know where the wrench is, or which of the three nuts is the right one, that advice gets you nowhere. An agent is the plumber you let into your flat. He crawls in himself, looks himself, works out that it isn't the nut but a cracked hose, replaces it, and turns the water back on to check it has stopped dripping. Meanwhile you were having tea.

And here comes the first honest caveat, which I'll keep repeating through the episode. You let the plumber in at your own risk. He can fix the wrong thing. He can fix things properly, but not the thing you meant. So working with agents is not "I stopped working". It is "my work moved". That gets its own section, and it is the most important one.

What you need to understand right now: you have seen a chat, and you most likely haven't seen an agent. When people say "I tried AI, it was fine, nothing special", ninety-nine times out of a hundred they tried a chat. That's like judging a car after sitting in it in a car park. Nobody started the engine.

The word "vibe coding" you've probably heard is about exactly this. It sounds unserious, and at first it annoyed me. But the meaning is precise: you describe what should come out in plain human words, and the machine takes on turning words into something that works. You set the direction and judge the result. You don't type code by hand. Strictly speaking, you don't even have to know what the code looks like.

I didn't come to this from engineering. I have a doctorate, and I spent my whole life working with people, not compilers. That turned out to be no obstacle, and sometimes even an advantage, because the key skill here isn't technical. We'll get there. First, the black window.

The terminal. A black rectangle, white letters, a blinking bar. Not a single button. Nothing labelled. It looks like something out of a hacker film, or like the screen that appears when your computer is already broken. I remember the feeling well: like standing at someone else's door with no right to touch it.

Let me take the mystery out of it.

A terminal is simply a way to give a computer commands in words instead of clicks. That's all. When you move the mouse and click icons, you give the very same commands, just through pictures. Pictures are convenient for people. But pictures have a limit: you can only press what someone drew in advance. With words you can say anything, including things nobody anticipated.

And here is the main reason we are here at all. An agent needs hands. A pretty window with buttons doesn't give it hands, because everything there is drawn for a human finger. A text command does. For an agent, the terminal is what the steering wheel and pedals are for you: not decoration, but the place where you actually drive. That's why all serious work with agents lives there.

Why does it look so bare? Because nobody designed it for you. It's the staff entrance. The restaurant kitchen: tiles, stainless steel, strip lights, nothing for show. The dining room has tablecloths and candles, but the food is cooked back here. The terminal's interface isn't about looks; it's about nothing standing between your intention and the machine. In a week you'll stop noticing the black background.

There is one more reason it looks the way it does, and I like it. Text is the most honest interface of all. It shows exactly what happened: here is the command, here is the answer, here is the whole error, with no polite little box saying "something went wrong". Pretty programs hide what is going on so as not to scare you. The terminal hides nothing. For the first few days that's irritating, and after that you start to value it: when you work alongside an agent, you need to see what it is doing, not guess.

Now the specific fears. There are three, and everyone has the same ones.

First: "I'll press something and delete everything." You won't. To wipe a system you have to deliberately type a fairly specific command, and usually confirm it with a password as well. You can't do it by accident, the same way you can't accidentally drive into oncoming traffic just by getting into a car. On top of that, a properly set up agent stops and asks before any irreversible action. Delete, overwrite, send something outside — it asks permission for all of that. You sit there and say "yes" or "no". That, by the way, is your new job, but more on that later.

Second fear: "I don't know the commands." You don't need to. That's the whole point of this moment. The terminal used to demand that you remember dozens of spells full of dashes and letters. Now you write to it in ordinary words: look at what's in this folder and sort the files by date. The agent types the commands. You're the one who explains what you want. To this day I know maybe five commands by heart, and it doesn't hold me back at all.

Third: "you need to know how to program." You don't. You need to be able to explain clearly and to look at a result critically. Doctors, lawyers, accountants, teachers, logistics managers — all of these people have spent years training exactly what's needed here: describing a task precisely and checking whether the answer adds up. Programming as the craft of typing symbols is the first thing the machine takes over.

And one last thing about fear. A computer isn't crystal. The worst that realistically happens to a beginner is that something stops working and you need to put it back the way it was. There's a simple rule that covers ninety percent of the panic: work on a copy. Make a copy of the folder, and touch whatever you like. Broke it? Delete the copy, take a fresh one. A child modelling clay isn't afraid of anything, because clay can be squashed back into a ball. Give yourself some clay.

Now to what happens for me every day, and why I decided to talk about it at all.

In my work there are dozens of agents running all the time. Not as an experiment, but as an ordinary production process: they do what hired people used to do. And the change I saw isn't about speed. Speed is a consequence. The change is in which roles are left at all.

Any product used to need a set of people. Someone designs the interface. Someone writes the code. Someone gathers numbers and writes reports. Someone writes the copy. Someone checks that it all works together. And then there's the person who keeps in mind why all of this exists and what we're actually doing.

Out of that list, the last one is still human. And also whoever accepts the result, which is often the same person.

Design of standard things — screens, cards, forms, the loading state, what an error looks like — agents do themselves, and they do it decently. Not brilliantly. Decently, evenly, fast, and without taking offence. Analysis, meaning "bring me the numbers and work out what follows from them", goes entirely: that is exactly the kind of work a machine does better than a person, because it doesn't get tired and doesn't cut corners. Building standard features — a form, a login, a payment, an export — goes. Anything someone has already done a thousand times, the machine does faster and more carefully than the average contractor.

What doesn't go. The question "what are we even building, and for whom" doesn't go. Taste doesn't go: the ability to look at five options and say why the third one is alive and the rest are dead. Responsibility for what we released into the world doesn't go. And checking doesn't go, but that gets its own section.

I call the remaining role the product builder. The person who frames the task and accepts the work. It used to be one role on a team. Now it is effectively the only role. Everything else, the execution, gets delegated.

And here is what kept me from accepting this idea for a long time. It seems that if you remove the people doing the work, quality will drop. In practice what drops isn't quality, it's the variety of mistakes. A human contractor can do brilliant work, or bad work because they're going through a divorce, because they misunderstood, because they were too shy to ask. An agent works evenly. Always the same kind of even. Its ceiling is lower than an outstanding specialist's, but its floor is far higher than an average one's. And in most companies the work isn't done by outstanding people. It's done by average, tired and distracted ones.

One more thing that needs saying honestly. For me, most calls to the model aren't my own questions at all, but subtasks that agents hand out to each other. So the main part of the work happens without me being involved in the moment. I frame it at the start and accept it at the end. The middle runs by itself. It's a very unfamiliar feeling, a bit like a department head realising for the first time that the department keeps working while they sleep.

And one more observation that surprised me most of all. It isn't the amount of work that changed, it's its rhythm. Between "had an idea" and "see it" there used to be weeks: set the task, wait in the queue, receive it, discuss, redo. Now between "had an idea" and "looking at the live thing" there's an evening. And that changes how you think more than any saving does. When testing an idea is cheap, you stop arguing and start trying. Half the meetings in the world exist only because trying used to be expensive.

Now the most uncomfortable part of the episode. I'll say it directly and try not to gloat, because there's nothing to gloat about.

Current models already do standard work faster and better than the average worker. Not next summer. Now. Writing a standard text, putting together a standard report, laying out a standard screen, working through a spreadsheet, building a standard feature — all of this is already done better than the average person on an average salary in an average company does it.

And yet almost nowhere has anything changed. People sit in the same seats, the stand-ups are the same, the deadlines are the same.

The gap isn't in the technology. The technology has arrived. The gap is that managers haven't grasped it yet. And not because they're stupid. The reasons are very human. First, to see the difference you have to try it yourself — not in a chat, but for real, with hands — and a manager has no time for that, they have meetings. Second, they're briefed by the very people whose jobs are in question, and those people report exactly what suits them: "we looked into it, it's not good enough for serious work". Third, changing how a department works is painful and scary, while not changing it is comfortable, because the quarterly numbers still add up.

That's how you get the silence. Everyone goes to work, everything is as usual, and under the floor there's already a different economy.

What happens when managers finally get it? Not gradually. It's like any postponed decision: while nobody moves, nobody moves; and when the first noticeable player in an industry moves and shows you can do the same work with a team a third of the size, everyone else has to follow, or they get eaten on price. From then on decisions are made not over years but over quarters. Abruptly, messily, with a lot of personal pain.

I'm not saying this to scare you. I'm saying it because the silence right now is a gift, and you can use it. You have a window of time that won't exist in two years. Right now a person who can set tasks for agents and accept the results is rare. They look like a wizard. At some point this will be a basic line in a job description, the way knowing how to use email once was.

So my advice is very boring. Don't wait for your company to decide. Don't wait for a course from the training department. Start yourself, on your own task, in the evening, out of curiosity. Whoever tried it earlier will turn out, when things break, not to be the one who's cut, but the one who's handed a new department. That's not a guarantee; I don't give guarantees. But the difference in position is huge.

And separately, for those who manage people. Check it yourself. Don't ask your team whether the new thing is any good. Take a real task from your department, the most standard one, and try to get it done with an agent in one evening, personally. You'll either calm down, or learn something nobody will tell you at a stand-up. Both outcomes are useful.

A short section so the whole picture comes together. You've surely heard the news: everyone is buying up computing power, building enormous data centres, there isn't enough electricity, the queue for chips is booked years ahead. It sounds like a separate, murky story about big money. In fact it's a direct consequence of what we're talking about.

Look. Work used to be done by heads. A head runs on a sandwich and coffee, sits in an office, and no special infrastructure has to be built for it — the offices already exist. Now exactly the same work is done by machines. And a machine, to think, needs electricity and hardware, a lot of both.

So there has been a move. Work physically moved from people to processors. And demand that used to show up as job openings and salaries now shows up as kilowatts and server racks.

The analogy is simple. Picture a small town where everything was carried by horses. Lorries appear. And suddenly you see something strange: everyone is building petrol stations, laying pipes, arguing over fuel. An outsider would say: some kind of oil fever, a bubble. But it isn't about the petrol. It's about transport switching to a different source of power, and now that source needs its infrastructure. Oats aren't needed in the old quantities; petrol is.

That's exactly what's happening now, only instead of petrol it's computation. Hence the queue for hardware, hence the talk of power stations next to data centres. No mystery: work started being computed, and the computing has to happen somewhere.

There's one practical conclusion for you, and it isn't about investing — I won't give investment advice and I'm not qualified to. The conclusion is this: if people are building factories and power stations for it, it's here for a long time. Nobody runs high-voltage lines for a one-season fashion. If you're still hesitating over whether to spend an evening figuring out agents, here's your argument. Infrastructure votes with money, and it's voting for work being done this way.

Now the thing people almost never say, because it spoils the nice story. But without this section the whole episode would be a lie.

By my estimate, roughly one task in five that I hand to an agent comes back wrong or unfinished. One in five. That's a lot.

And here's the key point: you can't tell from how the result looks. The work looks finished. The report is upbeat, everything is tidy, "done, checked, it works". The model is equally confident when it's right and when it's wrong. A person gives signals of doubt — they hesitate, qualify, look away, write "I think". A machine has none of those signals. A confident tone isn't a sign of being right, it's just a way of speaking.

From this follows something you have to accept straight away: the work doesn't disappear. It moves. From doing to checking. You used to spend eight hours doing it. Now you spend an hour explaining and an hour and a half checking. That's a huge gain — but it isn't zero, and it's a different kind of tiredness. Checking someone else's work all day wears you down differently from doing your own.

The second limitation. There are tasks where explaining takes longer than doing. If you need to rename three files, rename three files. By the time you've worded exactly what and by which rule, you'd have finished. It's like asking someone to pass you a mug that's a foot away: the explanation is longer than the action. The threshold is roughly this: if doing it by hand takes you more than fifteen minutes, or you do it regularly, delegate it. If it's a one-off two-minute move, do it yourself and don't show off.

The third, and most important. There are tasks where being ninety percent right is useless. Take medicine: a dose calculated correctly nine times out of ten isn't "not bad", it's dangerous. The same goes for money, for legal deadlines, for anything where one mistake doesn't average out but blows up. In those places an agent can be a draft and an assistant, but not the final authority. The final authority is the person who carries the responsibility.

And the fourth. I'm not going to promise you'll become a programmer in a week. You won't. In a week you'll become someone who can build themselves a small working tool instead of waiting three months for somebody else to do it. That sounds far more modest and changes your life far more.

By the way, about the one in five. It isn't a verdict on the technology, it's just a parameter of the process. Every production line has a defect rate, and production doesn't stop because of it — it puts quality control in place. The only difference is that here the inspector is you, and that's a separate thing to learn.

Practice. If you've listened this far, you should come away knowing what to do concretely, not just "how interesting".

First. Install an agent that works in the terminal. Not a chat in a browser — an actual agent with hands. Create a separate empty folder for it. An empty folder is your sandbox: there's nothing to break there, because there's nothing there. That alone removes half the fear.

Second. The first task. Don't pick your biggest pain. Pick something small, useful and yours. For example: you have four hundred files in your downloads folder — ask it to sort them by year and type. Or: take a spreadsheet and ask for a one-page report with a chart. Or: ask it to write a simple calculator for something you work out regularly — an estimate, a dose, a delivery cost. The test of a good first task is this: you know exactly what the right answer looks like, and you can check it in a minute. You're not learning to solve hard things — you're learning to notice when you're being lied to.

Third. Watch what it does. Don't look away. It will write what it's about to do and ask for permission. Read those questions, even if you don't understand half the words. In three days you'll start to understand. It's like your first days in a foreign country: first noise, then separate words, then meaning.

What not to do. Don't let it near important files until you've got a feel for how it behaves. Don't hand over a task you don't understand yourself — then you can't check the result, and that's the most common trap. Don't accept "done" without checking — open it, run it, look with your own eyes. And don't start with a big dream like "build me an app like the big ones have" — you won't be able to accept that work, and you'll drown.

And separately, about pace. Don't run a weekend marathon — all it leaves you with is tiredness and the feeling it didn't work. Better an hour in the evening, but every day. It's a skill, and skills come from repetition, not heroics. After two weeks of that, you'll notice you no longer think "is this even possible" — you think "how do I phrase this". That switch in your head is the whole result of learning. Everything else is details of the tool, and they'll change, more than once.

And now the main skill that made all of this worth listening to. The ability to describe what "done" means.

It sounds trivial until you try. Tell an agent "make it look nice" and you'll get who knows what, and that will be your fault, not its. Tell it "make a page with the name at the top, a list of three items below, a button at the bottom, nothing shifting on a phone, and when the list is empty it says it's empty" — and you'll get what you asked for.

Test yourself with a simple exercise; it works even without a computer. Take a task and describe it so that it could be done by a person who can't read your mind and doesn't know the context. What goes in. What should come out. How we'll know it worked. What to do if the data is messy. If you can do that, you're already a vibe coder; the only question is the tool.

And you know what's funny? It's exactly the same skill that makes a good manager, a good doctor with a patient, and a good parent. The ability to say precisely what you mean, and to agree how we'll know the job is done. No machine will do that for you, because it isn't about the machine.

The takeaway is simple. A chat answers; an agent does. The terminal isn't a test for the chosen few, it's the staff entrance through which the agent gets its hands; it looks unfriendly simply because nobody designed it to be pretty. Machines already do standard work better than the average worker, and the only reason everything around still looks the same is that the people who make that decision haven't made it yet. One task in five will come back wrong, and you'll only know by checking. So the work hasn't disappeared, it has changed: less doing, more framing and accepting.

I didn't come here from engineering; I learned this from zero and I'm still learning. And the only thing I regret is spending several months afraid of the black window instead of opening it and trying.

Open an empty folder and give the agent its first small task. It will take an evening. After that, things will be clear.