AI & Software EngineeringKnowledge Atlas
Home / Catalogues / NDSE2 chapters

N collection · 13 records

NDSE2 · Published second edition

13 chapters from the published Non-Deterministic Software Engineering, Second Edition. English and Italian titles, section outlines and literal source citations are reconciled to the author-supplied final 13.7.1 sources.

Cover of Non-Deterministic Software Engineering, Second Edition, by Enrico Papalini.
Non-Deterministic Software Engineering · Second Edition

NDSE2 · Published second edition

Non-Deterministic Software Engineering, Second Edition

Engineering Trustworthy Change in the Age of AI and Coding Agents

By Enrico Papalini

Non-Deterministic Software Engineering, Seconda edizione — Progettare cambiamenti affidabili nell'era dell'AI e dei coding agent

Publication status as recorded: Published — author-confirmed 2026-10-18. Source edition version: 13.7.1. 13 chapter guides connect the English and Italian editions to their cited sources. Each guide includes an outline, learning goals and citation provenance.

View this book on Amazon.com ↗Browse the chapter guides
Edition and source detailsBook metadata and citation evidence
Explore this collection in the atlasJSON catalogueCSV catalogue

13 records shown

NDSE2:C01NDSE2 chapters

AI Changes the Unit of Software Work

Enrico Papalini · 2026

L'AI cambia l'unità di lavoro della software engineering

Defines an accepted, operable change as the unit of engineering work. The approval-routing case separates business intention, implementation, verification and acceptance, showing why brownfield understanding and explicit decision rights still matter when an AI agent generates the patch.

Chapter guide and cited sources →

Evidence, context & provenance
Evidence boundaryAuthor engineering synthesis and teaching material; publication is not independent empirical validation.

Source type, as recorded: Published author chapter; engineering synthesis

Learning goals

  • distinguish an implementation artifact from an accepted change
  • name the people and evidence required between a request and release
  • scope an AI assistant's task without delegating business authority
Obiettivi in italiano

Obiettivi di apprendimento

  • distinguere un artefatto di implementazione da una modifica accettata
  • identificare le persone e le evidenze necessarie tra la richiesta e la release
  • delimitare il task affidato a un assistente AI senza delegargli l'autorità sulle decisioni di business
Chapter outline
  • 1.1 Software engineering begins before the code
  • 1.2 From autocomplete to delegated execution
  • 1.3 The engineer's work before and after AI
  • 1.4 The lifecycle of a trustworthy change
  • 1.5 The autonomy–accountability boundary
  • 1.6 Why brownfield change starts with system comprehension
  • 1.7 What the research can and cannot tell us
  • 1.8 A teaching case, not a reported field experiment
  • 1.9 From generated output to an evidence question
  • 1.10 Worked engineering example: where does a change become acceptable?
  • 1.11 Practice exercise: define the unit of trustworthy work
Struttura del capitolo
  • 1.1 La software engineering comincia prima del codice
  • 1.2 Dall'autocomplete all'esecuzione delegata
  • 1.3 Il lavoro dell'ingegnere prima e dopo l'AI
  • 1.4 Il ciclo di vita di una modifica affidabile
  • 1.5 Il confine fra autonomia e accountability
  • 1.6 Perché una modifica brownfield parte dalla comprensione del sistema
  • 1.7 Che cosa può e non può dirci la ricerca
  • 1.8 Un caso didattico, non un esperimento sul campo
  • 1.9 Dall'output generato alla domanda sulle evidenze
  • 1.10 Esempio ingegneristico svolto: quando una modifica diventa accettabile?
  • 1.11 Esercizio pratico: definire l'unità di lavoro affidabile
Publication status
PUBLISHED_AUTHOR_CONFIRMED
Original source file
EN/chapters/chapter01.tex
Original SHA-256
277ec2181a885dfee7268a6d504503c8c039a8cc6c8201bfd2a966515d5b2500
Provenance
Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.
24 recorded source relationships

These retain the graph’s exact relation labels. A connection is not automatically a causal claim or an independent replication.

All preserved graph attributes
{
  "chapter_number": 1,
  "chapter_hub": "C:C01",
  "title": "AI Changes the Unit of Software Work",
  "title_it": "L'AI cambia l'unità di lavoro della software engineering",
  "summary": "Defines an accepted, operable change as the unit of engineering work. The approval-routing case separates business intention, implementation, verification and acceptance, showing why brownfield understanding and explicit decision rights still matter when an AI agent generates the patch.",
  "summary_it": "Definisce il cambiamento accettato e gestibile come unità del lavoro ingegneristico. Il caso di instradamento delle approvazioni distingue intenzione di business, implementazione, verifica e accettazione, mostrando il ruolo della comprensione del sistema e delle responsabilità decisionali anche quando la patch viene generata da un agent.",
  "author": "Enrico Papalini",
  "volume_id": "V06",
  "edition_id": "EDITION:NDSE2:13.7.1",
  "source_version": "13.7.1",
  "source_file": "EN/chapters/chapter01.tex",
  "source_sha256": "277ec2181a885dfee7268a6d504503c8c039a8cc6c8201bfd2a966515d5b2500",
  "source_file_it": "ITA/chapters/chapter01.tex",
  "source_sha256_it": "e89175da618cfae5b422e16c8e01fd457d1da8308a5d9359a2b6aac592cf63ca",
  "learning_goals_json": "[\"distinguish an implementation artifact from an accepted change\", \"name the people and evidence required between a request and release\", \"scope an AI assistant's task without delegating business authority\"]",
  "learning_goals_it_json": "[\"distinguere un artefatto di implementazione da una modifica accettata\", \"identificare le persone e le evidenze necessarie tra la richiesta e la release\", \"delimitare il task affidato a un assistente AI senza delegargli l'autorità sulle decisioni di business\"]",
  "publication_status": "PUBLISHED_AUTHOR_CONFIRMED",
  "provenance": "Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.",
  "evidence_class": "Published author chapter; engineering synthesis",
  "limitation": "Author engineering synthesis and teaching material; publication is not independent empirical validation.",
  "label": "AI Changes the Unit of Software Work",
  "kind": "published_book_chapter",
  "node_class": "NDSE2_PUBLISHED_EDITION_20261018"
}
View in atlas →Permanent entry link
NDSE2:C02NDSE2 chapters

Measuring Productivity from Code to Production

Enrico Papalini · 2026

Misurare la produttività: dal codice alla produzione

Examines productivity measures from generated output to accepted releases. It distinguishes randomized evidence from observational comparisons and develops a pilot that records review, rework, quality and hidden human effort before an adoption decision.

Chapter guide and cited sources →

Evidence, context & provenance
Evidence boundaryAuthor engineering synthesis and teaching material; publication is not independent empirical validation.

Source type, as recorded: Published author chapter; engineering synthesis

Learning goals

  • choose a productivity denominator that includes review and rework
  • distinguish measured acceptance from reported speed and generated output
  • design a comparison that protects against selection bias and missing quality outcomes
Obiettivi in italiano

Obiettivi di apprendimento

  • scegliere un denominatore di produttività che comprenda review e rework
  • distinguere l'accettazione effettivamente misurata dalla velocità dichiarata e dall'output generato
  • progettare un confronto che protegga dalle distorsioni di selezione e dagli esiti di qualità non osservati
Chapter outline
  • 2.1 The productivity denominator problem
  • 2.2 How to read causal evidence
  • 2.3 Why controlled studies disagree
  • 2.4 Observational adoption and its confounders
  • 2.5 Writing code versus shipping code
  • 2.6 Quality-adjusted productivity
  • 2.7 Developer experience and hidden time
  • 2.8 Designing a coding-specific field pilot
  • 2.9 From metrics to an evidence-based pilot decision
  • 2.10 Worked engineering example: pick the denominator before the tool
  • 2.11 Practice exercise: measure accepted throughput, not generated output
Struttura del capitolo
  • 2.1 Il problema del denominatore nella produttività
  • 2.2 Come leggere le evidenze causali
  • 2.3 Perché gli studi controllati possono essere in disaccordo
  • 2.4 L'adozione osservazionale e i fattori confondenti
  • 2.5 Scrivere codice non significa rilasciarlo
  • 2.6 Produttività corretta per la qualità
  • 2.7 Developer experience e tempo nascosto
  • 2.8 Progettare un pilot sul campo per task di coding
  • 2.9 Dalle metriche a una decisione sul pilot basata sulle evidenze
  • 2.10 Esempio ingegneristico svolto: scegliere il denominatore prima dello strumento
  • 2.11 Esercizio pratico: misurare il throughput accettato, non l'output generato
