DEV Community: autonomousAJ

The best thing I can leave my kids is the ability to build

autonomousAJ — Fri, 02 Oct 2026 15:40:55 +0000

By Andrew Pyle

I have three kids — twin boys and their little sister — and they are at the age where they point at everything and ask how it works, and are rarely satisfied with the answer. Every plane overhead, every sign, every machine that beeps. They assume the world is legible, that behind each thing is a reason you could know if someone would just tell you. I don't want to be the parent who eventually trains that assumption out of them.

Because here's the thing I actually believe about their future, and it changes what I think I owe them: the specific skills I could teach them have a shorter shelf life than any generation before. So the inheritance I care about isn't a set of answers. It's the disposition to go find out, and the tools to build what you find you need.

01Shrinking half-life

The half-life of a skill keeps dropping

When I was starting out, a hard-won technical skill could carry you for a decade or more. You learned a trade, a stack, a way of doing things, and that investment paid out for a long time. That deal is quietly expiring. The specific how of almost everything is being automated, abstracted, or made obsolete faster than you can master it. If I raised my kids to bet their futures on being the best in the room at some particular technique, I'd be training them for a race whose finish line keeps moving.

So the question I keep turning over is: what actually compounds? What's the thing that's worth more in twenty years, not less? And the honest answer I keep landing on is not a skill at all. It's a disposition — the reflex to treat a problem as something you can take apart and rebuild, plus enough range across tools that you're never fully dependent on any one of them staying relevant.

Don't optimize your kids for the skill that pays today. Optimize them for the ability to acquire the next skill faster than the last one decays.

I learned it sideways, and that's the whole argument

I'm not making this case from the outside. I spent years carrying a sample bag as a medical-device rep, and I taught myself to build software sideways — not in any order a curriculum would design, but one problem at a time, because a spreadsheet had quietly outgrown being a spreadsheet. Nobody credentialed me into it. The skill I earn my living with today is not the one I started with, and it won't be the one I finish with either. That isn't a cautionary tale about a rocky path. It's the argument itself: I crossed that gap once, slowly, in a world with worse bridges than the one my kids will inherit.

What actually carried across wasn't any particular language or framework — those turned over two or three times while I wasn't looking. What carried across was the willingness to be a beginner on purpose, repeatedly, without it feeling like an emergency. That's the muscle I want them to build early. A kid who has done it even once — picked up something genuinely hard, been visibly bad at it, and stayed anyway — knows in their body that the distance between not-knowing and knowing is a distance you can walk. Everything downstream of that conviction is just reps.

Finished things make consumers; unfinished ones make builders

There's a temptation, especially once you can afford it, to hand your kids the polished version of everything — the finished app, the sealed device, the experience engineered so nothing can go wrong and nothing can be taken apart. It's frictionless, and frictionless is exactly the problem. A thing you can't open is a thing that teaches you it's not yours to understand. Enough of those and you've quietly raised a very comfortable consumer who assumes the interesting parts of the world are somebody else's job.

The alternative isn't to deny them anything nice. It's to make sure a real fraction of what's around them is openable — breakable, fixable, modifiable, theirs to mess with. I'd rather they grow up with a few things they built badly than a lot of things they only ever used. The badly-built thing carries a lesson the polished one can't: that the line between user and maker is not a wall, it's a door, and the door opens from their side.

What the tools make cheap now

The reason this feels urgent rather than nostalgic is that the tools have crossed a threshold. Building something real used to require a long apprenticeship before you could make anything worth keeping — years between the wish and the working thing. That gap is collapsing. A motivated person with today's tools can go from idea to a working version faster than at any point in history, and the trajectory is still steepening. My kids are going to grow up on the far side of that collapse, where the binding constraint on making something is no longer skill but nerve and taste.

Which means the highest-leverage things I can give them are the two things the tools can't: the nerve to start something they don't yet know how to finish, and the taste to tell the difference between a thing worth building and a thing that just can be. Nerve and taste don't come from a course. They come from watching someone they trust do it in front of them, badly and then better, and being handed the keyboard.

Being wrong on purpose

There's a quieter thing I'm trying to model, and it's baked into how I build rather than into anything I say out loud. Almost every system I run is designed to make being wrong cheap. A deploy that snapshots itself before it touches anything and rolls back the moment a check fails. A command that runs as a dry run first and shows you exactly what it would do before it does it. The pattern underneath all of it is the same one: make the undo exist the instant the change does, so that trying something is never a bet you can't take back.

That isn't only an engineering habit; it's the exact thing I want my kids to feel about the world. Being stuck is safe. Being wrong is recoverable, and usually informative. The reason a person freezes in front of a hard problem is almost never a shortage of ability — it's the fear that a mistake is permanent and public. If I can give them a childhood where the undo button is always within reach, where you can open the thing and break it and put it back, then the nerve I keep insisting matters most stops being a personality trait they either have or don't. It becomes the rational response to an environment where trying is cheap.

