What Does Productivity Mean in the Agentic Age?

With everything going on in AI and in the industry right now, it feels like we're all getting a little bit crazy, and obviously this is an industry and life-changing period in time. And while many of us are being 10x productive because we can produce more code than ever, we're treating these new capabilities as just faster horses, keeping our existing ways of working, ceremonies and tools.

I want to share my observations on common pressures that I hear people mention when we're discussing what's going on right now.

It's been almost a year since the last time that I wrote a line of actual code myself, and this alone is a landmark because I spent an entire career honing that craft. And talking to my friends and others in the industry, I'm not the only one, and yet, we seem to be busier than ever. We're incredibly productive and it seems the business has developed a voracious appetite for even more features and functionality. The appetite was always there, but it was curbed by the fact that if you wanted to make it go faster, you'd have to hire more engineers.

More engineers meant more managers and other people, and more people came with communication breakdown and a need for an effective distribution of labor. Now that we are no longer limited to the time we can spend typing code on a keyboard to deliver, I think we're getting much more exposed to the pressures from the business, because every time we present a new piece of software or feature, the question is when the next one will arrive. And our reward having always been to "deliver the thing", we feel responsible for producing even more. After all, they've given us these incredible tools, so we should use them, right?

But with the faster delivery cycles we also stop building up the metacognition that we gain over time as we work on a problem for a longer period.

When you're actively participating by typing actual code, drawing on a whiteboard or scribbling notes on a college block during a lecture, your brain and body work together to store and process the information. This embodied cognition is exactly what allows us to build intuition and deep understanding of what we're actually trying to build and how it all fits together.

The loss of metacognition doesn't hit everybody equally hard: if you have a lot of practice in taking high level ideas into actual implementation, you might not need to know exactly how the code is written and structured. But like any good architect in the real world, you still need to understand the physical properties of brick and mortar. And while architecture builds on millennia of knowledge, two decades of experience in software development has seen more churn than two centuries of brick laying in Dutch housing.

When I was a junior I joked that I was lucky if I got more than six hours of work done in the day. I thought I was pretty daring to admit I didn't put in the full eight on coding. As a principal, later in life, I knew I was lucky if I was able to dedicate more than 20% of my entire time getting "work done". At this point I think I can output that entire 20% of productivity in 10% of the wall-clock hours it used to take me - so if I'd managed to get eight hours of coding done in a week, it also meant I was spending 36 hours on other stuff.

We've gone from two week sprints to almost daily sprints. But why did we do two week sprints in the first place? For me it was about the ratio between productive time and overhead. A two week sprint gets you 10 standups that ran over time, 4 hours of sprint planning, a weekly check-in and a bi-weekly demo. That's 20% of the time spent on reporting and preparation.

Among engineers, there were several hours of 1:1s, whiteboarding sessions, document reviewing, debating and discussing. We might spend an extra half hour after lunch bragging about the latest achievement or sharing a bit of knowledge that we had just gained. I think that in an average engineering team, if you were able to spend 20 hours a week on actual coding work, you would probably be in a highly productive, extremely efficient environment.

If we assume we continue to do the rest of our work as before, still need several hours to plan our work, are still spending time on the dailies and still want to actually demo and receive feedback on what we deliver, would it be crazy to think we spend at least three hours on those activities for every hour of prompting?

I don't actually think we want to embrace this much overhead. 6 hours of prep and processing for 2 hours of productivity. I became an engineer in the first place because I like my quiet time and I like my focus.

So we have to change the way of working once more. When I started out in software, in one of my first jobs, I spent the first weeks drafting functional requirements, building user experience flows, exploring and piecing together the architectural bits and pieces I would use. Even within a stack that was largely a given, that still took up a lot of time. And by the time I was finished, I had my work cut out, chopped up into focus blocks, and we were off to the races. This process was called waterfall.

The entire industry now collectively rolls their eyes. We later embraced Kanban and Scrum in an attempt to deliver faster, more frequently and more reliably. To be honest, I was never a fan of all that grooming and overhead, but what I liked about it was the ability to deliver fast.

I think as engineers we would do good by taking more ownership over the product details so that we can support product managers instead of product managers supporting us. Product managers, UX design, they've all become the new bottlenecks for engineering teams. They're the ones getting overworked as engineers demand more work, more feedback, more input for their agents. We cannot delegate the responsibility of delivering good software to AI or other people. And I think we need to go back to some sort of waterfalling. So spend that time up front thinking, debating, deliberating, talking about what you're going to build. And then once you find that focus time, include time to review, test and debate what you've just built.

Well written architecture documents, clear specifications and requirements and high level domain modeling (Shift left!) are the way to produce clean software with agents and allowing humans to still understand it. Agile always allowed time to work on technical debt. Now that we're able to create technical debt at a faster pace than ever, we really need to invest in preventing the slop.

Rather than focusing on one feature after another, I think we need to focus on raising the bar for quality and alignment, and take the time to process what is done. You can delegate the coding to agents, but you cannot delegate learning and understanding, or teaching, for that matter.