Publication status
PUBLISHED_AUTHOR_CONFIRMED
Original source file
EN/chapters/chapter02.tex
Original SHA-256
2f513eeed43e6183a3b26ebcebaa19a35ab53dbf561260b015e69357b049a72f
Provenance
Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.
24 recorded source relationships

These retain the graph’s exact relation labels. A connection is not automatically a causal claim or an independent replication.

All preserved graph attributes
{
  "chapter_number": 2,
  "chapter_hub": "C:C02",
  "title": "Measuring Productivity from Code to Production",
  "title_it": "Misurare la produttività: dal codice alla produzione",
  "summary": "Examines productivity measures from generated output to accepted releases. It distinguishes randomized evidence from observational comparisons and develops a pilot that records review, rework, quality and hidden human effort before an adoption decision.",
  "summary_it": "Esamina la produttività dal codice generato ai rilasci accettati. Distingue le evidenze randomizzate dai confronti osservazionali e sviluppa un progetto pilota che misura revisione, rilavorazione, qualità e lavoro umano poco visibile prima di decidere sull'adozione.",
  "author": "Enrico Papalini",
  "volume_id": "V06",
  "edition_id": "EDITION:NDSE2:13.7.1",
  "source_version": "13.7.1",
  "source_file": "EN/chapters/chapter02.tex",
  "source_sha256": "2f513eeed43e6183a3b26ebcebaa19a35ab53dbf561260b015e69357b049a72f",
  "source_file_it": "ITA/chapters/chapter02.tex",
  "source_sha256_it": "2336ccabfd1817c7c21c8f4e06fec37bee109fee2b80718824482abd5f393ddb",
  "learning_goals_json": "[\"choose a productivity denominator that includes review and rework\", \"distinguish measured acceptance from reported speed and generated output\", \"design a comparison that protects against selection bias and missing quality outcomes\"]",
  "learning_goals_it_json": "[\"scegliere un denominatore di produttività che comprenda review e rework\", \"distinguere l'accettazione effettivamente misurata dalla velocità dichiarata e dall'output generato\", \"progettare un confronto che protegga dalle distorsioni di selezione e dagli esiti di qualità non osservati\"]",
  "publication_status": "PUBLISHED_AUTHOR_CONFIRMED",
  "provenance": "Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.",
  "evidence_class": "Published author chapter; engineering synthesis",
  "limitation": "Author engineering synthesis and teaching material; publication is not independent empirical validation.",
  "label": "Measuring Productivity from Code to Production",
  "kind": "published_book_chapter",
  "node_class": "NDSE2_PUBLISHED_EDITION_20261018"
}
View in atlas →Permanent entry link
NDSE2:C03NDSE2 chapters

Limits and Capability of Coding Agents

Enrico Papalini · 2026

Limiti e capacità dei coding agent

Turns agent capability into a bounded engineering hypothesis. Permissions, tools, budgets, stopping rules and escalation constrain execution; the chapter compares execution routes and parallel work while keeping technical completion separate from authorized acceptance.

Chapter guide and cited sources →

Evidence, context & provenance
Evidence boundaryAuthor engineering synthesis and teaching material; publication is not independent empirical validation.

Source type, as recorded: Published author chapter; engineering synthesis

Learning goals

  • translate a task request into a permission and budget envelope
  • tell a model suggestion from an orchestrator-authorized action
  • stop or escalate an agent without confusing technical completion with acceptance
Obiettivi in italiano

Obiettivi di apprendimento

  • tradurre una richiesta di lavoro in un envelope di permessi e budget
  • distinguere un suggerimento del modello da un'azione autorizzata dall'orchestrator
  • fermare un agent o portare un caso in escalation, senza confondere completamento tecnico e accettazione
Chapter outline
  • 3.1 From suggestion to a permission-bounded agent
  • 3.2 What an agent actually observes
  • 3.3 The task envelope
  • 3.4 Agent benchmarks and observed pull requests
  • 3.5 Common failure modes in real changes
  • 3.6 A bounded propose–act–observe loop
  • 3.7 The minimum sufficient execution route
  • 3.8 When parallel agents help and hurt
  • 3.9 Stopping rules versus acceptance authority
  • 3.10 Agent capability as a testable hypothesis
  • Technical laboratory — A permission-bounded candidate, not an autonomous release
  • 3.11 Worked engineering example: permission is a state-machine input
  • 3.12 Practice exercise: define an agent's actual authority
Struttura del capitolo
  • 3.1 Dal suggerimento a un agent con permessi delimitati
  • 3.2 Che cosa osserva realmente un agent
  • 3.3 Il perimetro del task
  • 3.4 Benchmark degli agent e pull request osservate
  • 3.5 Modalità di fallimento frequenti nelle modifiche reali
  • 3.6 Un loop delimitato propose–act–observe
  • 3.7 Scegliere il percorso minimo di esecuzione sufficiente
  • 3.8 Quando gli agent paralleli aiutano e quando peggiorano il risultato
  • 3.9 Regole di arresto e autorità di accettazione
  • 3.10 Le capacità dell'agent come ipotesi verificabili
  • Laboratorio tecnico — Una candidata con permessi delimitati, non una release autonoma
  • 3.11 Esempio ingegneristico svolto: i permessi sono input della macchina a stati
  • 3.12 Esercizio pratico: definire l'autorità effettiva di un agent
Publication status
PUBLISHED_AUTHOR_CONFIRMED
Original source file
EN/chapters/chapter03.tex
Original SHA-256
ce0ca41e0ce359c1fd4752f2db1de6b1312c006510fc9c3ba364e3310916c2b1
Provenance
Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.
42 recorded source relationships

These retain the graph’s exact relation labels. A connection is not automatically a causal claim or an independent replication.

All preserved graph attributes
{
  "chapter_number": 3,
  "chapter_hub": "C:C03",
  "title": "Limits and Capability of Coding Agents",
  "title_it": "Limiti e capacità dei coding agent",
  "summary": "Turns agent capability into a bounded engineering hypothesis. Permissions, tools, budgets, stopping rules and escalation constrain execution; the chapter compares execution routes and parallel work while keeping technical completion separate from authorized acceptance.",
  "summary_it": "Trasforma la capacità degli agent in un'ipotesi ingegneristica delimitata. Permessi, strumenti, budget, condizioni di arresto ed escalation vincolano l'esecuzione; il capitolo confronta percorsi operativi e lavoro parallelo distinguendo il completamento tecnico dall'accettazione autorizzata.",
  "author": "Enrico Papalini",
  "volume_id": "V06",
  "edition_id": "EDITION:NDSE2:13.7.1",
  "source_version": "13.7.1",
  "source_file": "EN/chapters/chapter03.tex",
  "source_sha256": "ce0ca41e0ce359c1fd4752f2db1de6b1312c006510fc9c3ba364e3310916c2b1",
  "source_file_it": "ITA/chapters/chapter03.tex",
  "source_sha256_it": "2c1ae14b69644084668fec3494a975a6f6be7822e77d7d96d1b21f654d2aa713",
  "learning_goals_json": "[\"translate a task request into a permission and budget envelope\", \"tell a model suggestion from an orchestrator-authorized action\", \"stop or escalate an agent without confusing technical completion with acceptance\"]",
  "learning_goals_it_json": "[\"tradurre una richiesta di lavoro in un envelope di permessi e budget\", \"distinguere un suggerimento del modello da un'azione autorizzata dall'orchestrator\", \"fermare un agent o portare un caso in escalation, senza confondere completamento tecnico e accettazione\"]",
  "publication_status": "PUBLISHED_AUTHOR_CONFIRMED",
  "provenance": "Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.",
  "evidence_class": "Published author chapter; engineering synthesis",
  "limitation": "Author engineering synthesis and teaching material; publication is not independent empirical validation.",
  "label": "Limits and Capability of Coding Agents",
  "kind": "published_book_chapter",
  "node_class": "NDSE2_PUBLISHED_EDITION_20261018"
}
View in atlas →Permanent entry link
NDSE2:C04NDSE2 chapters

Intentions, Contracts and Iterative Change

Enrico Papalini · 2026

Intenzioni, contratti e cambiamento iterativo

Develops a versioned intention contract for an existing service. Behavioral examples and acceptance rules are established independently of implementation, while late policy changes trigger targeted impact analysis and invalidate only the decisions and evidence they affect.

Chapter guide and cited sources →

Evidence, context & provenance
Evidence boundaryAuthor engineering synthesis and teaching material; publication is not independent empirical validation.

Source type, as recorded: Published author chapter; engineering synthesis