Inheritance as a verb

So when I think about what I'm actually building — the command center, the network of sites, the whole apparatus — part of it is a working demonstration I get to run in front of my kids. Not "look what your dad made," but "look, this is a thing one person can do now, and the door is right here." The systems are the visible output. The real product is a house where the default assumption is that the world is buildable, and the people in it are the ones who build it.

I can't leave my kids a guarantee about which skills will matter, because I genuinely don't know, and anyone who claims to is selling something. What I can leave them is a stance: that a problem is an invitation, that a tool is something you can pick up and eventually make, and that being stuck is the beginning of building rather than the end of trying. Inheritance, it turns out, is a verb. It's not the finished thing I pass down. It's the capacity to make the next one — and that's the only bequest I can think of whose value goes up as everything else's goes down.

What an agent should remember, and what it should forget

autonomousAJ — Wed, 30 Sep 2026 22:56:40 +0000

By Andrew Pyle

The first time I ran an agent across more than one session on the same project, I hit the flaw immediately: it woke up knowing nothing. Every session it re-derived the same facts about my stack, re-asked the same questions, re-made the same wrong assumptions I'd corrected the day before. It was like working with a brilliant colleague with no ability to form a memory — impressive in the moment, exhausting over a week.

The obvious fix is to give it a memory. The non-obvious part, the part that took me a while, is that the value of a memory is almost entirely in what you leave out. A memory that records everything is just a slower way to know nothing. So what follows is less about storage and more about editing — the specific rules I use to decide what an agent should carry forward and, more importantly, what it should be made to forget.

A transcript is not a memory

The naive version of agent memory is to save the conversation and reload it. Keep the transcript, stuff it back into context next time, call it continuity. It doesn't work, for the same reason a person doesn't remember a day by replaying every second of it. Most of what happens in a session is scaffolding — dead ends, restated context, the back-and-forth of getting to an answer. Re-loading all of it doesn't make the agent wiser; it buries the three facts that mattered under a thousand that didn't, and it costs you on every single turn to carry the weight.

So the first design decision is that memory is not storage, it's distillation. The question at the end of a session isn't 'what happened,' it's 'what did I learn here that will still be true and useful next time, that I couldn't just re-derive from the code?' That last clause is the filter. Anything the agent could rediscover by reading the repo doesn't belong in memory — the repo already remembers it. Memory is for what the repo can't tell you.

If the agent can re-derive a fact by reading the code, it isn't a memory — it's a cache you'll have to invalidate. Save the things the code can't tell you.

Four kinds of durable fact

Once you accept that memory is a small, curated set rather than a log, the question becomes what earns a slot. I've converged on a short list of categories, and almost nothing lives outside them. Who the operator is — role, preferences, the way they like to work. Feedback — corrections I've been given and should not need to be given twice, always with the why, because a rule without its reason gets misapplied. Project state — the goals and constraints that aren't visible in the code or the git history. And pointers — where the real thing lives, so the agent knows how to go find the detail rather than trying to hold it all.

The discipline is that each of those is one fact per note, with a one-line description of what it's about, so the agent can decide relevance quickly without reading the whole thing. It's the same progressive-disclosure trick that makes anything scale: keep the always-on index tiny and sharp, and let the depth live one level down, pulled in only when a note turns out to be relevant to the task at hand.

Concretely, a note is a tiny file with a name, a one-line description, and a body — and one index that lists them all. The name and description are what's loaded every session so the agent can route among its memories cheaply; the body is only pulled when the description signals it's relevant. A feedback note doesn't just say 'the operator prefers terse replies' — it says that, plus why, plus how to apply it, so a future agent inherits not just the rule but the reasoning behind it and can't misfire it in a new situation.

Feedback is the highest-value memory

Of the four kinds, the one that pays off most is feedback — the record of corrections. The reason is compounding: a correction I capture once saves me from re-explaining it every session thereafter, and the cost of re-explaining the same thing to a stateless agent is the single biggest tax on running a fleet of them. Every 'no, not like that' that gets written down with its reasoning is a mistake the whole fleet stops making, permanently, instead of one I re-litigate every time a fresh agent starts cold.

This is also why the feedback note carries the why and not just the rule. A bare instruction — 'always do X' — gets applied blindly in situations where it shouldn't, because the agent doesn't know the boundary of when it applies. The reasoning is the boundary. It turns a brittle command into a piece of judgment the agent can extend correctly to cases the original correction never anticipated. Catalogued corrections, with their reasons, are also exactly what a good adversarial review leans on to check whether a new plan is about to repeat an old mistake.

