Development Was Never About Coding

A few years ago, at a hackathon, my then-CTO Per Åsberg and I skipped building a feature and instead pulled data. We exported time reports, combined them with task tracking data, and added survey answers from developers about how they actually spent their days. The goal was to understand what developers in an agile R&D team really do with their time.

The punchline: time spent writing code that actually made it to production and created user value was around 10% of working hours. I've since looked at external research from Sweden, the Nordics, and the broader Western world, and the numbers line up surprisingly well. Let me walk through how we broke it down.

The concentric circles of developer time

We modeled developer time as concentric circles, moving from the outside in, each layer eating into what's available for the next.

Being an employee in Sweden. A full-time employee here typically gets 30 days of paid vacation (standard in IT) and around 11 public holidays that remove about 9 working days. That leaves roughly 221 actual workdays, or 1,768 hours if you count 8-hour days. Before anyone touches a keyboard, vacation and public holidays have taken 15% of working days. Include weekends and you're working about 20% of the hours in a year.

Being in an office. From those remaining days, lunch breaks, short breaks, and informal admin nibble away at time. Internal communication is a big one: studies show knowledge workers spend several hours per week just on email and chat, and context switching reduces effective focus time further. It's reasonable to say 10-15% of work time disappears into general office overhead, leaving roughly 85-90% of gross working time as structured work time.

Being in an agile process. In a typical Scrum setup with two-week sprints you have daily standups, sprint planning, backlog refinement, sprint review, and retrospectives. Research and practical breakdowns put this at 15-20% of a developer's time, and that doesn't include ad hoc syncs, stakeholder meetings, or coordination. Smoothing this together with the office overhead, we're at roughly 70% of original working time available for actual engineering work.

Being a developer. Now we get to what most people think of as "development." Multiple studies over the last decade show that of the time available for engineering work, around 10-20% is spent writing new code, 20-40% goes to debugging and fixing issues, 10-15% to writing tests, and a big chunk (25-35%) goes to reading documentation, understanding requirements, and navigating existing code. The rest is collaboration, code review, CI/CD, deployment, and similar. Taking midpoints, active hands-on coding (writing, debugging, testing) accounts for roughly half of engineering time, or about 35% of total working time.

The innermost circle: code that reaches production and creates value. Even inside "coding time," not everything survives. There are throwaway experiments, spikes, refactors that get reverted, features that never ship, and code that gets replaced before release. When we narrowed it down to lines written that passed review, were deployed, were actually used, and created user impact, roughly a quarter to a third of hands-on coding work survived. Applied to our 35%, that puts value-creating code at roughly 10% of total working time, or about 2% of the calendar year.

What this means for AI

So roughly 35% of a developer's working time goes to hands-on implementation: writing new code, debugging, testing, and refactoring. That is where AI coding tools hit hardest, but not uniformly. AI doesn't make all coding 30% faster. It makes some tasks, like generating boilerplate, writing test cases, and routine refactoring, one or two magnitudes faster, not including parallelization. In some cases it can run those tasks unattended, continuously, at a scale that has nothing to do with your headcount.

The useful question for a CTO isn't "how much more efficient are my developers now?" It's "how much of that 35% can I decouple from human hours entirely, and what do I need in place to absorb the output?" That second part is where most organizations stall, because it requires organizational work, not just tooling. You need to separate mechanical implementation from work that requires human judgment. You need architecture and test coverage structured so that AI output is easy to validate. You need to treat AI capacity as a continuous software factory rather than a faster pair of hands, and you need to redirect developer time toward system design, prioritization, and quality gates.

The other 65% of developer time (the meetings, the reading, the coordination, the judgment calls) doesn't go away. If anything it becomes more important, because it's now the bottleneck. If your developers are still manually writing boilerplate, manually creating repetitive tests, and manually handling routine refactors, that's an organizational choice, and it's an expensive one.

The hackathon exercise showed that coding was never the majority of the job. AI doesn't change that. But a human developer delivers value-creating code roughly 2% of their calendar year. An AI system can do that same type of mechanical work 100% of the year. The question is no longer how to make developers faster. It's how to find the right ratio between human and machine effort, and how to organize the work so both deliver maximum value. That's not a tooling decision, it's a leadership one.

(Thanks to David Hesselbom for meme image, and calling out the unnecessary airiness of a previous version.)