Learning goals

  • separate intention approval from implementation design
  • derive independent behavioral examples from a versioned contract
  • incorporate late intention changes by invalidating only the affected decisions and evidence
Obiettivi in italiano

Obiettivi di apprendimento

  • separare l'approvazione dell'intenzione dal design dell'implementazione
  • ricavare esempi comportamentali indipendenti da un contratto versionato
  • integrare cambiamenti tardivi dell'intenzione invalidando soltanto le decisioni e le evidenze interessate
Chapter outline
  • 4.1 Separate intention determination from design
  • 4.2 From a request to a versioned intention ledger
  • 4.3 Write behavioral examples before implementation
  • 4.4 The smallest native intention bundle
  • 4.5 Executable contracts without circular oracles
  • 4.6 Architecture decision versus acceptance contract
  • 4.7 One canonical change-and-evidence trace
  • 4.8 A delta-driven iterative brownfield lifecycle
  • 4.9 Late intentions and explicit impact analysis
  • 4.10 Native intent gates and optional compatibility adapters
  • 4.11 The approval-rule contract across two iterations
  • 4.12 Worked engineering example: a late requirement need not restart the project
  • 4.13 Practice exercise: absorb a late intention without a waterfall restart
Struttura del capitolo
  • 4.1 Separare la definizione dell'intenzione dal design
  • 4.2 Dalla richiesta a un registro versionato delle intenzioni
  • 4.3 Scrivere esempi comportamentali prima dell'implementazione
  • 4.4 Il più piccolo insieme di artefatti nativi dell'intenzione
  • 4.5 Contratti eseguibili senza oracle circolari
  • 4.6 Decisione architetturale e contratto di accettazione
  • 4.7 Una traccia canonica di modifica ed evidenze
  • 4.8 Un ciclo di vita brownfield iterativo, guidato dai delta
  • 4.9 Intenzioni sopraggiunte e analisi d'impatto esplicita
  • 4.10 Gate nativi dell'intenzione e adapter di compatibilità opzionali
  • 4.11 Il contratto delle regole di approvazione attraverso due iterazioni
  • 4.12 Esempio svolto: un requisito tardivo non deve far ripartire il progetto
  • 4.13 Esercizio pratico: integrare un'intenzione tardiva senza ricominciare in waterfall
Publication status
PUBLISHED_AUTHOR_CONFIRMED
Original source file
EN/chapters/chapter04.tex
Original SHA-256
f9ba7148a44598fb3bb1a59888f37f376faadff0f300dafb908a98168176f7a7
Provenance
Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.
30 recorded source relationships

These retain the graph’s exact relation labels. A connection is not automatically a causal claim or an independent replication.

All preserved graph attributes
{
  "chapter_number": 4,
  "chapter_hub": "C:C04",
  "title": "Intentions, Contracts and Iterative Change",
  "title_it": "Intenzioni, contratti e cambiamento iterativo",
  "summary": "Develops a versioned intention contract for an existing service. Behavioral examples and acceptance rules are established independently of implementation, while late policy changes trigger targeted impact analysis and invalidate only the decisions and evidence they affect.",
  "summary_it": "Sviluppa un contratto di intenzione versionato per un servizio esistente. Esempi comportamentali e regole di accettazione vengono stabiliti indipendentemente dall'implementazione; le modifiche tardive della policy richiedono un'analisi d'impatto e invalidano solo decisioni ed evidenze coinvolte.",
  "author": "Enrico Papalini",
  "volume_id": "V06",
  "edition_id": "EDITION:NDSE2:13.7.1",
  "source_version": "13.7.1",
  "source_file": "EN/chapters/chapter04.tex",
  "source_sha256": "f9ba7148a44598fb3bb1a59888f37f376faadff0f300dafb908a98168176f7a7",
  "source_file_it": "ITA/chapters/chapter04.tex",
  "source_sha256_it": "878773f16a0704f3cb52d7547b3b7959cb5497eadfc30a93ad23816c8ac69ed5",
  "learning_goals_json": "[\"separate intention approval from implementation design\", \"derive independent behavioral examples from a versioned contract\", \"incorporate late intention changes by invalidating only the affected decisions and evidence\"]",
  "learning_goals_it_json": "[\"separare l'approvazione dell'intenzione dal design dell'implementazione\", \"ricavare esempi comportamentali indipendenti da un contratto versionato\", \"integrare cambiamenti tardivi dell'intenzione invalidando soltanto le decisioni e le evidenze interessate\"]",
  "publication_status": "PUBLISHED_AUTHOR_CONFIRMED",
  "provenance": "Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.",
  "evidence_class": "Published author chapter; engineering synthesis",
  "limitation": "Author engineering synthesis and teaching material; publication is not independent empirical validation.",
  "label": "Intentions, Contracts and Iterative Change",
  "kind": "published_book_chapter",
  "node_class": "NDSE2_PUBLISHED_EDITION_20261018"
}
View in atlas →Permanent entry link
NDSE2:C05NDSE2 chapters

Quality, Architecture and Maintainability

Enrico Papalini · 2026

Qualità, architettura e manutenibilità

Separates immediate correctness from architectural fit and maintenance obligations. Through duplication, post-merge evidence and a second change to the running service, it develops fitness checks and explicit stewardship instead of treating a passing test suite as complete quality assurance.

Chapter guide and cited sources →

Evidence, context & provenance
Evidence boundaryAuthor engineering synthesis and teaching material; publication is not independent empirical validation.

Source type, as recorded: Published author chapter; engineering synthesis

Learning goals

  • review generated code for architectural fit as well as immediate correctness
  • write fitness checks for critical system invariants
  • locate who will maintain the result when the original agent and reviewer are gone
Obiettivi in italiano

Obiettivi di apprendimento

  • sottoporre il codice generato a review non solo per la correttezza immediata, ma anche per la coerenza architetturale
  • scrivere controlli di fitness per gli invarianti critici del sistema
  • individuare chi si occuperà della manutenzione quando l'agent e il reviewer originari non saranno più disponibili
Chapter outline
  • 5.1 What counts as code quality?
  • 5.2 Reading AI-versus-human studies correctly
  • 5.3 Code smells are signals, not incidents
  • 5.4 Generated duplication and missed reuse
  • 5.5 Architectural fit in a living codebase
  • 5.6 Post-merge evolution and maintenance burden
  • 5.7 Tracing quality across agents and projects
  • 5.8 Authorship is not stewardship
  • 5.9 A second change exposes the difference
  • 5.10 Architecture fitness in the approval service
  • 5.11 Worked engineering example: test the architecture, not just the output
  • 5.12 Practice exercise: choose a maintainable implementation
Struttura del capitolo
  • 5.1 Che cosa significa qualità del codice?
  • 5.2 Come leggere correttamente gli studi che confrontano AI e sviluppatori
  • 5.3 I code smell sono segnali, non incidenti
  • 5.4 Duplicazioni generate e riuso trascurato
  • 5.5 Coerenza architetturale in un codebase in evoluzione
  • 5.6 Evoluzione dopo il merge e onere della manutenzione
  • 5.7 Seguire la qualità tra agent e progetti
  • 5.8 Scrivere il codice non significa esserne responsabili
  • 5.9 È la seconda modifica a far emergere la differenza
  • 5.10 Verificare l'architecture fitness nel servizio di approvazione
  • 5.11 Esempio ingegneristico svolto: verificare l'architettura, non soltanto l'output
  • 5.12 Esercizio pratico: scegliere un'implementazione manutenibile
Publication status
PUBLISHED_AUTHOR_CONFIRMED
Original source file
EN/chapters/chapter05.tex
Original SHA-256
f6e123ae06931297b82554424c5b9b9c4b6bdb00e897814d515d11203e684075
Provenance
Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.
36 recorded source relationships

These retain the graph’s exact relation labels. A connection is not automatically a causal claim or an independent replication.

