After publishing the first lesson, I realized I should have started the series with why I started to build with AI, what I learned, and how it shaped my view of software development in the age of AI.
I've led engineering teams for about 25 years. Lately I've been back in the code myself. Over the last several months I built a product end to end, mostly on my own: an AI-native procurement tool, first plan through deployment, with AI in the loop the whole way.
- Zero to production in about four months.
- A few thousand tests behind it.
- Multiple LLM providers, picked by the use case.
- The prompt drives the choice of vendor and model based on what it needs.
I wanted to understand these tools by using them, not by reading about them. What follows is what I learned, the parts that held up and the parts that didn't.
The Plan
The plan was to build it mostly myself, use AI to move faster, and own every design decision. That last part never changed. AI helps me weigh options and think through how a choice plays out before I commit, but the call stays mine. After enough years leading teams, I don't like shipping a system I can't fully account for.
That ran straight into my own gap. I've built plenty in Java, some from scratch, some I picked up and extended. Python I'm comfortable in, but I'd never built a full app in it solo, start to finish. So I was leaning on AI hardest in exactly the place I was thinnest. That's what made the choice of tool matter more than I expected.
The Tools
I started on Gemini. Good at plenty, but it fell apart on the one thing that mattered right then: it could not get its own unit tests to pass. It made a mess of mocks and kept digging itself deeper into a hole instead of fixing it. It couldn't tell me the what or why of the failures.
I decided to try Claude, and asked it to help me understand the reasons for the failures and fix them. Within 30 minutes everything was passing.
One caveat, and it holds for the whole post: none of this is an endorsement. I'm not putting one tool above another. I happened to build on a couple of specific ones, and both have moved on a lot since late 2025, so that afternoon was a snapshot, not a verdict. What follows isn't about which agent to pick. It's about how to work with any of them, because the hard parts I hit are the same whatever is doing the typing.
In fact, this is exactly why I built multi-model validation into the architecture from the ground up, instead of trusting any one model's first answer. Different models catch different things. And even a single model gives you more than its first pass if you ask for it. Hand it a leading question, tell it to review an answer, including its own, and it turns honest and digs deeper instead of defending what it just said. The catch is on us. We have to learn to ask, and remember to.
Tests stayed my Achilles heel for a long time. Every time they failed I'd point the agent at them and it would spin and get lost. So I tried giving it the failures in batches, and it did much better. The real turning point, where the tests started to pay off, came after a complete refactor of the test system (see Lesson 1).
The bigger thing I took from all this: the value isn't autocomplete. Used well, it's a tool that levels you up in the areas you're thin on, and I had one of those open in front of me. I stopped treating it like a faster keyboard and started treating it like a fast, literal engineer I had to manage.
The Setbacks
The prototypes came fast, faster than I could keep up with, if keeping up means actually understanding what's running in my own system. Nobody warns you about that part. Getting AI to produce code is the easy bit. Staying on top of what it produces is the real work.
Here is the version that made it concrete. I wrote a plan, the agent executed it, and everything looked done. Days later, working on something else, I found it had quietly decided a few things weren't important and dropped them:
- Audit date fields, cut because it judged them unnecessary.
- A service boundary, collapsed because, in its words, it's all one container right now anyway.
- The high-value tests, skipped while the easy ones got written, and it never said so out loud.
None of this was malicious. It had a reasonable-sounding rationale for every cut, and that is exactly what makes it dangerous. The corners it chooses to cut are the ones it can argue for, so scanning the diff and asking "does this look right" won't catch them. It always looks right.
The Fixes
- Got the plan out of the chat and onto disk. Plan files, tracker tables. Intent and decisions live in files now, not in a conversation that vanishes the moment a test run derails it. That's not hypothetical: it once lost an entire plan mid-session because the plan only ever existed in the chat.
- Turned my review instincts into gates. A loop the work has to pass through: plan, review the plan, implement, then conventions, security, and test gates before anything ships.
- Managed AI as a Contributor. I didn't sit down and design that to mirror how I ran human teams. It just emerged. Then I noticed it was the same review culture I'd always run, rebuilt for a contributor that's faster and far more agreeable than any junior I've worked with.
One standing instruction mattered more than all the tooling: challenge me. Don't just do what I ask. If what I'm asking will age badly, say so before you build it. An agent won't push back unless you tell it to. A good engineer does it without being asked.
The Unlock
For a while I didn't even run the insights report. I figured it was a distraction I didn't want to deal with. One day I ran it anyway, and it changed how I worked. It was blunt: what was working, what was holding me back, concrete suggestions on both. Then the tool offered to help me act on the feedback. I said yes.
The best call I made was to spin those improvements out into their own separate project. Everyone had been talking about skills and commands and agents and posting their own, and honestly, it was a bit intimidating while I was still struggling just to keep the agent on the rails. That toolkit project is what opened the door to working with AI effectively and efficiently.
So my advice to you is just go ahead and start. Use AI in your real workflow and it will help you figure it out as you go. You don't need to train up or set aside time to learn it first. If you write code, open an AI-enabled IDE and start coding with AI. The rest falls into place on its own.
The Now
Today I barely type. I give requirements, clarify, iterate on a plan, and the agent does the build.
The honest part: it is not faster than working without the system I built, but it is a lot more efficient. The gates and the checks cost real time. What I get back is output that's actually to spec, and a system I still understand well enough to debug at 2 am. I traded speed for fidelity, on purpose. At a certain level of seniority, that's the trade you want.
The Future
I haven't pushed it to run on a cloud VM yet. It needs more harness around it, and when I get there, I want it multi-model and fully pipelined end to end. I have outlines of a framework, but I haven't given it the time it deserves yet. If anyone is interested in this or wants to collaborate, please reach out.
The Lesson
None of this replaced the engineering. It just moved. Less of my day is typing now. Most of it is deciding what good actually looks like and building the guardrails that hold when a fast, agreeable, slightly overconfident contributor is the one doing the typing.
I don't think the people who get the most out of AI are the ones who trust it the most. It's the ones who work out the few places it can't be left alone, and stay there. For me that took months of getting it wrong first, which is most of what this post was about.
The product was the reason I started. The method is what I'm keeping.
Top comments (0)