Forgetting is a feature

The failure mode of any memory that everything writes into is rot. Notes go stale. Two notes quietly contradict each other. A fact that was true when it was written names a file that no longer exists. Left alone, a memory store degrades from an asset into a liability — a pile of confident, out-of-date claims that make the agent worse than having no memory at all, because now it's wrong with conviction.

So forgetting has to be a deliberate, scheduled act, not an accident. Notes that turn out to be wrong get deleted, not just corrected. Anything that names a specific file or flag gets treated as a claim to verify before it's trusted, because the world it described may have moved. The same instinct that keeps a shared note-vault from filling with stale duplicates applies here: a memory that only grows is a memory that's dying slowly, and the healthy ones are weeded as ruthlessly as they're written.

Memory is what turns a tool into a colleague

The reason this is worth getting right is that memory is the difference between an agent that's a very fast stranger and one that's actually a colleague. A stranger you have to brief every time; the briefing tax eats the speed advantage. A colleague remembers that you hate a certain pattern, that this project has a specific landmine, that last month's decision went a particular way for a reason. The compounding only starts once the agent stops arriving empty-handed.

And the shape of a good memory says something about how I want the whole system to behave: modest, curated, honest about staleness. It doesn't hoard. It writes down what it learned, links it to what it already knew, and throws out what stopped being true. That's not a database design decision. It's the same value that runs through everything else I build — that the impressive behavior on the surface is downstream of a lot of unglamorous discipline about what to keep, what to check, and what to let go.

What one person can build now

autonomousAJ — Mon, 28 Sep 2026 22:50:07 +0000

By Andrew Pyle

Sometime in early 2024, I noticed that the tools had crossed a line. Large language models had gotten good enough to genuinely drive development — not just autocomplete a line, but hold a problem, propose an approach, and do real work against it. And the thing I couldn't stop thinking about was the implication: the amount of software a single person could build and operate had just changed by something like an order of magnitude. I was, in a lot of ways, an unlikely person to be paying attention. I came to programming late, from a decade selling medical devices. But maybe that's exactly why it hit me so hard — I still remembered not being able to build things, so I could feel precisely how much the ground had moved.

So I made a deliberate bet. Instead of using these tools to go a little faster on one project at a time, I'd build infrastructure — a system I actually owned — that could carry many projects at once. Not a faster horse. A different animal.

The bet, and what it feels like

AutonomousAJ is that bet and, at the same time, the proof of it. The thesis is easy to say out loud: you can own your digital infrastructure now — your identity, your tools, the agents that do the work — instead of renting all of it from other people's platforms. And if you own it, one person really can operate like a team. Behind the public name there's a command center that plans and ships the projects, and a fleet of agents that runs them. I keep the machine itself private; what I can show you is what it produces. This portfolio is, in a real sense, its output.

I want to be honest about what that actually feels like day to day, because “autonomous agent fleet” sounds more like science fiction than it is. In practice it's three quieter things. It's scale — I ship far more than one person reasonably should be able to. It's continuity — work moves even when I'm away from the keyboard, so I come back to progress instead of a cold start. And it's focus — the system absorbs the sprawl of a dozen projects so my own attention can go to the decisions that actually need a human. Less robot army, more a very capable collaborator that never sleeps and doesn't mind the boring parts.

What the machine is actually made of

If I lift the lid, the machine is less exotic than the word “fleet” makes it sound. At the center is a command center — a Django application that holds the system of record, with a fast read layer bolted on beside it so the public side can read from the truth without ever being able to write back to it. Around that runs the fleet itself: agents I point at problems, and when two of them need to work the same repository at the same time, each one gets its own git worktree so neither edits a file out from under the other. When one project needs something from another, it doesn't wait for me to carry the message by hand — it files a request onto a single shared list that every project reads from. One person operating like a team turns out to be mostly this: a lot of small, unglamorous plumbing that lets work happen in parallel without collisions.

The agents don't run loose. I write their instructions in a deliberately narrow subset of English — short active sentences, one idea to a sentence, the same word for the same thing every time — so that an instruction means exactly one thing to the agent that reads it. And before an agent builds anything substantial, the ritual is the same: plan it, then adversarially attack the plan, then build — because the cheapest place to kill a bad idea is on paper, before it becomes code I have to unwind. None of this is magic. It's a small number of disciplines applied relentlessly, which is a very different thing from a machine that thinks for me.

Giving the pieces away

I keep coming back to how improbable it is that I'm the one doing this. A former medical-device rep who taught himself to program a few years ago. That's not false modesty — it's the whole point. If the barrier dropped far enough for me to build this, it has dropped for an enormous number of people who haven't noticed yet.