All preserved graph attributes
{
  "chapter_number": 5,
  "chapter_hub": "C:C05",
  "title": "Quality, Architecture and Maintainability",
  "title_it": "Qualità, architettura e manutenibilità",
  "summary": "Separates immediate correctness from architectural fit and maintenance obligations. Through duplication, post-merge evidence and a second change to the running service, it develops fitness checks and explicit stewardship instead of treating a passing test suite as complete quality assurance.",
  "summary_it": "Distingue la correttezza immediata dalla coerenza architetturale e dagli obblighi di manutenzione. Duplicazioni, evidenze successive al merge e un secondo cambiamento al servizio guidano controlli di adeguatezza e responsabilità di manutenzione esplicite.",
  "author": "Enrico Papalini",
  "volume_id": "V06",
  "edition_id": "EDITION:NDSE2:13.7.1",
  "source_version": "13.7.1",
  "source_file": "EN/chapters/chapter05.tex",
  "source_sha256": "f6e123ae06931297b82554424c5b9b9c4b6bdb00e897814d515d11203e684075",
  "source_file_it": "ITA/chapters/chapter05.tex",
  "source_sha256_it": "31ceb5547ea22913089d9eba92093a622b30f98f3052e9a0f793dee86df8938e",
  "learning_goals_json": "[\"review generated code for architectural fit as well as immediate correctness\", \"write fitness checks for critical system invariants\", \"locate who will maintain the result when the original agent and reviewer are gone\"]",
  "learning_goals_it_json": "[\"sottoporre il codice generato a review non solo per la correttezza immediata, ma anche per la coerenza architetturale\", \"scrivere controlli di fitness per gli invarianti critici del sistema\", \"individuare chi si occuperà della manutenzione quando l'agent e il reviewer originari non saranno più disponibili\"]",
  "publication_status": "PUBLISHED_AUTHOR_CONFIRMED",
  "provenance": "Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.",
  "evidence_class": "Published author chapter; engineering synthesis",
  "limitation": "Author engineering synthesis and teaching material; publication is not independent empirical validation.",
  "label": "Quality, Architecture and Maintainability",
  "kind": "published_book_chapter",
  "node_class": "NDSE2_PUBLISHED_EDITION_20261018"
}
View in atlas →Permanent entry link
NDSE2:C06NDSE2 chapters

Securing Generated Code and Agent Runtimes

Enrico Papalini · 2026

Mettere in sicurezza il codice generato e i runtime degli agent

Threat-models two distinct surfaces: the generated application and the agent runtime. Dependency provenance, prompt injection, tool permissions and external services become enforceable boundaries, with security evidence tied to the release decision.

Chapter guide and cited sources →

Evidence, context & provenance
Evidence boundaryAuthor engineering synthesis and teaching material; publication is not independent empirical validation.

Source type, as recorded: Published author chapter; engineering synthesis

Learning goals

  • threat-model the generated product and the agent runtime separately
  • enforce tool permissions independently of instructions embedded in files
  • specify the evidence required before accepting a security-sensitive patch
Obiettivi in italiano

Obiettivi di apprendimento

  • costruire threat model distinti per il prodotto generato e per il runtime dell'agent
  • far rispettare i permessi dei tool indipendentemente dalle istruzioni incorporate nei file
  • specificare le evidenze necessarie prima di accettare una patch sensibile dal punto di vista della sicurezza
Chapter outline
  • 6.1 Two attack surfaces, two threat models
  • 6.2 Functional correctness is not security
  • 6.3 What vulnerability studies actually measure
  • 6.4 Security-directed generation and remediation
  • 6.5 Dependency provenance and hallucinated packages
  • 6.6 Prompt injection through repository and tools
  • 6.7 Harness configuration, skills and external services
  • 6.8 A secure agent execution profile
  • 6.9 Threats turned into enforceable boundaries
  • 6.10 Security evidence and release decision
  • 6.11 Worked engineering example: two threats, two defenses
  • 6.12 Practice exercise: threat-model both the product and the agent
Struttura del capitolo
  • 6.1 Due superfici di attacco, due threat model
  • 6.2 La correttezza funzionale non basta per la sicurezza
  • 6.3 Che cosa misurano davvero gli studi sulle vulnerabilità
  • 6.4 Generazione e remediation guidate dalla sicurezza
  • 6.5 Provenienza delle dipendenze e package inventati
  • 6.6 Prompt injection attraverso repository e tool
  • 6.7 Configurazione dell'harness, skill e servizi esterni
  • 6.8 Un profilo di esecuzione sicura per gli agent
  • 6.9 Dalle minacce ai confini applicabili
  • 6.10 Evidenze di sicurezza e decisione di release
  • 6.11 Esempio ingegneristico svolto: due minacce, due difese
  • 6.12 Esercizio pratico: costruire due threat model, per prodotto e agent
Publication status
PUBLISHED_AUTHOR_CONFIRMED
Original source file
EN/chapters/chapter06.tex
Original SHA-256
3af782fd4b06529539e8b78e95b77ad3911980472e272fe111ddcfcc82ce777a
Provenance
Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.
20 recorded source relationships

These retain the graph’s exact relation labels. A connection is not automatically a causal claim or an independent replication.

All preserved graph attributes
{
  "chapter_number": 6,
  "chapter_hub": "C:C06",
  "title": "Securing Generated Code and Agent Runtimes",
  "title_it": "Mettere in sicurezza il codice generato e i runtime degli agent",
  "summary": "Threat-models two distinct surfaces: the generated application and the agent runtime. Dependency provenance, prompt injection, tool permissions and external services become enforceable boundaries, with security evidence tied to the release decision.",
  "summary_it": "Analizza due superfici di attacco distinte: l'applicazione generata e il runtime dell'agent. Provenienza delle dipendenze, prompt injection, permessi degli strumenti e servizi esterni diventano vincoli applicabili, collegando le evidenze di sicurezza alla decisione di rilascio.",
  "author": "Enrico Papalini",
  "volume_id": "V06",
  "edition_id": "EDITION:NDSE2:13.7.1",
  "source_version": "13.7.1",
  "source_file": "EN/chapters/chapter06.tex",
  "source_sha256": "3af782fd4b06529539e8b78e95b77ad3911980472e272fe111ddcfcc82ce777a",
  "source_file_it": "ITA/chapters/chapter06.tex",
  "source_sha256_it": "f4a3e1c62eae1528ce10817e76376558b41cdc7a6d337397c394cc5cb840ea9e",
  "learning_goals_json": "[\"threat-model the generated product and the agent runtime separately\", \"enforce tool permissions independently of instructions embedded in files\", \"specify the evidence required before accepting a security-sensitive patch\"]",
  "learning_goals_it_json": "[\"costruire threat model distinti per il prodotto generato e per il runtime dell'agent\", \"far rispettare i permessi dei tool indipendentemente dalle istruzioni incorporate nei file\", \"specificare le evidenze necessarie prima di accettare una patch sensibile dal punto di vista della sicurezza\"]",
  "publication_status": "PUBLISHED_AUTHOR_CONFIRMED",
  "provenance": "Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.",
  "evidence_class": "Published author chapter; engineering synthesis",
  "limitation": "Author engineering synthesis and teaching material; publication is not independent empirical validation.",
  "label": "Securing Generated Code and Agent Runtimes",
  "kind": "published_book_chapter",
  "node_class": "NDSE2_PUBLISHED_EDITION_20261018"
}
View in atlas →Permanent entry link
NDSE2:C07NDSE2 chapters

Independent Verification and the Oracle Problem

Enrico Papalini · 2026

Verifica indipendente e problema dell'oracle

Builds independent verification around authorized behavior. Regression cases, properties, counterexamples and mutants expose circular testing; correlated checker errors and benchmark limits motivate an evidence dossier that supports review without granting the maker acceptance authority.

Chapter guide and cited sources →

Evidence, context & provenance
Evidence boundaryAuthor engineering synthesis and teaching material; publication is not independent empirical validation.

Source type, as recorded: Published author chapter; engineering synthesis

Learning goals

  • derive an independent oracle from authorized behavior
  • use counterexamples and mutants to reveal circular testing
  • assemble a dossier that allows another person to decide whether a candidate is ready for review
Obiettivi in italiano

Obiettivi di apprendimento

  • ricavare un oracle indipendente dal comportamento autorizzato
  • usare controesempi e mutant per smascherare i test circolari
  • preparare un dossier di evidenze che consenta a un'altra persona di decidere se una modifica candidata sia pronta per la review
Chapter outline
  • 7.1 The oracle problem in AI-generated software
  • 7.2 A hierarchy of evidence
  • 7.3 Preventing bug-shaped test generation
  • 7.4 Regression tests for existing and changed behavior
  • 7.5 Properties and adversarial counterexamples
  • 7.6 Benchmark success versus merge readiness
  • 7.7 Independent checkers and correlated error
  • 7.8 Bounded repair versus independent acceptance
  • 7.9 The acceptance evidence dossier
  • 7.10 Worked engineering example: make wrong behavior fail independently
  • 7.11 Practice exercise: build an oracle the maker does not control
