This is my first post on this site, and my third or fourth attempt at building a meaningful blog. It is also the start of something I have been circling for a while.

I want to operate a fleet of increasingly autonomous bots that can help me build and maintain passion projects, handle repetitive work, research ideas, create and test prototypes, monitor systems, organise knowledge, and coordinate development tasks. The point is not novelty for its own sake. The point is to free more of my time for creative and strategic thinking.

I am not claiming I have solved autonomous software development. I have not. This is an experiment and a journey: part systems work, part workflow design, part stubborn curiosity about how much of the boring machinery around building things can be handed to agents without handing over judgment.

From writing every line to directing the work

The biggest benefit of AI, for me, is not faster code generation. Speed is nice. What changed more is where my attention goes.

I spend less time trapped in repetitive bug fixing. I get more room to think about passion projects instead of grinding through the same mechanical problems. I can explore several ideas at once, spin up prototypes without committing weeks to each one, and keep multiple projects moving without pretending I have cloned myself.

When I say I work across multiple projects at the same time, I do not mean literal simultaneity. I mean something closer to a small team: I assign bounded tasks to different AI agents, review what comes back, reject weak solutions, accept decent ones, and decide what should happen next. My role shifts from implementing every detail by hand toward designing systems and coordinating execution.

There is a real satisfaction in that loop. Assign the work. Check progress. Read the diff. Push back. Redirect. Move on. It feels less like solitary coding and more like running a miniature development team where I am still the project manager, architect, and final reviewer.

I still need technical knowledge. Judgment, architecture, verification, testing, and ownership do not disappear because a model wrote the first draft. If anything, those skills matter more. AI can produce a convincing answer that is subtly wrong, and the cost of trusting it blindly is still paid by the human who ships it.

Editors, subscriptions, and refusing to marry one tool

My workflow is deliberately messy in one respect: I do not rely on a single editor or a single AI product. Depending on the project, I move between VS Code, Codex, and Cursor, plus the CLI, an Android emulator, and Flutter when the work needs them. Lately I have even been using Neovim and Emacs. Spending time in those editors changes your perspective on tools. You stop treating one IDE as the centre of the universe and start noticing what actually helps you think, navigate, and ship. Each option has strengths. Each has days when it feels brilliant and days when it feels oddly stubborn.

Pricing shapes that choice more than marketing does. I would rather combine several cheaper subscriptions and use each tool where it performs best than pay for the most expensive plan from one provider, whether that is Cursor Max or anything else. Annual AI subscriptions are a hard no for me. This industry moves too quickly. A tool that looks unbeatable today can feel ordinary in a few months, and I do not want a long contract reminding me of last year’s favourite.

This is not a manifesto against any company. It is a practical preference: keep options open, pay for what I actually use, and treat tooling as temporary infrastructure rather than identity.

Part of making this workable was rebuilding my machine around NixOS. That story is in Why NixOS. This post is about what I am trying to build on top of it.

The uncomfortable side

I am not going to pretend this is all upside.

AI depends on data centres that consume large amounts of electricity and water. In parts of the United States, communities are increasingly worried about what that means for local utilities, resources, and bills. See, for example, reporting from Consumer Reports, the World Resources Institute, and Route Fifty. I do not live there, so I am not writing from inside that pressure. That does not make the concern imaginary. If the tools I find useful are part of a broader infrastructure boom with real local costs, pretending otherwise would be dishonest.

There are product incentives I dislike too. Some companies seem determined to make their tools habitual, even sticky, in ways that go beyond usefulness. Cheap access at the beginning can become expensive dependence later. Privacy, vendor lock-in, hallucinations, unreliable generated code, and overdependence are all live issues, not theoretical ones.

I use these tools anyway. I also refuse to treat enthusiasm as an excuse for ignoring the trade-offs. The honest position, for me, is somewhere between fearmongering and blind optimism: useful, powerful, incomplete, and worth watching carefully.

Stick around

I am writing this partly to mark the beginning, and partly so I have a place to document the experiments, the failures, the tooling choices, and whatever I learn while trying to build my own small digital workforce.

If that sounds interesting, follow along. I will be writing about AI agents, automation, development workflows, NixOS, and the messy middle between ambition and something that actually works.

This is hello, automation. Come along for the ride.