How we work
How we work with agents
Every engineer here works with coding agents daily. That part isn't interesting anymore, everyone does it. What's interesting are the second-order problems, and we're in the middle of it.
When writing code gets cheap, reading it becomes the bottleneck.
Most engineering process assumed producing code is the expensive part. It isn't anymore, and line-by-line review was built on that assumption; on large agent-assisted changes it had become theatre. So we're moving the human review upstream: automation catches what automation is good at, and the engineer reviewing your work spends their time on whether the approach is right, not whether line 340 has an off-by-one.
You own every line you commit.
"The agent wrote" it is not an explanation. Same review standards, same PR discipline, same expectation that you can defend any line in a code review, in an incident, or six months later when it breaks. Authorship moved; accountability didn't.
We measure whether it's working.
Change failure rate is a first-class health metric, not something we think of in a post-incident review. That's what lets us move quickly on process changes like the one above: if velocity starts costing us reliability, the number tells us before a customer does. Agents get more rope because we're measuring the rope.
Agents have our internal context, not just our code.
Engineers run agents against internal systems: data, issue tracker, docs, observability tooling, so the work isn't limited to what fits in a repo.