Struttura del capitolo
  • 7.1 Il problema dell'oracle nel software generato dall'AI
  • 7.2 Una gerarchia delle evidenze
  • 7.3 Evitare test modellati sui bug
  • 7.4 Regression test per comportamenti esistenti e modificati
  • 7.5 Proprietà e controesempi avversariali
  • 7.6 Successo nei benchmark e prontezza al merge
  • 7.7 Checker indipendenti ed errori correlati
  • 7.8 Correzione delimitata e accettazione indipendente
  • 7.9 Il dossier delle evidenze per l'accettazione
  • 7.10 Esempio svolto: far fallire autonomamente il comportamento errato
  • 7.11 Esercizio: costruire un oracle che il maker non controlla
Publication status
PUBLISHED_AUTHOR_CONFIRMED
Original source file
EN/chapters/chapter07.tex
Original SHA-256
0990c2265ce14a6e4f7274c64952b424d7b29678a995352ab6ec2258ca7dfe00
Provenance
Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.
38 recorded source relationships

These retain the graph’s exact relation labels. A connection is not automatically a causal claim or an independent replication.

All preserved graph attributes
{
  "chapter_number": 7,
  "chapter_hub": "C:C07",
  "title": "Independent Verification and the Oracle Problem",
  "title_it": "Verifica indipendente e problema dell'oracle",
  "summary": "Builds independent verification around authorized behavior. Regression cases, properties, counterexamples and mutants expose circular testing; correlated checker errors and benchmark limits motivate an evidence dossier that supports review without granting the maker acceptance authority.",
  "summary_it": "Costruisce la verifica indipendente a partire dal comportamento autorizzato. Regressioni, proprietà, controesempi e mutanti rivelano i test circolari; errori correlati dei checker e limiti dei benchmark motivano un dossier di evidenze senza attribuire al maker l'autorità di accettazione.",
  "author": "Enrico Papalini",
  "volume_id": "V06",
  "edition_id": "EDITION:NDSE2:13.7.1",
  "source_version": "13.7.1",
  "source_file": "EN/chapters/chapter07.tex",
  "source_sha256": "0990c2265ce14a6e4f7274c64952b424d7b29678a995352ab6ec2258ca7dfe00",
  "source_file_it": "ITA/chapters/chapter07.tex",
  "source_sha256_it": "7de646cec6272bbb7bdfb1f1ba7d6aa762680382fd4efac383bc341e8f394739",
  "learning_goals_json": "[\"derive an independent oracle from authorized behavior\", \"use counterexamples and mutants to reveal circular testing\", \"assemble a dossier that allows another person to decide whether a candidate is ready for review\"]",
  "learning_goals_it_json": "[\"ricavare un oracle indipendente dal comportamento autorizzato\", \"usare controesempi e mutant per smascherare i test circolari\", \"preparare un dossier di evidenze che consenta a un'altra persona di decidere se una modifica candidata sia pronta per la review\"]",
  "publication_status": "PUBLISHED_AUTHOR_CONFIRMED",
  "provenance": "Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.",
  "evidence_class": "Published author chapter; engineering synthesis",
  "limitation": "Author engineering synthesis and teaching material; publication is not independent empirical validation.",
  "label": "Independent Verification and the Oracle Problem",
  "kind": "published_book_chapter",
  "node_class": "NDSE2_PUBLISHED_EDITION_20261018"
}
View in atlas →Permanent entry link
NDSE2:C08NDSE2 chapters

Code Review and Trust Calibration

Enrico Papalini · 2026

Code review e calibrazione della fiducia

Allocates review effort by consequence and uncertainty. It examines human and AI reviewers, false positives, shared blind spots and automation bias, then separates finding disposition, coverage of acceptance obligations and the accountable release verdict.

Chapter guide and cited sources →

Evidence, context & provenance
Evidence boundaryAuthor engineering synthesis and teaching material; publication is not independent empirical validation.

Source type, as recorded: Published author chapter; engineering synthesis

Learning goals

  • allocate review effort by consequence and uncertainty
  • recognize when two reviewers share the same error source
  • distinguish the disposition of a review finding, coverage of acceptance obligations and release authority
Obiettivi in italiano

Obiettivi di apprendimento

  • distribuire l'impegno della review in base alle conseguenze e all'incertezza
  • riconoscere quando due reviewer condividono la stessa fonte di errore
  • distinguere l'esito di un finding di review, la copertura degli obblighi di accettazione e l'autorità necessaria per la release
Chapter outline
  • 8.1 Why review becomes the scarce resource
  • 8.2 The influence of code complexity and provenance
  • 8.3 Human intervention in agent pull requests
  • 8.4 What AI reviewers catch—and miss
  • 8.5 False positives, verbosity and developer response
  • 8.6 Self-review, cross-model review and shared blind spots
  • 8.7 Automation bias in software review
  • 8.8 Risk-based review allocation
  • 8.9 The review verdict is an artifact, not a comment count
  • 8.10 From comments to accountable acceptance
  • 8.11 Worked engineering example: review the riskiest uncertainty first
  • 8.12 Practice exercise: review two plausible agent pull requests
Struttura del capitolo
  • 8.1 Perché la review diventa la risorsa scarsa
  • 8.2 L'impatto della complessità e della provenienza del codice
  • 8.3 Interventi umani nelle pull request degli agent
  • 8.4 Che cosa trovano, e che cosa non trovano, gli AI reviewer
  • 8.5 Falsi positivi, verbosità e risposta degli sviluppatori
  • 8.6 Self-review, review tra modelli diversi e punti ciechi condivisi
  • 8.7 Automation bias nella code review
  • 8.8 Assegnare la review in base al rischio
  • 8.9 Il verdetto della review è un artefatto, non un conteggio di commenti
  • 8.10 Dai commenti all'accettazione responsabile
  • 8.11 Esempio svolto: esaminare prima l'incertezza più rischiosa
  • 8.12 Esercizio: esaminare due pull request plausibili create da agent
Publication status
PUBLISHED_AUTHOR_CONFIRMED
Original source file
EN/chapters/chapter08.tex
Original SHA-256
b542b5aa04f66dd3fb402a4780f9ed7dacf076a6f2827d7b083887467b50e92a
Provenance
Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.
56 recorded source relationships

These retain the graph’s exact relation labels. A connection is not automatically a causal claim or an independent replication.

All preserved graph attributes
{
  "chapter_number": 8,
  "chapter_hub": "C:C08",
  "title": "Code Review and Trust Calibration",
  "title_it": "Code review e calibrazione della fiducia",
  "summary": "Allocates review effort by consequence and uncertainty. It examines human and AI reviewers, false positives, shared blind spots and automation bias, then separates finding disposition, coverage of acceptance obligations and the accountable release verdict.",
  "summary_it": "Distribuisce il lavoro di revisione in base a conseguenze e incertezza. Esamina reviewer umani e AI, falsi positivi, punti ciechi condivisi e automation bias, distinguendo la gestione delle osservazioni, la copertura degli obblighi di accettazione e il verdetto di rilascio.",
  "author": "Enrico Papalini",
  "volume_id": "V06",
  "edition_id": "EDITION:NDSE2:13.7.1",
  "source_version": "13.7.1",
  "source_file": "EN/chapters/chapter08.tex",
  "source_sha256": "b542b5aa04f66dd3fb402a4780f9ed7dacf076a6f2827d7b083887467b50e92a",
  "source_file_it": "ITA/chapters/chapter08.tex",
  "source_sha256_it": "698ba9efd6ff328bcf2e7bfeb9f9136b14e933dad466c0b23d1fcbc789928824",
  "learning_goals_json": "[\"allocate review effort by consequence and uncertainty\", \"recognize when two reviewers share the same error source\", \"distinguish the disposition of a review finding, coverage of acceptance obligations and release authority\"]",
  "learning_goals_it_json": "[\"distribuire l'impegno della review in base alle conseguenze e all'incertezza\", \"riconoscere quando due reviewer condividono la stessa fonte di errore\", \"distinguere l'esito di un finding di review, la copertura degli obblighi di accettazione e l'autorità necessaria per la release\"]",
  "publication_status": "PUBLISHED_AUTHOR_CONFIRMED",
  "provenance": "Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.",
  "evidence_class": "Published author chapter; engineering synthesis",
  "limitation": "Author engineering synthesis and teaching material; publication is not independent empirical validation.",
  "label": "Code Review and Trust Calibration",
  "kind": "published_book_chapter",
  "node_class": "NDSE2_PUBLISHED_EDITION_20261018"
}
View in atlas →Permanent entry link
NDSE2:C09NDSE2 chapters

System Understanding, Context and Persistent Memory

Enrico Papalini · 2026

Comprensione del sistema, context e memoria persistente

Treats context and persistent memory as claims with provenance, ownership and expiry. It develops software-specific knowledge records and invalidation rules, then uses a handoff and an explicitly limited retrieval comparison to test what a successor can reconstruct.

