Lethain has finally weighed in on AI adoption

Will Larson published a post last week on facilitating AI adoption at Imprint. It’s one of the most practical things I’ve read on the topic. It’s that way because it speaks from hands-on experience. If you’re an engineering leader trying to figure out where to start, read, then do.

The post maps to a lot of what I’ve learned and witnessed after 16 years at Red Hat. Some of it extends what I’m seeing or sits in tension with the research I’ve been tracking.

Here’s my attempt to sort through it.

In agreement

Build your intuition first.

Will spent 2-10 hours on bounded projects. He calls this “prework.” It’s the most underrated advice in the post. At a recent team f2f, I was upfront with my peers (SWE directors): you yourselves have to spend multiple weekends discovering what your job needs to become. The post echo’d that “In an era of crushing optics, senior leaders immersing themselves in the details is one of our few defenses.”

If you skipped this step throw a 180 – it’s not too late. Folks read about agents, attend demos, approve budgets. Then they’re surprised when adoption stalls. You can’t lead a transformation you don’t understand first-hand.

Continue reading →

6 thoughts on my first AI.engineer CODE + AI Native DevCon

AI.engineer was exceptional. We should crowd-source somehow keeping it the way it is. Larger conferences typically operate at a higher altitude and there is a useful niche for smaller technical events. Recordings here.

I wanted to reflect on some common trends across talks from Stanford, McKinsey, Capital One, Every, Tessl, Human Layer, and others.

But first, 80+ people starred the repo for AgentReady. I bootstrapped that in real-time during AIE.

Since then, I found this tweet acknowledging the need for measuring codebases against up-to-the-minute guidance on what makes a codebase “Agent Ready”.

I’ve since added an align verb that can be used to level-set your repo interactively, or run it headless/CI to prevent drift or implement new techniques as things evolve.

To this point I hadn’t seen a measurement angle on assessing brownfield codebases for introducing agents. People are still figuring it out and it had only just gotten started being discussed in the abstract. Capital One had it nailed during their talk though.

So – we can measure things now, at least relatively. Is it accurate? Claude thinks so. This is an area I would love Issues, PRs or even just discussions on social media.

On to my conference take-aways:

Continue reading →

Agentic Development: A Day in the Life

Re-envisioning what a day in the life of a software engineer looks like going forward in this agentic vision…

We’ve talked about why Ambient Code matters and what it means for your career. So what does your day look like when you’re shepherding code instead of writing it?

The Morning Dashboard (8:00 AM)

You grab coffee. You log into your agentic development platform. You have a custom dashboard/cockpit view that shows (conceptually):

GitHub notifications from overnight
Agentic activity waiting for review
Work blocked on your decisions
Pull requests ready for merge

You’re not staring at an empty editor wondering where to start. You’re reviewing what your agents accomplished while you slept. There’s a button to unblock Claude after you’ve reviewed its work. You review, and work continues.

This is the first waterfall of your day.

Continue reading →

Tokenomics for Code: Value per Token in the Agentic Era

Think about how much will change in the AI landscape during the lifetime of your next application. You can bet on improvements to code generation models, hardware, talent, review capabilities and more. This leads us to the need for a new metrics: something like TCO, but that also represents efficiency. I propose Value Per Token (VPT) as the buy-side equivalent to hyperscaler cost-per-million-token mindset.

VPT = (Business Value Delivered) / (Tokens Consumed)

Cost per token is and was never the real objective. It’s just the lowest common denominator right now, like compute power or memory. The real objective is value per token. If every token you issue does not generate enough business logic, maintainability or architectural clarity, you’re burning budget on noise. This is tokenomics in action.

The primary goal of tokenomics in software engineering is to collapse the costs and friction of the software development lifecycle: spec, iteration, debugging, integration, maintenance…all of it, by orders of magnitude. Let’s say a 1000x reduction in complete SDLC for a product. How do we achieve that when even the most forward thinking companies are settling around 10-30% productivity improvements using GenAI? One way is by lowering our material costs. Both labor and capital. This blog is about the capital side of the problem.

Continue reading →

Sowing the Agentic Brownfield

In the near future, it’s entirely plausible that your entire codebase will be written, refactored, and evolved by AI agents. But the “brownfield” you’ll inherit won’t be legacy human code, it will be legacy AI decisions. And those decisions will stem from choices you make today. For example, whether and when to adopt an AI-first development paradigm, and how to prepare your stack to reach that point.

I believe this shift requires a revival of spec-driven development: a discipline that ensures an agentic brownfield can be safely maintained, evolved, and understood by multiple future generations of engineers and product leaders. The challenges were detailed at the beginning of this video on the c4model. I happen to be preferring this at the moment, but are there are others as widely supported as UML/PlantUML/Mermaid?

Continue reading →