For about a year, I talked to AI every day and felt like I had little to show for it.
I wasn’t building a company or shipping products. I was asking Google’s Gemini to help me write my annual performance review. That was December 2024. I’d closed my company, moved countries, and gone back to being an employee. The orchestra was down to one instrument. AI showed up not as something strategic but as something to do with the restless energy that had nowhere else to go.
By spring it was a daily habit. Work questions at first: customer pitches, organizing thoughts about accounts, preparing for meetings. Then the questions got wider. What Mexican beers are available at Systembolaget? What should I name a YouTube channel? How do I design a logo for a homesteading brand?
My wife and I bought a domain for a gardening channel. We did the logo, picked the colors, talked about what episodes would look like. We never recorded a single video.
Around the same time, I was applying for jobs. But compared to the US, the market in Sweden is smaller, the companies are fewer, and then you have a name like McGlaun in a sea of Norbergs and Fredrikssons. I’d open LinkedIn and scroll through the same listings for weeks before anything new popped up. When something did, I’d apply and get a quick rejection or nothing at all.
The YouTube channel was one attempt at owning something. The job applications were another. AI was quietly becoming a third, though I didn’t see it yet. I’d been looking for more, and everything I tried kept landing flat.
The first real thing I learned had nothing to do with better prompts.
Every time I opened a new conversation, I had to re-explain everything. Who I was, what I was working on, what I’d already tried. The conversations were useful, but the setup was killing me. So I started writing markdown files. One for my background. One for the project. One for the people involved. The next time I started a conversation, I’d attach the files and the AI already knew who I was.
Nobody taught me that. There were no articles about “context engineering” because nobody was calling it that yet. I was just tired of repeating myself. But that was the first time I stopped just using AI and started managing it. Putting structure around how it worked for me instead of starting from scratch every single time.
The second thing I learned was harder. AI has a type of tunnel vision where it will solve whatever problem is directly in front of it and forget about everything else. If you need to get from A to Z and you ask about step A, you’ll get a beautiful answer for A while B through Z cease to exist. It has no memory of the larger picture unless you give it one.
So I started naming my conversations. One called “Project X - Strategic” that held the big picture. Another called “Project X - Tactical v1” where I did the actual work. When the tactical session would die, and it always died, sometimes mid-sentence, I’d go back to the strategic one: “v1 is dead, give me a prompt to start v2.” It would write a handoff with all the context, I’d paste it into a fresh conversation, and keep going. v1, v2, v3, sometimes v4.
The sessions died constantly. Right in the middle of working through a problem, the conversation would just stop. Context gone. Thought process gone. Decisions gone. Start over. There were days I wanted to throw my computer against the wall. But the pattern at least gave me a way to pick up where I left off, even if it was ugly.
I found out later that what I’d built with conversation labels and copy-paste is called multi-agent architecture. I didn’t know the term at the time. I was just trying to stop losing my work.
There was a lot of building things that went nowhere.
Ideas were coming faster than I could track them, so I decided to build something that I called Ideas Genie. I could drop a YouTube link into Slack, N8N gets the transcript, AI would summarize it, then store it in Airtable, and it shows up in Notion. Nice! You solve the first problem and it feels great. But when I needed to go beyond just capturing the idea, the workflow became too fragile and it fell apart.
That wasn’t working, so I tried actually developing something. Replit was the next step up, a cloud-based development environment where I could write real code. I could do more complex things there, but the codebase outgrew it faster than I expected.
I also tried putting together a McGlaun AI website in HubSpot. I knew what I wanted to do: get my name out there, start associating myself with AI even if all I had was “this is incredible and I’m trying to figure it out.” But everything I wrote came out forced. I hadn’t found my voice yet, and by the end of most days I didn’t have the energy to keep searching for it. So I put my head down and went back to where I was most comfortable: building things and breaking shit and learning.
In July I ordered a MacBook. Not because I wanted to spend the money but because every tool I’d tried had a hard ceiling. If I was going to do this for real, I needed a real machine to do it on. Unfortunately, I didn’t know how to set up a development environment or write code on a local machine. I didn’t know what an IDE was, much less how to use one. So while I waited for it to arrive, I spent every spare hour planning. Framework options. Architecture decisions. A vision document I called “Solo Developer + AI Army” that laid out how one person could manage AI like a development team.
The Mac arrived in August. I made 413 commits that month, roughly fourteen a day, every day.
I was writing real code for the first time. Or AI was writing it and I was learning to direct it. We were moving fast, and skipping things I didn’t understand, which was most of the engineering discipline. Testing. Type safety. Build processes. AI told me not to worry about it. We’ll cross that bridge later.
Later showed up around October.
Turns out if your codebase has type errors, it can’t compile. And if it can’t compile, nothing you built actually works. I asked how many errors we had. 594. All those months of building without guardrails had produced something that looked like a product but couldn’t do anything in real life.
I fixed the 594 type errors and turned on strict mode. 607 more violations. I fixed those and ran the linter: 534 more. Then I found hardcoded values scattered across 57 files with cost estimates that were wrong by a factor of twelve. The tests that existed were horseshit, passing regardless of what the code actually did, and anything with real substance had no testing at all. There was a security vulnerability where one user’s data could leak into another user’s view. Twelve major cleanup efforts over three months, each one uncovering the next. Over 120 individual work sessions just to make what I’d already built actually work.
Every AI demo I’ve ever watched seems to skip this part. You see the finished product, maybe a time-lapse of the build, and it looks like magic. And sometimes using AI does feel like magic. But there’s a stretch between “this is amazing” and “this actually works” that I’ve rarely witnessed. You can see the potential but you just don’t know how to wield it. I have fewer of those moments now, but back then, that was my every day.
I think this is where a lot of people stop because I know it’s where I came close. Not because I thought AI didn’t work, but because I couldn’t shake the feeling that I was in over my head and the hole just got deeper.
I didn’t quit. I put my big boy pants on and did it.
The individual tasks weren’t even that hard. It was the volume, and the gut punch of finishing one shit sandwich only to find another one waiting. But every cleanup taught me something I wouldn’t have learned any other way. Every round of remediation was a lesson in what happens when you skip the discipline, and every fix was me learning to put the discipline in place.
By the time I came out the other side, I understood testing. I understood type safety. I understood why you enforce code quality from the start instead of patching it later. None of that came from a tutorial or a course. All of it came from consequences.
The failure was the training.
When I was building the platform, I didn’t know what I was building. I knew the concept: take an idea from nothing to a piece of content. But I couldn’t have explained a workflow. Every session was going to the hardware store, buying just enough wood and nails to get through that day. What if it could do this? What if it could do that? We were hammering boards together one session at a time. There were no blueprints. We didn’t know how many stories the house would have. We didn’t know how many bathrooms. We didn’t even know what a bathroom was.
When I sat down months later and built a working demo in 33 hours for a panel presentation, I spent the first six hours on nothing but blueprints. Tests first. Quality gates. A methodology for breaking work into stories and executing them in sequence. We had our mise en place. Everything up front so that when we started building, it just flowed. All of it came directly from the months I spent cleaning up my own mess.
But the 33 hours proved I’d learned to build. What surprised me was that the building wasn’t even the point.
Everything I’d done was code: building a platform, fixing a platform, cleaning up the mess I’d made of a platform. But I started applying the same discipline to everything else. Preparing for customer meetings. Organizing information across dozens of accounts. Managing a workload that had tripled. The markdown files, the strategic sessions, checking AI’s work and pushing back when it was wrong: none of that required a codebase. I stopped thinking of AI as a development tool and started building it into how I worked across the board.
I’m not a developer. I never was. I’m a business person who spent a year learning to manage AI by building something too ambitious and cleaning up the wreckage. What came out of it wasn’t a software skill. It was knowing how to take on more than any one person can handle and actually make sense of it. How to verify what AI tells you. How to push back when it’s wrong. Because it will be wrong, and the moment you put something forward that isn’t true, you’re toast.
Then in March, my wife mentioned that her company had been trying to get a blog up for two years. I had some time that afternoon so I put something together. Three hours later she was looking at a working proof of concept. The owner booked a meeting before the day was over. I quoted a fair price. She replied in three minutes. Within two weeks I had a registered consulting practice.
There were a lot of times I just kept going because I didn’t feel like I had any alternative.
I thought I was learning a tool. And I was. But somewhere in all those failed projects and abandoned workflows and late nights staring at errors I’d created, I got back something I thought I’d lost. The ability to have an idea and actually build it. To walk into a room and show someone the path from where they are to where they could be. That had been dormant since I closed the company, and I didn’t realize how much I missed it until it came back.
And it only cost five thousand commits, several dead projects, numerous conversations that died mid-sentence, and a YouTube channel that never happened.
I’ve been saying “you don’t learn from your wins” for years. It’s easy to say when things are going well. When you’re living in a nice house and the business is growing and life is good, it rolls right off the tongue. When you’re staring at 594 errors after months of work, or watching another session die mid-sentence, or wondering if you’re just a guy talking to a computer every night for no reason, it doesn’t feel like learning. It feels like you’re a fucking idiot.
But that’s what learning actually looks like when you’re in it. And if you stick with it long enough, you might find something you weren’t even looking for.
Get notified when I publish.
What worked, what didn't, what I'd do differently. Delivered to your inbox.