The Mastery Question

I’ve been thinking about what it means to master software engineering in an era where AI is writing more and more of the code. I’ve read articles on the topic and had the concern raised on my team at Caribou. The concern is rational. Agents can implement features now. They generate idiomatic code and tests faster than you can type them. So what exactly are you the master of? That’s a fair question, and it deserves a real answer, not reassurance.

This isn’t the first time our craft has done this to itself.

Before compilers, developers decided everything: register assignment, memory layout, and calling conventions. The compiler took those decisions away, and it felt like losing something real. What actually happened was that the decisions moved up a level. The mastery relocated.

We did it again in web development, and many of you lived through it.

Before frameworks like Rails and Spring MVC, building a web application meant deciding everything yourself: routing, session management, database connection handling, and how HTTP requests mapped to code. Every codebase was a unique artifact because every team made those decisions differently, and differently usually meant inconsistently.

Rails and Spring MVC emerged around the same time and solved the same problem in the same way: Convention over configuration. The framework took these decisions away: URL structure, where models live, how database tables map to objects, and what a form submission does. The criticism was immediate, and it came from experienced developers. Developers won’t understand what’s happening underneath. ActiveRecord produces bad SQL. The magic hides the real work. Some of that was true at the edges. ActiveRecord does produce bad SQL sometimes. Developers who never looked under the hood struggled when abstractions leaked. The criticism wasn’t entirely wrong.

But look at what people built. GitHub. Shopify. Stripe. Built faster because Rails made the scaffolding decisions, and engineers put their energy into something harder.

The developers who thrived weren’t the ones who knew the framework least. They were the ones who knew it deeply enough to reason about it, debug it, and override it when the situation called for it. The abstraction didn’t reduce their mastery. 

The mastery relocated. 

That’s what’s happening now. There's a skill that used to be secondary and is now becoming central: the ability to decompose a problem and specify a solution precisely enough for an agent to execute it, then evaluate whether the result is actually correct. That's not prompt engineering. It's the engineering discipline of thinking clearly and communicating technically with precision. 

We expected these skills from staff engineers; now we expect them from everyone to some degree. If you're earlier in your career, you might be wondering how you develop those skills if the agent is doing the work you were supposed to learn from. Here's what I'd say: the learning isn't gone, the shape of it changed. Read what the agent produces. Ask every question you have about why it made the choices it did. Catch the mistakes before your reviewer does. That's not skipping the reps. That's the new version of the reps, and engaged engineers will build judgment faster this way, not slower.

Software architecture, algorithms, patterns, performance reasoning, and knowing when the generated code is subtly wrong: none of that is going away. Mastery of specific syntax constructs matters less. The judgment about what to build, how to structure it, and whether the result is correct matters more than ever.

The engineers who will struggle are the ones who treat the agent as magic they don’t need to understand, the same ones who treated ActiveRecord as magic in 2006. The engineers who will do the best work of their careers are the ones who engage with AI tooling the way a senior Rails developer engages with the framework: knowing enough about what's underneath to direct it with precision, override it with confidence, and build things with it that wouldn't have been possible before. That's the mastery that's available right now. It's different than what it was. It's not smaller. This is what I'm building our engineering organization around: clear opportunities to develop this kind of mastery, and clear expectations at every level for what it looks like. We're not protecting the old work from AI; we're getting serious about where the mastery is now.