Your Engineers Are Compute -Constrained. Why Aren’t You Doing Anything About It?
We buy our engineers the highest-end MacBook Pros we can, with 128gigs of RAM and 2 TB of disk. They used to cost about $5,000 each; now they are closer to $7,000. In the preagentive world that was a box that engineers loved to have and they never tested the limits of.
Now they are hitting their limits. CPU and disk, primarily.
Our engineers are running multiple coding agents, building software, and executing tests. Several streams of work compete for the resources of a machine assigned to one person. That is a server-class load on a consumer-class device.
That raises a question beyond the next hardware purchase. If machines at this level are becoming a constraint, we need to revisit how we decide what capacity to give the people building our software.
The conventional provisioning model is straightforward. Give each engineer a computer. Choose specifications, establish a replacement cycle, and handle exceptions when somebody needs more. Capacity follows headcount. Once everyone has a sufficiently powerful machine, the provisioning problem is considered solved.
That model embeds an assumption about how development works: the amount of useful computation one engineer can initiate is reasonably bounded by the capacity of one workstation.
Agentic development puts pressure on that assumption.
An engineer can initiate work, leave an agent executing it, and move on to another task. Each additional stream needs somewhere to run commands, build software, and execute tests. It needs working files, dependencies, and space for the things those tools produce. Even when the model itself runs remotely, the work it directs still needs an execution environment.
The amount of computational work that an engineer can set in motion can grow substantially without any change in headcount.
Parallel builds, automated tests, and overloaded developer machines have existed for years. Shared build infrastructure is hardly a new idea. What deserves renewed attention is the relationship between one engineer and the amount of compute they can productively use.
We are changing how much work an engineer can initiate without necessarily changing how we provision the capacity to execute it.
At Whitepages, we are designing a transition to lightweight client laptops, with a planning target of about $1,200 each, paired with persistent 96-core ARM servers. We are choosing ARM so the developer’s environment can produce native builds for production. Agent sessions, repository checkouts, builds, and tests run together on that execution host. The laptop becomes the interface to the work, which can continue when it disconnects. Existing laptops stay in service until their normal replacement time.
That hardware decision is paired with a redesign of CI. We are moving the required check phase into Nix, our build system. The design ties those checks to the build: an artifact can be signed and published to the trusted binary cache only after its required checks succeed. That gives us a production artifact with evidence we can use throughout the delivery process.
CI then becomes a policy check against that exact artifact and its evidence. It does not compile the artifact again or rerun its tests. Matching inputs allow developers and CI to reuse the existing output; changed inputs require the affected build and checks to run again in the development environment. The intended result is a quick policy decision in CI, with the expensive execution already completed where the engineer and agents are working.
Shorter PR cycle times are part of the reason to make this investment. The same architecture gives agents room to execute and removes repeated build-and-test work from the PR path. If we increased agent output while leaving those queues intact, we would only be feeding the bottleneck faster. The compute expansion and the CI redesign have to work together.
For years, engineering leaders have had good reasons to focus on people and organizational constraints. Unclear priorities, excessive dependencies, poor architecture, and slow decisions can consume far more delivery capacity than an underpowered computer. A faster workstation does very little for a team waiting three weeks for somebody to decide what it should build.
Those problems remain. Agentic development adds another variable to the system. When engineers can direct several useful streams of execution, compute deserves another look as a potential constraint on delivery.
Beyond a baseline that lets an engineer work comfortably, extra workstation capacity may once have produced little measurable benefit. Agentic development changes that calculation. When one engineer can keep multiple builds, tests, and coding agents running at the same time, the machine becomes a shared execution environment for several streams of work. A hardware standard that was generous when one person performed each task directly can become the bottleneck when that same person is directing several tasks in parallel.
There is an aspect of industrial production in this. A person’s productive capacity depends partly on the equipment available to them and on how effectively the surrounding operation can use its output. Improving the equipment can allow the same people to accomplish more, provided the rest of the system can absorb the work.
Software has always had this relationship with tools. Agentic development may change how much additional execution capacity is worth purchasing. An engineer who can define, supervise, and integrate several pieces of work may be able to use substantially more compute than an engineer carrying out each piece directly.
That creates an investment question: how much additional delivery capacity could we obtain by changing compute, builds, and validation together, and what would it cost?
The answer could be financially significant even when the improvement is modest. We already commit substantial money to employing a capable engineering team. Additional compute can be a comparatively small expense. If it allows that team to complete useful work sooner, it deserves to compete for funding on that basis.
The cost comparison has to include the whole arrangement: hardware or rental charges, model usage, storage, the people operating the environment, and the disruption involved in changing how engineers work. A cheap server that requires constant attention can be an expensive development environment.
In our model, cheaper future laptop replacements and reduced hosted CI charges are separate sources of savings. They have to be weighed against the new infrastructure and its operating costs. Savings arrive as replacements are avoided and duplicate work disappears. The $5,000 laptops we already own are a sunk cost; moving work off them does not recover their purchase price.
This is where our organizational habits can get in the way.
Hardware spending is visible. It has a purchase order, a budget owner, and a number somebody can reduce. The cost of engineers adapting their work to inadequate capacity is harder to see. It may appear as longer feedback cycles, work that gets postponed, or time spent managing the environment instead of advancing the product.
When procurement is evaluated on cost per employee and engineering is evaluated on delivery, the two functions can make locally reasonable decisions that work against each other. The laptop meets the approved specification. The hardware budget looks disciplined. The engineering team absorbs the constraint.
An engineer who learns to work around a limit can make that limit less visible. They may run fewer tasks at once, defer an expensive test, or spend time clearing space. The machine becomes manageable because the person has adjusted the workload to fit it.
A quiet workstation, by itself, tells us very little about whether we have supplied enough capacity. We also need to understand the work people have learned to avoid starting.
That is why compute allocation belongs in the engineering leadership conversation. IT can procure and operate the equipment. Engineering leadership has to connect the capacity decision to how work gets delivered.
There is an equally important trap on the other side: mistaking computational activity for productive work.
A saturated CPU establishes that a machine is busy. An engineer can spin up three coding agents that thrash the disk, duplicate effort, and generate changes requiring hours of human scrutiny. Give that workload a bigger server, and it can produce the same problem faster.
Automated review complements this build-and-check path. Terminal-native review bots can inspect changes, use the existing check results, flag likely defects, and return findings to the coding agent before asking a person to review. That keeps the initial feedback close to the work. The point is to reduce the human effort needed to reach a sound decision. More bot comments are useful only if they help do that.
Human reviewers still have to judge whether the change meets the requirement, fits the architecture, and introduces acceptable risk. Automated review must earn its place by reducing that burden and catching problems earlier. Fast CI and faster agent execution only improve delivery if the team can assess and integrate the resulting changes. PR cycle time, human review effort, and rework belong beside build time in the investment case.
The objective is to remove compute as an artificial constraint on engineering throughput while shortening the path from a change to production. That requires treating execution capacity, validation, and review as parts of the same system.
Our proposed first step is a single rented ARM server for a 30-day pilot with two engineers. They would run their actual concurrent workloads through lightweight clients, produce production artifacts with the required Nix checks, and exercise the trusted cache and policy-only CI path. We would measure PR cycle time as well as the full time from starting work to delivery, so moving a wait earlier cannot masquerade as progress. Build feedback, human review effort, rework, defects, and actual hosted CI charges complete the comparison.
We should also look at the team around those engineers. An individual may complete tasks faster while shifting additional work onto colleagues. The investment has to improve the delivery system as a whole.
If additional capacity produces little benefit, that is useful information. The constraint may be elsewhere, or the workload may need improvement before expansion makes sense. If it produces a worthwhile benefit, we have a basis for investing further. As the constraint moves, the next investment may belong in a different part of the system.
I keep coming back to a question for CTOs: why do we scrutinize the cost and utilization of production infrastructure while giving the computational capacity available to our engineers so little sustained attention?
Run a 30-day pilot of your own. Choose a small group whose work is visibly constrained and establish a baseline across development, CI, and review. Give them an execution environment with enough capacity to test the difference, then test how validated artifacts can move through the rest of the delivery process without repeating work. Use an ordinary client laptop so the experiment also tests whether execution capacity can be separated from the device on the desk.
Before the pilot starts, price the whole arrangement and decide what improvement would justify it. Include the engineering effort required to build and operate the environment. Model future laptop purchases and avoidable CI charges separately, with realistic timing. Those costs belong in the calculation alongside server rental, storage, and model usage.
At the end, compare the cost with what the team delivered, the time from starting work to delivery, PR cycle times, and the review and rework required along the way. Use that evidence to decide whether to expand the capacity, change the workflow, or invest elsewhere.
Before you approve the next round of developer laptops, find out how much useful work the current arrangement is preventing. Run the pilot, measure the effect on delivery, and fund the capacity the evidence supports.