Chapter guide and cited sources →

Evidence, context & provenance
Evidence boundaryAuthor engineering synthesis and teaching material; publication is not independent empirical validation.

Source type, as recorded: Published author chapter; engineering synthesis

Learning goals

  • distinguish retrieved context from trusted system knowledge
  • design versioned memory with explicit invalidation rules
  • test a handoff by asking a new maintainer to reconstruct an operational decision from stored evidence
Obiettivi in italiano

Obiettivi di apprendimento

  • distinguere il context recuperato dalle conoscenze affidabili sul sistema
  • progettare una memoria versionata con regole esplicite di invalidation
  • verificare un handoff chiedendo a un nuovo maintainer di ricostruire una decisione operativa a partire dalle evidenze conservate
Chapter outline
  • 9.1 Why comprehension dominates brownfield work
  • 9.2 Mental models, rationale and cognitive load
  • 9.3 Authorship, ownership and stewardship
  • 9.4 Context assembly for an agent
  • 9.5 Different forms of persistent memory
  • 9.6 Memory consistency, decay and invalidation
  • 9.7 A typed graph for software-specific knowledge
  • 9.8 Turnover, succession and long-term maintenance
  • 9.9 A verified memory handoff
  • 9.9.1 A scripted evidence-retrieval comparison, not a comprehension experiment
  • 9.10 Worked engineering example: a memory fact needs a validity condition
  • 9.11 Practice exercise: build a memory that can be invalidated
Struttura del capitolo
  • 9.1 Perché la comprensione del sistema è centrale nel lavoro brownfield
  • 9.2 Modelli mentali, rationale e carico cognitivo
  • 9.3 Authorship, ownership e stewardship
  • 9.4 Comporre il context di un agent
  • 9.5 Le diverse forme di memoria persistente
  • 9.6 Coerenza, decadimento e invalidation della memoria
  • 9.7 Un grafo tipizzato per la conoscenza del software
  • 9.8 Turnover, successione e manutenzione di lungo periodo
  • 9.9 Un handoff della memoria sottoposto a verifica
  • 9.9.1 Un confronto di retrieval delle evidenze eseguito via script, non un esperimento sulla comprensione
  • 9.10 Esempio svolto: un fatto di memoria richiede una condizione di validità
  • 9.11 Esercizio pratico: costruire una memoria che possa essere invalidata
Publication status
PUBLISHED_AUTHOR_CONFIRMED
Original source file
EN/chapters/chapter09.tex
Original SHA-256
ab431c886c607f8a192a36336c3409fa0bf9b828d20ab6d16ffd74c162641029
Provenance
Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.
34 recorded source relationships

These retain the graph’s exact relation labels. A connection is not automatically a causal claim or an independent replication.

All preserved graph attributes
{
  "chapter_number": 9,
  "chapter_hub": "C:C09",
  "title": "System Understanding, Context and Persistent Memory",
  "title_it": "Comprensione del sistema, context e memoria persistente",
  "summary": "Treats context and persistent memory as claims with provenance, ownership and expiry. It develops software-specific knowledge records and invalidation rules, then uses a handoff and an explicitly limited retrieval comparison to test what a successor can reconstruct.",
  "summary_it": "Tratta context e memoria persistente come affermazioni con provenienza, responsabilità e validità. Sviluppa registrazioni della conoscenza software e regole di invalidazione, usando un passaggio di consegne e un confronto di recupero esplicitamente limitato per verificare ciò che un successore può ricostruire.",
  "author": "Enrico Papalini",
  "volume_id": "V06",
  "edition_id": "EDITION:NDSE2:13.7.1",
  "source_version": "13.7.1",
  "source_file": "EN/chapters/chapter09.tex",
  "source_sha256": "ab431c886c607f8a192a36336c3409fa0bf9b828d20ab6d16ffd74c162641029",
  "source_file_it": "ITA/chapters/chapter09.tex",
  "source_sha256_it": "87fbeee59f022f508080e38b413de15ce2b11b53515d7605560ddc60cb5244ea",
  "learning_goals_json": "[\"distinguish retrieved context from trusted system knowledge\", \"design versioned memory with explicit invalidation rules\", \"test a handoff by asking a new maintainer to reconstruct an operational decision from stored evidence\"]",
  "learning_goals_it_json": "[\"distinguere il context recuperato dalle conoscenze affidabili sul sistema\", \"progettare una memoria versionata con regole esplicite di invalidation\", \"verificare un handoff chiedendo a un nuovo maintainer di ricostruire una decisione operativa a partire dalle evidenze conservate\"]",
  "publication_status": "PUBLISHED_AUTHOR_CONFIRMED",
  "provenance": "Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.",
  "evidence_class": "Published author chapter; engineering synthesis",
  "limitation": "Author engineering synthesis and teaching material; publication is not independent empirical validation.",
  "label": "System Understanding, Context and Persistent Memory",
  "kind": "published_book_chapter",
  "node_class": "NDSE2_PUBLISHED_EDITION_20261018"
}
View in atlas →Permanent entry link
NDSE2:C10NDSE2 chapters

Developer Learning, Mentoring and Comprehension Debt

Enrico Papalini · 2026

Apprendimento, mentoring e debito di comprensione degli sviluppatori

Distinguishes assisted task completion from retained competence. Mentoring, explanations, repairs and deliberate practice lead to delayed retention and transfer checks; proposed competence measures remain instruments to validate rather than established scores.

Chapter guide and cited sources →

Evidence, context & provenance
Evidence boundaryAuthor engineering synthesis and teaching material; publication is not independent empirical validation.

Source type, as recorded: Published author chapter; engineering synthesis

Learning goals

  • distinguish finishing a task from learning to maintain it
  • design delayed retention and transfer checks
  • give junior developers meaningful responsibility without treating unvalidated competence scores as established measures
Obiettivi in italiano

Obiettivi di apprendimento

  • distinguere il completamento di un task dall'apprendimento necessario per mantenerlo
  • progettare verifiche differite della retention e del transfer
  • assegnare responsabilità significative agli sviluppatori junior senza presentare punteggi di competenza non validati come misure consolidate
Chapter outline
  • 10.1 Short-term task success versus retained understanding
  • 10.2 Comprehension debt is distinct from technical debt
  • 10.3 Novices, misconceptions and verification difficulty
  • 10.4 Cognitive offloading, physiology and limitations
  • 10.5 Learning through explanations, repairs and code tours
  • 10.6 Onboarding is a long process, not a first PR
  • 10.7 Mentoring and apprenticeship in a team with agents
  • 10.8 Measuring retention and engineering fluency
  • 10.9 A practical capability-development contract
  • 10.10 Worked engineering example: measure what the engineer remembers
  • 10.11 Practice exercise: test whether competence survives the assistant
Struttura del capitolo
  • 10.1 Completare un task non significa conservarne la comprensione
  • 10.2 Il debito di comprensione è diverso dal debito tecnico
  • 10.3 Principianti, fraintendimenti e difficoltà di verifica
  • 10.4 Cognitive offloading, fisiologia e limiti
  • 10.5 Imparare attraverso spiegazioni, correzioni e code tour
  • 10.6 Onboarding: un percorso, non la prima PR
  • 10.7 Mentoring e apprendistato in un team con agent
  • 10.8 Misurare retention e padronanza ingegneristica
  • 10.9 Un contratto pratico per lo sviluppo delle competenze
  • 10.10 Esempio svolto: misurare ciò che l'ingegnere ricorda
  • 10.11 Esercizio: verifica se la competenza rimane quando l'assistente non c'è
Publication status
PUBLISHED_AUTHOR_CONFIRMED
Original source file
EN/chapters/chapter10.tex
Original SHA-256
8c1523efe9ff14e391995db26334a679c629258003f891389e55b9183e57f36f
Provenance
Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.
44 recorded source relationships

These retain the graph’s exact relation labels. A connection is not automatically a causal claim or an independent replication.