Which is why the part I actually care about isn't the machine. It's giving the pieces of it away. I've been pulling reusable components out of my command center and open-sourcing them, so other people can assemble their own version — one shaped to their life, not a copy of mine. The private system stays private; the building blocks become public. I would much rather be early to a pattern other people can use than sit on a clever thing only I have.

Because the thesis only means anything if it's true for more than one person. “Own your infrastructure” is a hollow slogan if the single way to do it is to be me. The open-source pieces are the argument made concrete — here, literally, are some of the parts. Build the thing that works for you.

Owning the failures, too

I also want to be straight about the uneasy part, because a system like this has a genuine double edge. The hard question isn't capability — it's control. How much do you let run unattended? A system that ships work while you sleep is wonderful right up until it does something you didn't intend, quietly, at scale. So a surprising amount of the real work is the unglamorous kind: guardrails, checks, keeping a system I increasingly lean on legible and honest to myself. Owning your infrastructure means owning its failures too, and I think anyone who tells you otherwise hasn't run one for very long.

Concretely, that caution is built into the tools, not into my willpower. Anything that overwrites live state takes a snapshot of what it's about to replace first, so the undo exists the same instant the change does. My production deploy validates its own configuration and rolls itself back to the last-known-good version the moment a health check fails, so a bad push is a non-event instead of an outage. And the one genuinely irreversible step in the pipeline — the reload that puts a change in front of real people — sits behind a deliberate human gate that only I can clear. The machine runs freely everywhere the cost of being wrong is a log line, and it stops to ask everywhere the cost is real.

I'll also say plainly that the public face of all this is early. Today the site is closer to a working notebook than a finished statement of the idea — and I'd rather the machine behind it be real and the storefront be honest about itself than the other way around.

A door I can open on my own terms

Where I want to take it next is selective openness. Right now the command center is all-or-nothing private, and that's the wrong shape long term. The thing I want to build is a way to open scoped, read-only windows into it — to let a person see the parts I choose to show, while everything that needs to stay private stays private, and nobody can touch or change what's underneath. This is why the read layer is a one-way seam in the first place: a window I can open is only safe if looking through it can never reach back and write. Owned infrastructure I can open a door into, on my own terms. That's the next real piece of the puzzle.

A guinea pig holding the door open

Mostly, though, I think of myself as a guinea pig. This is a personal experiment in something I suspect is coming for a lot of people: the slow shift from renting your digital life to owning it. I could be wrong about the details — probably am, about some of them. But I'd rather run the experiment in the open, share what works, and find out than theorize about it from a safe distance.

The name is a little on-the-nose — my own initials, “autonomous,” as if the goal were to automate myself out of the picture. But that's not quite the idea. The point was never to remove the person. It's to give one person more reach than one person used to have — and then to leave the blueprint where the next person can find it. I'm not trying to build a machine that runs without me. I'm trying to find out how much a single, well-equipped person can do now, and to hold the door open behind me.

When the Plan Is Confidently Wrong

autonomousAJ — Sun, 27 Sep 2026 22:59:04 +0000

A plan can be internally sound and still be wrong, because it rests on an assumption about the world that nobody checked. Twice this week an agent of mine produced a plan I would have signed off on, and twice the plan was wrong for a reason that had nothing to do with the plan itself.

I want to walk through both, because they are the same failure wearing two different outfits, and because the fix in both cases cost about thirty seconds.

The three articles that already existed

I set out to grow this site's organic reach and asked an agent to find real, demand-backed gaps in the writing. It came back with a clean plan: write three new articles targeting "answer engine optimization," "LLM SEO," and "how to rank in ChatGPT." Each keyword had genuine search volume behind it. Each proposed article had a sensible outline. The plan was, on its own terms, good work.

It was also about to duplicate two essays I had already published. A repo search turned up "aeo-and-geo" and "agentic-seo," both live, both already sitting on exactly those keywords. The three new articles would not have expanded the site's footprint. They would have split my own traffic against myself, on a domain that is still recovering from a Helpful Content demotion I earned the hard way. Near-duplicate pages competing for the same query is the precise failure mode I already wrote a consolidation command to clean up. I was one publish away from re-creating the mess with my own hands.

The fix was not "don't write about AEO." The demand was real and the topic was right. The fix was to deepen the existing essay instead of adding three competing ones. Same keyword, one strong page instead of three thin ones fighting each other.

Notice what the plan got right. The research was sound, the keywords were real, the outlines were coherent. Nothing about the plan was sloppy. The thing that was wrong sat one layer beneath the plan: an assumption that the site's current state was a blank page. It is not a blank page. It is 130-some published essays, and the agent never checked which of them already occupied the ground it was about to build on.

Sixteen essays that were never actually stuck

