In my 20+ year career in tech, only once have I accepted a position as a manager. And while we eventually parted ways for reasons that are outside the scope of this article, the experience of being a manager was actually quite satisfying, to my surprise.

Sure, I wasn’t close to the code anymore but I still understood the architecture and was able to make informed decisions about it when my reportees hit an impasse. From time to time I did get to write some code that was not in the critical path, which tested my second-hand knowledge of the system.

Delegating the development to my team freed me from having to understand every little detail of the system. It allowed me to exercise a skill that I did have but was always clouded by knowing too much on the technical side: talking about and advocating for my system to other directors from a product perspective.

It was an experience that I said I would gladly repeat in a different company, but now with AI coding tools, I kinda get a version of that experience. And I’m pretty happy with it too.

Obsessing over details

My journey with AI coding tools started around January of 2026, after reading a couple of articles about what it really means to use AI for coding. I accepted, after reading them, that I should at least try to create something using Claude Code in order to answer the question that I thought mattered: “can AI code as well as or better than I can?”.

As a result, it took me a good 4 months to launch my first product, trackm.net, because I was paranoid about getting every detail right: that the code was structured exactly like I would have structured it if coding by hand and that the test coverage was perfect at every level possible.

This is the stage that now, in retrospect, I call my “micro-managing” phase. I double-checked every commit, looked at every line of code, was excited when I found bad code and would correct it by hand then tell the AI to store as a memory what “the correct way to do it” was.

It was exhausting.

If I had written everything by hand, maybe I could have gotten it developed in a year or so. But more likely, I would have just dropped it because much of any project is the stuff you need to build that are not core to it. Sign-up, data encryption, backup and restore service/tools, payment processing. All that is not really the core of the project (ok, encryption was because this deals with money data) but had to be done correctly.

Launching trackm was a key point in this journey because it showed me that I could actually create a full product, end-to-end, by myself. The UI looks as good as a backend engineer can make it look and it dawned on me that if I had a designer and a PM working with me, it could have come out even better.

Scaling things up

Around March of 2026 AI use started picking up at my work. Up until that point I was writing all of my Go code by hand. But then we got access to AI coding tools to experiment with them and see where it would take us.

During trackm development, I experimented with letting go a bit of the details of the code in the frontend because, well, I’m a backend engineer that prefers not to deal with JavaScript. So I would describe what I needed to be done, let the AI write it and then look at the result. I would still look at the code but not being an experienced JavaScript coder, I could only pick up so much about what could be wrong.

So instead, I resorted to describing what was wrong, asking the AI to create an end-to-end test for it, then fixing it. This sometimes took a few iterations (one particular alignment bug took 8 commits because it kept breaking alignment in different places), but in general everything got solved quickly, with tests to back them up.

End-to-end testing has been the biggest change for me: I rarely wrote them before because it required so much setup and so much work to keep them up to date. Now I just have a rule that every feature added requires an end-to-end test and that it should be run on every commit.

I brought that flow to work, where the system was much bigger and every change needed a reviewed design doc. Over time I shifted toward less coding and more design documents, using the AI to probe the possible solutions to the problems at hand, creating PoCs to isolate parts of the design and then ending up with a cohesive (if overly verbose) document that I could then split into phases to work on.

Each phase required end-to-end testing, benchmarking, and load testing to validate the design assumptions. If an assumption was broken, the design was updated, an end-to-end test was created / updated / deleted and we would move on.

To some extent there was still a lot of micro-managing, but now it was at the design level. What I mean by that is that now I was obsessing about the document format, which details go in, which details go out. Would I write it exactly like that? This wording seems artificial, etc.

But I had already let go of the code. I concentrated on getting the design right and updating it whenever the code proved it wrong.

Becoming the tech lead manager

In my spare time, I played with an 8-bit computer called the Agon Light 2, for which I had developed a text editor, AED, in C. I’ve written about both before and I’m really fascinated by this computer because at 18MHz it can still get a lot of things done! I wanted to have all the tools needed on it to be able to use the machine as a development computer and write programs for the Agon.

But, as usually happens, I stopped developing for it because it required time and dedication that I didn’t have anymore. So it stayed dormant for about 2 years, until I realized I could use Claude to resume the development.

After getting Claude to write a design doc for the editor, I started adding features to it. Features that I had already planned but never had the time to do. And unlike at work, I was no longer reviewing design docs or the code at all. I conversed with the AI to describe the feature, get the details right, ask it to record them in a doc and then just let it rip through the C code.

Once the feature was “done”, I would test it, find bugs, describe them back to Claude, it would add tests to reproduce the bug, fix it and then report back. At some point I also added Kodus to do code reviews of the PR using a different AI model so that they could counter each other until the PR was approved.

With this flow and Kodus in place, I was no longer looking at the code. Like, at all. The only exception: when I saw that the C code it wrote was full of single-letter variables and function parameters and deeply nested ifs, I added some style rules to avoid that. But otherwise, Claude went its merry way to write the code as it pleased.

And now AED is a fully functional editor, optimized for the peculiar architecture of the Agon, with syntax highlighting for C, BASIC and Assembly, copy-cut-paste, and undo/redo.

What can I do when I let go?

I got so excited by this that I decided to create a new assembler for the Agon called zap. I had actually started it around the same time I was working on AED, because the assembler available at the time was fairly slow due to its 2-pass design. So I set out to write a single-pass assembler, aligned with my goal to make the Agon a viable development machine.

As with AED, it stalled, and I only picked it back up after reviving AED.

Zap is out and it’s fast. After I talked with the author of the ez80asm assembler, he switched his assembler to single-pass too, and I contributed optimizations that I discovered and recorded in an advanced C optimizations guide for the eZ80 CPU used by the Agon.

With zap done, I now wanted a C99-compliant C compiler that could run on the Agon too. Today you develop in C using AgonDev which requires a PC or Mac. But being able to write C and compile on the machine itself would make the machine so much more useful, and so now that is what I’m doing. And that is how acc was born.

In all of these Agon projects, I barely look at the code; I just discuss in detail what needs to be accomplished and the end-to-end tests to develop. For zap it was easy: the output had to be byte-for-byte identical to ez80asm’s. For acc, I’m using the torture tests from GCC and other compiler projects to ensure the code is compliant.

Fundamentally, I’m now limited by what I want to do and how many tokens I can use from my AI subscription. I can actually build useful programs that others can use, even though I haven’t written any of the code!

I’m still a software engineer in the loop. I still need to drive the design, define the features and the end-to-end tests to validate them, and make technical decisions that the robot really can’t make (single pass design for zap, linker format for acc and interop with agondev are a couple of decisions I made). But now I don’t care that much about how it writes the code or even the documents it writes as long as I can understand the high-level picture.

I can just delegate to my AI agents to do the actual implementation. Just like a tech lead manager would do with their software engineering team.