One of the most important things that has become apparent with the current crop of LLMs is that, for the first time in a long time, the fundamental unit of work for software engineers is growing.

One of the key insights from the DevOps movement was that it’s the entire value chain that truly creates value. A line of code can’t provide value until it is deployed for someone to use. How much code can an individual or team write and get into production in a relatively short time frame, say a week? That is the definition of a unit of work.

For most of my life, the class has been the unit of work. Updating or writing a reasonably complex object, whether that represented a database record, a UX component, or an orchestration, was typically the “right” unit of work. A class was the amount of code that could make it through the deployment pipeline quickly. At first, this was technical (shoutout to those who remember linkers!). Even as we transitioned to scripted languages and more automated compilation, the overall change management required in an enterprise system became the bottleneck.

A well structured class change was easy to get through a PR review. The old standard of PRs with fewer than 250 lines spread across a handful of files is another way of describing a well-structured class. Writing tests for a single class is easy to include in continuous integration. Furthermore, a developer can often manually smoke test these changes in a development environment. Finally, smaller changes can be hidden behind a feature flag or deployed safely without one.

LLMs change all of these calculations. Code is no longer a bottleneck at all. Current coding agents can update even the messiest legacy enterprise code bases. Reviewing all of that code could become a bottleneck, but when was the last time you reviewed a binary or container image? In many ways, the actual code will become an executable rather than a product in and of itself.

So what will the new unit of work be? Change management, long the bugbear of current practices, will likely remain the bottleneck. Realistically, we can see the new unit of work to be the next step up from a class. In the backend, this might be the equivalent of a microservice, while redesigning pages might become much more palatable on the front end. The key will likely be isolating the QA process. Within your system, what can you reliably and repeatably test that has value? That is the new bottleneck that will form your organization’s unit of work.

Once you can identify that testing boundary, you can create QA agents to automate the new functional test suite. The QA agent can create traditional bug reports and passing test reports. Since the QA agent operates in a separate context window, the worst hallucinations of the coding agent, such as updating tests for the new code, will be flagged by continued “bug” reports from the QA agent, forming an effective gate. These QA reports also provide a solid artifact for future spec development and an audit trail for the correctness of the newly delivered code.