I recently learned about a term for the extra time/efficiency you gain from automation: a productivity dividend. While the dust hasn’t settled on just how much more productive using coding agents makes engineers, it’s clear that at least for producing, investigating, and optimizing code, the dividend is nonzero. A natural question is where to spend it.

The most obvious way to spend the dividend is to ship more. You can view vibe coding through this lens: if you use a coding agent and it reduces your time to produce a feature by X%, vibe coding is when you take all of that X% and apply it to adding another feature to your project. Using some of your dividend to ship additional features is reasonable, but there are other ways to use the time that might help you move even faster and more confidently in the long run.

Here’s a collection of other ways to reinvest your productivity dividend:

  • Understanding. Prior to agentic coding, one of the engineers on our team was entirely dedicated to marketing frontend/website updates. With help from agents (and code review, which we still do), they’ve now shipped multiple full-stack experiments and backend migrations. On each of these new-to-them PRs, they took extra time to read the code, ask the agent about various constructs they weren’t familiar with, and explore that part of the codebase more to help their own understanding. I can’t attribute success on these projects to agents or code review or the persistence of an individual alone. Still, I’m confident that without an agent, we wouldn’t have considered assigning this many unfamiliar projects to the engineer this quickly, and that the engineer wouldn’t have had the time to dig in and understand what was going on. Taking the time to understand extends to all levels of experience: I’ve spoken with multiple engineers inside and outside of B12 who, when faced with an agent-generated PR, ask an agent to draw an architecture diagram or otherwise explain the solution. Slowing down to gain a better understanding is a way to spend some of your dividend with an eye on the long term.
  • Research. Before starting numerous security and infrastructure projects, and before contributing to parts of the codebase I haven’t touched before or in a while, I’ve asked agents to offer multiple approaches to solving a problem, read more about each path on my own, and then steered agents toward the implementation that made the most sense for my project. As a concrete example, I hadn’t implemented OAuth 2.0 before adding it to ayb, so I had an agent explain the space to me and learned about PKCE through its suggestion. I then read more to vet that it was a good application of the technique, and had an agent implement the first version.
  • Ensuring quality. Part of the critique of agentic coding is that writing code is only a fraction of the time it takes to practice software engineering. At least historically for me, ensuring the quality of my implementation has been another big aspect of the job. Now you can build tools to make this process more effective. We recently introduced a /product-review skill at B12 that looks at a PR, identifies the portion of the product experience that’s being updated, creates a QA checklist for itself (with input, if you provide it), and records a labeled video of itself clicking through the checklist. For many bread-and-butter product features, it’s now possible to open up the agent-generated QA report and videos without having to spin the environment up for manual testing yourself. (The skill requires a bit of finesse to make the videos human-palatable: we use agent-browser to explore the experience at slow agent speeds, then have the agent write and run a Playwright script to make the video play without long agentic pauses. If it would help to publish this skill, let me know.)
  • Improving your workflow. Beyond tooling to make it easier to QA our product, we’ve rolled out other mechanisms to make our workflows more efficient. As an example, anyone who has deployed an agent in a product knows that you rack up examples of users who had awkward interactions with the agent. To help us improve our agent in these situations, we’ve built interfaces for evaluating how our agent performs in various scenarios, making it easier to capture when users run into a bad interaction, turn that into an evaluation example, and optimize our prompts/implementation to prevent such cases in the future. We’ve also been building a Slack bot called Loopsie that teams use to triage errors flagged by Sentry or our support team, write up plans/build prototypes of product features given some user stories, and even write a draft PR to address some of these issues.
  • Paying down tech debt. Triage and address the Sentry exception backlog. Delete the old experiment code that’s littering your onboarding flow. Revisit the part of your experience in which adding a feature generally introduces a bug. I don’t have anything magical to say about why paying down tech debt is good (sometimes), but every engineer can relate to the fact that paying it down often takes a back seat to some other time-sensitive task. Now you can have an agent working on your team’s biggest area of debt in the background, and when you free up between projects you can poke in and steer it around. The cost of paying down debt has gone down, and you’ve found some extra free time on your other projects, so clean things up to make future features safer and easier to ship!
  • Maintenance. Version bumps used to be the bane of our existence. Package updates, language and framework updates, and operating system updates all required navigating some level of annoying dependency hell followed by repeated rounds of thorough automated and manual testing to make sure our key flows still worked. Understandably, we’d delay them. Agents don’t absolve us of the responsibility to test, but it’s far more palatable to work with an agent to expand our end-to-end tests, have it click through the experience with a browser for added testing, and have it iterate on the inevitable cascade of version updates before an engineer needs to look at it.
  • Optimization. What’s the slowest part of your users’ experience, or the slowest/flakiest part of your engineers’ experience? Send an agent off to collect traces and propose optimizations. It’s pretty rewarding to see users and teammates enjoy snappier interfaces, CI, and deploys.
  • Small experience improvements. If a human is involved in shipping a feature or improvement, there’s some overhead to doing the work: some git setup and teardown, some review, some QA, some GitHub navigation. As a result, every team has some easy tasks that don’t get done because of the friction/overhead involved in the work. You can use some time freed up by agentic coding to ship delightful little improvements to the experience. I put this bullet last because “you can use some time to ship more little things” is almost tautological if you do it naively. But with the help of some of the previous bullets, you can do better than that. If you show up to a PR that an agent automatically opened up due to some user feedback, and the tests on the PR ran fast, and an agentic product reviewer recorded a video of itself walking through the relevant part of the experience, then you’re a small code/product review away from clicking merge. So you likely should use some of your AI productivity dividend on previous bullets before this one, and I bet you’ll find it easier to ship small improvements that have a big impact.

I felt a little funny writing this post, because in some ways it reads like an “if engineers have more time, here’s how they can spend it” laundry list that could have predated agentic coding. But I think it goes farther than that: even with some extra time in the pre-agent world, it might still have been too big a time sink to pay down debt or manually QA a change you introduced, leaving less opportunity to spend your dividend in diverse ways. So it’s less “here’s how to spend your time” and more “how to spend your time in ways that previously still wouldn’t have been sensible but totally are today.” Agents also turn some of what used to be a byproduct of work into a deliberate investment: when every line of code was written by a human, someone on your team had no choice but to understand it. Today, they have to make that choice.

One thing that hasn’t changed compared to the pre-agent world is that these investments compound: making QA faster or having an agent take a first stab at triaging and implementing tiny fixes means you can focus more on researching/planning/better understanding big problems facing your users, which will lead to better features down the line. It’s a strange time to be an engineer, but it’s comforting to know you can use the extra time the agents gave you to make a more pleasant experience for your users and your team.