There I am. It’s 5am on a Monday morning, and I’m doing that thing I do.
It’s been a really fruitful coding marathon.
The coding agent project is done, or so I think.
The workflow is perfect.
Narration works, including the new granular narration, so users won’t get confused when a long-horizon agent sits and thinks for a while.
Context works. Memory works. The process looks pristine.
I was feeling pretty confident.
And then I told Nora to run the long test.
The long test is the final eval, where I point the new coding agent platform at a big huge giant repo for an existing open source project.
The assignment: reverse engineer the backend of the app and give me a 1:1 replacement in Golang.
Reason being:
a) I have a lot of apps I want to experiment with this way.
b) It is exactly the kind of job that should take a swarm of agents a day to complete.
Decomp went fine. Two tickets hit the frontier. A good preliminary assessment. A real project plan, and two boring very formal tickets.
Exactly what I expect from Robot Kanban at stage one.
Meanwhile, I’m running the agent project on another totally innocent subdirectory off ~/projects.
The concurrency failure
That’s when it hit the fan.
Nora had shut down the eval to report that the eval had started correctly.
When it started back up, total chaos.
Locking issues with DuckDB that I thought we had already resolved. Alarms, lights, very polite error messages telling me the system was failing.
This, I did not expect.
See, the system works, but database consolidation broke multiple concurrent sessions.
Crap.
This project has gotten too big for a single portable database system, I think. We’re sitting at about 150k LOC right now, and these dinky portable databases are simply not enough anymore.
SQLite failed early because of the way the vector plugin works. You’re either dropping data, or scheduling writes so hard the whole thing slows to a crawl.
DuckDB is smoother. Also a portable database format. Also nice and workable... as long as you’re not trying to do high concurrency with it.
I could switch to a real database server, but then I’m kicking the can down the road, and adding a Docker dependency is not something I want for an app like this.
Not today, Docker Satan.
I do believe it’s time to use NATS.
More soon.