Minh Tri Le · on july 2 i typed git init for the platform i’m building: a place where you run a small team of ai agents that work for you. on october 17 the repo had 1,069 commits, 578 issues and 94 pull requests.
it’s one person. me, plus whichever coding agent still had quota that day.
this isn’t a success post. there are no users yet. it’s what 3.5 months looks like when you read the git log back, including the stuff i built and then threw away.
the numbers first
| month | commits |
|---|---|
| july | 312 |
| august | 236 |
| september | 415 |
| october (to the 17th) | 106 |
- 88 of the 108 days had at least one commit.
- by type: 319
feat, 232fix, 78docs, 64refactor, 55test. - 527 of the 578 issues are closed. 82 of the 94 prs are merged.
- busiest day: 42 commits on october 16. second busiest: 40 on september 27.
one caveat before anyone asks “how much did the ai write?”: i don’t know, and git doesn’t either. who’s listed as the author of a commit says nothing about who typed the lines. so i’m not giving you a percentage.
before day one
the platform didn’t come out of nowhere. in april i did two small elixir agent experiments. in june i built my own liveview ui kit (113 commits) and a tiny public agent loop: think, act, observe, in one file. two days after that loop, the real repo started.
july: build everything
day one’s most memorable commit was a perf commit: “eliminate O(n²) patterns, parallel tool execution, ets hot paths”. i optimized before i had a single user. still not sure if that was smart or just fun.
day two, i read the source of kimi-code (an open-source coding agent cli) and ported ideas from it: a todo list tool, context compaction, a swarm mode. reading other people’s agent source is the cheapest r&d there is.
then it was a sprint:
- jul 4: a crewai-compatible orchestration layer. teams, crews, workflows.
- jul 6: a roadmap, phase plans, a todo checklist, and the first agent guide file. the plan was written down from the first week.
- jul 9: moved from sqlite to postgres, with an import task for the old data. a secrets vault and an ssrf guard landed the same day.
- jul 12: multi-tenancy and google sign-in.
- jul 24: prompt-injection quarantine. tool results and webhook payloads get wrapped as untrusted data before the model sees them. same day: a decision record picking wasi/wasmex as the code sandbox.
august: delete things
august is the month i started deleting my own decisions.
- aug 3: the wasi/wasmex sandbox lasted about 10 days. retired it, moved code execution to bubblewrap (
bwrap) with memory-aware admission. - aug 4: replaced pgvector session memory with plain-text memory the agent can edit itself. simpler won. same day, split the repo into a proper umbrella app.
- aug 10: found out a production release had google oauth’s client id and secret baked in as
nil. the classic elixir trap: compile-time config vs runtime config. - aug 22: deepseek sometimes prints its tool calls as plain text instead of calling them. the fix recovers them at the codec. my rule from that commit: never confabulate around them.
september: the boring parts that make it real
september was the biggest month (415 commits), and almost none of it would make a good demo:
- multi-node clustering, plus draining websockets on deploy so people don’t get dropped.
- sep 3: ripped out the whole team/crew/workflow layer from july. one agent that can spawn sub-agents won. two months of compatibility work, gone in one commit, and the right call.
- sep 9: admission control: claim and release around every llm call, per provider. rate limits treated as a resource.
- sep 13: a durable, lease-safe run lifecycle, and the race fixes that came with it.
- sep 22: a capability manifest. what an agent may do is compiled when its run starts, not assumed.
october: agents and a human in one chat
on october 14 i opened the epic for group conversations: one chat where a human and several agents work together. it was split into seven slices, g0 to g6, all filed as issues the same day. g0 and the first schema pr merged that day. by october 16 there were prs open for every slice.
the first real design write-up from that work is pubsub is a hint. the database is the truth.
how i actually work with coding agents
this is the part people ask about, so here’s the real loop.
1. get grilled first. i use matt pocock’s skills for claude code. 25 of them are pinned in the repo, including grill-me, to-spec and to-tickets. before i write a spec, i let the agent attack the idea: what breaks, what’s missing, what i’m hand-waving. one commit from august 10 literally says “rewrite plan per grilling session, publish spec + tickets”.
2. spec → github issues. the spec becomes issues. the issue tracker is the agent’s task queue, which is why there are 578 of them. the group chat epic above is a typical example: one spec, seven issues, same day.
3. set a goal, let it run until done. the agent gets an issue and a goal, and it keeps going until the goal is met, not until it gets bored. a plan and a roadmap sit in the repo, so every session starts from the same picture.
4. make the repo friendly to agents, not just humans. from september 26 to 29 i made 93 commits, and the main thing i built was a verification contract for coding agents. a script reads the git diff, picks the checks that change actually needs, runs them and writes a receipt. the rule i care about most:
a required check that did not run is never a pass.
ci now runs the required checks on every pr, so an agent can’t merge work that only passed on its own machine. later the main agent guide went from one 31 kb file (which agents either read entirely or not at all) to a short root file plus rules that only load for the paths you’re touching.
5. many agents at once, on worktrees. each agent works in its own git worktree. the tooling for that took three days in mid-september. it still wasn’t enough: parallel agents kept stepping on each other’s dev databases and ports. so on october 16, the 42-commit day, every checkout got its own slot: its own native dev server, warm start, parallel compile, a test cluster that’s safe to run side by side, a partitioned test database, and postgres max_connections raised to 500 for parallel test vms. most of that day was making agents not collide.
6. switch agents when you hit the limit. the coding agent changed several times over these months: claude sonnet, opus, and another agent in between. no deep reason. i hit usage limits, and i switched. the workflow above is what made switching cheap: the context lives in the repo, not in one chat window.
what i’d tell myself on july 2
- write the plan down on day one. agents are only as good as the context they can find.
- expect to delete half of what you build. the crew layer and the wasm sandbox were both “done” before they were wrong.
- invest in verification earlier. the more agents you run, the more “it works on my machine” multiplies.
- flaky tests and shared state are the real tax of running many agents. not tokens.
next up is shipping group conversations slice by slice, in public. if you’re building something similar with coding agents, i’d like to hear what your loop looks like. i’m @trile_412 on x.