For decades, we have estimated software projects in human time.

Developer-hours.
Developer-days.
Developer-months.
Developer-years.

“This project will take four developers six months.”

That was a natural way to estimate software.

Humans were doing the work, so we measured the work by the amount of human time required to complete it.

Then we translated that time into cost.

But software development is changing.

AI agents are no longer simply suggesting a line of code or answering a developer’s question. They can explore repositories, write and modify code, run tests, use tools, investigate problems, and work asynchronously on tasks. The industry is increasingly moving from developers writing code with AI assistance toward developers orchestrating agents that perform the work.

That creates a problem with the way we estimate projects.

If AI is doing part of the work, human time is no longer the complete measurement of the work.

But measuring AI consumption alone isn’t enough either.

We need a new unit.

The AI Unit

An AI Unit is a unit of work that combines:

AI execution + the human time required to review, validate, and approve the result.

This is an important distinction.

The AI Unit isn’t simply:
“One AI agent working for one day.”

And it isn’t:
“$X of AI consumption.”

Instead, it represents the combined work required to turn AI execution into an accepted result.

That is what makes the unit useful.

Why AI time alone isn’t enough

Imagine two AI agents working on two similar tasks.

Agent A

• 6 hours of AI execution
• 30 minutes of human review

Agent B

• 3 hours of AI execution
• 4 hours of human review

If we only measure AI runtime, Agent B looks much more efficient.

But that isn’t necessarily true from the project’s perspective.

The second agent required considerably more human involvement before its work could be accepted.

The real work wasn’t just the time the AI spent running.

It was:

AI execution + human review.

That is the quantity we actually care about.

The missing part of AI economics

This is one of the things that can be easy to miss when talking about AI cost.

We often look at:

• tokens
• model calls
• inference cost
• compute
• API usage

But there is another cost:

the human watching the AI.

Someone needs to decide what the agent should do.

Someone needs to review its output.

Someone may need to test it.

Someone needs to determine whether the result is actually correct.

Someone may need to send the agent back to fix something.

And eventually, someone needs to approve the result.

Today’s agentic-development tooling already reflects this reality. GitHub’s documentation explicitly says AI code review should be supplemented by careful human review, and Anthropic’s research describes agentic coding as a highly collaborative process in which humans continue to provide judgment and validation.

So when we measure AI work, we shouldn’t pretend that the AI operates independently of the human.

The human is part of the execution loop.

From developer-days to AI Units

Consider how we estimate a traditional project.

4 developers × 6 months
= 24 developer-months

That estimate represents the human work required to deliver the project.

Now imagine an AI-native development team.

The estimate might look more like:

2 developers × 6 months

• 5,000 AI Units

The 2 developers aren’t simply replacing the other two developers.

They may be spending their time:

• defining tasks
• designing architecture
• directing agents
• reviewing results
• resolving exceptions
• making product decisions
• approving changes

Meanwhile, the AI agents are performing a significant portion of the execution.

The project therefore has two different types of capacity:

Human capacity

and

AI-assisted capacity.

But the AI Unit is not “one AI day”

This is where I think the definition needs to be different from simply measuring AI runtime.

Suppose an agent runs for eight hours but produces a result that requires four hours of human correction.

Another agent runs for ten hours and produces a result that requires only 20 minutes of review.

Which one consumed more useful work?

Looking only at AI runtime doesn’t tell us.

Looking only at AI cost doesn’t tell us either.

What matters is the total effort required to get from:

task → AI execution → human validation → accepted result

That entire cycle is the meaningful unit.

So an AI Unit should represent AI-assisted work that reaches an accepted state, including the human effort required to review and approve it.

The output matters

This also changes how we think about AI efficiency.

We shouldn’t optimize AI simply for:

fewer tokens

or:

lower model cost

or even:

less AI runtime.

Those are inputs to the economics.

The actual goal is:

Produce the desired result with the least combined human + AI effort.

This is increasingly reflected in how AI development tools themselves are being optimized.

GitHub recently described its work on coding-agent efficiency in terms of completing tasks effectively rather than simply minimizing token consumption. Its research found that reducing individual outputs doesn’t necessarily reduce the overall work required to complete a task.

That distinction is crucial.

A cheaper AI interaction isn’t necessarily a cheaper piece of software work.

If it causes the developer to spend another hour fixing or reviewing the result, the overall work may have increased.

AI Units measure work. Cost comes afterward.

There is another important distinction.

An AI Unit should not be defined by dollars.

The same way we don’t define a developer-month as a fixed dollar amount, an AI Unit shouldn’t be a fixed amount of AI spending.

Instead:

Work → measured in units

Cost → calculated from the work

For human work:

Human time → human cost

For AI-assisted work:

AI Units → AI cost

The cost of an AI Unit can change dramatically.

Different models have different prices.

Different tasks require different amounts of context.

Agents may use different tools.

Some workflows may require multiple attempts.

Model prices may fall.

Models may become more capable.

Agents may become more efficient.

