Post

one thing I do wonder about when it comes to this attitude is because I settled, early on, on a couple of things: - don’t spend less to achieve a goal at the cost of quality - it is all about latency and not about bandwidth

a polytoken ticket, run through the normal workflow, takes between four and six hours. I have accelerated ones for faster turnarounds at the cost of more human interaction but my stuff is mostly AI container ships putt-putting across the ocean

Polytoken is closing in on a million lines of code, counting the test suite (hovering around 50%). It has basically all been built this way.

And not to toot my own horn too much, but one thing I’m proud of is that there are very few regressions in that time. And all but two I can think of were my own meatbag fault—bad design and insufficient guardrails on flagging changes for unexpected disruption

A few things that seem to also help: - my workflows encourage recording “housekeeping” tasks because in my harness models really don’t like to boyscout. They will ignore those problems and not report them. I average 2 tickets per implemented plan and I have agents burn them down 12-18 at a time

(this is the one thing I think Beads really did get directionally right)

- one day a week (lately more like every other week), I stop all new work and start garbage collection. Go find problems. Hand out the codebase in an overlapping combination and Go Find Problems. I’m augmenting this with a treesitter code map to look for suspected duplicate functionality right now