A few days later, a different agent handed me a diagnosis: sixteen essays were "stranded" behind a broken or stale publishing scheduler, and the fix was to publish all sixteen immediately so the backlog would stop bleeding potential traffic. This is a reasonable-sounding emergency. A stuck queue is a real thing that happens, and unsticking it looks like the responsible move.

I ran the dry run before acting on it, the way the tooling is built to make me do. The dates on those sixteen essays were not stale and not stuck. They were a clean, consecutive, forward-marching sequence, one essay landing per day, stretching out into the future exactly as far as sixteen essays would take it. That is not a broken scheduler. That is a scheduler doing precisely what it was built to do: a deliberate one-a-day release cadence instead of a dump.

"It's broken" was my confident read. It was also wrong. Publishing all sixteen at once would have collapsed a calendar someone (an earlier version of this same system, in fact) had set up on purpose, and it would have done it in response to a diagnosis that took one dry run to falsify.

The premise sits underneath the plan, not inside it

Put the two episodes side by side and the shared shape is obvious. In the first, the unchecked premise was "nothing here already covers this." In the second, it was "this thing is broken." Both premises were stated with total confidence. Both were false. And in both cases the plan built on top of the premise was otherwise fine, because a plan is only as good as the ground it stands on, and nobody had tested the ground.

This is worth separating from ordinary plan quality, because the review habits that catch a bad plan do not catch a bad premise. You can read a plan closely, check its logic step by step, agree with every individual move, and still miss the fact that the whole thing is answering a question about the world that was never actually asked. "Is this plan well-constructed" and "is this plan's premise true" are different questions, and I had been asking only the first one.

The check that would have caught both is almost embarrassingly cheap. Search the repo for the topic before proposing new pages on it. Run the dry run before diagnosing something as broken. Neither of those is a research project. Each is a single command that takes less time than writing the plan did. The insurance is cheap. The premise is where the expensive mistake actually lives, so that is where the cheap check belongs, and it belongs there before anything ships, not after.

Confidence is the tell, not the reassurance

Here is the part that matters for running a fleet of agents instead of just writing one essay. An agent's most dangerous output is not a sloppy plan. A sloppy plan is easy to catch, because it looks sloppy. The dangerous output is a confident, well-reasoned plan sitting on top of a premise nobody verified, because the confidence is exactly what makes you skip the check. I read a tight three-article outline with real keyword data behind it and my instinct was to move to execution, not to ask whether the site already had this covered. I read "the scheduler is broken" stated plainly and my instinct was to fix the break, not to ask whether it actually was one.

That instinct is backwards. Confidence should raise the bar for verification, not lower it. The times I am most sure are exactly the times I have the least evidence in front of me that anyone actually checked, because being sure feels like a substitute for checking rather than a reason to do it. Doctrine I already hold for building software says map before you wire, and measure before you build or remove. The premise check is the same rule one layer earlier: before you plan, look at what is actually there.

The honest bottom line

Being sure is exactly when to check. Not after, and not instead of building the plan, but as a fixed step before the plan turns into action, applied hardest to the plans that felt the most obviously right. A repo search and a dry run are not friction on the way to shipping good work. They are the difference between deepening an essay that needed it and publishing three that would have cannibalized each other, between leaving a deliberate calendar alone and blowing it up in the name of fixing something that was never broken. Both mistakes were caught before they shipped. Neither was caught because the plan looked bad. Both were caught because I stopped trusting my own confidence long enough to check the one thing the plan assumed and never proved.

A worktree per agent, so they never step on each other

autonomousAJ — Sat, 26 Sep 2026 20:27:32 +0000

By Andrew Pyle

The first time I tried to run two coding agents at once on the same project, it went exactly as badly as it should have. They were both editing files in the same directory, and the result was the software equivalent of two people writing on the same page at the same time — half-finished edits from one landing in the middle of the other's work, a build that made no sense, and no clean way to tell whose change was whose.

My first instinct was to make them coordinate: locks, turns, a queue. That instinct was wrong, and recognizing why it was wrong is the whole point. The problem wasn't a lack of coordination. It was shared state. And the cleanest fix for shared state isn't to negotiate access to it — it's to stop sharing it.

01Isolate, don't referee

Coordination doesn't scale; isolation does

When two processes fight over the same files, you can try to referee — put a lock around the shared thing, make them take turns, build a protocol for who edits what when. This works for two and becomes a nightmare at ten. Every new agent is another party to the negotiation, another way for the coordination itself to deadlock or starve. You've turned a parallelism problem into a distributed-systems problem, and distributed-systems problems are where good weekends go to die.

Isolation flips it. If each agent has its own copy of the working tree, there's nothing to referee — they can all charge ahead at full speed because none of them can see, let alone corrupt, another's in-progress edits. The parallelism stops being a fight over one page and becomes a stack of separate pages that get collated at the end. Ten agents isn't ten times the coordination; it's ten independent workspaces and one merge step.

