{"course":{"slug":"how-software-changed","title":"How Software Development Changed","url":"https://addaly.com/learn/how-software-changed","level":"intermediate","track":"work"},"lesson":{"slug":"the-cost-curve-moved","title":"The cost curve moved, but only part of it","url":"https://addaly.com/learn/how-software-changed/the-cost-curve-moved","position":1,"of":87,"minutes":8,"answer":"Generating code got cheap; deciding what to build and confirming it is right did not.","keyIdea":"Generating code got cheap; deciding what to build and confirming it is right did not."},"body":{"format":"markdown","text":"## What actually got cheaper\n\nA working first draft of a well-specified function is now close to free. Parsing a CSV with awkward quoting. A paginated list endpoint. Converting a callback-based class to promises. Writing fixtures for a test. Adding a migration. That work used to cost somewhere between twenty minutes and a day. It now costs roughly as long as it takes you to describe it and read the result.\n\nThat is a real change, and not a small one. But notice how narrow the claim is. It holds where you already know exactly what you want, the shape of the solution is common, and correctness is easy to check.\n\n## What did not get cheaper\n\nNone of this moved much:\n\n- Deciding what to build, and for whom\n- Knowing whether the thing you got back is right\n- Integrating it with everything that already exists\n- Operating it at 3am when it fails\n- Getting five people to agree on one interface\n- Understanding a system well enough to change it safely\n\nThese were always the expensive parts. They were just harder to see, because typing was expensive too, and typing was the visible activity.\n\n## The arithmetic that people skip\n\nSuppose your engineers spend about a third of their working week actually writing code. Estimates vary a lot by team and by study, so treat that as a rough figure, not a fact about you. Now make that third three times faster.\n\nYou have removed about 22% of the week. Not 60%. Not 10x. And you have removed it from the stage of the pipeline that was never the queue.\n\n> Figure: A forty-hour week, and the stage that got faster. Bars (hours in a forty-hour week): Figuring out what to build 8; Writing code 13; Verifying and reviewing 9; Meetings, operations, waiting 10. Make the highlighted stage three times faster and about nine hours leave the week, which is roughly 22 per cent. The other thirty hours are untouched, and the queue is in one of them.\n\nThis is the old lesson about optimising the wrong part of the system. If code review takes four days because reviewers are busy, and you now produce three times as many diffs, review takes longer, not shorter. You did not speed up delivery. You built a bigger pile in front of the same door.\n\n## The evidence is mixed, and you should know that\n\nTwo things are both true and they get quoted selectively.\n\nOn greenfield work, unfamiliar languages, boilerplate-heavy tasks, and one-off scripts, the gains are large and easy to feel. People who write a lot of glue code, or who work across many stacks, are not imagining it.\n\nOn mature codebases that you know well, the picture is murkier. A widely-discussed 2025 randomised trial had experienced open-source maintainers work on issues in their own repositories, with and without AI assistance. They finished roughly 19% slower with it. They believed they had been about 20% faster. The sample was small, the participants were unusually expert, and the tooling has changed since. Do not treat it as the final word. But the gap between felt speed and measured speed is the finding that keeps replicating in less formal settings, and it should make you cautious about your own impressions.\n\nBoth results can hold. Speed comes from not having to know things. In a codebase you already know, there is less not-knowing to buy your way out of, and more cost in checking output against context the model does not have.\n\n## Where the constraint went\n\nThe useful mental model is a factory with two stations: production and inspection. Production got much faster. Inspection did not. Every unit still has to pass through a human who understands the system, and that human's throughput is roughly what it was in 2022.\n\nSo the constraint moved from *making the thing* to *confirming the thing*. Almost every other lesson in this course is a consequence of that one sentence.\n\nThis is why teams that adopt these tools and change nothing else often see more activity and the same delivery. Commits are up, pull requests are up, everybody feels productive, and lead time is flat. The measurement that matters is not how much code you produced. It is how much verified, integrated, working change reached users, and how often it had to be rolled back.\n\n## Try this\n\nFor one week, tag your working hours into four buckets: figuring out what to build, writing, verifying and reviewing, and everything else (meetings, operations, waiting). Do it roughly. Half-hour granularity is fine.\n\nMost people are surprised. If writing is 20% of your week, then the tool that makes writing free has a ceiling of 20% on you, and the honest question is what to do about the other 80%."},"check":{"question":"Your team's engineers spend about 30% of their week writing code. A new tool makes that part roughly three times faster, and everyone adopts it. Six months on, commits per week have nearly doubled and delivery time for a typical feature is unchanged. What is the most likely explanation?","options":[{"text":"Writing was not the constraint. The queue is in review, decisions and integration, and those got no faster, arguably slower, with more diffs arriving.","correct":true},{"text":"The team has not learned to use the tool well. With better prompting and more practice, the delivery gains will show up.","correct":false,"tempting":"Assumes the gap is skill with the tool, when the arithmetic caps the possible gain at about a fifth of the week before skill enters the picture."},{"text":"Delivery time is a lagging measure. The real gain is visible in output, and doubled commits is the result you were looking for.","correct":false,"tempting":"Treats volume as the goal, which is exactly the substitution that hides a throughput problem behind a busy-looking team."},{"text":"The generated code is lower quality, so rework is consuming the time that was saved.","correct":false,"tempting":"Often partly true, but even with flawless code the 30% ceiling means feature delivery could improve at most about 20%, not double."}]},"prev":null,"next":{"slug":"the-fifth-time-code-got-cheap","title":"The fifth time code got cheap","url":"https://addaly.com/learn/how-software-changed/the-fifth-time-code-got-cheap"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'The cost curve moved, but only part of it', in How Software Development Changed. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/how-software-changed/the-cost-curve-moved (Accessed: 31 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"The cost curve moved, but only part of it","courseTitle":"How Software Development Changed","module":{"index":1,"slug":"where-the-cost-went","title":"Where the cost actually went"},"answer":null,"keyIdea":"Generating code got cheap; deciding what to build and confirming it is right did not.","hero":{"kind":"figure","figure":{"t":"figure","label":"Figure 1.1","figure":{"type":"bars","unit":"hours in a forty-hour week","title":"A forty-hour week, and the stage that got faster","series":[{"label":"Figuring out what to build","value":8},{"label":"Writing code","value":13,"highlight":true},{"label":"Verifying and reviewing","value":9},{"label":"Meetings, operations, waiting","value":10}],"caption":"Make the highlighted stage three times faster and about nine hours leave the week, which is roughly 22 per cent. The other thirty hours are untouched, and the queue is in one of them."},"alt":"Figure: A forty-hour week, and the stage that got faster. Bars (hours in a forty-hour week): Figuring out what to build 8; Writing code 13; Verifying and reviewing 9; Meetings, operations, waiting 10. Make the highlighted stage three times faster and about nine hours leave the week, which is roughly 22 per cent. The other thirty hours are untouched, and the queue is in one of them."}},"blocks":[{"t":"h2","id":"what-actually-got-cheaper","runs":[{"text":"What actually got cheaper"}]},{"t":"p","runs":[{"text":"A working first draft of a well-specified function is now close to free. Parsing a CSV with awkward quoting. A paginated list endpoint. Converting a callback-based class to promises. Writing fixtures for a test. Adding a migration. That work used to cost somewhere between twenty minutes and a day. It now costs roughly as long as it takes you to describe it and read the result."}]},{"t":"p","runs":[{"text":"That is a real change, and not a small one. But notice how narrow the claim is. It holds where you already know exactly what you want, the shape of the solution is common, and correctness is easy to check."}]},{"t":"h2","id":"what-did-not-get-cheaper","runs":[{"text":"What did not get cheaper"}]},{"t":"p","runs":[{"text":"None of this moved much:"}]},{"t":"ul","items":[[{"text":"Deciding what to build, and for whom"}],[{"text":"Knowing whether the thing you got back is right"}],[{"text":"Integrating it with everything that already exists"}],[{"text":"Operating it at 3am when it fails"}],[{"text":"Getting five people to agree on one interface"}],[{"text":"Understanding a system well enough to change it safely"}]]},{"t":"p","runs":[{"text":"These were always the expensive parts. They were just harder to see, because typing was expensive too, and typing was the visible activity."}]},{"t":"h2","id":"the-arithmetic-that-people-skip","runs":[{"text":"The arithmetic that people skip"}]},{"t":"p","runs":[{"text":"Suppose your engineers spend about a third of their working week actually writing code. Estimates vary a lot by team and by study, so treat that as a rough figure, not a fact about you. Now make that third three times faster."}]},{"t":"p","runs":[{"text":"You have removed about 22% of the week. Not 60%. Not 10x. And you have removed it from the stage of the pipeline that was never the queue."}]},{"t":"p","runs":[{"text":"This is the old lesson about optimising the wrong part of the system. If code review takes four days because reviewers are busy, and you now produce three times as many diffs, review takes longer, not shorter. You did not speed up delivery. You built a bigger pile in front of the same door."}]},{"t":"h2","id":"the-evidence-is-mixed-and-you-should-know-that","runs":[{"text":"The evidence is mixed, and you should know that"}]},{"t":"p","runs":[{"text":"Two things are both true and they get quoted selectively."}]},{"t":"p","runs":[{"text":"On greenfield work, unfamiliar languages, boilerplate-heavy tasks, and one-off scripts, the gains are large and easy to feel. People who write a lot of glue code, or who work across many stacks, are not imagining it."}]},{"t":"p","runs":[{"text":"On mature codebases that you know well, the picture is murkier. A widely-discussed 2025 randomised trial had experienced open-source maintainers work on issues in their own repositories, with and without AI assistance. They finished roughly 19% slower with it. They believed they had been about 20% faster. The sample was small, the participants were unusually expert, and the tooling has changed since. Do not treat it as the final word. But the gap between felt speed and measured speed is the finding that keeps replicating in less formal settings, and it should make you cautious about your own impressions."}]},{"t":"p","runs":[{"text":"Both results can hold. Speed comes from not having to know things. In a codebase you already know, there is less not-knowing to buy your way out of, and more cost in checking output against context the model does not have."}]},{"t":"h2","id":"where-the-constraint-went","runs":[{"text":"Where the constraint went"}]},{"t":"p","runs":[{"text":"The useful mental model is a factory with two stations: production and inspection. Production got much faster. Inspection did not. Every unit still has to pass through a human who understands the system, and that human’s throughput is roughly what it was in 2022."}]},{"t":"p","runs":[{"text":"So the constraint moved from "},{"text":"making the thing","i":true},{"text":" to "},{"text":"confirming the thing","i":true},{"text":". Almost every other lesson in this course is a consequence of that one sentence."}]},{"t":"p","runs":[{"text":"This is why teams that adopt these tools and change nothing else often see more activity and the same delivery. Commits are up, pull requests are up, everybody feels productive, and lead time is flat. The measurement that matters is not how much code you produced. It is how much verified, integrated, working change reached users, and how often it had to be rolled back."}]},{"t":"h2","id":"try-this","runs":[{"text":"Try this"}]},{"t":"p","runs":[{"text":"For one week, tag your working hours into four buckets: figuring out what to build, writing, verifying and reviewing, and everything else (meetings, operations, waiting). Do it roughly. Half-hour granularity is fine."}]},{"t":"p","runs":[{"text":"Most people are surprised. If writing is 20% of your week, then the tool that makes writing free has a ceiling of 20% on you, and the honest question is what to do about the other 80%."}]}],"check":{"question":[{"text":"Your team’s engineers spend about 30% of their week writing code. A new tool makes that part roughly three times faster, and everyone adopts it. Six months on, commits per week have nearly doubled and delivery time for a typical feature is unchanged. What is the most likely explanation?"}],"options":[{"text":[{"text":"Writing was not the constraint. The queue is in review, decisions and integration, and those got no faster, arguably slower, with more diffs arriving."}],"correct":true,"tempting":null},{"text":[{"text":"The team has not learned to use the tool well. With better prompting and more practice, the delivery gains will show up."}],"correct":false,"tempting":[{"text":"Assumes the gap is skill with the tool, when the arithmetic caps the possible gain at about a fifth of the week before skill enters the picture."}]},{"text":[{"text":"Delivery time is a lagging measure. The real gain is visible in output, and doubled commits is the result you were looking for."}],"correct":false,"tempting":[{"text":"Treats volume as the goal, which is exactly the substitution that hides a throughput problem behind a busy-looking team."}]},{"text":[{"text":"The generated code is lower quality, so rework is consuming the time that was saved."}],"correct":false,"tempting":[{"text":"Often partly true, but even with flawless code the 30% ceiling means feature delivery could improve at most about 20%, not double."}]}],"order":[2,3,1,0],"why":null},"prev":null,"next":{"slug":"the-fifth-time-code-got-cheap","title":"The fifth time code got cheap","minutes":9}}}