Effort Inversion: When the Code Is Done Before the Estimate Allows

The Starting Hypothesis

On May 11, 2026, Day Zero of a software project, I formulated an expectation: the actual effort would systematically exceed the estimated effort. At least 30 percent more than the upfront estimate, so the prediction went. The reasoning was classic: experienced developer, a partly unfamiliar tech stack (Tailwind & Vite), plus a workflow with AI tools that had barely been tested in practice. Anyone who has been building software for 27 years knows this pattern. New technologies always cost more than expected.

The hypothesis was wrong. Not slightly off, but wrong in direction.

What Was Measured

The project, a touch-typing trainer called Daktylo, served as the vehicle and experiment for an empirical study of AI-augmented software development. Every coding task was estimated upfront and then measured. The measurement captured the pure coding layer: the time between handing the prompt to Claude Code and the finished commit. The ratio of actual to estimated time yields the effort factor. A factor of 1.0 means the estimate and reality match. A factor of 0.5 means the task was done in half the estimated time.

The estimates came from the concept phase. They were developed in a dialogue with Claude.ai, so AI-assisted themselves, and were calibrated to the experience of a seasoned developer working with a partly unfamiliar stack. Not to the experience of a developer working with an AI agent. That distinction turned out to be decisive.

The Data

Phase 1: Setup (Day 2)

The first two tasks confirmed the hypothesis. Setup work with a partly unfamiliar stack did indeed take longer than estimated. TASK-001 included a serious incident (Claude Code accidentally deleted documentation files and had to be recovered), which drove the factor up.

Phase 2: Infrastructure Established (Day 5-9)

Between Day 2 and Day 5 came the full infrastructure setup: CLAUDE.md, heredoc commit pattern, plan-mode convention, TypeScript strict, Zod validation, Vitest. From TASK-003 onward, not a single factor exceeded 0.5. The trend line was monotonically decreasing: 0.50, 0.50, 0.30, 0.40, 0.20, 0.13, 0.10, 0.06.

TASK-010, the visual keyboard component, was estimated at four hours and was done in fifteen minutes. Factor 0.06. Six percent of the planned time.

Phase 3: Routine (Day 11-15)

Median of these eight tasks: 0.14. The tasks were completed in one-seventh of the estimated time.

Outliers

Two tasks fell clearly outside the pattern:

Both were visual layout tasks where correctness could only be verified by human browser inspection, not through automated tests. TASK-027 also had an undetected dependency. These outliers confirm the rule rather than undermine it: where a human remains in the verification loop, the factor approaches the traditional range.

What Effort Inversion Means

The term “effort inversion” does not merely describe tasks being completed faster than planned. That would be an estimation error. The inversion lies in direction: the starting hypothesis expected overrun (+30%), reality showed underrun of 83-94% with established infrastructure. The sign has flipped, and the deviation is a full order of magnitude from the expectation.

The median factor across all tasks after the setup phase is 0.13-0.17. A task that an experienced developer estimates at two hours is done in 15-20 minutes of coding time, given the following conditions:

1. The infrastructure is in place (TypeScript strict, linting, testing, CI conventions).
2. The prompt is prepared (concept decisions resolved upfront in Claude.ai).
3. The task has a clear specification with acceptance criteria.
4. Verification is automatable (tests, type checking, lint).

What the Data Does Not Show

This is the most important methodological limitation of this finding, and it was not brought in from outside but discovered in the course of the project itself.

The effort factors measure only the coding layer. The time between prompt and commit. They do not measure the total effort of a workday. And the workdays were regularly longer than planned:

Day	Planned End	Actual End
13	8:10 PM	~11:30 PM
14	~6:00 PM	10:45 PM
20	~4:10 PM	~8:05 PM

Where does the saved time go? Into layers that do not appear in the coding estimate.

The concept layer: every coding task begins with a clarification session in Claude.ai. Which architecture? Which API? Which approach? The lowest coding factors (TASK-017: 0.09, TASK-025: 0.11) had the most thorough concept conversations. Concept work is not free; it is just not measured.

The documentation layer: research journal, daily close-outs, concept notes, ADR maintenance, inbox dispatch. In a research project this is expected, but even in an ordinary project there are code reviews, architecture documentation, and knowledge transfer.

The process layer: sync workflows, budget tracking, file management between Claude.ai and Claude Code, session starts, token usage planning. Emergent workflows that extend wall-clock time even as the actual tasks get faster.

The original hypothesis H4 (“P1 underestimates effort by 30%”) turned out to be methodologically underspecified. It asked about the effort without distinguishing which layer was meant. For the coding layer, it is clearly falsified, in the opposite direction. For wall-clock time per day, it may well be confirmed.

This insight led to a split into three more differentiated hypotheses:

H4a (coding layer): Claude.ai systematically overestimates the coding effort for Claude Code. Median factor ~0.15. Clearly confirmed.

H4b (wall-clock time per day): wall-clock time per day regularly exceeds the plan, due to the non-coding layers. Confirmed by data from Days 13, 14, 15, and 20.

H4c (total MVP effort): open. The MVP was published on June 7, 2026, one day before the four-week deadline. Within the timeframe, but without buffer.

What Follows From This

For Estimation

Classical effort estimates, whether they come from humans or from AI systems, are calibrated to the baseline of manual development. In an AI-augmented workflow with established infrastructure, the coding layer is not the bottleneck. Estimates that look only at this layer will systematically come out too high. Estimates that ignore the non-coding layers will systematically come out too low. Both at the same time.

For the Workflow

The lowest effort factor does not correlate with a particular prompt mode (Plan vs. Direct+STOP), but with the quality of the preparation. Tasks where all decisions were resolved before the prompt had the lowest factors. Value creation shifts from the coding layer to the concept layer.

For Research

The phenomenon is weakly documented so far. Most reports on AI-assisted development measure “productivity gains” as a percentage (30% faster, 50% faster). The effort inversion observed here, factors of 0.06-0.21 at the coding layer, is a different order of magnitude. At the same time, the wall-clock data shows that total effort does not decrease in the same proportion. The work does not disappear; it shifts.

Methodology and Limitations

All data comes from a single project (N=1) with a single developer. Transferability is not statistically established and must be assessed through the contextual description: solo developer, 27 years of experience, new stack, two AI tools (Claude.ai for concept work, Claude Code for implementation), React/TypeScript/Vite, four weeks project duration.

The effort factors measure only the coding layer. The estimates come from the same AI environment that also performed the implementation. The estimates were created at the start of the project and deliberately not adjusted, to preserve historical comparability.

The data is part of a research journal with more than 5,700 lines, kept according to the schema “Situation, Expectation, Observation, Surprise” with strict separation of observation and interpretation. The methodological framework draws on Design-Based Research (Brown 1992, Collins 1992) and Reflective Practice (Schön 1983).

This article is based on data from the research project “AI-Augmented Solo Development”, documented on labs.straight8.de since May 2026. The complete dataset, including the research journal, hallucination register, and cycle reviews, will be published as part of the project.

First published: June 28, 2026.