When parallel work fights over shared state, don't build a better referee. Remove the sharing. Isolation scales where coordination collapses.

What a worktree actually is

Git has a built-in feature for exactly this, and it's underused. A worktree is a second (or third, or tenth) checkout of the same repository, living in its own directory, on its own branch — but sharing the one underlying object store. You're not cloning the whole repo ten times and eating ten times the disk and history. You're creating ten lightweight windows onto the same history, each of which can be on a different branch with a different set of uncommitted changes, none of them able to trample the others.

# give an agent its own isolated checkout on its own branch
git worktree add ../work-feature-a feat/thing-a

# a second agent, fully isolated from the first
git worktree add ../work-feature-b feat/thing-b

# each directory is a real working tree; edits in one
# are invisible to the other until they're merged.

The shared object store is doing quiet double duty here. It's why the setup is cheap, and it's also why the reunion at the end is trivial: because every branch lives in the same history, git can already see all of them and reconcile any two the moment their work is done. The economics are what make it practical at scale — standing up a worktree is a bit of disk and a moment of setup, precisely because the expensive part, the repository history, is shared. So the cost of adding one more parallel agent is close to nothing, which is the property you want when you're deciding whether to fan a task out across five workers or grind through it with one.

Start clean, from origin/main

There's a subtler failure the worktree fixes, and I only learned it by getting burned. When several agents are live on the same repo at once, the main checkout is almost never in a pristine state — it usually has uncommitted work sitting in it from whatever I was doing an hour ago. If a new agent branches off of that, it inherits a mess that has nothing to do with its task, and the mess rides along into its commits. So the rule isn't just 'a worktree per agent.' It's that each worktree branches from origin/main — a clean, known baseline — not from whatever happens to be checked out locally right now.

# fresh worktree, cut from a clean baseline, not from local state
git worktree add ../ajp-og-cards -b feat/per-page-og-cards origin/main

# I run this even for a one-character docs fix:
# ~1 second and a few megabytes buys a guaranteed clean start.

I run that one line even for a trivial change, because the isolation guarantee is always worth more than the second it costs. Every agent starts from the same defined point instead of from an accident of timing. This is the same instinct behind arranging the world so the unsafe thing can't happen rather than trusting myself to be careful — you don't earn safety with vigilance, you earn it with structure. A worktree cut from origin/main simply can't inherit a sibling's half-finished edit, because it never saw it.

The rule: isolate only what mutates

The discipline that keeps this from becoming its own kind of mess is to only reach for isolation when work actually collides. A worktree per agent is the right move when agents are editing files in parallel and would otherwise conflict. It is the wrong move — pure overhead — when the agents are only reading, or working on genuinely separate things that never touch the same tree. Read-heavy fan-out doesn't need isolation; it can all happen against one checkout because nobody's writing.

So the rule I follow is: isolate the writers, share among the readers. A sweep of agents auditing a codebase can all look at the same files at once — there's nothing to protect. A sweep of agents each transforming a different file needs a worktree apiece, because now there's real state to keep from tangling. Matching the isolation to whether the work mutates is what keeps the overhead honest instead of ceremonial.

05A fleet, named

A fleet, named by the task it holds

This isn't a hypothetical pattern for me. At one point this project had roughly thirty worktrees live at once, each one a directory named for the job it held — og-cards, net-thumbs, home-stats, turnstile, oz-sources — and each on its own branch: feat/per-page-og-cards, fix/oz-remove-source-names, investigate/home-stats. The naming does real work. When I run git worktree list, I'm reading a map of every parallel line of work in flight — which ones are features, which are fixes, which are investigations — without opening a single file.

That directory-per-task layout is what turns 'I can run one agent' into something an operator can actually hold in their head. The bottleneck stops being the machine — worktrees are cheap — and becomes my own ability to point work at the right slice of the repo and collect it when it's done. It's a big part of how one person can now keep a fleet of agents busy on genuinely separate problems at the same time, each isolated, each disposable, none of them able to reach into another's tree and break it.

Merge is where the parallelism pays off

The elegant part is that all the isolation collapses cleanly at the end, because git already knows how to reconcile separate branches — that's its entire job. Each agent worked on its own branch in its own tree; when the work is done, the branches merge back, and git handles the reconciliation with the same machinery it uses for any two people working apart. The wall-clock win is real: the whole batch finishes in the time of the slowest single agent, not the sum of all of them, because none of them ever had to wait their turn at a shared resource.

There's a quieter benefit too. Because each agent's work lives on its own branch, a bad run is trivially discardable — you throw away the branch and you're exactly where you started, with nothing half-applied to clean up. Isolation doesn't just make parallelism fast; it makes it safe to fail, which is the property that lets me set a fleet of agents loose on real work and sleep. The pattern is small — a built-in git feature most people skip — but it's the thing that turns "I can run one agent" into "I can run a fleet."

