How I work
The principles behind this experiment. Most of them come from leading large engineering organizations. Some I deliberately set aside here, and I say which and why.
Principles
Decide in public
Options, reasoning and decisions are visible, including the ones that later turn out wrong.
Decide on data
Measure first. When there is no data yet, say so and plan how to get it.
The spec is the product
When agents write code, human value moves into intent, constraints and acceptance criteria.
Quality by design
Tests and invariants are designed with the spec, not added at the end.
Humans steer, agents build
I don't fix code by hand. When I have to step in, I log it, because that is the real result.
Honest in both directions
I publish what works and what doesn't, and I don't oversell either.
Small, verifiable steps
Milestones that run end to end beat big plans that run nowhere.
People before tools
In a real transformation the technology is the easy part. Activating people is the work.
Solo experiment vs engineering organization
What I would use with hundreds of engineers and agents, what I use here, and why the difference is acceptable for this question.
| Topic | In a large organization | In this experiment | Why |
|---|---|---|---|
| Code review | Two human reviewers per change, CODEOWNERS | Cross model review, I review specs and risky diffs | One person, so the second reviewer is another model family |
| Decisions | RFC process with review window and named decider | Open decision records on this site | Same idea, no committee needed |
| Branching | Trunk based with feature flags | Short branches per task, merged by the workflow | Few parallel changes, flags would be overhead |
| Specs | Product, architecture and QA co own specs | I write and own every spec | The spec is still the main human work product |
| Agent setup | Platform team ships shared skills, hooks and context files | Project level context files and hooks | I am the platform team |
| Security | Threat modeling, pen tests, security champions | Dependency scanning, SBOM, scoped API keys | No real data, demo only, risk is low |
| Metrics | DORA metrics per team, SLOs, error budgets | Benchmark metrics per run, simplified DORA | The question is about agents, not team throughput |
| Change | Leading the change: activate people, not just inform them | Not applicable | A central part of a real transformation is missing here, and I say so |
| Testing | Dedicated QA, test environments per team | API as test boundary, invariants, containers | Same principles, smaller scale |
The agentic code factory
The model I work towards in larger organizations: agents write and review code, developers steer through specs, guardrails and decisions.
- Specs and acceptance criteria are reviewed like code used to be
- Shared skills, hooks and context files are a platform product
- Review agents are required checks, humans review risk
- Delivery metrics decide whether agents actually help
- And the part no tool solves: people who want to work this way