I no longer write my repo for me, I write it for the agents

I open my terminal in the morning and part of the work is already done.

The CI watch ran every 30 minutes through the night. Commits were reviewed. Work in progress was committed so nothing got lost. It isn’t magic, and it isn’t even about the model. It’s about tidying up.

For a long time I did the opposite. I pasted the same context paragraph at the start of every session, got annoyed when the agent forgot a rule, and concluded the model was limited. That rule was written nowhere. It lived in my head.

Today I don’t design my repo for me. I design it for the agents that will work inside it. The goal fits in one line: the agent should be able to understand, code, test, review and even merge without needing me at every step.

1. Context is an artifact of the repo, not a prompt

Project context lives in the repository.

At the root, an AGENTS.md acts as a router: “you want to do X, read Y”. The project doctrine is versioned next to the code, I have about twenty in-house skills loaded on demand, hooks, and a project memory.

Most importantly: when the context is wrong, it gets fixed by a PR. Context is no longer something I keep in my head or retype into a prompt. It’s part of the codebase, with a history, an author and a review.

2. I work spec-first

I start from intent, not syntax. With BMAD or OpenSpec, I describe what I want, and an agent produces the spec and the breakdown.

I decide the architecture, the product, the business and the trade-offs. I no longer spend my time deciding how each function should be written.

Then we cut the work into tiny, independent units. That’s not an aesthetic preference: the smaller the task, the less context it burns, and the easier it is to parallelise.

3. Several agents work in parallel

When tasks are independent, I no longer run A, then B, then C. I run A, B and C at once. When several agents need to touch the same files, each one works in its own worktree.

And when I don’t yet know which solution is best, I fan out: several agents propose an approach, an adversarial jury tries to break them, and I keep what survives.

So I don’t only ask “give me a solution”. I also ask “try to prove this solution is bad”. That second question changes the output quality more than anything else.

4. Verification happens before I look

I don’t want to be the first quality filter.

The agent runs the lint, the tests, the build. Then another agent reviews the diff adversarially, with instructions to find problems rather than to say it looks good.

That’s also why I keep my business logic pure, with no I/O. An agent can test it with no emulator, no secrets, no complicated environment, in a couple of seconds. To me that’s the real criterion for an AI-native codebase, far more than the choice of model: a codebase an agent can test on its own is a codebase an agent can evolve on its own.

5. Part of the system runs without me

My agents and crons run in production 24/7 on my products. One agent watches commits, reviews PRs, and can merge once checks pass. The CI watch runs every 30 minutes. Work in progress is auto-committed. Project memory hygiene happens without me.

And my third-party tools are plugged in over MCP. The agent sends a campaign itself, reads product data, opens the logs, acts on the tools it needs.

I’m no longer the human API between the agent and my tools. That’s the part I took longest to let go of.

6. When something breaks, I don’t read the logs anymore

I used to spend thirty minutes hunting for the line that broke.

Now I give the agent access to the logs and the database, and I ask three questions: what’s your hypothesis, what’s the repro, what’s the minimal patch.

The agent investigates. I decide.

7. I don’t depend on a single model

I run multi-provider. Each agent has its model and its fallback, with routing that accounts for cost. Claude Code daily, GLM and Gemini for volume.

I even wrote my own agent harness from scratch, able to run a local LLM: github.com/yelkamel/sarj. I want to understand what’s inside the loop. I don’t want my understanding of the system to depend entirely on a vendor’s product.

The guardrail

The idea isn’t that AI does everything.

Autonomous in execution, controlled in outcome. An agent can merge code that passed the checks. It doesn’t decide what we build, nor the security rules, nor payments, nor business trade-offs. That stays human, and it will.

The real shift

The change isn’t “I code with AI”. It goes deeper.

I organise my development environment so that agents can work inside it. The repo becomes their workplace, specs become their contract, tests become their guardrail, hooks become their reflexes, MCP servers become their tools. And I become, more and more, the architect and the pilot of the system.

It’s the same mechanic I describe in my organisation: one company, one capability, one outcome. And it rests on the software architecture I install everywhere, because an agent can only safely evolve what the compiler and the linter hold in place for it.

The best proof is that beedone.co, up-drive.com and evolum.co already run without me touching them every day.

I’m curious to see what all of this looks like a year from now.