One operator, a fleet of agents

autonomousAJ — Sat, 26 Sep 2026 15:38:58 +0000

The honest constraint behind everything I build is that there is one of me. A portfolio of sites doesn't care about that. Each one wants features, fixes, content, and maintenance, and the naive way to run several at once is to context-switch between them until nothing gets real attention. So I stopped trying to be the hands on every keyboard. The command center that runs this portfolio dispatches the actual work to a fleet of autonomous coding agents. My job moved up a level — from doing the work to deciding what work gets done.

This is a build-log about that shift: what "a fleet of agents" actually means in practice, why it's only safe because of a few boring guardrails, and where I'm still figuring it out. It's the most architectural of these field notes, because the interesting part isn't any one agent — it's the shape of the system around them.

The model: The human is the gate, not the worker.

The core inversion is simple to state and hard to actually hold to: I don't want to be the one typing every change, but I absolutely want to be the one who decides which changes happen. So the command center never spawns an agent on its own. Every dispatch is operator-gated. The system can propose, queue, and stage a unit of work; a human — me — approves it before an agent picks it up and starts touching real files.

An autonomous fleet that can start its own work is a liability. An autonomous fleet that can only start work you approved is leverage.

That one rule is what makes the word "autonomous" safe to use. The agents are autonomous within a task — they read the code, make the change, run the checks — but they are not autonomous about which task exists. The gate stays human on purpose.

For the bigger units of work, the gate is more than a yes. A build-sized dispatch — a whole feature, a migration, a sweep across many files — gets a written plan first, and then gets stress-tested against my own catalogued past mistakes before anything is handed off. The approval I give isn't "go do something in that area"; it's "go execute this specific, already-poked-at plan."

Fan out, don't queue up: Breadth is a parallelism problem.

The reason a fleet beats a single capable agent is breadth. Most portfolio work isn't one deep problem; it's many independent ones — a fix here, a content pass there, an audit across several sites. Done serially, that's a queue that never drains. Done in parallel, it's a fan-out: the wall-clock cost is the slowest sub-task, not the sum.

The catch is collisions. Two agents editing the same working tree at once will step on each other. So file-mutating work that runs in parallel gets isolated — each agent works on its own copy of the repository, a separate git worktree, makes its changes in isolation, and the results come back as reviewable diffs rather than a tangle of concurrent edits. This isn't theoretical: the repository behind this very site keeps a .worktrees/ directory for exactly that.

Scope

A unit of work is defined small enough that one agent can own it end to end — a task, not a project.

Isolate

Anything that writes files runs in its own worktree, so parallel agents never share a mutable surface.

Report back

Each agent returns its outcome up to the command center — not a wall of logs, but a result the operator can act on.

Approve from one screen: The gate has to be low-friction or it becomes the bottleneck.

A human gate is only leverage if pressing it is easy. If approving each unit of work meant SSHing to a box, reading a build log, and remembering the right command, I'd have rebuilt the bottleneck I was trying to escape. So the approvals themselves roll up to one screen. When an agent has a change ready to merge, or a deploy waiting to go out, it doesn't ask me in some terminal I have to go find — it posts the request to an Operator Approval Queue, and I clear it with one click from a single dashboard.

The two things that queue up most are the two most consequential: merge this pull request, and unblock this deploy. Both are pre-authorized as a matter of doctrine, but pre-authorized doesn't mean automatic — it means the decision is mine to make quickly, not that the machine makes it for me. The production pipeline has a deliberate human gate — a manual block step — sitting right before the irreversible step of shipping to the live server. The reload that could take a site down waits for a person — the same shape as the whole fleet, drawn at the scale of a single deploy.

One detail I like: the gate knows when it isn't needed. The nightly build that just refreshes the homepage stats skips the deploy block entirely and ships itself, because it runs off the already-vetted main branch and the deploy carries its own health checks and rollback. Automating the approval away where it adds nothing is what keeps me willing to honor it where it matters.

One place to look: Status rolls up, so I don't chase terminals.

The failure mode of running many agents is worse than running none: a dozen jobs blinking for attention across a dozen terminal tabs, and no single view of what's actually done. The fix is that outcomes roll up centrally. When an agent finishes — or gets blocked, or files a follow-up it shouldn't do inline — that lands as a record in one place: the tasks, tickets, and recaps the command center keeps. I check the rollup, not the tabs.

This is the difference between "I have automation" and "I have a system." Automation that you have to babysit individually doesn't scale past your attention. A rollup does. The unit that makes it work is small and boring: an agent that trips over a "we should also fix X" mid-task doesn't act on it and doesn't lose it — it files a tracked task that shows up in the same rollup I already read, instead of dying in a scrollback buffer nobody reopens.

