Every quote in this chapter is something I wrote myself, in Spanish. They’re translated here with the typos left in: the typos are half the evidence.
On 28 June 2025, at 22:28, I wrote this:
Now generate a guide so I can explain the artifact, make it very simple so I can explain to a technical person what I’m proposing without them realising I don’t understand the document
I had a client, a technical proposal on the table and a meeting coming up with someone who actually knew about this. So I asked for help faking it.
Nine months later I delivered the project, running on that client’s server. Almost everything I know how to do today sits between those two things.
The job
I didn’t go looking for it. A friend who runs a communications agency passed it to me: they’d won it and had nobody to put on it, because they had no specialist. I said yes before knowing whether I could do it, which is the only reason this chapter exists.
A public body in the Canary Islands wanted an assistant that could answer questions about their own website: calls for applications, job openings, who does what. It sounds small and it isn’t. For a bot to answer well you have to read it the whole site and store it in a shape it can search. And then the hard part: getting it not to make up what it can’t find.
I had never done any of that. I didn’t know how to log into a server or what a container was, and I had no way of telling whether the plan I was proposing would stand up. On 10 July I wrote it out in plain words:
Do you think this is a viable plan given that I have no experience with system environments or with Llama
The right answer to that question was no, and I went ahead anyway.
Switching tools every month isn’t failing, it’s the syllabus
In four months my archive runs through an entire catalogue. I started in May with n8n, which chains flows together, and in July I moved to Flowise, which actually built chatbots. At the end of August I tried Botpress, by September I was wiring up a web crawler myself — Cheerio first, Crawlee after — and in February I ended up putting the whole thing into containers with Docker.
From the outside it looks like a man who can’t make up his mind, and partly I was. But every switch came from hitting a specific ceiling: this one doesn’t read PDFs, this one breaks on update, this one needs a bigger machine than the one I’ve got. You don’t learn that from reading comparison articles. You learn it when you crash into it on a Tuesday at eleven at night with a deadline on top of you.
That was the syllabus, and there was no other way to teach it.
4 August, nine in the evening
That day I wrote the most important question of the whole year, and I didn’t notice:
How do I use Claude Code?
I’d been generating flows that then didn’t work when I pasted them, so I asked the obvious thing: whether the usual version wasn’t enough. It was enough for talking. Not for somebody to look at my files, change them and check whether the thing started up.
Everything I’ve built since comes out of that one-line question.
“It works!!! Never propose changes again”
On 5 August, at 23:12, after hours fighting with an n8n install on a server, I wrote this:
It works!!! Never again propose changes that could affect the integrity of the project. Never again!!
Two weeks later it wasn’t anger any more, it was a house rule:
remember our maxim of making sure we won’t affect other services that are already working
And from then on, before every change, the same question: can this touch something that already works?
I’d written that sentence before. It was at a terminal in Las Palmas, after a spreadsheet of mine miscalculated a blend and it had to be fixed in the tank. The lesson back then was that the tool amplifies the mistake exactly as much as it amplifies the good call. Which is why you put a human brake in front of anything that can’t be undone.
Fifteen years later I was explaining it to a machine, at eleven at night, shouting. Same lesson as always. The only thing that’s changed is whose hands are on it.
The day I stopped taking its word for it
On the morning of 25 August, going over a deployment, I decided to check a path I’d just accepted as true, and it turned out the path was wrong and so was the port.
flowise runs on port 3000!!!
Five exclamation marks, which I’m counting because they mark a before and an after.
Until that day I copied whatever it told me and pasted it into the console. From that day I check first. Not because the machine lies — it doesn’t — but because it states what it knows and what it’s imagining with exactly the same confidence. From outside, the two look identical.
That, to me, is the first requirement of working this way. It isn’t writing better instructions: it’s not believing the answer until you’ve watched it work.
The first demo lasted one question
When I finally had something presentable I showed it to the client, and straight away somebody in the room jailbroke it: turned it round and got it drunk on me.
I tell this because at the time it was a bad afternoon and today it’s one of the things I’m most grateful for. I came from twenty years of spreadsheets, where the worst possible user is somebody in a hurry. Here the worst possible user is somebody curious with five minutes to spare, and they’re sitting inside your own client. That isn’t in any guide: you learn it when they knock your demo over.
I hardened it, kept testing, and that’s where the long part started.
The night of the three hundred and ninety messages
On 28 August I tried the demo on my own, just in case, and on the first question it answered nonsense.
That conversation has 390 messages and nearly twelve thousand words of mine, and it started at half past nine at night. The bot was finding the documents but answering as if it hadn’t read them. So we worked backwards: the answer, the search, the database, what had been stored when the site was crawled, and what the site actually said.
I fixed nothing that night, but I learned how to look, which is different and worth more in the long run.
Nobody learns to trace a fault in a system by reading about how faults are traced: you learn it on a night when the thing doesn’t work and you can’t go to bed.
It took me weeks to be able to say the fault in one sentence, and when I could, it was embarrassingly simple: I was asking the machine to find a needle in a haystack. I’d hauled in the entire website raw, without ordering it or labelling what each thing was, and then I asked it to find one specific fact in there. To the question “who runs this place?” — the easiest fact in the house, sitting on their own page — the bot couldn’t answer.
That was my most expensive lesson on the project, and it goes against what gets said out there. The clever part doesn’t fix a disorganised warehouse. Before you ask it for anything you have to decide what gets stored, how it’s cut up and what label each piece carries. The model doesn’t do that: you do, and if you do it badly, no instruction will save it.
What stayed with me from my own trade
On 2 September I opened the working session like this:
Continuing implementation […] Bot - Day 2. Run context recovery: ./context-recovery.sh
I’d written myself a script that, at the start of the day, told the machine where we’d left off. What was installed, what had failed and what the last command was. I did it out of laziness: every morning I lost half an hour explaining the same thing.
It took me months to realise what it actually was. It’s the shift handover.
Years earlier I spent whole nights building a table so that what one shift knew reached the next one intact, without depending on somebody remembering to mention it. I was doing exactly the same thing, in a folder, for a machine that forgets everything when you close the window.
What I now call memory, context or handover between sessions I didn’t learn on any course. I learned it at a fuel terminal, and here I only recognised it.
The working relationship
It wasn’t idyllic either, and there’s no point telling it as if it had been. On 18 September, after a whole afternoon going round the same bug, I wrote to it that this wasn’t working and that I expected more from it. The next day, with the thing sorted:
Finally, you’re wonderful almost always but you make mistakes that drive me up the wall. Let’s continue
Read today they make me laugh and they’re useful. I talk to a machine the way I’d talk to someone on my team: I tell it what’s expected of it, I point at the mistake, and I move on. I don’t apologise for that. It’s the only way I know of working well with anyone, body or no body.
The name came last
On 14 October 2025, five months after starting, I wrote for the first time the name of what I’d been doing for half a year:
define how to implement this logic in the project through the use of vide coding
Typo included — and that same night I asked whether the whole project could have been done that way from the start.
I like that it happened in that order. First nine months of servers, of mistakes, of late nights and of an actual delivery. Then the word for it.
Throw it all out and start again
By then the models had taken a leap and for the first time you really could build this way: not ask for a chunk of code and paste it, but work with someone who opens your files and changes them. I looked at what I had — an n8n flow, boxes and arrows patched all over — and decided to bin it and do it again from scratch, this time writing the whole project with Claude Code.
That’s when it came out complete. And I still didn’t like it.
The bot worked but it was stiff, robotic, without any of the ease these machines have when you talk to them. Since I hadn’t managed to organise the information properly, I compensated with rules: a script that looked at the question, decided whether it was about something that changes every day or something fixed, and sent it down one path or the other. It works, it ships, and it fools nobody who knows how to look: every rule you add to paper over a design hole gets paid for later.
I delivered it like that, for better or worse. I said it was ready and that we could try it whenever they liked.
Delivered isn’t the same as live
And nothing happened. Not a week, not two: months.
That wait is a part of the trade that appears nowhere. You finish, you tell them, and on the other side there are people with their own work, their own priorities and their own calendar, for whom your project is item fourteen on the agenda. It isn’t contempt. It’s that delivering and going live are two different things, and the second one isn’t up to you.
When they finally said “let’s put it live”, everything had changed: the technology and me. So I did it again. And this time yes. This time I knew what to store, how to cut it up and what label to put on each piece; I knew how to tell what changes daily from what doesn’t; and the result looked nothing like the previous one.
Then came the part nobody talks about and which is also the work: a dossier, the final documentation, a meeting, moving the project to their servers, and another meeting with the people who run their website to authorise the door the bot was going to come in through. All of that, which nobody sees, is half of a delivered project.
One thing was left outstanding, a security certificate only they could issue, and there it stalled again for a few more months.
The day my own system audited my first project
A week ago they wrote to me again, and this time I didn’t open the project myself: I asked my own system to audit it.
It’s the scene that closes this chapter better than I could write it. The project I started without knowing how to log into a server was reviewed, line by line, by something I built myself with what I learned doing it. It found things, and the biggest one was mine: a whole OpenClaw instance sitting inside the project, 3.6 GB of container. The three ugliest failures in the audit came out of it, and all it did was carry the message between the bot and the model: no tools, no memory of its own, no agent character. Cracking a nut with a sledgehammer. We took it out and wrote that same errand in a hundred and fifty lines inside the program itself, with the bot’s character in a file you can read in one sitting. Two afternoons.
It’s finished and ready to hand over. A year and a bit after starting it.
What I learned
That vibe coding isn’t the machine writing the code for you. It’s knowing what to ask it, what not to believe and how to stop it getting lost between one session and the next. The first is judgement, the second is distrust and the third is method. The machine supplies none of the three.
That the only school that has ever worked for me has a deadline and somebody waiting at the other end. In the previous chapter I set up eight ideas in eight weeks and finished none of them. Here I finished one, because I couldn’t not finish it.
That twenty years clearing monkeywork out of the way were worth more than I thought. I knew what a shift handover is, why you stop before touching what already works, and how to document so somebody else can carry on. What I didn’t know was the technical part, and that turned out to be exactly the part you can delegate.
And that that small job for a Canarian public body ended up being the floor under everything that came after. When months later I sat down to build a system that builds systems, I wasn’t starting from zero. I was starting from nine months of crashing into permissions, wrong paths and a bot that answered nonsense to the first question.
And that what I took away from here was in no budget, literally: I still haven’t been paid a euro for this project, for the reasons I tell in the previous chapter. A year and a half, three versions, two complete rebuilds and nothing invoiced. Looked at with a calculator, it’s the worst job of my life. Looked at through what I can do today, it’s the best school I’ve ever been to. And both are true at the same time.