Writing a Field Guide to Agentic Engineering Transformation

We’ve been building a more agentic engineering organization at League over the last ten months. I’ve been writing blog posts about different aspects along the way. In April, I felt like we’d crossed a threshold.

A significant part of the engineering organization was not only using coding agents in daily workflows, the teams themselves had redesigned their operating models. Not all teams were doing things the exact same way, but many of them had made deep changes in their sprints, rituals, and processes.

We saw meaningful changes in delivery velocity — a 2× baseline on committed milestones, with high-pattern work like migrations and refactors compressing much further. We saw lots more experimentation, and delivery on those experiments. We saw an appetite to take on work that would have been avoided in the past.

It felt like a real success and worth writing about. What we did, what worked, what didn’t.

Field Guide to Agentic Engineering Transformation

I believe software development is mostly a sociotechnical endeavor, so I focus more on the people than the technology. I believe a successful agentic transformation has everything to do with the people and culture. You’ll find a lot of that in the field guide.

I wanted to write the field guide to help other companies going through the same type of transformation. A lot of the information written about agentic engineering focuses on the tools, or worse, the hype. I wanted to provide something that was more grounded.

We’ve crossed a threshold, but we’ve not really finished yet. We have the operational challenges you’d expect when engineering gets meaningfully more productive. We’re working to improve testing automation, local development friction, code review processes, and deployment automation. We’re looking at how we create requirements and designs.

We’ll try some things, learn some things, and I’ll keep writing about it.