I had built the foundations for something that could scale. I had put in the hard work. And still, something was not right.
I was finding little bugs. Agents that worked one day and not the next. Nothing major — no single thing on fire — just bits and pieces, here and there, that were not behaving. A constant low hum of things being slightly off.
It took me a while to admit what that hum actually was.
Where night school stopped
All the research, all the studying I had done — the night school I have written about before — had taught me the foundation. What the pieces were. What the words meant. How the thing was meant to fit together.
What it had not taught me was the basics of how to actually lay that foundation. The craft underneath the concepts. I knew what good looked like. I did not yet know how to build it properly.
So I did the thing that, a year ago, my ego would never have allowed.
I asked for help.
Showing someone the magic behind the scenes
I called in some AI experts and a software engineer to review my codebase.
I was nervous. It is a strange, exposing thing, showing someone your code — the magic behind the scenes — especially when they understand far more than you do. You are not just handing over a file. You are handing over every shortcut you took and every thing you did not know you did wrong.
The verdict was unanimous:
"What you have is impressive. You have laid good foundations. But you have skipped the basic fundamentals of being a software engineer. You have transitioned from vibe coding to building a product that could truly scale — but you have not learned the difference between the two."
(Vibe coding is when you build by feel. You describe what you want, the AI produces something, it works, you move on. It is brilliant for getting started. It is not the same as engineering something that has to hold up under weight — and I had crossed from one to the other without noticing.)
The fourteen-thousand-line file
Then they showed me a single, very concrete example.
I had one file with over fourteen thousand lines of code in it. And every single time I asked Claude to make a change, it had to read all fourteen thousand lines first.
No wonder the system was breaking. No wonder the agents worked sometimes and failed other times. No wonder I felt stuck in a permanent loop of tiny bug fixes that never quite ended.
(Imagine asking someone to fix one sentence in a book, but first making them re-read the entire book, cover to cover, every time. They will be slower, they will get tired, and eventually they will make mistakes. That was what I was doing to Claude on every request.)
It was not that I had done something dramatically wrong. It was that I had never learned the boring, fundamental habits that stop a system tying itself in knots as it grows.
The network I had been treating as a hard drive
There was a second thing I had been getting wrong, quieter than the first.
My code lived on GitHub. I had read about it, I had an account, I dutifully stored my work there. But to me it was a backup drive — a safe place to put files. I had completely missed the actual point of it.
(GitHub is where much of the world's software is built out in the open. Yes, it stores your code. But it is also a vast network where people publish the things they have already worked out — tools, structures, entire ways of working — for anyone to pick up and use. The storage is the least interesting part.)
One of the experts pointed me to exactly that kind of thing. A framework called DGS — Deliver Great Systems — that you plug into Claude. Instead of me inventing a fresh approach every session, it handed me a structure to follow: how to organise the work, how to make changes safely, how to stop a system collapsing into a single fourteen-thousand-line mess in the first place.
It was a game changer. Not because it was flashy — it was the software-engineering equivalent of tidying your workshop so you can find your tools — but because someone who genuinely knew what they were doing had already worked the structure out, and had put it somewhere I could simply take it.
That was the lesson inside the lesson. I had spent months trying to invent good practice from scratch, alone, at night. A lot of it already existed. I had just never understood that the network was for that — not only for safekeeping.
It did not fix everything overnight. The work stayed hard, and plenty of bugs were still ahead of me. But for the first time I was building on a structure someone had thought through, instead of one I was improvising as I went.
The lesson
Here is what I got wrong, and it is a trap I think a lot of us building with AI are walking straight into.
AI is so good now that it lets you build things far beyond your actual skill level. That is genuinely amazing — and it is exactly where the danger hides. You can lay a foundation you do not really know how to lay, on top of fundamentals you never learned, and it will work just well enough to fool you. Right up until it does not.
Foundations are not the same as fundamentals. One is knowing what to build. The other is knowing how to build it so it survives.
Asking for help was not the moment I failed. It was the moment I stopped pretending I had not already been failing quietly for months!