All preserved graph attributes
{
  "chapter_number": 10,
  "chapter_hub": "C:C10",
  "title": "Developer Learning, Mentoring and Comprehension Debt",
  "title_it": "Apprendimento, mentoring e debito di comprensione degli sviluppatori",
  "summary": "Distinguishes assisted task completion from retained competence. Mentoring, explanations, repairs and deliberate practice lead to delayed retention and transfer checks; proposed competence measures remain instruments to validate rather than established scores.",
  "summary_it": "Distingue il completamento assistito di un compito dalla competenza conservata. Mentoring, spiegazioni, correzioni e pratica deliberata conducono a verifiche differite di ritenzione e trasferimento; le misure di competenza proposte restano strumenti da validare.",
  "author": "Enrico Papalini",
  "volume_id": "V06",
  "edition_id": "EDITION:NDSE2:13.7.1",
  "source_version": "13.7.1",
  "source_file": "EN/chapters/chapter10.tex",
  "source_sha256": "8c1523efe9ff14e391995db26334a679c629258003f891389e55b9183e57f36f",
  "source_file_it": "ITA/chapters/chapter10.tex",
  "source_sha256_it": "6222bf93c5aaff838c33613a03d0e0cbf6bd5a8ac293616b215d9ee5fd534e7f",
  "learning_goals_json": "[\"distinguish finishing a task from learning to maintain it\", \"design delayed retention and transfer checks\", \"give junior developers meaningful responsibility without treating unvalidated competence scores as established measures\"]",
  "learning_goals_it_json": "[\"distinguere il completamento di un task dall'apprendimento necessario per mantenerlo\", \"progettare verifiche differite della retention e del transfer\", \"assegnare responsabilità significative agli sviluppatori junior senza presentare punteggi di competenza non validati come misure consolidate\"]",
  "publication_status": "PUBLISHED_AUTHOR_CONFIRMED",
  "provenance": "Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.",
  "evidence_class": "Published author chapter; engineering synthesis",
  "limitation": "Author engineering synthesis and teaching material; publication is not independent empirical validation.",
  "label": "Developer Learning, Mentoring and Comprehension Debt",
  "kind": "published_book_chapter",
  "node_class": "NDSE2_PUBLISHED_EDITION_20261018"
}
View in atlas →Permanent entry link
NDSE2:C11NDSE2 chapters

Teams, Governance and the Engineering Organization

Enrico Papalini · 2026

Team, governance e organizzazione dell'ingegneria del software

Moves from individual output to team throughput and decision rights. Policy owners, makers, checkers and release authorities coordinate parallel work and late intention changes, with operational feedback and review capacity governing staged, reversible adoption.

Chapter guide and cited sources →

Evidence, context & provenance
Evidence boundaryAuthor engineering synthesis and teaching material; publication is not independent empirical validation.

Source type, as recorded: Published author chapter; engineering synthesis

Learning goals

  • assign policy, maker, checker and release responsibilities
  • coordinate parallel agents and late policy revisions safely
  • choose a reversible team-level adoption gate based on review load and operational outcomes
Obiettivi in italiano

Obiettivi di apprendimento

  • assegnare responsabilità su policy, maker, checker e release
  • coordinare in sicurezza agent paralleli e revisioni tardive della policy
  • scegliere un gate di adozione reversibile a livello di team in base al carico di review e agli esiti operativi
Chapter outline
  • 11.1 From individual productivity to team throughput
  • 11.2 New division of labor in engineering teams
  • 11.3 Policies that make expectations visible
  • 11.4 Executable policy as an engineering proposal
  • 11.5 Agile team work with agent-produced increments
  • 11.6 Human accountability, conflicts and escalation
  • 11.7 Maintainer load and newcomer participation
  • 11.8 Knowledge handoff and stewardship rights
  • 11.9 Staged deployment gates, not a guaranteed ROI
  • 11.10 Worked engineering example: coordinate parallel work under a new policy
  • 11.11 Practice exercise: govern concurrent agents after intention changes
Struttura del capitolo
  • 11.1 Dalla produttività individuale al throughput del team
  • 11.2 Una nuova divisione del lavoro nei team di ingegneria
  • 11.3 Policy che rendono esplicite le aspettative
  • 11.4 Una policy eseguibile come proposta ingegneristica
  • 11.5 Lavoro agile con incrementi prodotti dagli agent
  • 11.6 Responsabilità umana, conflitti ed escalation
  • 11.7 Carico dei maintainer e partecipazione dei nuovi contributori
  • 11.8 Handoff della conoscenza e diritti di stewardship
  • 11.9 Gate di deployment graduali, non un ROI garantito
  • 11.10 Esempio ingegneristico svolto: coordinare il lavoro parallelo dopo una nuova policy
  • 11.11 Esercizio pratico: governare agent concorrenti dopo un cambiamento dell'intenzione
Publication status
PUBLISHED_AUTHOR_CONFIRMED
Original source file
EN/chapters/chapter11.tex
Original SHA-256
18eb375b24343b3106d1530b9ca03a4a3dd0b88a58a34459858cd1f93cace300
Provenance
Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.
38 recorded source relationships

These retain the graph’s exact relation labels. A connection is not automatically a causal claim or an independent replication.

All preserved graph attributes
{
  "chapter_number": 11,
  "chapter_hub": "C:C11",
  "title": "Teams, Governance and the Engineering Organization",
  "title_it": "Team, governance e organizzazione dell'ingegneria del software",
  "summary": "Moves from individual output to team throughput and decision rights. Policy owners, makers, checkers and release authorities coordinate parallel work and late intention changes, with operational feedback and review capacity governing staged, reversible adoption.",
  "summary_it": "Passa dall'output individuale alla capacità di consegna del team e ai diritti decisionali. Responsabili delle policy, maker, checker e autorità di rilascio coordinano lavoro parallelo e cambiamenti tardivi delle intenzioni, governando un'adozione graduale e reversibile con feedback operativo e capacità di revisione.",
  "author": "Enrico Papalini",
  "volume_id": "V06",
  "edition_id": "EDITION:NDSE2:13.7.1",
  "source_version": "13.7.1",
  "source_file": "EN/chapters/chapter11.tex",
  "source_sha256": "18eb375b24343b3106d1530b9ca03a4a3dd0b88a58a34459858cd1f93cace300",
  "source_file_it": "ITA/chapters/chapter11.tex",
  "source_sha256_it": "d6d2c7ee5c616cbd5012cd7d666e360aaab4413958e73e0e92ef71db50b9edb1",
  "learning_goals_json": "[\"assign policy, maker, checker and release responsibilities\", \"coordinate parallel agents and late policy revisions safely\", \"choose a reversible team-level adoption gate based on review load and operational outcomes\"]",
  "learning_goals_it_json": "[\"assegnare responsabilità su policy, maker, checker e release\", \"coordinare in sicurezza agent paralleli e revisioni tardive della policy\", \"scegliere un gate di adozione reversibile a livello di team in base al carico di review e agli esiti operativi\"]",
  "publication_status": "PUBLISHED_AUTHOR_CONFIRMED",
  "provenance": "Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.",
  "evidence_class": "Published author chapter; engineering synthesis",
  "limitation": "Author engineering synthesis and teaching material; publication is not independent empirical validation.",
  "label": "Teams, Governance and the Engineering Organization",
  "kind": "published_book_chapter",
  "node_class": "NDSE2_PUBLISHED_EDITION_20261018"
}
View in atlas →Permanent entry link
NDSE2:C12NDSE2 chapters

Economics, Jobs, Risk and Evidence-Based Adoption

Enrico Papalini · 2026

Economia, lavoro, rischio e adozione basata sulle evidenze

Evaluates the economics of the whole engineering loop, including human effort, failed attempts, maintenance and risk. Employment evidence and alternative explanations remain separate from forecasts; adoption requires a counterfactual, uncertainty bounds and a reversal condition.

Chapter guide and cited sources →

Evidence, context & provenance
Evidence boundaryAuthor engineering synthesis and teaching material; publication is not independent empirical validation.

Source type, as recorded: Published author chapter; engineering synthesis

Learning goals

  • calculate full-loop rather than token-only cost
  • separate employment observations from causal forecasts
  • frame an AI adoption decision with an explicit counterfactual, uncertainty and rollback condition
Obiettivi in italiano

Obiettivi di apprendimento

  • calcolare il costo dell'intero loop, e non soltanto quello dei token
  • distinguere le osservazioni sull'occupazione dalle previsioni causali
  • formulare una decisione di adozione dell'AI con controfattuale, incertezza e condizione di rollback espliciti
Chapter outline
  • 12.1 Economics of the entire engineering loop
  • 12.2 Why cheap generation may increase total cost
  • 12.3 Choosing the least-cost adequate level of autonomy
  • 12.4 Estimating return without fabricated certainty
  • 12.5 Jobs, hiring, vacancy flows and unequal cohorts
  • 12.6 Alternative causes of junior-market change
  • 12.7 The apprenticeship and long-term skill economy
  • 12.8 Distributional effects and quality of forecasts
  • 12.9 A reversible, risk-adjusted adoption decision
  • 12.10 Worked engineering example: calculate a reversible adoption choice
  • 12.11 Practice exercise: write the adoption decision, not an ROI slogan