Therefore, defining the unit directly in dollars would make the unit unstable.

The work unit should describe the work.

The cost model should describe the economics.

The human component is not overhead

This may be the most important part of the idea.

It is tempting to think of human review as overhead added on top of AI work.

But if a human must review and approve the result for the work to be considered complete, that review is part of the work.

Imagine an agent creates a pull request.

The agent has finished its execution.

But the software engineer hasn’t finished the task.

The engineer still needs to determine:

• Is this what we asked for?
• Is the implementation correct?
• Did the agent introduce a security problem?
• Did it break something else?
• Are the tests sufficient?
• Is the architecture appropriate?
• Can we actually ship this?

Only after that process is complete do we have an accepted result.

So the human review isn’t merely an administrative step.

It is part of the unit of work.

AI Units change the project estimate

This leads to a new way of thinking about project estimation.

Traditional software:

Project Work = Human Time

AI-assisted software:

Project Work = Human Time + AI-assisted Work

And AI-assisted work can be represented by:

AI Units = AI execution + required human review/approval

This gives us a richer project estimate.

For example:

Traditional estimate

24 developer-months

AI-native estimate

10 developer-months + 8,000 AI Units

The second estimate tells us something the first one cannot.

It tells us that the project is expected to require both human capacity and AI-assisted execution capacity.

The human-to-AI ratio becomes interesting

Once AI Units are measurable, we can begin asking new questions.

How much human time does an AI Unit require?

Which types of tasks require the most human review?

Which models produce work that requires the least correction?

Which agents can operate with minimal supervision?

Where are developers spending time reviewing AI rather than creating directly?

And perhaps the most important question:

Is the amount of human work required per AI Unit going down?

If it does, AI becomes increasingly autonomous.

Imagine a project initially requiring:

10 developer-months

• 1,000 AI Units

Later, perhaps the same type of project requires:

6 developer-months

• 10,000 AI Units

And eventually:

3 developer-months

• 50,000 AI Units

The numbers themselves aren’t the point.

The important change is the distribution of work between humans and AI.

More execution moves to machines.

Humans increasingly provide direction, judgment, validation, and accountability.

This is more than a developer productivity metric

For the last few years, much of the AI conversation has focused on developer productivity.

Are developers 20% faster?

Are they 2× faster?

How many lines of code can they generate?

How many hours can AI save?

Those measurements are useful, but they assume the developer remains the fundamental unit of work.

Agentic development challenges that assumption.

If a developer can orchestrate several agents working in parallel, the important question isn’t necessarily how much faster that developer types.

It is:

How much total work can this human + AI system complete?

That is a different measurement problem.

From headcount to work capacity

For decades, engineering capacity was closely tied to headcount.

If you needed more capacity, you hired more developers.

With agents, capacity becomes more elastic.

A developer can potentially orchestrate multiple agents.

Multiple agents can work in parallel.

Agents can work asynchronously.

And agents can operate outside normal human working hours.

This doesn’t make human capacity irrelevant.

It changes the relationship between human capacity and execution capacity.

The engineering organization increasingly becomes a combination of:

Human judgment + AI execution.

And AI Units give us a way to begin measuring that second component.

The next generation of project planning

Eventually, project planning may stop looking primarily like:

12 developers
18 months

and start looking more like:

Human capacity: 8 developer-months
AI capacity: 15,000 AI Units
Expected review ratio: 12% human time per AI Unit

That gives engineering leaders a completely different view of their organization.

They can ask:

How much AI capacity are we actually using?

How much human capacity is being consumed by AI supervision?

Where are agents generating valuable work?

Where are they creating additional review burden?

Which models and workflows produce the best combined outcome?

And, critically:

Where is AI actually reducing total work rather than simply moving work from writing to reviewing?

The AI Unit is not about replacing the developer

This isn’t an argument that human time is going away.

Quite the opposite.

The more capable agents become, the more important it may become to measure the human effort required to direct and validate them.

The goal isn’t:

AI instead of humans.

It is:

AI + humans as a combined system.

The unit should reflect that reality.

From Developer-Years to AI Units

Software has historically been measured in human time because humans performed the work.

Now AI agents are becoming active participants in software development.

They can execute tasks, use tools, modify code, run tests, and work asynchronously. At the same time, organizations are developing new approaches to human oversight, approval, monitoring, and governance.

That means the old measurement is becoming incomplete.

We don’t need to abandon developer-days or developer-months.

We need another dimension.

Human Time measures the work performed directly by people.

AI Units measure the combined AI execution and human effort required to turn that execution into an accepted result.

And underneath both sits the economic model that translates work into cost.

The fundamental shift is simple:

We used to estimate software by how much human time it would take.

We may increasingly estimate it by how much human time and AI-assisted work it will take.

The future project estimate may therefore look less like:

Developer-years

and more like:

Human Time + AI Units

The AI Unit isn’t a measure of tokens.

It isn’t a measure of dollars.

It isn’t a claim that AI can replace a developer-day.

It is a way to measure the combined work required when humans and AI build software together.