AISE502/Folien/Planung_7-13_json/L12.json

{
  "lecture": 12,
  "week": 12,
  "lessons": 3,
  "title": "Lecture 12: The AI Dimension I -- Axis A Evidence, Axis B Foundations",
  "script_reference": "Script: Part V, Sections 40--41, 42.1--42.5",
  "agenda": [
    "Two axes, one method -- Assumption A6 falls due",
    "Axis A: two contradictory RCTs and the empirical record",
    "Reconciling the divergence; the verification bottleneck (Maxim 7); Axis A compact",
    "Axis B: the news-sentiment call, wired the obvious way",
    "The three component types; why containment: the SE4AI classics",
    "The reference architecture: LLM gateway, queue, ontology guard",
    "The eval harness as an engineering artefact",
    "This week's exercise: AdvisorAgent + sub-agents behind the gateway"
  ],
  "recap": [
    "Parts I--IV complete; Lecture 11 closed Part IV: fitness functions -- three families (dependency gates, budgets, chaos experiments); the four-layer cascade and the eight-row C10 reference contract; cost of change flat within / steep across architecture boundaries; Conway -- the fit is three-way; six limits; Maxim 9 -- Part IV closed",
    "AI Lens threads so far -- deck 1: the two AI axes and Assumption A6; deck 3: an LLM component stresses D3, D10, D12; an agent drafts the ADR, a human owns the decision; ADR-011: all LLM calls through one gateway port",
    "Deck 6: C10 profile -- D12 = H, evals as the operative meaning of testability, cost per request; outlook: agent orchestration reuses the catalogue's topologies, workflows before agents (15x token finding); deck 11: fitness functions are the operating licence for agents (A); eval pass rate and token budget are fitness functions with old mechanics (B)",
    "Today: Part V redeems A6 systematically -- the two axes as one method; the Axis A evidence and its resolution; the Axis B foundations up to the eval harness",
    "Project: M4 delivered (deterministic core fully tested and resilient); M5 begins -- AdvisorAgent + 2--3 sub-agents behind the gateway, ontology guard active; the reference architecture today is just-in-time"
  ],
  "frames": [
    {
      "no": 1,
      "deck_section": "Title",
      "title": "AISE502: AI in Software Engineering II -- Lecture 12: The AI Dimension I -- Axis A Evidence, Axis B Foundations",
      "kind": "content",
      "script_ref": "Title slide; metadata block copied from deck 6 (AISE502_Vorlesung_6_Folien.tex 116-120)",
      "content": [
        "\\title[AI in Software Engineering II]{AISE502: AI in Software Engineering II}",
        "\\subtitle{Lecture 12: The AI Dimension I -- Axis A Evidence, Axis B Foundations\\\\[0.4ex]{\\small Script: Part V, Sections 40--41, 42.1--42.5}}",
        "\\author{Dr.\\ Florian Herzog}; \\shortname{AISE502}; \\fullname{Fachhochschule Graub\\\"unden, Chur -- Autumn Semester 2026}"
      ],
      "elements": [
        "FHGR title page (theme)"
      ],
      "minutes": 0,
      "notes": "Copy deck 6 lines 116-120 verbatim and change only the subtitle. Institution typeset as Graub\\\"unden."
    },
    {
      "no": 2,
      "deck_section": "Agenda",
      "title": "Agenda",
      "kind": "agenda",
      "script_ref": "Deck skeleton; semester plan week 12 row (Semesterplan_AISE502_HS26.md line 23)",
      "content": [
        "1. Two axes, one method -- Assumption A6 falls due",
        "2. Axis A: two contradictory RCTs and the empirical record",
        "3. Reconciling the divergence; the verification bottleneck (Maxim 7); Axis A compact",
        "4. Axis B: the news-sentiment call, wired the obvious way",
        "5. The three component types; why containment: the SE4AI classics",
        "6. The reference architecture: LLM gateway, queue, ontology guard",
        "7. The eval harness as an engineering artefact",
        "8. This week's exercise: AdvisorAgent + sub-agents behind the gateway"
      ],
      "elements": [
        "\\small enumerate, as deck 6 lines 132-144"
      ],
      "minutes": 1,
      "notes": "Eight one-line items (items 3 and 4 of the previous version merged)."
    },
    {
      "no": 3,
      "deck_section": "Recap",
      "title": "Recap: where we are",
      "kind": "recap",
      "script_ref": "Deck 11 summary frame 38 (bullets 1, 3, 4, 6, 7, 8) and AI Lens frames 20-21 (L11 plan); deck 6 summary and AI Lens frames (deck 6 lines 254-263, 498-521, 555-638); deck 3 lines 350-366, 560-606; semester plan row 12 (line 23); exercise sheet M4/M5 (project_exercise.tex 424-442)",
      "content": [
        "Parts I--IV complete; Lecture 11 closed Part IV: fitness functions -- three families (dependency gates, budgets, chaos experiments); the four-layer cascade and the eight-row C10 reference contract; cost of change flat within / steep across architecture boundaries; Conway -- the fit is three-way; six limits; Maxim 9 -- Part IV closed",
        "AI Lens threads so far -- deck 1: the two AI axes and Assumption A6; deck 3: an LLM component stresses D3, D10, D12; an agent drafts the ADR, a human owns the decision; ADR-011: all LLM calls through one gateway port",
        "Deck 6: C10 profile -- D12 = H, evals as the operative meaning of testability, cost per request; outlook: agent orchestration reuses the catalogue's topologies, workflows before agents (15x token finding); deck 11: fitness functions are the operating licence for agents (A); eval pass rate and token budget are fitness functions with old mechanics (B)",
        "Today: Part V redeems A6 systematically -- the two axes as one method; the Axis A evidence and its resolution; the Axis B foundations up to the eval harness",
        "Project: M4 delivered (deterministic core fully tested and resilient); M5 begins -- AdvisorAgent + 2--3 sub-agents behind the gateway, ontology guard active; the reference architecture today is just-in-time"
      ],
      "elements": [
        "\\footnotesize bullets, five, each at most three lines (bullets 1 and 3 run to three); no box"
      ],
      "minutes": 3,
      "notes": "One frame only; name the AI Lens boxes, do not re-teach them. Bullet 1 condenses deck 11's summary bullets 1, 3, 4 and 8 (plus the Conway and six-limits bullets 6 and 7 as half-clauses); in speech, name the two AI rows of the C10 reference contract (AI correctness = eval-harness pass rate, triggered; AI cost = token budget per request, continual) -- they are the immediate predecessors of today's guardrails (frame 16) and eval harness (frame 36, 'thresholds in the measurement contract'). Bullet 3 ends with deck 11's two AI Lens frames, so the AI Lens thread now runs deck 1 -> 3 -> 6 -> 11 without a gap."
    },
    {
      "no": 4,
      "deck_section": "Two Axes, One Method",
      "title": "Part V opens: the promissory note falls due",
      "kind": "content",
      "script_ref": "§40 intro (part5_ai_dimension.tex 10-12)",
      "content": [
        "Leading question (italic, bankblue): Four parts built a complete decision theory without ever making artificial intelligence its subject -- does the construction survive the technology that defines its decade?",
        "Not a rhetorical flourish but a promissory note falling due: Part I issued it as Assumption A6 -- AI components extend the quality attribute space but do not change the method. The bet in two sentences: everything AI does to software engineering can be absorbed by the apparatus you now own",
        "If AI-bearing systems required a genuinely different method, the bet would be lost -- this part is where the claim must survive contact with the evidence",
        "Roadmap line: cases first, generalisation after -- two contradictory randomised experiments open Axis A (§41); one concrete LLM call, wired wrongly and then rightly, opens Axis B (§42); the matrix reading (§43) and the emergent pattern (§44) follow next week"
      ],
      "elements": [
        "Leading question in italic bankblue; three \\small bullets; no box (the keypoint moves to frame 5)"
      ],
      "minutes": 3,
      "notes": "Opening frame in the deck 4-6 style: question, one short paragraph, roadmap line. The list of apparatus items (scenarios, tactics, profiles, ADRs, fitness functions) is spoken here and printed on frame 5's caption line."
    },
    {
      "no": 5,
      "deck_section": "Two Axes, One Method",
      "title": "The two axes of the AI dimension",
      "kind": "definition",
      "script_ref": "§40 definitionbox (part5_ai_dimension.tex 14-21), fig:twoaxes (25-48), keypoint (50-52)",
      "content": [
        "Definition (left column): Axis A -- AI as a tool in the SDLC. Code assistants, agentic coding tools, review bots participate in building the software: they generate code, tests, documentation, draft design artefacts. The software that ships may contain no AI at all. Unit of analysis: the development process and its economics",
        "Axis B -- AI as a runtime component. LLM services, trained ML models, optimisation solvers are part of the delivered system and execute in production. Unit of analysis: the running system and its quality attributes",
        "The axes are independent: a classical payroll system built with heavy agent support (A without B); a hand-crafted AI-native advisory platform (B without A). In practice, and in the course project, both apply simultaneously -- which is why they must be kept conceptually apart",
        "Figure (right column): Axis A (AI as tool: agents, assistants) -> Development process (specify, build, verify, operate), arrow 'shifts SDLC economics'; Axis B (AI as component: LLM, ML, solver) -> Delivered system (structure, quality attributes), arrow 'stretches quality attribute space'; process -> system 'produces'",
        "Caption line beneath the figure: Axis A changes how systems are built; Axis B what the built system contains -- both absorbed by the same method: scenarios, tactics, profiles, ADRs, fitness functions",
        "Key Concept (one \\footnotesize line under both columns): Two axes, one method -- Axis A changes how systems are built, Axis B what they contain; the axes are independent and must be kept apart -- and both are analysed with the apparatus of Parts I--IV, nothing new"
      ],
      "elements": [
        "definitionbox[The two axes of the AI dimension] (lines 14-21), \\footnotesize, left column 0.52, each item at most two lines",
        "tikz fig:twoaxes (lines 25-48) redrawn in the right column 0.44: rounded rectangles, aiviolet for the two axis boxes, bankgreen process box, bankblue system box",
        "keypoint 'Two axes, one method' (lines 50-52) as one \\footnotesize line spanning the frame bottom"
      ],
      "minutes": 4,
      "notes": "Two columns [T]. Definition first, key concept after it (script order, decks 4-6 order). If the keypoint box pushes the columns down, use \\vspace{-1ex} and shorten the third definition item to one line."
    },
    {
      "no": 6,
      "deck_section": "Axis A -- Evidence and Resolution",
      "title": "Case 1 -- the Copilot RCT: +55.8\\,\\% on a greenfield task",
      "kind": "case",
      "script_ref": "§41 intro + §41.1 (part5_ai_dimension.tex 60-65)",
      "content": [
        "Leading question (italic): AI makes developers 55.8\\,\\% faster -- or 19\\,\\% slower. Which study is wrong? Both numbers come from randomised controlled trials, both methodologically sound; few topics in software engineering carry a larger gap between headline and evidence",
        "Case 1 (published 2023): 95 professional developers randomly split into two groups; same task -- implement an HTTP server in JavaScript; one group with GitHub Copilot, one without; the clock measured time to completion",
        "The treatment group finished 55.8\\,\\% faster",
        "Qualification 1: the confidence interval (21--89\\,\\%) is very wide -- the headline number is a point estimate, not a natural constant",
        "Qualification 2: a bounded, well-defined greenfield exercise -- no legacy context, no architectural constraints, no review process",
        "Qualification 3: speed was measured, not quality; completion rates did not differ significantly",
        "Within those bounds the result is real -- and it is the origin of the 'AI doubles productivity' headline genre"
      ],
      "elements": [
        "Leading question in italic bankblue; \\small bullets; the 55.8\\,\\% and the CI in bold. No \\measured box (the macro is defined only in deck 2's preamble, line 114; deck 6's preamble does not carry it)"
      ],
      "minutes": 4,
      "notes": "Read as an experiment, not as a headline: setting first, finding second. All percentages typeset with the thin space \\,\\% throughout the deck."
    },
    {
      "no": 7,
      "deck_section": "Axis A -- Evidence and Resolution",
      "title": "Case 2 -- the METR RCT: 19\\,\\% slower in your own mature codebase",
      "kind": "case",
      "script_ref": "§41.2 (part5_ai_dimension.tex 67-70); the 'So which study is wrong? Neither' paragraph (line 72) moves to frame 11",
      "content": [
        "Leading question (italic): What happens when the same technology meets experts on their own terrain?",
        "16 experienced open-source maintainers; 246 real issues in repositories they had maintained for years -- large, mature codebases (over a million lines) with high implicit quality standards; each issue randomly assigned to an AI-allowed condition (predominantly Cursor with frontier models of early 2025) or an AI-forbidden condition",
        "With AI, the developers took 19\\,\\% longer",
        "The perception data are the didactic core: forecast before the study +24\\,\\% speed-up; measured --19\\,\\%; post-hoc estimate +20\\,\\% faster -- even experts cannot validly introspect their own AI-assisted productivity",
        "METR's own explanation maps boundary conditions rather than refuting Case 1: deep repository familiarity left little for AI-supplied context to add; codebases large and conventionally dense; substantial time spent checking, repairing, discarding AI proposals"
      ],
      "elements": [
        "Leading question in italic; the three perception numbers (+24\\,\\%, --19\\,\\%, +20\\,\\%) in bold; five \\footnotesize bullets"
      ],
      "minutes": 4,
      "notes": "The perception gap is the single most instructive fact of the section -- dwell on it. Do not answer 'which study is wrong' here; the answer opens the moderator table (frame 11)."
    },
    {
      "no": 8,
      "deck_section": "Axis A -- Evidence and Resolution",
      "title": "The full empirical record, 2023--2025",
      "kind": "table",
      "script_ref": "§41.3 intro + tab:aievidence (part5_ai_dimension.tex 77-103); Ziegler caution from the 'Field experiments at scale' paragraph (line 105)",
      "content": [
        "Intro (one \\footnotesize line): the two cases are the extreme corners of a larger record -- seven strands, 2023--2025, from randomised experiments to organisational telemetry and longitudinal code analysis; read every row setting first, finding second",
        "Row Copilot RCT | 95 developers; greenfield HTTP server (JavaScript) | +55.8\\,\\% task speed (95\\,\\% CI 21--89\\,\\%); completion rate not significantly different",
        "Row Three field experiments | 4,867 developers; Microsoft, Accenture, Fortune-100 firm | +26.1\\,\\% completed tasks (s.e. 10.3\\,\\%); less experienced developers gain most",
        "Row METR RCT | 16 expert OSS maintainers; 246 real issues, own mature repositories | 19\\,\\% slower with AI -- while estimating afterwards that AI had made them 20\\,\\% faster",
        "Row DORA 2024 | ~3,000 respondents; organisational delivery level | +25\\,\\% AI adoption associated with --1.5\\,\\% throughput and --7.2\\,\\% delivery stability",
        "Row DORA 2025 | ~5,000 respondents | throughput association now positive; instability persists; AI acts as an amplifier of existing strengths and dysfunctions",
        "Row GitClear longitudinal | 211 million changed code lines, 2020--2024 | 4x growth in code duplication; moved-code share (the refactoring signature) collapsed from ~25\\,\\% to below 10\\,\\%",
        "Row Stack Overflow survey | >49,000 developers | 84\\,\\% use or plan to use AI; 46\\,\\% actively distrust its output; top frustration: 'almost right' code",
        "\\scriptsize note line under the table: methodological caution from GitHub's own telemetry-plus-survey study -- the best predictor of perceived productivity is the suggestion acceptance rate, not the persistence of accepted code in the repository; much vendor-reported 'productivity' evidence measures perception, not verified output. Case 2's perception gap is the controlled-trial demonstration of the same fact"
      ],
      "elements": [
        "7-row scriptsize booktabs table Evidence | Setting | Finding with p{2.4cm}p{4.0cm}p{6.0cm} (12.4 cm) and \\renewcommand{\\arraystretch}{0.85}, Setting cells one line each, headline numbers in bold, from tab:aievidence lines 79-103; one \\scriptsize note line beneath"
      ],
      "minutes": 3,
      "notes": "Former frame 9 dropped; its only non-duplicate content (the Ziegler acceptance-rate caution, line 105) is the note line under the table; the 'juniors and task novices benefit most' pattern is spoken with row 2. Compile-check the height; if it overflows, split (1/2) rows 1-3 experiments and (2/2) rows 4-7 organisation, code, survey (frame count 43, still in band)."
    },
    {
      "no": 9,
      "deck_section": "Axis A -- Evidence and Resolution",
      "title": "The system level: DORA 2024 and 2025",
      "kind": "content",
      "script_ref": "§41.3 paragraph 'The system level: DORA 2024 and 2025' (part5_ai_dimension.tex 107)",
      "content": [
        "DORA measures neither task times nor perceptions but delivery performance at the level of the organisation -- throughput and stability -- exactly the level at which architecture acts",
        "2024 (~3,000 respondents; 75.9\\,\\% use AI for at least part of their work, roughly three quarters report productivity gains) -- a 25\\,\\% increase in AI adoption is associated with: mini-table left column +7.5\\,\\% documentation quality, +3.4\\,\\% code quality, +3.1\\,\\% review speed | right column --1.5\\,\\% delivery throughput, --7.2\\,\\% delivery stability. Proposed mechanism is classical: more code per change, and larger batch sizes have been a documented risk driver for years",
        "2025 (~5,000 respondents): adoption near saturation (90\\,\\%, median about two hours of daily use); more than 80\\,\\% report productivity gains; 30\\,\\% still express little or no trust in AI-generated code; the throughput association has turned positive as tools and practices matured -- the negative association with delivery stability persists",
        "Central metaphor: AI is an amplifier -- it magnifies the strengths of well-run organisations and the dysfunctions of badly run ones",
        "Individual acceleration and system-level performance are different quantities, and only the second one pays salaries"
      ],
      "elements": [
        "\\footnotesize bullets, five; the 2024 associations as a two-column \\scriptsize mini-table (gains | losses) inside bullet 2"
      ],
      "minutes": 3,
      "notes": "Connect to Lecture 11 (four DORA metrics) in speech only; do not add content beyond §41.3."
    },
    {
      "no": 10,
      "deck_section": "Axis A -- Evidence and Resolution",
      "title": "Code structure and practitioner trust in the longitudinal record",
      "kind": "content",
      "script_ref": "§41.3 paragraphs 'Code structure in the longitudinal record' and 'Practitioner trust' (part5_ai_dimension.tex 109-111)",
      "content": [
        "GitClear, 211 million changed lines (2020--2024): duplicated code blocks (five or more lines) at four times their pre-AI level in 2024; moved lines -- the fingerprint of refactoring and modularisation -- fell from roughly 25\\,\\% to under 10\\,\\%: 2024 was the first year in which copy-paste exceeded code movement",
        "Churn -- code reworked or discarded within two weeks of commit -- rose from a pre-AI baseline of roughly 3--4\\,\\% to 5.7\\,\\% in 2024, trend continuing; two obligatory caveats: GitClear is a commercial analytics vendor, and the analysis is correlational -- AI's causal share is plausible but not isolated",
        "Converges with DORA's stability data: more code, produced faster, structurally worse maintained -- reuse by abstraction displaced by reuse by duplication, the opposite of what Parnas-style modularisation (Part II) works to achieve",
        "Stack Overflow 2025 (>49,000 developers): 84\\,\\% use or plan to use AI tools; 46\\,\\% actively distrust the accuracy of the output; most-cited frustration (45\\,\\%): 'almost right, but not quite' -- adoption rises while trust falls, consistent with METR and DORA: the effort has migrated from writing to verifying"
      ],
      "elements": [
        "\\footnotesize bullets, four; GitClear and Stack Overflow headline numbers in bold"
      ],
      "minutes": 4,
      "notes": "The 8.3\\,\\% -> 12.3\\,\\% copy-paste share, the 3\\,\\% high-trust figure and the 66\\,\\% 'more time fixing almost-right code' figure are spoken, not printed (the 66\\,\\% returns as 'two thirds' on frame 13). The last bullet is the bridge to the bottleneck frame."
    },
    {
      "no": 11,
      "deck_section": "Axis A -- Evidence and Resolution",
      "title": "Reconciling the divergence: five moderator variables",
      "kind": "table",
      "script_ref": "§41.2 closing paragraph (part5_ai_dimension.tex 72) as the intro; §41.4 intro + tab:moderators (113-134)",
      "content": [
        "Intro (\\footnotesize): So which study is wrong? Neither -- resolving the contradiction is the lesson: different populations (task novices versus domain experts in their own code), different codebases (greenfield versus mature), different tasks (bounded versus real issues) -- the results never actually compete; the resolution requires reading study designs, not abstracts",
        "The apparent contradictions dissolve once the studies are indexed by their moderator variables: Case 1 and Case 2 sit at opposite corners of a five-dimensional design space, and every other row of the record finds its place in the same coordinates",
        "Row Experience | juniors, task novices (Copilot RCT, field experiments) | domain experts in their own code (METR)",
        "Row Codebase | greenfield, small, standard stack | mature, large, dense implicit conventions",
        "Row Task | well-defined, bounded | under-specified, cross-cutting",
        "Row Measurement | task time, perceived productivity | delivery stability, maintainability, churn (DORA 2024, GitClear)",
        "Row Organisation | small batches, test automation, loose coupling | large batches, weak guardrails, tight coupling (DORA 2025)",
        "Closing line: the same technology yields +55.8\\,\\% and --19\\,\\% because the two cases differ on every one of the five rows"
      ],
      "elements": [
        "5-row footnotesize booktabs table Moderator | Gains high | Gains low or negative, p{2.2cm}p{5.0cm}p{5.2cm} (12.4 cm), from tab:moderators lines 118-134"
      ],
      "minutes": 4,
      "notes": "This table is the intellectual answer to the leading question of frame 6 -- announce it as such; the intro paragraph is the script's own 'Neither' answer, moved here from Case 2."
    },
    {
      "no": 12,
      "deck_section": "Axis A -- Evidence and Resolution",
      "title": "Discussion: which setting is yours?",
      "kind": "discussion",
      "script_ref": "§41.4 thinkbox (part5_ai_dimension.tex 136-138)",
      "content": [
        "The same class of technology produced +55.8\\,\\% in one randomised experiment and --19\\,\\% in another. Walk through the five moderators: on which rows do the two studies differ?",
        "Consider the systems you are likely to work on two years after graduation -- greenfield exercises, or mature codebases with implicit conventions? Which study's setting is closer to that reality?",
        "What does the METR perception gap (forecast +24\\,\\%, measured --19\\,\\%, post-hoc estimate +20\\,\\%) imply about relying on your own felt productivity as evidence?",
        "One-line codegray aside beneath the box (outside the thinkbox, marked 'Project transfer'): which moderator row describes your repository in week 12?"
      ],
      "elements": [
        "thinkbox 'Discussion' with the script's three questions, \\footnotesize; a \\scriptsize codegray aside beneath it for the project transfer"
      ],
      "minutes": 4,
      "notes": "Four minutes of plenum discussion; keep the moderator table of frame 11 in speech. The project-transfer question is not script text -- it stays outside the box."
    },
    {
      "no": 13,
      "deck_section": "Axis A -- Evidence and Resolution",
      "title": "The verification bottleneck",
      "kind": "content",
      "script_ref": "§41.5 (part5_ai_dimension.tex 143-145)",
      "content": [
        "The structural conclusion underneath the moderator table, in one sentence (centred, bold): code generation became cheap; specification, verification, and architecture became the binding constraints",
        "When the marginal cost of producing plausible code approaches zero, the scarce resource is no longer typing but everything that surrounds it: understanding the requirement precisely enough to specify it, reviewing and testing what was generated, and accepting responsibility for shipping it",
        "The strands converge: DORA -- individual acceleration coexists with delivery instability where control systems are weak; two thirds of surveyed developers spend more time on almost-right code; a substantial share of METR's slow-down is time spent checking, repairing, discarding AI proposals; industry analyses describe code review as the new bottleneck -- more and larger pull requests meeting unchanged human review capacity",
        "Economically put: AI lowers the cost of producing code, not the cost of taking responsibility for code"
      ],
      "elements": [
        "\\small bullets; the one-sentence conclusion set as a centred bold line"
      ],
      "minutes": 3,
      "notes": "Keep it sparse; the next frame carries the three consequences."
    },
    {
      "no": 14,
      "deck_section": "Axis A -- Evidence and Resolution",
      "title": "Three consequences bind Axis A into the fit theory -- Maxim 7",
      "kind": "keyconcept",
      "script_ref": "§41.5 enumerate + keypoint Maxim 7 (part5_ai_dimension.tex 147-155)",
      "content": [
        "1. Architecture quality gates AI gains -- DORA 2025's core finding: teams in loosely coupled architectures with fast feedback loops convert AI adoption into throughput; tightly coupled systems with slow processes do not -- the AI-era echo of loosely coupled architectures and teams as the strongest predictor of continuous delivery performance (the coupling finding of Lecture 11)",
        "In the theory's vocabulary: D7 (evolvability) and D9 (testability and deployability) gain weight in every requirements profile -- architecture--application fit acquires a second reading: fit to a mode of work in which change volume rises by an order of magnitude",
        "2. Architecture documentation becomes a control interface -- ADRs, repository convention files, and machine-readable rules are no longer passive records; agents execute them on every run (§41.6)",
        "3. Fitness functions become the operating licence for agents -- an agent iterating against a dense test suite and CI-enforced architecture rules is contained; without them, every agent change is unpriced risk (§41.7)",
        "Key Concept -- Maxim 7: Good architecture was always the art of making change cheap and safe; AI raises the change rate by an order of magnitude -- and therefore raises, not lowers, the value of architecture"
      ],
      "elements": [
        "numbered list \\footnotesize",
        "keypoint box 'Maxim 7' (lines 153-155) verbatim"
      ],
      "minutes": 4,
      "notes": "Maxim 7 is examinable; set it apart visually. Each consequence 'is measurable' -- say so. The D7/D9 reading is the new content; the coupling finding is marked as Lecture 11's."
    },
    {
      "no": 15,
      "deck_section": "Axis A -- Control Interface and Guardrails",
      "title": "Architecture documentation as a control interface for agents",
      "kind": "content",
      "script_ref": "§41.6 text + lst:agentsmd (part5_ai_dimension.tex 160-188), condensed per semester plan ('Guardrails (kompakt)')",
      "content": [
        "Agentic tools are context-driven: they produce architecture-conformant code only if the architecture is explicit, machine-readable, and in the repository -- Part I's documentation artefacts, written for human readers, upgrade into a control interface for machine collaborators. ADRs (preferably MADR) serve agents twice: as input context (why is the system structured this way? which options were rejected, and why?) and as output format -- an agent drafts, a human decides and signs, per Assumption A1 (deck 3)",
        "Agent instruction files -- project-local CLAUDE.md and the vendor-neutral AGENTS.md (published 2025, adopted within months by over 60,000 open-source repositories) -- carry stack, conventions, build and test commands, module boundaries, no-go zones; loaded at every session start: documentation once 'too expensive to maintain for human readers' now amortises because it is executed on every agent run. Machine-checkable conventions (dependency directions, naming, layering) are a failing test rather than a prose exhortation -- the fitness-function discipline of Part IV",
        "The corollary cuts both ways: documentation debt is now reproduced at machine speed -- a stale convention file or ADR is executed by every agent session; DORA 2025: 'AI-accessible internal knowledge' and healthy data ecosystems rank among the seven capabilities that amplify AI benefits",
        "Listing (excerpt from the course project's agent instruction file): '# Portfolio Intelligence Platform -- agent instructions'",
        "'## Architecture (binding; see docs/adr/)' -- Modular monolith, module boundaries enforced by CI (see fitness_functions/boundaries_test.py). Do not add cross-module imports; use the module's public API. -- All LLM access goes through gateway/ -- never call a provider SDK from domain code (ADR-011)",
        "'## Verification (run before proposing changes)' -- make test (unit + module-boundary rules); make evals (eval harness; required for any change under prompts/ or gateway/)",
        "'## No-go zones' -- ledger/: append-only audit journal. Propose changes as an ADR draft instead of editing code",
        "One \\scriptsize caption line beneath the listing: every line is a control statement that an agent executes on each run -- and that therefore must be kept as current as code"
      ],
      "elements": [
        "three \\footnotesize bullets (each at most three lines) above the listing; inline continuity marker '(deck 3)' in \\scriptsize",
        "lstlisting lst:agentsmd (lines 170-188) full-width in a grey tcolorbox, \\scriptsize\\ttfamily, the three blank separator lines removed (14 code lines), as the ADR-011 frame of deck 3 (lines 560-576); one \\scriptsize caption line beneath"
      ],
      "minutes": 4,
      "notes": "Former frames 15 and 16 merged (semester plan: 'Guardrails (kompakt)'). Just-in-time: students maintain exactly this file in M5. Point to ADR-011 and the eval-harness line, which foreshadows §42.5. Compile-check with pdftoppm: three footnotesize bullets (~8 lines) plus 14 listing lines at scriptsize must clear the footline; if they do not, drop bullet 3 (the corollary) to speech first, then fall back to the two-frame version (text frame + listing frame, frame count 43)."
    },
    {
      "no": 16,
      "deck_section": "Axis A -- Control Interface and Guardrails",
      "title": "Guardrails as the precondition for safe agent use",
      "kind": "content",
      "script_ref": "§41.7 (part5_ai_dimension.tex 193-201), condensed",
      "content": [
        "If verification is the scarce resource, then everything that automates verification multiplies the value of AI tooling -- and everything that leaves verification informal converts AI speed into instability",
        "Test suites are the operating licence: against a dense, fast test suite an agent can iterate -- wrong code fails immediately and is repaired or discarded at machine speed; without that net every agent-generated change ships unpriced risk (DORA's 'strong version control and test automation' amplifier pair)",
        "Architectural fitness functions fence the structure: an objective integrity assessment of an architectural characteristic is the machine-readable form of an architecture decision -- dependency rules, cycle checks, module-boundary verification as CI gates were good practice before AI; with agents in the loop they are the mechanism by which an architect constrains a collaborator who never attends design meetings",
        "The delivery pipeline becomes a defence instrument: static analysis, SAST, dependency and secret scanning, contract tests, progressive delivery move from hygiene to necessity -- the only controls that scale with generation volume",
        "Continuity with Part IV: nothing here is new machinery -- the measurement contract already demanded executable invariants; Axis A merely adds a new class of change producer whose volume makes the contract non-optional"
      ],
      "elements": [
        "\\footnotesize bullets, five"
      ],
      "minutes": 3,
      "notes": "Compact; refer back to Lecture 11's fitness-function taxonomy in speech."
    },
    {
      "no": 17,
      "deck_section": "Axis A -- Control Interface and Guardrails",
      "title": "The tool landscape, soberly -- and the AI Lens on MCP",
      "kind": "ailens",
      "script_ref": "§41.8 intro, tool list, two standards + ailinse (part5_ai_dimension.tex 206-219), condensed",
      "content": [
        "Record the landscape as a geologist records a riverbed -- evidence of forces, not a map that stays accurate. Generation 2021--2023 (autocomplete-style assistants) suggested lines; generation 2024/2025 onwards plans, edits multiple files, runs builds and tests, iterates on failures -- agentic loops with tool access",
        "Claude Code (Anthropic): agentic CLI tool, research preview February 2025, GA May 2025; repository-level anchor CLAUDE.md",
        "Cursor (Anysphere): AI-first IDE with an agent mode; the dominant tool among the METR study's experts",
        "GitHub Copilot: Copilot Workspace retired May 2025; its concepts live on in the asynchronous Copilot coding agent (issues to pull requests, in CI) and the synchronous IDE agent mode",
        "Devin (Cognition): 'first AI software engineer' (2024); 13.86\\,\\% SWE-bench in March 2024 triggered the agent wave; acquired Windsurf July 2025 -- rapid market consolidation",
        "Two open standards matter more than any product, because they are architectural: Model Context Protocol (MCP, Anthropic, November 2024; JSON-RPC, servers expose tools, resources, prompts; adopted by OpenAI, Google DeepMind, Microsoft in 2025; December 2025 to the Agentic AI Foundation under the Linux Foundation; over 10,000 public servers) and AGENTS.md for project-level instructions; vendor SDKs extract the agent loop as a library -- the bridge to Axis B (§44, next week)",
        "AI Lens [MCP is ports-and-adapters at ecosystem scale]: strip the branding and MCP is a familiar shape -- a technology-neutral port (the protocol) with swappable adapters (servers wrapping databases, ticket systems, browsers), letting any conforming client use any conforming tool -- the role JDBC/ODBC played for databases. The hexagonal pattern of Part II did not become obsolete in the agent era; it became an ecosystem standard"
      ],
      "elements": [
        "\\footnotesize bullets, six (product bullets one line each, names in bold); ailinse[MCP is ports-and-adapters at ecosystem scale] (lines 217-219), condensed"
      ],
      "minutes": 4,
      "notes": "Former frames 19 and 20 merged. Announce that the examinable content is the pattern pair (sync pair-agent vs async task-agent), not product names -- the hinweisbox follows on frame 18. Ties back to deck 4's HX frames; the port/adapter vocabulary is exactly what the gateway frames reuse. If the box overflows, drop the parenthetical MCP adoption chronology to speech."
    },
    {
      "no": 18,
      "deck_section": "Axis A -- Control Interface and Guardrails",
      "title": "Benchmarks and their limits -- an expiry date on this section",
      "kind": "content",
      "script_ref": "§41.8 paragraph 'Benchmarks and their limits' + hinweisbox (part5_ai_dimension.tex 221-225)",
      "content": [
        "SWE-bench: 2,294 real GitHub issues from twelve Python projects -- given repository and issue text, produce a patch that passes hidden tests. Trajectory: 1.96\\,\\% (best 2023 setup) -> 13.86\\,\\% (Devin, March 2024) -> around 77--81\\,\\% for frontier models by late 2025 on the human-validated 500-task SWE-bench Verified subset",
        "Four qualifications keep the number honest: (1) contamination -- the repositories are in the training data; (2) scope -- Python only, issues with tests only; (3) criterion -- 'tests pass' is not 'maintainable, architecture-conformant'; (4) saturation -- on the contamination-resistant SWE-bench Pro, frontier models initially scored around 23\\,\\%. Near-80\\,\\% benchmark scores next to METR's measured slow-down: the module's canonical exercise in benchmark literacy",
        "Important Note: this section encodes the state of early 2026; product names carry an expiry date measured in months (Copilot Workspace lived roughly a year). Stable -- and examinable -- are the patterns: the synchronous pair-agent versus the asynchronous task-agent as interaction modes, context files and ADRs as the control interface, fitness functions as the containment mechanism. Every concrete tool claim carries its own temporal fitness function: re-verify on every tool generation"
      ],
      "elements": [
        "two \\footnotesize bullets; hinweisbox (lines 223-225), condensed, \\footnotesize"
      ],
      "minutes": 3,
      "notes": "Compressed to two SWE-bench bullets plus the hinweisbox; the box is the examinable part."
    },
    {
      "no": 19,
      "deck_section": "Axis A -- Control Interface and Guardrails",
      "title": "Risks and responsibility: security, bias, skill, accountability",
      "kind": "content",
      "script_ref": "§41.9 paragraphs 'Security of generated code', 'Automation bias and skill formation', 'Accountability' (part5_ai_dimension.tex 230-234), condensed per semester plan ('kompakt')",
      "content": [
        "Security -- the evidence predates the agent wave and gains relevance with volume: roughly 40\\,\\% of 1,689 Copilot-generated programs (89 security-relevant scenarios) contained CWE top-25 vulnerabilities; a user study: participants with an AI assistant wrote less secure code on most tasks while believing their code to be more secure; package hallucination ('slopsquatting'): across roughly 576,000 generations, about a fifth of recommended package references did not exist -- names an attacker can register pre-emptively. Consequence: SAST, dependency and secret scanning, licence checks in CI are not optional; security review capacity must scale with generation volume",
        "Automation bias: over-trust in automated systems is a decades-old human-factors finding -- Perry et al.'s participants overestimated their security, METR's experts overestimated their speed",
        "Skill formation: a randomised study of engineers learning a new library -- AI assistance reduced comprehension-test scores by roughly 17\\,\\%; the usage pattern is the decisive moderator (conceptual questions preserved learning, wholesale delegation destroyed it); entry-level developer positions are measurably declining. For this module: the role being trained is the specifier, verifier, and architect -- rebuild the competence ladder deliberately, including AI-free practice of fundamentals",
        "Accountability: legally and professionally, the person who merges code answers for it, regardless of what generated it; AI tools are not liability-bearing entities -- treat AI output as the contribution of an unknown third party: mandatory review, provenance labelling, an explicit policy for permitted uses (DORA 2025: a clearly communicated AI policy first among the seven amplifier capabilities)",
        "AI may draft an ADR; a nameable person decides, signs, and defends it (deck 3) -- architecture is an accountability performance, not a text-production performance. IP risk open but manageable: Doe v. GitHub -- the DMCA claim dismissed in 2024, licence-related claims continue; response: provider duplication filters and indemnification, licence scanning in CI, a documented residual risk in the governance record"
      ],
      "elements": [
        "\\footnotesize bullets, five (bullets 1 and 3 up to three lines); the headline figures (40\\,\\%, less secure / more secure, one fifth of 576,000, --17\\,\\%, entry-level decline) in bold; 'architecture is an accountability performance' as a highlighted clause",
        "\\scriptsize fallback for the bullets if the frame overflows"
      ],
      "minutes": 3,
      "notes": "Former frames 20 and 21 (risks 1/2 and 2/2) merged (semester plan: 'kompakt'). Address the students directly on the skill-formation bullet; it is the personal reading of Maxim 7. The ADR rule is one clause with the deck-3 marker; do not re-teach it. The 8.3 -> 12.3 copy-paste and 3\\,\\% high-trust figures stay in speech as before."
    },
    {
      "no": 20,
      "deck_section": "Axis A -- Control Interface and Guardrails",
      "title": "Project link: Axis A governs how you build the platform",
      "kind": "content",
      "script_ref": "§41.9 projektbox (part5_ai_dimension.tex 236-238)",
      "content": [
        "Axis A governs how you build the Portfolio Intelligence Platform; the project applies every mechanism of this section",
        "(i) the repository carries an AGENTS.md / CLAUDE.md in the spirit of the listing -- and you are expected to keep it as current as code",
        "(ii) every architecture decision is an ADR -- agents may draft, but a named team member signs",
        "(iii) agent-generated changes enter the main branch only through the CI gate: module-boundary fitness functions, the test suite, and -- for anything touching prompts or the gateway -- the eval harness of §42.5",
        "(iv) your project handbook contains a one-page AI policy: permitted tools, provenance labelling, review rules",
        "The graded artefact is not the generated code -- it is the control system around it"
      ],
      "elements": [
        "projektbox (lines 236-238), \\footnotesize, four numbered items plus the closing sentence in bold"
      ],
      "minutes": 2,
      "notes": "Closes the Axis A block; the closing sentence deserves emphasis before the break."
    },
    {
      "no": 21,
      "deck_section": "Axis B -- Component Types",
      "title": "Axis B opens: the news-sentiment call, wired the obvious way",
      "kind": "case",
      "script_ref": "§42 intro + §42.1 (part5_ai_dimension.tex 246-251)",
      "content": [
        "Leading question (italic): One of the platform's features is a single LLM call -- news in, sentiment out. Why not call it like any other function?",
        "Axis B moves AI from the workshop into the product; as always the case precedes the taxonomy: walk one concrete call end to end, watch what breaks, and name every break with a dimension you already own",
        "The feature: when a user opens a portfolio, the platform fetches the latest news items for its positions and asks an LLM, per item -- is this news positive, negative, or neutral for this holding, and why? One prompt, one structured answer: the simplest runtime AI component the course project owns",
        "Wired the obvious way: a provider-SDK call inside the request handler, synchronously in the page-rendering path",
        "Five failures arrive on schedule -- each landing on one of the twelve dimensions"
      ],
      "elements": [
        "Leading question italic bankblue; optional small tikz strip: request handler -> provider SDK call -> page render (synchronous), grey boxes"
      ],
      "minutes": 3,
      "notes": "Keep the frame light; the failures get two frames of their own."
    },
    {
      "no": 22,
      "deck_section": "Axis B -- Component Types",
      "title": "Five failures on schedule (1/2): latency, cost, non-determinism",
      "kind": "case",
      "script_ref": "§42.1 enumerate items 1-3 (part5_ai_dimension.tex 254-256)",
      "content": [
        "Subtitle line (\\scriptsize, codegray): the deck-3 AI Lens, now concrete",
        "1. Latency (D3): the call takes seconds -- one to sixty-plus, depending on model and load -- where every other call in the handler takes milliseconds: the page now blocks on the slowest and least controllable component in the stack",
        "2. Cost (D10): priced per token, so the feature bills per request -- every portfolio open costs real money; a loop over twenty positions is a twenty-fold cost regression the way an n+1 query is a latency regression. No classical component in the platform has this property",
        "3. Non-determinism (D12): run the same article twice and the answers differ; sometimes an answer is garbage -- a score for a company not in the portfolio, a negative headline read as positive",
        "Wired synchronously, the component has none of the three things Part I said such a component needs: no queue to absorb its latency and outages, no port behind which a test can substitute a deterministic fake, no measurement point where the cost and quality of every call are observable"
      ],
      "elements": [
        "numbered list \\footnotesize, dimension codes in bold; subtitle marker line"
      ],
      "minutes": 3,
      "notes": "Deck 3's AI Lens (D3, D10, D12; queue/port/measurement point) is marked on-slide as the source; the case is that box made concrete."
    },
    {
      "no": 23,
      "deck_section": "Axis B -- Component Types",
      "title": "Five failures on schedule (2/2): drift, injection, diagnosis",
      "kind": "case",
      "script_ref": "§42.1 items 4-5 and closing paragraph (part5_ai_dimension.tex 257-261)",
      "content": [
        "4. Drift (D7): the provider ships a new model version or deprecates the old one -- GA models carry deprecation windows of the order of six months -- and the component's behaviour changes without any local action: no commit, no deployment, no reviewable diff. The feature's behaviour is now co-owned by a third party",
        "5. Injection (D6): the news article is untrusted input read by a component that cannot reliably separate instructions from data -- a crafted 'article' can carry instructions to the model; the feature has quietly opened an attack surface that no classical threat model in the platform covers (the attack surface in depth: §42.6, next week)",
        "Diagnosis (bold): nothing on this list is a bug in the model, and nothing on it is fixed by a better prompt -- every failure is a property of the wiring: a non-deterministic, fallible, latency-heavy, per-call-priced component was integrated as if it were deterministic, reliable, fast, and free",
        "The rest of the section generalises: the component taxonomy -> why containment, not mere integration (SE4AI classics) -> the reference architecture that re-wires the call correctly -> the test instrument for a component without exact assertions (eval harness)"
      ],
      "elements": [
        "numbered list continued (4, 5), then a bold diagnosis line and a roadmap line"
      ],
      "minutes": 3,
      "notes": "The diagnosis sentence is the thesis of Axis B; give it its own visual weight."
    },
    {
      "no": 24,
      "deck_section": "Axis B -- Component Types",
      "title": "The three component types -- one species, three profiles",
      "kind": "definition",
      "script_ref": "§42.2 intro + definitionbox 'AI runtime component' (part5_ai_dimension.tex 265-269)",
      "content": [
        "The sentiment call is one instance of a species: for the first time, production systems contain building blocks that are non-deterministic, fallible, latency-heavy, priced per call, and capable of changing behaviour without any local action -- through model updates, data drift, or provider deprecation",
        "Thesis, prepared by Assumption A6: such components change no principle of software engineering but shift the weights in the quality attribute space -- and thereby the pattern choice; loose coupling, asynchronous integration, explicit contracts, and observability migrate from 'nice to have' to mandatory",
        "Industry speaks of compound AI systems (deck 6, C10) for exactly this reason: state-of-the-art results increasingly come from systems composed of models, retrievers, validators, and deterministic services rather than a single model call",
        "Definition [AI runtime component]: a component of the delivered system whose output is produced by a learned or search-based model rather than by explicitly programmed logic. Three types with systematically different engineering profiles: (a) LLM components for analysis, extraction, and generation over unstructured input; (b) classical ML components for classification and regression; (c) optimisation components (LP/MIP and constraint solvers, metaheuristics)",
        "The types differ exactly on the dimensions this theory measures -- determinism, latency, cost model, dominant risk, explainability -- and therefore demand different integration forms"
      ],
      "elements": [
        "definitionbox[AI runtime component] (lines 267-269), \\footnotesize"
      ],
      "minutes": 3,
      "notes": "Three bullets above the definition box; keep the definition box the visual centre."
    },
    {
      "no": 25,
      "deck_section": "Axis B -- Component Types",
      "title": "The three AI component types and their profiles",
      "kind": "table",
      "script_ref": "§42.2 tab:aicomponents (part5_ai_dimension.tex 271-288)",
      "content": [
        "Columns: Dimension | (a) LLM analysis / generation | (b) ML classification / regression | (c) Optimisation (LP/MIP/CP)",
        "Row Determinism | non-deterministic (even at T=0 only 'mostly') | deterministic after training | reproducible at fixed seed/threads/limit; variance in practice",
        "Row Latency | seconds (1--60+) | milliseconds possible | seconds to hours; anytime behaviour",
        "Row Cost model | per token/call (operating expenditure) | training expensive, inference cheap | compute + solver licence",
        "Row Dominant risk | hallucination, prompt injection, provider drift/deprecation | data/concept drift, training/serving skew | modelling errors, runtime explosion",
        "Row Explainability | low (generated justifications are themselves model output) | medium (feature importance) | high -- provable: optimality gap, duals, IIS",
        "Row Integration form | gateway + async + cache | serving endpoint + MLOps pipeline | job queue / batch worker",
        "Caption sense: each column implies a different integration form -- which is why 'add AI' is never a single architectural decision"
      ],
      "elements": [
        "6-row scriptsize booktabs table with p{2.0cm}p{3.5cm}p{3.3cm}p{3.5cm} (12.3 cm) from tab:aicomponents lines 276-287; 'high -- provable' in bold"
      ],
      "minutes": 3,
      "notes": "Read column-wise. Speaker guidance: (a) is the sentiment call and the AdvisorAgent's insights, (c) is your Optimization service; type (b) has no instance in the project -- the script says only that it belongs in every advisory platform (the exercise sheet's Performance/Risk/Optimization services are deterministic, project_exercise.tex 181-187)."
    },
    {
      "no": 26,
      "deck_section": "Axis B -- Component Types",
      "title": "Type (a): LLM components -- RAG, prompts, structured outputs",
      "kind": "content",
      "script_ref": "§42.2 paragraph 'Type (a): LLM components' (part5_ai_dimension.tex 290)",
      "content": [
        "LLM components turn unstructured input -- documents, e-mails, reports -- into analyses, extractions, or generated text; three engineering building blocks define the type",
        "Retrieval-augmented generation (RAG): knowledge is moved out of the model weights into a swappable, versionable, inspectable data component -- updated by re-indexing rather than retraining, with provenance through citable sources",
        "RAG is an engineering problem, not a model problem: case-study evidence documents seven recurring failure points (missing content, failed ranking of the relevant documents, extraction and formatting errors, incomplete answers) -- with the sobering observation that RAG robustness evolves in operation rather than being designed in",
        "Prompts are configuration artefacts: version-controlled, regression-tested, behaviour-determining like code -- exactly the configuration-debt territory Sculley et al. mapped",
        "Structured outputs: since 2024 provider APIs can enforce, via constrained decoding, that outputs conform to a developer-supplied JSON schema -- syntactic correctness guaranteed; semantic correctness remains to be verified (reference architecture, eval harness)",
        "Lifecycle risk is the provider: GA models carry deprecation windows of the order of six months, shorter windows observed -- a hard-coded model name is a ticking dependency: an architectural statement, not an operational one"
      ],
      "elements": [
        "\\footnotesize bullets, six; the three building blocks (RAG, prompts, structured outputs) in bold"
      ],
      "minutes": 3,
      "notes": "The AdvisorAgent's insights are type (a); the ontology guard answers 'semantic correctness remains to be verified'."
    },
    {
      "no": 27,
      "deck_section": "Axis B -- Component Types",
      "title": "Types (b) and (c) -- perishable models, heavy solvers",
      "kind": "content",
      "script_ref": "§42.2 paragraphs 'Type (b): classical ML components' and 'Type (c): optimisation components' (part5_ai_dimension.tex 292-294)",
      "content": [
        "(b) Self-trained models (scoring, churn, fraud, forecasting) bring the full nine-stage workflow -- model requirements and data collection through training, evaluation, deployment, monitoring -- with dense feedback loops; characteristic problems: training/serving skew (divergent data preparation, one of the most frequent production failure sources) and data/concept drift (sudden, gradual, incremental, recurring)",
        "(b) A deployed model is a perishable good -- monitoring and retraining are operating requirements, not options; tooling: feature stores with consistent online/offline views, model registries versioning model, data, code, and configuration together, the MLOps discipline (maturity ladder: §43, next week)",
        "(c) Routinely overlooked in the SE4AI literature but belongs in every advisory platform: LP/MIP solvers, constraint programming (CP-SAT dominated recent MiniZinc Challenges, a complete gold-medal sweep in 2024), stochastic metaheuristics -- the profile inverts the LLM's: deterministic but heavy. Reproducible at fixed seed, thread count, time limit (run-to-run variability in practice); runtimes seconds to hours, often anytime behaviour -> asynchronous integration: job queue, status polling, callback; never a synchronous call in a web request path",
        "(c) Compensating strength: provable explainability -- optimality gap, dual values and shadow prices, and on infeasibility an irreducible infeasible subset (IIS): a minimal set of contradictory constraints as the explanation. In regulated domains the load-bearing argument for the project's division of labour: hard, auditable decisions belong to the solver and the deterministic services, not to the LLM"
      ],
      "elements": [
        "\\footnotesize bullets, four (each at most three lines); 'a deployed model is a perishable good' and 'deterministic but heavy' in bold"
      ],
      "minutes": 3,
      "notes": "Split off from the former type-(b)/(c) keypoint frame; the keypoint now has its own frame (28)."
    },
    {
      "no": 28,
      "deck_section": "Axis B -- Component Types",
      "title": "Key concept: adding AI is a per-component matching problem",
      "kind": "keyconcept",
      "script_ref": "§42.2 keypoint (part5_ai_dimension.tex 296-298)",
      "content": [
        "One-line strip above the box (\\footnotesize, dimension codes in bold): the three types differ exactly where the twelve dimensions measure -- determinism (D4) | latency (D3) | cost (D10) | auditability (D6) | testability (D9)",
        "Key Concept: 'We are adding AI' is therefore never one decision -- it is a per-component matching problem, answered with the same profile logic as everything else in this module. One rule spans all three types: contain the component behind an explicit boundary; never scatter it through the domain",
        "\\scriptsize codegray aside beneath the box (project transfer): the sentiment call and the AdvisorAgent's insights are type (a); the Optimization service is type (c); type (b) has no instance in the project"
      ],
      "elements": [
        "keypoint box (lines 296-298), verbatim-condensed, \\footnotesize; one-line dimension strip above; one-line project aside beneath"
      ],
      "minutes": 2,
      "notes": "Author note: the script maps determinism to D4 here (line 297) while §42.1 (line 256) and the deck's frame 22 map non-determinism to D12, and tab:dimensions labels D4 'Consistency & transactional integrity' -- a script-internal tension; keep the script wording for fidelity and say in speech that the twelve-dimension table places non-determinism under D12. The project aside is a transfer, not script text; it stays outside the box."
    },
    {
      "no": 29,
      "deck_section": "Axis B -- Containment",
      "title": "Why containment: the SE4AI classics -- hidden debt and CACE",
      "kind": "definition",
      "script_ref": "§42.3 (part5_ai_dimension.tex 303-309)",
      "content": [
        "Two foundational results explain why AI components need architectural containment rather than mere integration",
        "Sculley et al. (2015) transferred the technical-debt metaphor to ML systems. Observation 1: only a small fraction of a real-world ML system is ML code -- the famous figure shows the model as a small black box amid large blocks of configuration, data collection, feature extraction, data verification, serving infrastructure, and monitoring. The system around the model is the actual engineering task -- precisely this module's perspective",
        "Observation 2: ML components resist modularisation",
        "Definition [CACE -- Changing Anything Changes Everything]: ML models entangle their input signals -- no feature is ever truly independent, so a change to one feature distribution, hyperparameter, or upstream data source changes the behaviour of the whole model. Architectural consequence: boundary erosion -- the strong abstraction boundaries on which modular design relies are systematically undermined by ML components",
        "Alongside the paper's system anti-patterns: glue code, pipeline jungles, dead experimental code paths, configuration debt, hidden feedback loops, undeclared consumers of model outputs"
      ],
      "elements": [
        "definitionbox[CACE -- Changing Anything Changes Everything] (lines 307-309), \\footnotesize"
      ],
      "minutes": 3,
      "notes": "Do not reproduce the Sculley figure (not in the script's assigned lines as a figure); describe it in words as the script does."
    },
    {
      "no": 30,
      "deck_section": "Axis B -- Containment",
      "title": "Three differences, 28 tests -- AI Lens: Parnas meets CACE",
      "kind": "ailens",
      "script_ref": "§42.3 Amershi paragraph + ailinse 'Parnas meets CACE' (part5_ai_dimension.tex 311-315)",
      "content": [
        "Amershi et al. (Microsoft product teams) -- three fundamental differences between ML-based and classical development: (1) data discovery, versioning, labelling, and schema management are harder than and qualitatively different from code management, with no Git-equivalent of comparable maturity; (2) model customisation and reuse demand combined SE and ML competence; (3) AI components are harder to modularise than software modules -- entangled (CACE), non-monotonic error behaviour, poorly predictable interactions between models",
        "Operational counterpart -- the ML Test Score: a rubric of 28 concrete tests and monitoring requirements across data, model development, infrastructure, and monitoring, distilled from Google production experience: production readiness made measurable, and a ready-made checklist for the course project",
        "AI Lens [Parnas meets CACE]: Part II established Maxim 4 -- domain-oriented partitioning around anticipated change is the strongest single predictor of evolvability. CACE identifies a component class in which change anticipation fails inside the component: everything co-varies with everything. The resolution is not to abandon Parnas but to apply him one level up: if the component cannot be decomposed, the decomposition happens around it -- the module boundary goes where the entanglement stops, at the component's contract. That is the entire intellectual content of the gateway pattern, and it is sixty-year-old advice"
      ],
      "elements": [
        "ailinse[Parnas meets CACE] (lines 313-315), condensed, \\footnotesize"
      ],
      "minutes": 3,
      "notes": "The AI Lens is the conceptual hinge to the reference architecture: say 'the boundary goes where the entanglement stops' before showing the figure."
    },
    {
      "no": 31,
      "deck_section": "Axis B -- Containment",
      "title": "The reference architecture -- the sentiment call, re-wired",
      "kind": "diagram",
      "script_ref": "§42.4 intro + fig:llmgateway (part5_ai_dimension.tex 320-385)",
      "content": [
        "One \\scriptsize line above the figure: not new machinery but old machinery applied more strictly -- the correct re-wiring of the sentiment call: behind a typed port into the gateway (curing drift, containing injection); non-interactive volume onto the queue (curing latency, buying batch pricing); every call across one measurement point (cost and quality observable)",
        "Figure, left: Deterministic domain core -- decides and books; no provider SDK imports -- 'typed port' arrow into the gateway",
        "Figure, centre: LLM gateway (anti-corruption layer) with five internals -- prompt assembly + schema validation; model router (cheap -> expensive cascade); semantic cache; timeouts, circuit breakers, fallback chains; cost telemetry per request / feature / tenant",
        "Figure, right: Provider A (models m1, m2); Provider B (fallback); Local model (last-resort degradation)",
        "Figure, bottom: async job queue (batching, backpressure, retries) -> worker pool (bounded concurrency) -> gateway, fed by the core's 'non-interactive jobs'; every output -> Ontology / schema guard (entity resolution, domain axioms, citation check) -> 'validated result or rejection' back to the core; Eval harness (CI gate: prompts, models, providers) dashed to guard and gateway",
        "Caption-like line beneath: this is the topology your AdvisorAgent and sub-agents are wired into this week -- ADR-011 (deck 3) made structural"
      ],
      "elements": [
        "tikz fig:llmgateway (lines 322-385) redrawn for 16:9: core bankblue, gateway frame aiviolet with five violet sub-boxes in a 2+3 grid, providers grey, queue/workers bankgreen, guard bankred, eval harness teal; \\resizebox to 0.95\\textwidth; one \\scriptsize line above and one beneath"
      ],
      "minutes": 7,
      "notes": "Give the figure the whole frame; seven minutes for the walk-through (the 3 minutes freed by the kompakt merges of frames 15 and 19 are reinvested here). Walk in the order of the script's intro sentence (line 320): typed port into the gateway (curing drift, containing injection -- failures 4 and 5 of frame 23) -> the five gateway internals -> providers and fallback -> non-interactive volume onto the queue and worker pool (curing latency, buying batch pricing -- failure 1 of frame 22) -> every output through the ontology/schema guard -> the eval harness as CI gate; every call crosses one measurement point (cost and quality observable -- failures 2 and 3 of frame 22). Consider revealing the four stages with \\onslide overlays (port, queue, guard, harness) so the re-wiring of the sentiment call is visible step by step; no content beyond the figure's labels and line 320 is added. Verify with pdftoppm that the 2+3 grid fits beside the providers."
    },
    {
      "no": 32,
      "deck_section": "Axis B -- Containment",
      "title": "The elements justified (1/4): gateway, deterministic core",
      "kind": "content",
      "script_ref": "§42.4 itemize items 1-2 (part5_ai_dimension.tex 388-389)",
      "content": [
        "Anti-corruption layer / LLM gateway: from domain-driven design -- a translation layer that prevents a foreign system's model from corrupting one's own. Applied to LLMs: no domain code speaks to a provider API",
        "A facade owns the provider SDKs, prompt construction, schema validation, retry logic, model selection, and cost telemetry; the domain sees only a typed interface: \\texttt{analyse\\_report(document) -> RiskAssessment}",
        "Provider deprecation becomes an adapter task instead of a crisis; the facade is mockable in every test; as an industry pattern the gateway has consolidated into its own infrastructure layer -- the AI counterpart of the API gateway. In hexagonal terms the LLM is an adapter on a port -- the strongest single reason HX gains weight in the AI era",
        "Deterministic core, probabilistic edge: everything deterministically computable -- validation, aggregation, key-figure computation, authorisation, persistence, booking -- stays deterministic code; the LLM handles only what determinism cannot (language understanding, extraction from unstructured text, formulation). Keep the non-deterministic core as small as possible and push it to the edge",
        "Centred, highlighted design rule (the line that is graded): LLM agents propose; deterministic services decide and book"
      ],
      "elements": [
        "\\footnotesize bullets, four, each at most three lines; the typed signature in \\texttt; the design rule as a highlighted centred line (bankblue, bold italic)"
      ],
      "minutes": 3,
      "notes": "Split off from the previous version's combined gateway/core/queue frame. The HX D12 '$++$' remark (the structural fact behind the $++$ in HX's D12 row) goes to speech or a one-line codegray aside."
    },
    {
      "no": 33,
      "deck_section": "Axis B -- Containment",
      "title": "The elements justified (2/4): queue, semantic cache",
      "kind": "content",
      "script_ref": "§42.4 itemize items 3-4 (part5_ai_dimension.tex 390-391)",
      "content": [
        "Asynchronous integration: seconds-scale latency, rate limits, and outage risk put AI calls behind a queue wherever the domain allows -- the caller enqueues a job, a worker pool calls the model at a controlled degree of parallelism, results return by event or callback",
        "The queue buys backpressure instead of overload, retries without blocking users, smoothing of rate limits, and natural batching points: provider batch APIs process non-urgent volume at roughly 50\\,\\% discount within processing windows up to 24 hours (figure from deck 6 -- here placed where it lives: in the gateway)",
        "Axis B's direct coupling to EDA and PF (Part II) -- exactly the mechanisms their D12 rows priced at $++$",
        "Semantic caching: instead of exact-match keys, requests are compared by embedding similarity, so semantically equivalent queries hit the cache",
        "The engineering point not to miss: a false-positive cache hit is a correctness risk, not a performance blemish -- the similarity threshold is a quality/cost regulator and belongs in the eval harness, not in a config file nobody reviews"
      ],
      "elements": [
        "\\footnotesize bullets, five, each at most three lines; 'correctness risk' in bold"
      ],
      "minutes": 3,
      "notes": "Link the queue to Lecture 11's resilience exercise and to deck 5/6 EDA/PF in speech."
    },
    {
      "no": 34,
      "deck_section": "Axis B -- Containment",
      "title": "The elements justified (3/4): model routing -- AI Lens",
      "kind": "ailens",
      "script_ref": "§42.4 item 5 + ailinse 'Model routing is a classical tactic in new clothes' (part5_ai_dimension.tex 392, 397-399)",
      "content": [
        "Model routing: model choice per request is one of the largest cost levers in the stack -- cascades that start with the cheapest model and escalate only on insufficient answer quality report up to 98\\,\\% cost reduction at comparable quality; learned routers trained on human preference data cut cost by more than a factor of two without quality loss, generalising to unseen model pairs (figures from deck 6 -- here placed where they live: in the gateway)",
        "AI Lens [Model routing is a classical tactic in new clothes]: Part I defined tactics as the atomic units of architectural design. Routing traffic across a cheap and an expensive resource depending on demand is the ancient resource-arbitration tactic -- the FrugalGPT cascade is its token-economics incarnation. Note where it lives in the figure: in the gateway, as infrastructure, invisible to domain logic. A tactic that leaks into the domain layer stops being a tactic and starts being coupling"
      ],
      "elements": [
        "one \\footnotesize bullet; ailinse[Model routing is a classical tactic in new clothes] (lines 397-399), condensed, \\footnotesize"
      ],
      "minutes": 3,
      "notes": "Deck 6's C10 frame already quoted the 98\\,\\% and factor-two figures as cost-model facts; the inline marker says so."
    },
    {
      "no": 35,
      "deck_section": "Axis B -- Containment",
      "title": "The elements justified (4/4): stability, ontology as contract",
      "kind": "content",
      "script_ref": "§42.4 itemize items 6-7 (part5_ai_dimension.tex 393-394)",
      "content": [
        "Stability patterns transfer directly from the classical catalogue: timeouts (an LLM call without one blocks a thread for minutes); retries with exponential backoff -- only for idempotent calls and with cost awareness, since every retry burns tokens; circuit breakers per provider and model; fallback chains -- alternative model -> alternative provider -> cached or rule-based answer -> honest degradation ('analysis currently unavailable'); bulkheads separating interactive from batch quotas",
        "Only the failure semantics are new: a semantically unusable answer -- schema violation, suspected hallucination -- must trigger the error path exactly like an HTTP 500",
        "Ontology and schema as contract -- the most effective systematic hallucination defence is layered: (1) structured outputs enforce syntax; (2) every extracted entity (account number, ISIN, customer name, key figure) is resolved against the deterministic data store -- unresolvable references are rejected, not passed on; (3) domain axioms hold as invariants -- sums add up, weights lie in [0,1], cited passages exist in the source document; (4) grounding via RAG makes citations mandatory",
        "The schema becomes a contract in the design-by-contract sense, and the gateway is the contract checker -- this is the ontology guard your project activates on all insights this week"
      ],
      "elements": [
        "\\footnotesize bullets, four; the four-layer defence as an inline numbered sequence"
      ],
      "minutes": 3,
      "notes": "Link to Lecture 11's resilience exercise (timeouts, retries, breakers, fallback on all external calls) in speech: the LLM provider is one more external call with token cost attached."
    },
    {
      "no": 36,
      "deck_section": "Axis B -- Containment",
      "title": "The eval harness -- definition and course thesis",
      "kind": "definition",
      "script_ref": "§42.5 intro, definitionbox 'Eval harness', keypoint 'The course thesis on testing AI' (part5_ai_dimension.tex 404-408, 419-421)",
      "content": [
        "Non-determinism breaks the classical test idiom: \\texttt{assert expected == actual} presupposes that equal inputs produce equal outputs. When that assumption falls, correctness must be redefined statistically -- 'correct in at least 95\\,\\% of the evaluation cases' -- and the team needs a test artefact of the first rank to carry that definition",
        "Definition [Eval harness]: a versioned suite of test cases, scoring logic, and statistical thresholds for a non-deterministic component, executed in the CI/CD pipeline like a test suite. It gates every prompt change, model update, and provider migration. Its thresholds are the response measures of the AI-related quality attribute scenarios (Assumption A4), and its pass rate is a fitness function in the measurement contract of Part IV",
        "Key Concept -- the course thesis on testing AI: the eval harness is to AI components what the test pyramid is to deterministic code -- the artefact that converts 'it seems to work' into a falsifiable, continuously executed claim. Without it, every model migration is a blind flight -- and given provider deprecation windows of months, migrations are not hypothetical. Statistical acceptance replaces exact assertion; the thresholds are architecture decisions and belong in the measurement contract"
      ],
      "elements": [
        "definitionbox[Eval harness] (lines 406-408), \\footnotesize",
        "keypoint box 'The course thesis on testing AI' (lines 419-421), condensed, \\footnotesize"
      ],
      "minutes": 3,
      "notes": "Two boxes plus one intro bullet -- fits at \\footnotesize. Recall deck 6: 'evals are the operative meaning of testability' (D9 = H for C10)."
    },
    {
      "no": 37,
      "deck_section": "Axis B -- Containment",
      "title": "Four complementary evaluation strategies make a complete harness",
      "kind": "content",
      "script_ref": "§42.5 enumerate (part5_ai_dimension.tex 410-417)",
      "content": [
        "1. Regression against labelled references: a curated golden set of input/expectation pairs from the domain, scored with task-appropriate metrics (exact match or F1 on extracted fields, rubric scores for generated text); every prompt change, model update, and migration runs against this suite -- the direct counterpart of the regression test",
        "2. LLM-as-judge: strong LLM judges agree with human preference judgements in over 80\\,\\% of cases -- the level of human--human agreement -- a scalable scoring instrument; biases to control for: position, verbosity, self-enhancement, weak reasoning grading. Conclusion: the judge is a measurement instrument that must itself be calibrated against human labels -- the judge needs its own eval",
        "3. Domain axioms and property-based testing: instead of exact expected values, the harness checks properties that must hold for all valid outputs -- schema validity, referential integrity against the ontology, metamorphic relations (a paraphrased input must yield a semantically equivalent output), domain monotonicities; axioms catch failure classes that no finite golden set covers",
        "4. Online evaluation: sampled human review, user feedback signals, drift monitoring of the eval metrics in production -- the LLM counterpart of model monitoring in the ML workflow"
      ],
      "elements": [
        "numbered list \\footnotesize; strategy names in bold; 'the judge needs its own eval' in italic"
      ],
      "minutes": 4,
      "notes": "Speaker notes carry the bias definitions (position bias: candidate order sways the verdict; verbosity bias: longer answers preferred; self-enhancement: judges favour their own outputs) and the countermeasures (position swapping, reference-guided judging), script line 414."
    },
    {
      "no": 38,
      "deck_section": "Axis B -- Containment",
      "title": "Example: an eval harness for the portfolio platform",
      "kind": "content",
      "script_ref": "§42.5 examplebox + lst:evalharness (part5_ai_dimension.tex 423-453)",
      "content": [
        "One \\footnotesize line above the listing: thresholds = response measures -- mean F1 >= 0.92 on the golden set | zero axiom violations | judge--human agreement kappa >= 0.70 (Cohen's chance-corrected measure) -- changing any of them is an architecture decision requiring an ADR; note what is absent: no assertion demands an exact output string",
        "Listing (stripped to 16 code lines: docstrings, blank lines and the comments that duplicate the bullets dropped): GOLDEN = load_cases(\"evals/portfolio_extraction_v3.jsonl\")",
        "def test_extraction_regression(gateway): scores = [f1(gateway.extract(c.report), c.expected) for c in GOLDEN]; assert mean(scores) >= 0.92   # statistical threshold",
        "def test_domain_axioms(gateway, ontology): answer = gateway.advise(sample_portfolio()); for pos in answer.positions: assert ontology.resolves(pos.isin), f\"unknown: {pos.isin}\"; total = sum(p.weight for p in answer.positions); assert abs(total - 1.0) < 1e-6; for cit in answer.citations: assert cit.passage in source_text(cit.doc_id)",
        "def test_judge_is_calibrated(judge, human_labels): agreement = cohens_kappa(judge.score(GOLDEN), human_labels); assert agreement >= 0.70   # the judge's own eval",
        "Caption line: runs in CI on every change to prompts, models, or the gateway, alongside the deterministic test suite"
      ],
      "elements": [
        "examplebox header (line 424) condensed to one \\footnotesize line",
        "lstlisting lst:evalharness (lines 426-452) stripped to ~16 lines in a grey tcolorbox, \\scriptsize\\ttfamily, Python; one \\scriptsize caption line beneath"
      ],
      "minutes": 3,
      "notes": "Verify the footline with pdftoppm before finalising. The docstrings ('Statistical acceptance, not exact assertion'; 'Properties that hold for ALL valid outputs'; 'LLM-as-judge is an instrument: calibrate it') are spoken per function. Point to week 13: this harness becomes the CI gate."
    },
    {
      "no": 39,
      "deck_section": "Closing",
      "title": "This week's exercise: AdvisorAgent + sub-agents behind the gateway",
      "kind": "exercise",
      "script_ref": "Exercise sheet M5 taskbox (project_exercise.tex 432-442) and hintbox (451-464); semester plan week 12 row (line 23); §41.9 projektbox (part5_ai_dimension.tex 236-238)",
      "content": [
        "Coaching slot (1 lesson). Milestone M5 -- Multi-Agent Orchestration, Evaluation, and Hardening (weeks 12--13)",
        "Mandatory this week: the AdvisorAgent orchestrates 2--3 sub-agents through contracts -- every LLM call through the gateway port (ADR-011); no provider SDK import in domain code",
        "Ontology guard active on all insights: entity resolution against the deterministic store, domain axioms, citation check -- unresolvable references are rejected, not passed on",
        "LLM agents propose; deterministic services decide and book -- keep the deterministic core free of LLM calls (the line that is graded)",
        "Closing line: Axis A discipline as on the project-link slide; week 13 turns the harness into a CI gate"
      ],
      "elements": [
        "projektbox with four items plus one closing line, \\footnotesize"
      ],
      "minutes": 3,
      "notes": "Items 5-7 of the previous version replaced by one closing line: the Axis A discipline is frame 20, the week-13 tasks and distinction work are frame 41."
    },
    {
      "no": 40,
      "deck_section": "Closing",
      "title": "Summary",
      "kind": "summary",
      "script_ref": "Frames 4-38",
      "content": [
        "1. A6 falls due -- two axes, one method: Axis A changes how systems are built, Axis B what they contain; independent, kept apart, analysed with the apparatus of Parts I--IV",
        "2. Copilot +55.8\\,\\% vs METR --19\\,\\%: neither wrong -- five moderators reconcile the record; the perception gap (+24 / --19 / +20) is the didactic core",
        "3. System level: DORA -- throughput positive, instability persists, AI is an amplifier; GitClear -- duplication 4x, refactoring signature collapsed; adoption up, trust down",
        "4. Verification bottleneck, Maxim 7: generation cheap, specification/verification/architecture binding; D7 and D9 gain weight in every profile",
        "5. Axis A compact: documentation as control interface, fitness functions as operating licence, who merges answers; patterns examinable, products expire; MCP = ports-and-adapters",
        "6. Axis B: the sentiment call fails on D3, D10, D12, D7, D6 -- properties of the wiring; three types = a per-component matching problem; CACE -> decompose around the component",
        "7. Reference architecture: typed port -> gateway (routing, cache, stability, cost telemetry) -> queue -> ontology guard; eval harness = statistical acceptance, thresholds in the measurement contract"
      ],
      "elements": [
        "\\footnotesize numbered list, 7 points, each at most 1.5 lines, as deck 6 lines 660-671"
      ],
      "minutes": 2,
      "notes": "Seven points trimmed to one-and-a-half lines each."
    },
    {
      "no": 41,
      "deck_section": "Closing",
      "title": "Next week",
      "kind": "nextweek",
      "script_ref": "Task brief 'Next lecture' line; semester plan week 13 row (line 24); exercise sheet M5 week 13 (project_exercise.tex 436-440)",
      "content": [
        "Left column: \\textcolor{bankblue}{\\textbf{Lecture 13 -- Part V closes: security and law, the matrix shift, the eighth pattern, synthesis}}",
        "Left column \\small bullet: OWASP LLM Top 10 and prompt injection; the EU AI Act as hard constraint",
        "Left column \\small bullet: How AI shifts the matrix: the C10 row cell by cell, D12 across the seven patterns, which cells shift, MLOps maturity",
        "Left column \\small bullet: Agent orchestration as the emergent eighth pattern: topologies, the economics of autonomy, capability-profile sketch",
        "Left column \\small bullet: Synthesis: one theory, five parts; exam orientation",
        "Right column -- Reading: this week Part V, Sections 40--41, 42.1--42.5; ahead Part V, Sections 42.6--42.7, 43--45",
        "Right column -- Exercise / deliverable: coaching; eval harness as CI gate; cost/latency observability; hardening; distinction work; \\textbf{milestone: eval harness in CI + guard + cost observability}"
      ],
      "elements": [
        "two columns 0.55/0.42 as deck 6 lines 673-698: bold bankblue lecture line + four \\small bullets left; Reading and Exercise/deliverable right; \\footnotesize if the topic bullets wrap beyond the column"
      ],
      "minutes": 1,
      "notes": "Verbatim in substance from the task brief; layout as decks 1-6."
    },
    {
      "no": 42,
      "deck_section": "Closing",
      "title": "Closing slide",
      "kind": "content",
      "script_ref": "Deck skeleton; closing block copied from deck 6 (AISE502_Vorlesung_6_Folien.tex 703-706)",
      "content": [
        "\\FHGRClosingPage[][{\\color{white}\\parbox{0.9\\paperwidth}{\\centering Thank you!\\\\[3ex] {\\normalsize\\mdseries Dr.\\ Florian Herzog\\\\[0.9ex] Fachhochschule Graub\\\"unden, Chur\\\\[2.4ex] {\\small AISE502 -- AI in Software Engineering II}}}}]"
      ],
      "elements": [
        "FHGR closing page"
      ],
      "minutes": 0,
      "notes": "Copy deck 6 lines 703-706 verbatim (parbox and white text -- trap 1/2 from the deck memory)."
    }
  ],
  "exercise_frame": {
    "title": "This week's exercise: AdvisorAgent + sub-agents behind the gateway",
    "content": [
      "Coaching slot (1 lesson). Milestone M5 -- Multi-Agent Orchestration, Evaluation, and Hardening (weeks 12--13)",
      "Mandatory this week: the AdvisorAgent orchestrates 2--3 sub-agents through contracts -- every LLM call through the gateway port (ADR-011); no provider SDK import in domain code",
      "Ontology guard active on all insights: entity resolution against the deterministic store, domain axioms, citation check -- unresolvable references are rejected, not passed on",
      "LLM agents propose; deterministic services decide and book -- keep the deterministic core free of LLM calls (the line that is graded)",
      "Closing line: Axis A discipline as on the project-link slide; week 13 turns the harness into a CI gate"
    ]
  },
  "summary": [
    "A6 falls due -- two axes, one method: Axis A changes how systems are built, Axis B what they contain; independent, kept apart, analysed with the apparatus of Parts I--IV",
    "Copilot +55.8\\,\\% vs METR --19\\,\\%: neither wrong -- five moderators reconcile the record; the perception gap (+24 / --19 / +20) is the didactic core",
    "System level: DORA -- throughput positive, instability persists, AI is an amplifier; GitClear -- duplication 4x, refactoring signature collapsed; adoption up, trust down",
    "Verification bottleneck, Maxim 7: generation cheap, specification/verification/architecture binding; D7 and D9 gain weight in every profile",
    "Axis A compact: documentation as control interface, fitness functions as operating licence, who merges answers; patterns examinable, products expire; MCP = ports-and-adapters",
    "Axis B: the sentiment call fails on D3, D10, D12, D7, D6 -- properties of the wiring; three types = a per-component matching problem; CACE -> decompose around the component",
    "Reference architecture: typed port -> gateway (routing, cache, stability, cost telemetry) -> queue -> ontology guard; eval harness = statistical acceptance, thresholds in the measurement contract"
  ],
  "next_week": {
    "lecture_line": "Lecture 13 -- Part V closes: security and law, the matrix shift, the eighth pattern, synthesis",
    "topics": [
      "OWASP LLM Top 10 and prompt injection; the EU AI Act as hard constraint",
      "How AI shifts the matrix: the C10 row cell by cell, D12 across the seven patterns, which cells shift, MLOps maturity",
      "Agent orchestration as the emergent eighth pattern: topologies, the economics of autonomy, capability-profile sketch",
      "Synthesis: one theory, five parts; exam orientation"
    ],
    "reading": [
      "this week: Part V, Sections 40--41, 42.1--42.5",
      "ahead: Part V, Sections 42.6--42.7, 43--45"
    ],
    "exercise": [
      "coaching; eval harness as CI gate; cost/latency observability; hardening; distinction work",
      "milestone: eval harness in CI + guard + cost observability"
    ]
  },
  "script_boxes_used": [
    {
      "box": "definitionbox 'The two axes of the AI dimension'",
      "location": "§40, part5_ai_dimension.tex 14-21",
      "used_in_frame": "5 The two axes of the AI dimension"
    },
    {
      "box": "tikz fig:twoaxes",
      "location": "§40, part5_ai_dimension.tex 25-48",
      "used_in_frame": "5 The two axes of the AI dimension (right column)"
    },
    {
      "box": "keypoint 'Two axes, one method'",
      "location": "§40, part5_ai_dimension.tex 50-52",
      "used_in_frame": "5 The two axes of the AI dimension (one-line keypoint at the bottom)"
    },
    {
      "box": "table tab:aievidence",
      "location": "§41.3, part5_ai_dimension.tex 79-103",
      "used_in_frame": "8 The full empirical record, 2023--2025"
    },
    {
      "box": "table tab:moderators",
      "location": "§41.4, part5_ai_dimension.tex 118-134",
      "used_in_frame": "11 Reconciling the divergence: five moderator variables"
    },
    {
      "box": "thinkbox (moderators, perception gap)",
      "location": "§41.4, part5_ai_dimension.tex 136-138",
      "used_in_frame": "12 Discussion: which setting is yours?"
    },
    {
      "box": "keypoint 'Maxim 7'",
      "location": "§41.5, part5_ai_dimension.tex 153-155",
      "used_in_frame": "14 Three consequences bind Axis A into the fit theory -- Maxim 7"
    },
    {
      "box": "lstlisting lst:agentsmd",
      "location": "§41.6, part5_ai_dimension.tex 170-188",
      "used_in_frame": "15 Architecture documentation as a control interface for agents (listing beneath the text)"
    },
    {
      "box": "ailinse 'MCP is ports-and-adapters at ecosystem scale'",
      "location": "§41.8, part5_ai_dimension.tex 217-219",
      "used_in_frame": "17 The tool landscape, soberly -- and the AI Lens on MCP"
    },
    {
      "box": "hinweisbox (state of early 2026, expiry date)",
      "location": "§41.8, part5_ai_dimension.tex 223-225",
      "used_in_frame": "18 Benchmarks and their limits -- an expiry date on this section"
    },
    {
      "box": "projektbox (Axis A governs how you build)",
      "location": "§41.9, part5_ai_dimension.tex 236-238",
      "used_in_frame": "20 Project link: Axis A governs how you build the platform (referenced by the exercise frame 39)"
    },
    {
      "box": "definitionbox 'AI runtime component'",
      "location": "§42.2, part5_ai_dimension.tex 267-269",
      "used_in_frame": "24 The three component types -- one species, three profiles"
    },
    {
      "box": "table tab:aicomponents",
      "location": "§42.2, part5_ai_dimension.tex 271-288",
      "used_in_frame": "25 The three AI component types and their profiles"
    },
    {
      "box": "keypoint (three types differ where the twelve dimensions measure; contain behind a boundary)",
      "location": "§42.2, part5_ai_dimension.tex 296-298",
      "used_in_frame": "28 Key concept: adding AI is a per-component matching problem"
    },
    {
      "box": "definitionbox 'CACE -- Changing Anything Changes Everything'",
      "location": "§42.3, part5_ai_dimension.tex 307-309",
      "used_in_frame": "29 Why containment: the SE4AI classics -- hidden debt and CACE"
    },
    {
      "box": "ailinse 'Parnas meets CACE'",
      "location": "§42.3, part5_ai_dimension.tex 313-315",
      "used_in_frame": "30 Three differences, 28 tests -- AI Lens: Parnas meets CACE"
    },
    {
      "box": "tikz fig:llmgateway (reference architecture)",
      "location": "§42.4, part5_ai_dimension.tex 322-385",
      "used_in_frame": "31 The reference architecture -- the sentiment call, re-wired"
    },
    {
      "box": "ailinse 'Model routing is a classical tactic in new clothes'",
      "location": "§42.4, part5_ai_dimension.tex 397-399",
      "used_in_frame": "34 The elements justified (3/4): model routing -- AI Lens"
    },
    {
      "box": "definitionbox 'Eval harness'",
      "location": "§42.5, part5_ai_dimension.tex 406-408",
      "used_in_frame": "36 The eval harness -- definition and course thesis"
    },
    {
      "box": "keypoint 'The course thesis on testing AI'",
      "location": "§42.5, part5_ai_dimension.tex 419-421",
      "used_in_frame": "36 The eval harness -- definition and course thesis"
    },
    {
      "box": "examplebox 'An eval harness for the portfolio platform' + lstlisting lst:evalharness",
      "location": "§42.5, part5_ai_dimension.tex 423-453",
      "used_in_frame": "38 Example: an eval harness for the portfolio platform"
    }
  ],
  "script_boxes_dropped": [],
  "open_issues": [
    "Minute budget: content frames 4-38 sum to 117 min; with agenda 1, recap 3, exercise 3, summary 2, next week 1 the total is 127 min for 135 -- the 8-min remainder is the reserve for the break. The former frame 9 was dropped, frames 19+20 and 22+23 of the previous version merged, and the freed time reinvested in the split frames 27/28 and 32/33; the cross-lecture review then merged frames 15+16 (§41.6 text + AGENTS.md listing) and 20+21 (risks 1/2 + 2/2) to honour 'Guardrails (kompakt)' -- §41.6-41.9 now take 6 frames / 16 min instead of 8 frames / 23 min -- and reinvested 3 of the 4 freed minutes in the reference-architecture walk-through (frame 31, now 7 min); the fourth minute went to the reserve.",
    "Density fallbacks that would raise the frame count (all still within the 40-46 band): frame 8 (tab:aievidence, seven rows at scriptsize with 12.4 cm columns) may need a (1/2)/(2/2) split -> 43 frames; frame 15 (merged §41.6 text + 14-line AGENTS.md listing at scriptsize) may need the corollary bullet moved to speech or, failing that, a re-split into text frame + listing frame -> 43 frames; frame 17 (merged landscape + MCP ailinse, six bullets plus box) may need the MCP adoption chronology moved to speech; frame 19 (merged risks, five footnotesize bullets) may need \\scriptsize.",
    "fig:llmgateway is drawn for \\textwidth portrait with five vertically stacked gateway sub-boxes; on a 16:9 frame (frame 31) it needs a redraw (gateway internals in a 2+3 grid, providers to the right, queue/guard/eval below) and a pdftoppm check; the walk-through now has 7 minutes and may use \\onslide overlays for the four re-wiring stages; no content beyond the figure's labels and the §42.4 intro sentence is added.",
    "lst:evalharness is 26 lines in the script; the deck shows ~16 code lines (docstrings, blank lines and duplicating comments dropped) so that the one-line threshold header and the caption line fit; verify the footline with pdftoppm.",
    "Script-internal tension flagged for the author (frame 28 note): the §42.2 keypoint (line 297) maps determinism to D4, while §42.1 (line 256) maps non-determinism to D12 and tab:dimensions labels D4 'Consistency & transactional integrity'. The deck keeps the script wording; if the script is corrected, render the strip as 'determinism (D12)'.",
    "Two transfer lines are not script text and are placed outside the boxes as \\scriptsize codegray asides: the project-transfer question under the discussion thinkbox (frame 12) and the 'which project component is which type' line under the keypoint (frame 28; type (b) has no instance in the project, since the exercise sheet defines Performance/Risk/Optimization as deterministic services). Drop both if strict verbatim is required.",
    "The \\measured macro exists only in deck 2's preamble (line 114); frame 6 does not use it. If the author wants the grey 'Measured / Instrument' box, copy the macro definition into this deck's preamble.",
    "Failure 5 (injection, D6) in §42.1 cites OWASP; the deck names only the mechanism and defers OWASP/prompt-injection content to Lecture 13 (§42.6) as instructed -- the reference-architecture frame's 'containing injection' phrase is the script's own wording and is kept.",
    "The script's §40 roadmap names §43 (matrix reading) and §44 (agent pattern); the deck cites them only as 'next week'; likewise the MLOps maturity ladder (§43) mentioned in the type (b) paragraph is pointed to, not taught.",
    "There is no script thinkbox for §42.1-42.5, so the deck has a single Discussion frame (Axis A, frame 12). A second discussion on Axis B would have to be authored outside the script; not done here.",
    "Deck 6's C10 frames already quoted the 50\\,\\% batch discount, the 98\\,\\% cascade figure and the factor-two router figure; frames 33-34 repeat them with an inline '(figures from deck 6 -- here placed where they live: in the gateway)' marker -- intentional repetition, not new content.",
    "Frame titles are capped at ~68 characters; the exercise-frame title (66 characters, the reviewer's wording) and frame 37's title (64) are the longest -- check in the FHGR header at compile time and shorten frame 37 to 'Four evaluation strategies make a complete harness' if it wraps. The merged risks frame 19 was shortened to 63 characters ('automation bias' -> 'bias' in the title only; the bullet keeps 'Automation bias')."
  ],
  "total_frames": 42
}