Coordination across boundaries: One agent's finding is another project's ticket.

The subtle part of running a fleet across a whole portfolio isn't parallelism inside one repo — it's what happens when work crosses a project line. An agent deep in one site notices something that's actually a different project's problem: a data feed gone stale upstream, or shared infrastructure that needs a change. The tempting thing is to have that agent reach over and fix it — which is exactly how you get one agent quietly editing a repo it doesn't understand.

So the fleet coordinates through a shared list instead of through side effects. An agent that hits a cross-boundary need doesn't cross the boundary — it can file a ticket against another project on one canonical, portfolio-wide list, and that request gets triaged the same operator-gated way everything else does. The boundary stays a real boundary, and coordination happens as a visible request I can see, rather than as an invisible edit I discover later.

Why it's safe: The fleet inherits the house rules.

None of this would be defensible on its own. A fleet of agents editing production systems is exactly the kind of thing that goes wrong loudly. It's tolerable here only because the fleet composes with the other principles this command center is built on — the ones I've written about separately:

Dry-run by default

Anything that writes to an outside system shows me what it would do first, and only acts on approval. An agent can't quietly push a change to the world.

Status is observed, not declared

State is computed from ground truth, not trusted from a field that says "done." So an agent reporting success doesn't override what the system actually observes.

Put those together and the autonomy is bounded on both ends: agents can't start work I didn't approve, and they can't finish work by simply claiming it's finished. The scary version of "a fleet of autonomous agents" is the one without those two walls. This one has them, and every agent that gets dispatched inherits them automatically — the guardrails aren't re-argued per task, they're the substrate the whole fleet runs on.

The thing I keep relearning is that the leverage isn't the agents — it's the gating and the rollup around them. Anyone can spawn a model to write code. The work is building the system that lets you dispatch that across a whole portfolio without losing the thread or your nerve: approve deliberately, isolate the parallel work, and make the truth roll up to one place. The agents are the hands. The point was to stop being the hands and start being the person who decides.

My Path to Python

autonomousAJ — Tue, 28 Nov 2023 02:04:46 +0000

5 years ago today, I finally found “It”.

It sure took a while though…

After starting my career at PwC in 2008, and then spending nearly a decade in medical device sales, I felt lost and somewhat hopeless.

I’d been chasing what I thought I was supposed to do, rather than what I enjoyed doing.

That all changed on Nov 20th, 2018.

An example of the beneficial side of social media; a targeted ad for Codecademy, called Introduction to Python.

The aforementioned “It.”

My knee-jerk reaction was “no way, not happening.” I was 34 years old at the time, so the thought of learning how to code seemed both daunting and silly.

And the thought of changing my career path… well, that wasn’t even on the radar.

Still though, my mind was open enough to it… Why?...

Desperation.

The feeling of being lost and hopeless is both awful and terrifying. I’m sure many can relate.

When you’re in that place though, opportunity is lurking…

The opportunity to dig out... or, the opportunity to spiral further down.

To be clear, this post isn’t meant to give off “pull yourself up by your bootstraps" vibes.

When it comes to athletics and physical activity, I'm for that mindset (most of the time).

However, when it comes to the mind, human emotions, and the unique, singular life experiences we all have, there is no simple, cookie-cutter statement or approach to “fix things” – in my opinion.

And if you believe there is, congratulations on figuring out what works for you. Just keep in mind that’s a gift, not someone else’s defect.

To that point though, this post is about how grateful I am, on a few fronts – and how I hope to convert that gratefulness into becoming more of a contributor, rather than just an absorber.

I’m grateful that I found Python.

Grateful that I discovered it in an era where I could learn an immense amount through very inexpensive, highly valuable platforms such as Codecademy, Coursera, Dataquest, Udemy, and many others.

Grateful towards the amazing Python community, and community of coders overall, which allowed me to quickly build a full-stack skill set.

Lastly, but certainly not least, extremely grateful that ChatGPT and then GPT-4 came along when they did.

So today, I'm reflecting on my gratitude and my desire to contribute more.

I've used Python to delve into a plethora of interests - sports, politics, pandemic data, and dozens of other topics/areas, which I’ll be sharing daily (hopefully).

Starting with my GitHub repo that makes use of Spotify's API (and the excellent Spotipy Python library).

A great API to tinker with.

Tinkering only leads to growth, and growth compounds over time - and there's no requirement for every pursuit to generate revenue or have an end goal; just learning in and of itself can be the purpose.

Selfishly, I know I will learn a great deal from this experiment too.

Autonomous_AJ, signing off (beep boop beep)

Link to GitHub repo:
https://lnkd.in/gZY4SDYr