I’ve started a video series on agentic coding, and you can view the first video here. This is a short summary if you prefer a post instead!

The agentic workflow is something I’m calling “local, parallel, and autonomous”. It’s a dive deep into making a whole codebase from scratch, completely hands-off.

The Core Attributes #

The main pillars for this workflow are straightforward:

  • Local: All the git worktrees run locally on my machine, avoiding the complications of remote execution.
  • Parallel: It’s built to scale so multiple agents can work on different issues across multiple worktrees at the same time.
  • Autonomous: The agents complete issues from start to finish without human intervention.

Choosing the Right Projects #

Let’s be clear: as of March 2026, there are a lot of risks with this approach. I wouldn’t confidently build and deploy a production SaaS web application this way because the necessary guardrails for safety and privacy requirements just aren’t there yet.

Because of that, I choose self-contained, smaller projects. I’ve built a few codebases this way, including:

For more complex, large-scale systems, I still rely heavily on a manual cycle where the AI generates code and I heavily review it.

Bootstrapping: Setting the Guardrails #

To get things started, I wrote a repository called agentic-bootstrap to provide the scaffolding. Inside its templates/ directory, I keep generic rules that help agents stay on the rails.

The bootstrap relies on a few key components:

  • AGENTS.md: This file acts as the playbook. It tells agents to study the README first, ensures CI passes, enforces linting rules, and mandates that documentation is always updated.
  • specs/: This directory holds design specifications. Splitting the design up limits the context an agent has to load to accomplish a particular task, separating the “designer” agent from the “executor” agent.
  • Example Files: For the Heaptrack UI, I included a sample .zst file in the repo so the agent actually knows how to read the format it’s supposed to parse.

Writing Specs: The “Grill” Approach #

When it’s time to write the overall design, you can write it yourself, but I used an approach called “grilling” to illustrate another, more agentic way to bootstrap.

I tell the agent: “Interview me about the purpose of this project”. It asks me questions about architecture and UI, and I respond with my requirements—for example, that the app should be a purely client-side React app, include dark mode, and support drag-and-drop.

The agent then writes out the design documents in the specs/ directory. I usually do a quick offline review; for instance, the agent once hallucinated some weird typography requirements asking for “Apple’s clear glass” style, which I promptly deleted.

Managing the Queue with Beads #

For the issue database, I use a tool called Beads, created by Steve Yegge. It acts as a local database for issues, supports being reused across multiple work trees, and is highly agent-friendly with support for --json flags.

You simply initialize it with bd init --stealth. From there, you can manage the queue:

  • bd create to make new issues.
  • bd update {id} --status=open or --status=closed to manage state.
  • bd delete {id} to remove them.

I like to use a “thinking” model for a seeder prompt to write highly detailed initial issues, and I use the Beads VS Code extension to visually track what the agents are working on.

Orchestration with Lelouch #

To orchestrate the workers, I wrote Lelouch. It’s effectively a way to run an agent, one per github worktree, pulling issues out of the Beads database.

To initialize it just run lelouch init per worktree. It monitors your repositories, pulling open tasks from the Beads database by priority and dispatching them.

I typically run Lelouch with the Gemini Flash model via CLI because it has a more forgiving usage limit. I also add a pre-prompt like “run tests, commit, and push” to make sure it follows through.

When I run lelouch run -v, the loop begins. It moves issues to “in progress” and logs the agent’s responses directly into the working notes, so I can see exactly what it’s up to. It’s incredibly satisfying to just watch the issues update in the VS Code extension while the agents hum away.

Handling Bugs and Gaps #

The process isn’t perfect. During my Heaptrack build, the agent created a gaps.md file but failed to actually implement the missing features. I had to manually prompt it: “There are gaps in gaps.md that are not yet implemented. Please create BD issues for them.”.

When I tested the UI, I found that the flame graph had sizing issues and the .zst file wasn’t loading properly.

Fixing this is a matter of adding issues to the command line via bd q "fix the bug with the zst file not outputting the flame graph". Lelouch immediately picks it up in the background.

Takeaways for 2026 #

I’ve done this with four or five projects now, and having a central issue database with parallel worker agents is a scalable model.

I know that there’s been existing examples online of people who have done everything from write compilers over to full web browsers, and games with varying success. Despite that, I’m still skeptical and looking for ways to get it to be a consistent, high quality enough generator that it can be used for more production code. To get there, I think it’ll take more guardrails, especially security-related ones. Some projects are already using agents with a security persona to try to get there.

But all technology has to start somewhere, and this workflow serves as an interesting baseline for my process I intend to grow.