Very true. If a PR has 1000 lines I would check only a handful full of them and leave the rest for test suit .

This mirrors exactly what I have been doing. - Give Claude/Codex a way to verify its own work (browser, smoke tests, e2e tests, high-fidelity local environment) - Keep all context (issue tracking, docs, ideas, plans, worklogs) in-repo ( https://github.com/shepherdjerred/monorepo/tree/main/package... ) - Give Claude/Codex access to observability (Grafana, Prometheus, Tempo, PagerDuty) - Have Claude/Codex follow good engineering guidelines like fail-fast, type safety, parse at boundaries I haven't yet been able to achieve full autonomy due to cost and CI load on my homelab.

it does not result in great results left unattended, it’ll start creating slop or hardcoding solutions but overtime if you adjust your verification rubric, it’s not too bad, gets pretty good, if you do make it do TDD, it gets kinda crazy and you’ll have 2000-3000 tests after awhile, or on my common case, 6000-7000 lines of code in single files (i usually have a cron to audit files for decomposition and create tickets) i wouldn’t use it at my job yet, but it’s been fun to use for personal projects - it’s like modded minecraft automation or factorio

I do quite a lot of what this post describes in a reasonably large project. Here's what works for me: - write gherkin features for new features; update them for enhancements; don't touch them for refactors. Label your PRs with these nouns. - use pre-push hooks for type checks, linting, unit tests, and other quick, scriptable validations. - make a viteperess subsite in your repo, have the agents maintain it - document important principles, architecture, etc. - make a cli command which lists all pages along with the yaml frontmatter description so agents can choose what to read without blowing up the context window. - use ddd and monorepo - write your logic in headless layers, and compose layers into apps. agents navigate layers very successfully. - use zod (or your language equivalent) and contract-first API development; this is my favourite bit tbh, I use orpc - make a single skill called "code" which describes the lifecycle: open a worktree, setup .env to guarantee no conflict with other agents (choose unused ports etc - docker is good here), write or update feature file (this is where you negotiate the spec), implement, validate (e.g. using playwright mcp), pre-push checks, push and wait for review, tear down and fast forward main - testcontainers is great for ensuring multiple agents can run tests that don't conflict Seriously I only have one skill that's it. Everything else is in the docs. I'm feeling very productive like this, in a "making good software" sense not a LoC sense.

I have an example of a side-project [1] where I think I naturally applied the best practices described in this article. My goal was to see if it's possible to code an entire project using a single agent (Claude). To do this, I "simply" asked the agent, every time it encountered an issue, how to resolve it, using a validation tool or script. I also asked it to code these tools during audits. As a result, I now have over 30+ rules [2] for validating their commits. It's working pretty well now. [1] https://github.com/gildas-lormeau/rebuild-and-ruin (let the timer expire to see the "demo" mode) [2] https://github.com/gildas-lormeau/rebuild-and-ruin/blob/a4c3...

You tell it to update the docs: not append. I've done the same thing with a readme in the root with links to the docs. After every commit, before the push, I have my agent "update all relevant and related docs, add or remove what's needed" or something to that extent. And it works remarkably well. I also have an append only change log it's supposed to add to. Between that, good commit messages, and comprehensive testing, I've built a homebrew OS and updating it is remarkably smooth. Runs a homebrew FTP and HTTP server and can run Wolfenstein. Working on DOOM right now. Close, but sound has been difficult. https://github.com/ESikich/smallos

This is the part I think we will see become more relevant. I created docs-cli (pypi) to manage the index of specs as source code: the framework that goes with it will first create tests for as much as it can, so reproducability becomes the goal, not readability. https://github.com/ArtRichards/docs-cli https://artrichards.github.io/agent-playbook-suite/blog/

Far from everybody is using it for massive code generation - code size is still very much a liability. I currently use it (ds4-flash, local, code isn't open to non-local) to modify and trim a certain internal project for a different use case. Tons of review passes, fuzz test generation and running, "give me your thoughts on this", etc, etc - basically iterating over and over and over. Funnily enough, my intrinsic knowledge of the codebase improves massively like this. It is involved, but the acceleration is real - and I don't have to worry about wrist nerves as much. The only people I know that have LoC/token use/etc metrics imposed on them work for big corps where such things are (or used to be) en vogue.

Codex updates usually appear every few hours (i am not saying this how often it's published) but that's my perception as a user. Often i update codex just to see new update within an hour so. Many times those updates are not properly tested, for example in one update the model selector got completely changed. then next hotfix was pushed which restored original.

Who needs a QA team when you can just test on users and iterate instantly /s