The Pressure on Developers: Productivity Claims, Adoption, Legacy and Accountability

All courses / AI Developer / Module 1 / Chapter 3

Learning objectives

After the lesson the participant can:

• Classify a claim about AI and developers as measured, surveyed, vendor or argued, and state how far it carries
• Explain why the three productivity results in the chapter cannot describe the same quantity
• Compare the adoption claims of Nordvik Region and Hansa Mutual with the measurements behind them
• Draft a work-and-load map for one sprint that shows where a tool could take part

Key concepts

Four grades of evidence

Measured rests on a study with a stated sample and method or an official text; surveyed on self-reported answers; vendor on a study by a company that sells in the area, read as a hypothesis; argued on reasoning from mechanism, only as strong as its premises.

Perceived and measured speed

In the randomised trial with 16 experienced open-source developers, allowing AI tools increased completion time by 19 per cent although the developers had forecast a 24 per cent reduction. The chapter uses it to show that belief about speed and measurement of speed can diverge.

Duties attach to named parties

The AI Act, the Cyber Resilience Act, the Product Liability Directive, NIS 2 and DORA address deployers, manufacturers, entities and management bodies. The chapter's implication is that none of these duties moves to a tool.

Evidence age

A claim has a date and an expiry. Under the defaults the book uses, usage figures expire after 90 days and value claims after 180 days; Nordvik's usage figures had expired by July 2030 and its 'a third faster' claim lapses in October 2030, and Hansa's 42 per cent of committed lines was past expiry.

Work-and-load map

An estimate by the developer of one sprint's hours by activity, with interrupted hours, the usage mode in which a tool could take part and the degree the delegation profile allows. It is compared at team level, never per named person.

Interactive exercises

Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.

Teaching plan

Discussion

1. The chapter concludes that the headcount expectation outruns the evidence in both directions. What would a measurement have to tie together before a smaller team could be defended?
2. Why does the chapter treat the written duties as firmer ground than any of the productivity or security studies?
3. The work-and-load map is an estimate by the developer and is compared only at team level. What would be lost, and what risked, if it were built from instrumented data instead?

Written exercise

Self-test

Choose an answer to see whether it is right, or open the answer below each question.

1. How does the chapter grade Veracode's report on generated code and GitClear's analysis of changed lines?

   1. As measured evidence, because both rest on large datasets of real code
   2. As surveyed evidence, because both rest on what developers said
   3. As vendor evidence, useful as a hypothesis and weak as a finding
   4. As argued evidence, because neither contains any measurement at all
   Show the answer

   C. As vendor evidence, useful as a hypothesis and weak as a finding
   Both come from companies that sell a tool or service in the area. The chapter reads such work as a claim by an interested party: useful as a hypothesis, weak as a finding.

2. Nordvik Region's executive committee was told that the pilot made developers 'a third faster'. What did the claim rest on?

   1. A comparison of delivery times before and after the pilot across four teams
   2. IDE telemetry of a 31 per cent acceptance rate and a survey answered by 9 of 12 developers
   3. A sample of 40 merged pull requests in which 27 per cent of lines were traced to suggestions
   4. A randomised trial run by the platform team with a control group of consultants
   Show the answer

   B. IDE telemetry of a 31 per cent acceptance rate and a survey answered by 9 of 12 developers
   The note rested on an acceptance rate and a survey of 9 of the 12 pilot developers; nobody had measured delivery time. The sample of 40 pull requests belongs to Hansa Mutual.

3. What is the chapter's own conclusion for the whole of Part I about where the strain on the developer role falls?

   1. On the capacity to prove and to own, more than on the capacity to produce
   2. On the capacity to produce code fast enough to meet the backlog
   3. On the capacity to learn new tools faster than they are replaced
   4. On the capacity to negotiate tool budgets with senior management
   Show the answer

   A. On the capacity to prove and to own, more than on the capacity to produce
   The chapter argues that a faster generator moves the limit to review and ownership: the pressures strain the capacity to prove and to own, not the capacity to produce.