Four days ago I started building my own development workflow. Not for work. I was studying for a GitHub certification, and I wanted something to learn with and something to build my own platform against.

The tools I tried along the way were complicated to use, and getting started meant reading a pile of Markdown files before I understood how any of it worked. That is a boring way to spend an evening you were supposed to enjoy.

They had a second problem, which bothered me more. They seemed to ignore the platform they were already running on. I wanted to lean on what GitHub gives you out of the box, so the workflow would feel like part of the platform instead of a second one bolted next to it. Platform-centric, and honestly just more enjoyable to use.

So I built my own. It is called octospec, and I want to write about what happened to my role while I built it, more than about the tool.

It is genuinely easy to build your own tools now

This is the part I did not expect.

I am not a systems programmer. I am a cloud engineer. Four days ago the repository was empty and now there is a tagged release with a checksummed installer, a Go CLI, CI that runs on every pull request, and 32 changes in its history. I did not write most of that by hand. I described what I wanted, the agents wrote it, and I decided whether it was right.

Four days. Some of that was my evening time, not all of it.

The bar for “I will just make my own” has dropped through the floor. A few years ago, wanting a workflow that fit me meant picking a tool and living with its opinions, because the alternative was months of work. Today the alternative is a few evenings and a much better fit.

That has a side effect worth naming. I now look at almost every friction point in my setup and think “I could fix that”. Some of those are worth fixing. A lot of them are not, and the tooling being easy is exactly what makes it tempting to fix them anyway. Building is cheap now. Attention is not.

Complexity is not the same thing as power

The tools I tried were not bad. They were built for teams and for scale, and they carried all the weight that comes with that. Every option had to be there because some team needed it.

What I wanted was smaller. I wanted one source of truth, which is the repository itself. I wanted to be able to change anything I disagreed with. And I wanted a human deciding at the important moments, not a pipeline that runs to completion and asks forgiveness afterwards.

So I built around what I already had. GitHub gives you issues, pull requests, reviews, labels, comments and required checks. A spec workflow needs almost exactly those things. The tool that ignores them and keeps its own files is throwing away the best part of the platform it is running on. Not every tool should be smaller, but mine could be, and that was the whole point.

The decisions nobody tells you about

Here is the part I actually want to talk about, because it is the part that changed me.

Building the thing was not the hard part. Deciding what went into the first version was the hard part.

You sit down with a long list of things you want, and you have to make that list shorter. Then you have to make it shorter again. At some point you have to look at a feature you genuinely want and write “not in this version” next to it. That hurt more than I expected.

I ended up scoping the first release to seven changes. Three of them I marked as blockers, meaning the release made no sense without them. By the time I tagged it the repository carried thirty two changes, because I was using the tool to build the tool. That is a strange feeling the first time you notice it.

And then there is the one that still stings, because it taught me something about agents rather than about my tool. I wanted to run several pieces of work at the same time, each one on its own branch, so an agent could move forward on one thing while I reviewed another. I built it, it worked, and I used it for an afternoon before I decided to delay it to a second version.

The code was not the problem. Parallelism is. When several agents work at once, the bottleneck moves to you. You are the one who has to hold the whole picture: what each one is doing, what they might collide on, and which result is ready to be looked at. It does not shrink the work, it queues it in front of you, and the queue is you. For one person on one project that is a worse deal than working on one thing at a time and finishing it.

I have never thrown away that much of my own work in one afternoon. It felt wrong for about a minute and correct immediately after. A first version that does the right five things beats one that does ten including three you regret.

The shift I did not see coming

The thing I keep thinking about is not the tool. It is what it did to my day.

A year ago my work was writing code. I was the one implementing, and the quality of my day was mostly the quality of my typing and my problem solving in the editor. The bottleneck was me, and it was a bottleneck I liked.

Now an agent does the typing. Not everything, and not unsupervised, but the mechanical part of the work. What is left for me is a different job.

I decide which requirements make it into a version and which wait. I decide when the design is wrong even though the code works. I read a change and decide whether I accept it or send it back. I am the one who has to notice that something is plausible but wrong, because plausible is what the output is designed to be.

That is not a smaller job. It is a harder one. Reviewing is harder than writing, because when you write it you know why every line is there, and when you review you have to reconstruct that from the outside. My attention is the scarce thing now, not my hands.

It also means the tooling question changed shape. What I want from a workflow is not a way to produce more. It is visibility, a way to know what is happening at each step, and a way to stop it. A feature that makes the agent go faster is worth less to me now than one that makes it easier for me to trust what it did. The reason I accept a change is not that an agent wrote it. It is that I can see where it came from, the review it went through, and the check that passed. Ownership did not go away. It moved.

I do not think this is specific to me or to what I built. Whoever picks up this kind of workflow next is going to feel the same shuffle, and the fit is going to depend less on the tool and more on the person: how you like to work, what you already know, what you want to keep doing by hand, how much noise you are willing to read. A workflow that fits one person is a bad fit for another one. That is fine as long as you know which one you are.

Where I landed

I would not go back to implementing everything by hand. Not because the agents are better than me at the work, but because the work I get to do now is the part I was always better at, and I had very little time for it before.

The uncomfortable part is that the new work is harder to be proud of. Nobody looks at a good decision the way they look at a good commit. You cannot screenshot a version scope. You just end up with a tool that is smaller than you wanted, shipped on time, and correct about the things you chose to care about.

The repository is public if you want to see how small a first version can get: Kerman-Sanjuan/octospec. Eight things are still open, and honestly most of them are waiting for me to decide they matter.