Struttura del capitolo
  • 12.1 L'economia dell'intero loop ingegneristico
  • 12.2 Perché una generazione economica può aumentare il costo totale
  • 12.3 Scegliere il livello di autonomia adeguato al costo minimo
  • 12.4 Stimare il ritorno senza inventare certezze
  • 12.5 Occupazione, assunzioni, flussi di vacancy e coorti differenti
  • 12.6 Cause alternative del cambiamento nel mercato junior
  • 12.7 L'apprendistato e l'economia delle competenze nel lungo periodo
  • 12.8 Effetti distributivi e qualità delle previsioni
  • 12.9 Una decisione di adozione reversibile e corretta per il rischio
  • 12.10 Esempio ingegneristico svolto: calcolare una scelta di adozione reversibile
  • 12.11 Esercizio pratico: scrivere una decisione di adozione, non uno slogan sul ROI
Publication status
PUBLISHED_AUTHOR_CONFIRMED
Original source file
EN/chapters/chapter12.tex
Original SHA-256
86c0ede476fd2a1b32d32f4ea86297429dd24aad34db3f6c7540431e1190ccbe
Provenance
Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.
46 recorded source relationships

These retain the graph’s exact relation labels. A connection is not automatically a causal claim or an independent replication.

All preserved graph attributes
{
  "chapter_number": 12,
  "chapter_hub": "C:C12",
  "title": "Economics, Jobs, Risk and Evidence-Based Adoption",
  "title_it": "Economia, lavoro, rischio e adozione basata sulle evidenze",
  "summary": "Evaluates the economics of the whole engineering loop, including human effort, failed attempts, maintenance and risk. Employment evidence and alternative explanations remain separate from forecasts; adoption requires a counterfactual, uncertainty bounds and a reversal condition.",
  "summary_it": "Valuta l'economia dell'intero ciclo ingegneristico, includendo lavoro umano, tentativi falliti, manutenzione e rischio. Mantiene separate evidenze sul lavoro, spiegazioni alternative e previsioni; l'adozione richiede un controfattuale, limiti d'incertezza e una condizione di reversibilità.",
  "author": "Enrico Papalini",
  "volume_id": "V06",
  "edition_id": "EDITION:NDSE2:13.7.1",
  "source_version": "13.7.1",
  "source_file": "EN/chapters/chapter12.tex",
  "source_sha256": "86c0ede476fd2a1b32d32f4ea86297429dd24aad34db3f6c7540431e1190ccbe",
  "source_file_it": "ITA/chapters/chapter12.tex",
  "source_sha256_it": "d1598543866ce040908920e04662bc2ffa6ff1831a4cf984240911bf9cd54924",
  "learning_goals_json": "[\"calculate full-loop rather than token-only cost\", \"separate employment observations from causal forecasts\", \"frame an AI adoption decision with an explicit counterfactual, uncertainty and rollback condition\"]",
  "learning_goals_it_json": "[\"calcolare il costo dell'intero loop, e non soltanto quello dei token\", \"distinguere le osservazioni sull'occupazione dalle previsioni causali\", \"formulare una decisione di adozione dell'AI con controfattuale, incertezza e condizione di rollback espliciti\"]",
  "publication_status": "PUBLISHED_AUTHOR_CONFIRMED",
  "provenance": "Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.",
  "evidence_class": "Published author chapter; engineering synthesis",
  "limitation": "Author engineering synthesis and teaching material; publication is not independent empirical validation.",
  "label": "Economics, Jobs, Risk and Evidence-Based Adoption",
  "kind": "published_book_chapter",
  "node_class": "NDSE2_PUBLISHED_EDITION_20261018"
}
View in atlas →Permanent entry link
NDSE2:C13NDSE2 chapters

Choosing Practices and Recognizing Their Limits

Enrico Papalini · 2026

Scegliere le pratiche e riconoscerne i limiti

Selects and combines practices from the observed problem rather than a fixed workflow. It compares proportionate responses, exposes over-engineering and unsafe shortcuts, and connects earlier volumes while asking which mechanisms can be omitted without losing the change obligations.

Chapter guide and cited sources →

Evidence, context & provenance
Evidence boundaryAuthor engineering synthesis and teaching material; publication is not independent empirical validation.

Source type, as recorded: Published author chapter; engineering synthesis

Learning goals

  • select a practice from an observed problem
  • combine practices without conflicting authority or stale evidence
  • justify omitting a mechanism while preserving the task's obligations
Obiettivi in italiano

Obiettivi di apprendimento

  • scegliere una pratica a partire da un problema osservato
  • combinare pratiche senza creare conflitti di autorità o usare evidenze obsolete
  • giustificare l'omissione di un meccanismo, preservando gli obblighi del task
Chapter outline
  • 13.1 Five decisions, one accountable outcome
  • 13.2 Compare two changes before building a workflow
  • 13.3 A compact symptom-to-action map
  • 13.4 Recognize over-engineering and unsafe shortcuts
  • 13.5 Working vocabulary
  • 13.6 Further reading through the Non-Deterministic series
  • 13.7 Worked engineering example: leave out what the change does not need
  • 13.8 Practice exercise: design the smallest adequate workflow
  • The last engineering decision: what can safely be left out?
Struttura del capitolo
  • 13.1 Cinque decisioni, un unico risultato di cui rispondere
  • 13.2 Confrontare due modifiche prima di costruire un workflow
  • 13.3 Una mappa sintetica dai sintomi alle azioni
  • 13.4 Riconoscere l'over-engineering e le scorciatoie insicure
  • 13.5 Vocabolario operativo
  • 13.6 Per approfondire: la serie Non-Deterministic
  • 13.7 Esempio ingegneristico svolto: lasciare fuori ciò che non serve alla modifica
  • 13.8 Esercizio pratico: progettare il workflow minimo adeguato
  • L'ultima decisione ingegneristica: che cosa possiamo lasciare fuori senza rischi?
Publication status
PUBLISHED_AUTHOR_CONFIRMED
Original source file
EN/chapters/chapter13.tex
Original SHA-256
3fc3434f5ac2348bb0e7a15d100650848db78e857201849955543d4b08405bfa
Provenance
Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.
2 recorded source relationships

These retain the graph’s exact relation labels. A connection is not automatically a causal claim or an independent replication.

All preserved graph attributes
{
  "chapter_number": 13,
  "chapter_hub": "C:C13",
  "title": "Choosing Practices and Recognizing Their Limits",
  "title_it": "Scegliere le pratiche e riconoscerne i limiti",
  "summary": "Selects and combines practices from the observed problem rather than a fixed workflow. It compares proportionate responses, exposes over-engineering and unsafe shortcuts, and connects earlier volumes while asking which mechanisms can be omitted without losing the change obligations.",
  "summary_it": "Seleziona e combina le pratiche a partire dal problema osservato. Confronta risposte proporzionate, rende visibili sovraingegnerizzazione e scorciatoie rischiose e collega i volumi precedenti, chiedendo quali meccanismi si possano omettere preservando gli obblighi del cambiamento.",
  "author": "Enrico Papalini",
  "volume_id": "V06",
  "edition_id": "EDITION:NDSE2:13.7.1",
  "source_version": "13.7.1",
  "source_file": "EN/chapters/chapter13.tex",
  "source_sha256": "3fc3434f5ac2348bb0e7a15d100650848db78e857201849955543d4b08405bfa",
  "source_file_it": "ITA/chapters/chapter13.tex",
  "source_sha256_it": "fc97b394346165efc6abeeaf66622b340180b38446227e61b7ae9e8bf3c58d0b",
  "learning_goals_json": "[\"select a practice from an observed problem\", \"combine practices without conflicting authority or stale evidence\", \"justify omitting a mechanism while preserving the task's obligations\"]",
  "learning_goals_it_json": "[\"scegliere una pratica a partire da un problema osservato\", \"combinare pratiche senza creare conflitti di autorità o usare evidenze obsolete\", \"giustificare l'omissione di un meccanismo, preservando gli obblighi del task\"]",
  "publication_status": "PUBLISHED_AUTHOR_CONFIRMED",
  "provenance": "Author-supplied final EN/ITA 13.7.1 LaTeX sources; publication confirmed by the author on 2026-10-18.",
  "evidence_class": "Published author chapter; engineering synthesis",
  "limitation": "Author engineering synthesis and teaching material; publication is not independent empirical validation.",
  "label": "Choosing Practices and Recognizing Their Limits",
  "kind": "published_book_chapter",
  "node_class": "NDSE2_PUBLISHED_EDITION_20261018"
}
View in atlas →Permanent entry link