Asimov's Zeroth Law of Robotics: Testing for AI  🔗 **Source:** [Asimov's Zeroth Law of Robotics: Testing for AI](https://nicolevanderhoeven.com/blog/20261007-asimovs-zeroth-law-testing-for-ai-hustef/) > [!note]+ Document Notes > tags: [ai-testing, llm-evals, observability, conference-talk, asimov-zeroth-law] > author: Nicole van der Hoeven > source: nicolevanderhoeven.com > reference: https://nicolevanderhoeven.com/blog/20261007-asimovs-zeroth-law-testing-for-ai-hustef/ > date created: 2026-10-12 11:04 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Asimov's Zeroth Law of Robotics: Testing for AI (HUSTEF 2026) > <!-- deep-read:sections start --> ## 🧭 Table of contents - [📝 Summary](#-summary) - [📖 Main content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning styles assessment](#-learning-styles-assessment) - [📊 Accessibility assessment](#-accessibility-assessment) - [🌍 DEIB assessment](#-deib-assessment) - [✅ Logical validity](#-logical-validity) - [🛡️ DARVO analysis](#️-darvo-analysis) - [🎯 Conclusion](#-conclusion) - [🔄 Refactor appendix](#-refactor-appendix--asimovs-zeroth-law-of-robotics-testing-for-ai-hustef-2026) ## 📝 Summary This is a descriptive reading of a first-person conference-talk write-up. Nicole van der Hoeven published it on their personal blog, nicolevanderhoeven.com, on 2026-10-07 (date taken from the URL). It recaps a keynote at HUSTEF 2026 in Budapest, Hungary. It is practitioner commentary and opinion, not a study, and the captured text has no data tables or measurements. - **What happened.** Nicole gave a keynote called "Asimov's Zeroth Law of Robotics: Testing for AI" (P1). It is the testing-focused version of a talk previously given as "Observability for AI" at KubeCon EU 2025 in London, Dutch Cloud Native Day 2025 in Utrecht, NewCrafts in Paris, and ExpoQA Madrid 2026 (P1). The post reproduces the abstract (P2), explains what changed (P3), and summarizes a demo and the Q&A (P6-P11). - **The claim.** The Zeroth Law changed from "a robot must be observable" to "a robot must be testable" (P3). Nicole's reasoning: observability shows what a system did, but "pure knowledge isn't the same as trust" (P3). Trust comes from testing the system in foreseen and unforeseen situations. - **The evidence offered.** One literary example, Speedy the robot from Asimov's "Runaround" in I, Robot (P4), and one personal project, an instrumented AI Dungeon Master for tabletop role-playing games (P6). The post reports no benchmark, eval scores, or failure rates. - **Why it matters.** The post argues testing is the discipline that survives AI-assisted development (P5) and that writing evals for non-deterministic systems forces teams to state requirements they'd otherwise discover in production (P6). - **Key stakeholders.** Testers and QA engineers (the HUSTEF audience), developers and AI engineers shipping agent features, engineering managers deciding how much to test, and colleagues who fear AI (P11). - **Risks and tradeoffs.** The "fire developers before testers" line (P9) is flagged by the author as provocative. The "tested enough" answer is risk and budget (P8), which defers the hard question of how to measure either. The demo app is a hobby project, so the transfer to life-critical systems is argued, not shown. - **Bottom line.** A clear, well-framed argument that trust requires tests, built on one fiction example and one hobby project. The recording was not yet published when the post went up (P14). ## 📖 Main content **The shift from observable to testable (P3).** Earlier versions of the talk said a robot must be observable. Nicole still holds that observability is "the only way to see the reasoning behind a system and find out what actually happened," but argues knowledge and trust are different. A system can be fully visible and still untrusted. The only route to trust is exposing it to cases: the ones you foresee and the ones you don't. So the Zeroth Law became "a robot must be testable." **The abstract's problem statement (P2).** AI systems "fail differently than traditional software": there is no single correct output to assert against, a response can be fluent and wrong, and models drift silently. The abstract says observability makes testing possible because tracing reasoning and measuring change lets you write evaluations, define "good," and catch regressions. It frames evals as the AI equivalent of a test suite and promises coverage of what to measure, how to catch hallucinations, and how to detect regression. The source is the abstract of the talk, so it states intent, not results. **Speedy as the cautionary tale (P4).** In Asimov's "Runaround," Speedy is sent to collect selenium on Mercury and loops around the pool because obedience (the second law) conflicts with self-preservation (the third). His owners can't predict or reason about the behavior, so they go into the danger zone and fix him in production. Nicole's reading: Speedy wasn't untestable through anyone's incompetence. He was never built to be tested. **Testing as the durable discipline (P5).** The post separates how software gets built from the discipline of trust. Trust means a system does what we say and, when it breaks, we know why and can fix it. Nicole names "a whole generation of AI engineers shipping software they haven't tested and can't explain" and says the tester's question remains "how do you know?" **The AI Dungeon Master demo (P6).** Nicole instrumented a tabletop role-playing game assistant and put it under test. Writing evals forced them to put into words when a dungeon master should call for a dice roll, which surfaced decisions that had stayed implicit even though Nicole runs games themself. The claim is that doing this up front beats finding the gaps in production. **Q&A (P7-P11).** Five threads: when an AI is tested enough (risk and budget, P8); testers versus developers (P9); expected results for non-deterministic systems, multi-turn evals with a simulated user given a personality, and the shift from imperative to declarative, compared to Kubernetes (P10); and colleagues who fear AI (P11). **Reading and code (P12-P14).** Nicole recommends the book Slow AI, describes it as neither apologist nor boycott, and shares the demo app on GitHub. The post will be updated with the HUSTEF recording. ## 🗒️ Notes #### 📄 ¶1-¶2 Venue, lineage, and abstract - The talk is the fourth rewrite in a line: KubeCon EU 2025 (London), Dutch Cloud Native Day 2025 (Utrecht), NewCrafts (Paris), ExpoQA Madrid 2026, then HUSTEF 2026 (Budapest). - The abstract lists Asimov's three laws, then adds a prerequisite: "a robot must be testable." - It names three AI failure modes: no single correct output, fluent but wrong responses, and silent model drift. - The abstract closes with a two-part maxim: you can't test what you can't see, and can't trust what you can't test. #### 📄 ¶3 From observable to testable - The Zeroth Law changes wording between iterations of the talk. - Observability remains necessary because it shows what actually happened. - Knowing what a system did is not the same as trusting it. - Trust comes from behavior under foreseen and unforeseen situations. #### 📄 ¶4 Speedy and "Runaround" - Speedy loops around the selenium pool, caught between obedience and self-preservation. - His owners can't predict or reason about him, so they fix him in production. - Nicole's point: he was untestable by design, not through negligence. - The post applies this to AI systems being shipped now. #### 📄 ¶5 The testing audience's through-line - AI changes how software is built, not the discipline of trust. - Trust means the system does what we say and failures are explainable and fixable. - Nicole says some AI engineers ship software they haven't tested and can't explain. - The tester's role is to ask "how do you know?" when someone says "the agent does this." #### 📄 ¶6 The AI Dungeon Master demo - The demo is a TTRPG side project, instrumented and put under test. - Writing evals for non-deterministic output forces explicit requirements. - Example: the rule for when to call for a dice roll depends on situation and on pacing ("keep the story moving"). - Surfacing that rule early replaces discovery in production. #### 📄 ¶7-¶8 Q&A: tested enough - The post introduces the Q&A as ranging beyond the slides. - "Tested enough" depends on risk and budget, as with any software. - A life-critical robot like Speedy needs every scenario its users rely on. The hobby demo needs less. #### 📄 ¶9 Q&A: testers versus developers - Nicole says they'd fire developers before testers, and calls it provocative. - Reasoning: anyone can write code now. Good developers were good at translation and safe, creative solutions. - Testers already work at that level across teams. #### 📄 ¶10-¶11 Q&A: non-determinism, multi-turn evals, and fear of AI - Multi-turn evals use a simulated user with a personality (adversarial, cooperative, beginner), not a script. - The broader shift is from imperative to declarative, compared to Kubernetes. - On colleagues who fear AI: AI is here to stay, and the choice is to help make it safe and trustworthy or stay on the sidelines. #### 📄 ¶12-¶15 Reading, repo, recording, resources - Slow AI is recommended for its balanced list of what AI is and isn't good for. - The instrumented AI DM is on GitHub and gets refined with each talk iteration. - The recording will be added once HUSTEF publishes it. - The capture ends with an empty "Resources" heading, and the link list supplies seven links. ## 📚 References The link list (7 entries) was checked first. Anchor text is the article's. All seven links are listed here. **Article** - [Asimov's Zeroth Law of Robotics: Testing for AI (HUSTEF 2026)](https://nicolevanderhoeven.com/blog/20261007-asimovs-zeroth-law-testing-for-ai-hustef/), Nicole van der Hoeven, 2026-10-07 (from the URL). **Venue and earlier versions of the talk (link list)** - HUSTEF 2026: https://hustef.com/nicole_van_der_hoeven_2026/ (the conference talk page, P1 context) - KubeCon EU 2025: https://nicolevanderhoeven.com/blog/20250402-asimovs-zeroth-law-of-robotics/ - Dutch Cloud Native Day 2025: https://nicolevanderhoeven.com/blog/20250703-asimovs-zeroth-law-dutch-cloud-native-day/ - NewCrafts: https://nicolevanderhoeven.com/blog/20251106-asimovs-zeroth-law-newcrafts/ - ExpoQA Madrid 2026: https://nicolevanderhoeven.com/blog/20260526-asimovs-zeroth-law-expoqa-madrid/ **Resources section (link list)** - Slow AI (book, P12): https://link.amazon/B0e4SIur8 - Demo app on GitHub (P13): https://nicole.to/asimov **Primary sources for named entities.** Asimov's short story "Runaround" appears in the collection I, Robot (P4). No link in the captured markup points to it, to the talk recording (which is not yet published, P14), or to the Kubernetes documentation behind the declarative comparison (P10). **Claims with no link in the captured markup.** The Q&A positions (P8-P11), the author's account of what the demo surfaced (P6), and the claim about a generation of AI engineers shipping untested software (P5) have no linked evidence. The post presents them as the author's view. ## 🗣️ Paraphrase Nicole van der Hoeven gave a keynote at HUSTEF 2026 in Budapest and wrote it up on their blog. The talk is the latest rewrite of one they've given since 2025 under the title "Observability for AI." The core change is the Zeroth Law: a robot must be testable, not just observable. Seeing everything a system did doesn't mean you trust it. You trust it after you've put it through foreseen and unforeseen situations. Nicole uses Asimov's Speedy, the robot looping around a selenium pool, to show what happens when a system isn't built to be tested: its owners can't predict it, so they fix it in production. They tie this to AI engineering today and say testers' habit of asking "how do you know?" is the discipline that keeps AI viable. A demo, an AI Dungeon Master for tabletop games, showed that writing evals forces you to say out loud requirements you'd otherwise find in production. The Q&A covered how much testing is enough (risk and budget), why testers matter more as code gets easier to write, multi-turn evals with personality-driven simulated users, and how to talk to colleagues who fear AI. ## 📰 Newsletter **A robot must be testable.** Nicole van der Hoeven's HUSTEF 2026 keynote rewrites the Zeroth Law of Robotics for AI engineering. Earlier versions said a system must be observable. This one says knowing what a system did isn't the same as trusting it, and trust comes from testing against foreseen and unforeseen situations. The post uses Speedy, the robot in Asimov's "Runaround" who circles a selenium pool on Mercury, as a warning: his owners couldn't predict him, so they fixed him in production. A hobby project, an AI Dungeon Master put under test, showed that writing evals for non-deterministic output forces you to define requirements you'd skip, such as when the assistant should call for a dice roll. If you build or test AI features, the practical takeaways are the multi-turn eval with a simulated user who has a personality (adversarial, cooperative, beginner) and the framing of evals as the AI equivalent of a test suite. The post is a conference recap and opinion, and it reports no eval results. Read the original: [Nicole van der Hoeven's blog](https://nicolevanderhoeven.com/blog/20261007-asimovs-zeroth-law-testing-for-ai-hustef/). Demo app: https://nicole.to/asimov. ## ✅ Action items These items concern the reader's own testing and documentation practice. They don't assess the talk's claims beyond what the post says. #### DevRel - Developer advocacy: when presenting an AI feature, show the eval that tells you it works, not only a demo run. - Education: build a short workshop around the post's "write evals to find your real requirements" exercise, using the dice-roll example as a template. - Developer experience: document how a developer can trace an AI feature's reasoning and then run a test against it, so observability and testing sit in one page. - Developer marketing: avoid claims like "the agent handles this" without a linked eval or test result. - Community management: invite testers into AI feature feedback threads, since the post argues they translate across teams (P9). - Internal/external: when asked "is it tested enough," answer with risk and budget terms (P8) and name the scenarios covered. #### OSPO - Policy and governance: no direct action from this source; nearest relevance is a policy that AI-assisted contributions ship with tests. - License compliance: no direct action from this source. - Security management: treat adversarial simulated users (P10) as a candidate test persona for AI-facing features. - Software inventory: list AI-powered features with a note on which have evals. - Developer support: no direct action from this source. - Community engagement: no direct action from this source. - Strategic alignment: no direct action from this source. #### Community - Maintainers: ask for an eval or test case when reviewing a PR that adds AI behavior. - Contributors: practice writing one eval for a non-deterministic behavior you own. - Sponsors: no direct action from this source. - Ecosystem: no direct action from this source; nearest relevance is shared eval sets for common AI tasks. #### WordPress - Core: no direct action from this source. - Core Performance: no direct action from this source. - Core AI: nearest relevance is the post's framing of evals as a test suite for AI features. Consider how AI features in core would be regression-tested. - Core Program Team: no direct action from this source. - Mobile: none. - Playground: none directly. Nearest relevance is a disposable environment for running eval scenarios. - Community: none directly. - Training: if AI testing is taught, use the Speedy example (P4) as a hook and source technical content elsewhere. - Marketing: none. - Support: none. - Design: none. - Documentation: no direct action from this source. - Photos: none. - TV: none. - Polyglots: none; nearest relevance is whether AI-assisted translations get evals per language. - Accessibility: none from this source. - Meta: none. - CLI: none. - Hosting: none. - Tide: none. - Openverse: none. - Themes: none. - Plugins: plugin authors adding AI features can adopt the "define what passing means" step before release. #### The WPOCC - Programs: no direct action from this source. - Projects: no direct action from this source. - Funding experiments: none. ### FAIR - Technical independence: no direct action from this source. - Policies and covenants: no direct action from this source. - Productized governance artifacts: nearest relevance is a published checklist of evals an AI-assisted package must pass. ## 🧪 Hypotheses 1. Teams that write evals before building an AI feature record more explicit behavior requirements than teams that write them after. 2. A multi-turn eval with a persona-driven simulated user (adversarial, cooperative, beginner) finds failures a scripted multi-turn test misses. 3. Observability without evals leaves more regressions undetected after a model change than observability with evals. 4. Organizations that cut testers before developers in AI-assisted teams see a higher rate of production incidents from AI features. 5. Declarative end-state specs for AI behavior produce less variance in eval results than step-by-step instructions. 6. "Tested enough" decisions made by explicit risk and budget criteria are more consistent across reviewers than ad hoc ones. ## 📊 Methodology - **H1.** Run a paired study on two small AI features. One team writes evals first, one after. Count requirements written down at release and incidents in the first 60 days. - **H2.** Build an eval suite for one assistant with a scripted user and a persona-driven simulated user. Compare the distinct failures each finds over the same number of conversations. - **H3.** Introduce a controlled model change to an observed assistant. Count regressions caught by trace review alone versus an eval run on the same change. - **H4.** Review incident data from organizations that changed team ratios. This is observational, so state confounders (product maturity, model choice). - **H5.** Run the same eval 30 times against two spec styles and compare the variance in pass rates. - **H6.** Give reviewers 20 AI feature cases with and without a risk and budget rubric and compare agreement. ## ❓ Questions - What does the talk define as "passing" for a non-deterministic response, and how is that threshold set? - How many evals did the AI Dungeon Master demo have, and how often did it regress after a model change? - How do multi-turn evals with personality-driven users get scored, and who grades them? - What did the observability-platform assistant mentioned in the abstract (P2) measure, and are those results published? - Is "fire developers before testers" (P9) meant as a staffing position or a rhetorical point about communication skills? - Where does the post's trust claim stop: does a passing eval suite earn trust for unforeseen situations, or only the ones someone thought to write? - How does the evaluation approach change for the abstract's "silent drift" case when no code changes? - What did the audience ask that did not fit in the Q&A summary? ## 🔮 Future research - **Eval design for non-deterministic systems.** Compare assertion styles (exact match, rubric, model-graded) on the same task and report agreement. - **Persona-driven simulation.** Study whether adversarial, cooperative, and beginner personas find distinct failure classes in multi-turn assistants. - **Requirements discovery via evals.** Measure how many implicit requirements surface when teams write evals for a feature they know well. - **Observability to testing handoff.** Study how traces get converted into regression tests in practice. - **Role effects in AI-assisted teams.** Examine whether testing skill predicts incident rates in teams that generate most code with AI. ## 💡 Implications - **Practice.** Write an eval before shipping an AI feature, and use the exercise to extract implicit rules, as the dice-roll example (P6) shows. - **Policy.** Teams can require a stated pass criterion and a risk and budget rationale for any AI feature (P8). - **Security.** Adversarial simulated users (P10) turn red-team thinking into a repeatable test. - **Education.** The Speedy story (P4) is a teachable case for designing for testability, and the post's observable-versus-trusted split is a usable distinction. - **Funding.** The post reports no costs. The "risk and budget" answer (P8) implies test depth scales with spend, which funders can ask to see. ## 🧠 Learning styles assessment - **Reading level estimate.** About 9th grade, Flesch-Kincaid Grade Level of roughly 9 and Flesch Reading Ease near 55, from a syllable heuristic on the roughly 1,000-word body, which counts the quoted abstract. The abstract's long sentences raise the level. The author's own paragraphs read easier. #### 👀 Visual learners - Present: no images or diagrams appear in the captured text. The talk had slides, which the post doesn't include. - Improve: add a one-line diagram of observe, evaluate, trust, or an eval loop with the simulated user. #### 🔊 Aural learners - Present: the post promises a recording (P14), so audio is planned but not yet linked. - Improve: link the recording and a transcript when published. #### 🗣️ Verbal learners - Present: a clear narrative from abstract to claim to example to Q&A, with short paragraphs. - Improve: define "eval" and "non-deterministic" in a clause for readers outside testing. #### 🧩 Kinesthetic learners - Present: the GitHub demo app (P13) lets a reader run and modify an instrumented, tested assistant. - Improve: add a short exercise, such as writing three evals for one behavior, with the dice-roll example as a start. #### 🧠 Logical learners - Present: a stated thesis (P3), an example (P4), and an applied case (P6). - Improve: show the eval design and results behind the demo so the claim can be checked. #### 🧑‍🤝‍🧑 Social learners - Present: the Q&A summary (P7-P11) brings in audience questions and the earlier talk venues. - Improve: add a discussion prompt or a link to a community thread. #### 🧘‍♀️ Solitary learners - Present: self-contained, with a link to each earlier version for deeper reading. - Improve: a short reading list beyond Slow AI. #### 🌿 Naturalistic learners - Present: none; the content is technical and literary. - Improve: not applicable beyond the Kubernetes comparison (P10). ## 📊 Accessibility assessment Judged from the captured text and link list only. Rendered contrast, focus order, and image alt text are unknowable from this capture. #### Screen reader semantics - Present: the capture ends with "## Resources," a heading marker that suggests a real heading, and the abstract is set as a blockquote (P2). The Q&A uses a list (P8-P11). - Improve: confirm the Resources heading has content or is removed, since an empty section reads as a dead end (WCAG 2.2 AA 1.3.1 Info and Relationships, 2.4.6 Headings and Labels). The abstract's paragraph breaks collapsed in capture ("assert against.A response"), so check the rendered blockquote keeps its paragraphs for 1.3.1. #### Keyboard navigation - Present: seven links, all ordinary anchors as far as the capture shows. - Improve: not verifiable from text. Check 2.1.1 Keyboard and 2.4.7 Focus Visible. #### Contrast and readability - Present: unknowable from the capture. Paragraphs are short, apart from the abstract. - Improve: verify 1.4.3 Contrast (Minimum) on body text and links. #### Text resizing and reflow - Present: text-only content should reflow, and the capture shows no fixed-size media. - Improve: verify 1.4.4 Resize Text and 1.4.10 Reflow at 320 CSS px and 200% zoom. #### Media and captions - No media referenced in the captured text beyond a promised recording (P14). The text mentions no captions or transcript for it. - Improve: publish captions and a transcript with the recording (1.2.2 Captions, Prerecorded). #### Forms and interactions - Present: no form appears in the captured text. - Improve: if a comment form or newsletter signup exists, check 3.3.2 Labels or Instructions. #### Standards reference - Likely gaps to verify against WCAG 2.2 AA: **2.4.4** Link Purpose (In Context) for the bare anchors "GitHub" and "HUSTEF 2026," which depend on context. **1.3.1** for the empty Resources section and the collapsed abstract paragraphs. **1.2.2** for the future recording. Everything else needs the rendered page. ## 🌍 DEIB assessment #### Cultural breadth - Present: the talk traveled across the UK, the Netherlands, France, Spain, and Hungary, and the post names each venue. - Improve: the examples are Western science fiction (Asimov, Skynet, cylons, the Butlerian Jihad) and a Western tabletop game. A sentence on non-English-language AI testing would widen reach. #### Inclusive language - Present: no exclusionary terms appear in the author's prose. The "fire developers before testers" line (P9) is labeled provocative by the author. - Improve: "sit on the sidelines" (P11) frames hesitant colleagues as bystanders. A note that fear of AI has varied causes would soften it. #### Neurodiversity support - Present: short paragraphs and a bulleted Q&A aid scanning. - Improve: the abstract is a long block with dense sentences (P2). A summary bullet list would reduce load. #### Representation - Present: the post names only the author and Asimov. The text gives no gender, and this analysis uses the name and singular they for the author. - Improve: the post cites one book (Slow AI) and no other practitioner voices. Naming other eval practitioners would broaden the picture. #### Psychological safety - Present: P11 says the author doesn't fear AI and invites colleagues to engage, without naming anyone. - Improve: acknowledge that testers and developers may feel threatened by the staffing comment in P9. ## ✅ Logical validity This is opinion and practitioner commentary from a conference talk. It argues a position and supports it with one fictional example and one personal project, not data. #### Strong reasoning - **Observed versus trusted, ¶3.** Separating "knowing what a system did" from "trusting it" is a useful and checkable distinction. A fully traced system can still fail unforeseen cases. - **Speedy example, ¶4.** The analogy is apt: a system whose behavior owners can't predict or reason about gets fixed in production. The author notes the cause was design, not incompetence. - **Requirements surfacing, ¶6.** The dice-roll example shows a concrete mechanism: writing an eval forces the author to articulate a rule. This is a testable claim, and the author gives a specific instance. - **Risk and budget answer, ¶8.** The "tested enough" answer matches how test depth is set for other software, with a contrast between a life-critical robot and a hobby app. - **Honest limits, ¶14.** The post says the recording isn't out yet and promises an update. #### Fallacies No formal fallacies in the main argument. What I checked: whether the thesis follows from the examples, whether the abstract's claims are backed in the body, and whether the Q&A positions overreach. These points are about strength of support: - **Weak analogy, ¶4.** "That's the trap I think a lot of AI systems are walking into right now." One fictional robot stands for a population of AI systems. No survey or incident count is given. *Fix:* cite an incident or a count of shipped systems lacking tests. - **Generalization, ¶5.** "There's a whole generation of AI engineers shipping software they haven't tested and can't explain." Presented as fact, with no source, and probably true for some, not all. *Fix:* narrow to "some teams I've seen" or cite a survey. - **Hyperbole, ¶5.** "Testing is the reason AI gets to survive." The author frames it as a rhetorical close. A reader could take it as a causal claim. *Fix:* state it as a view. - **False dilemma, ¶11.** "Help make it safe and trustworthy, or sit on the sidelines." Other options exist, such as critical engagement from outside the industry. *Fix:* widen the options. - **Staffing line, ¶9.** "I'd fire developers before testers" rests on the claim that anyone can write code now and developers' value was translation. Testers' translation role is asserted, not shown, and the author labels the line provocative. *Fix:* separate the rhetorical point from a hiring claim. No instructions addressed to an AI or "the reader" appear in the source text. #### Tone of voice - Confident, conversational, and first person, with a mix of literary reference and practical advice. The author is an advocate for the testing position and for engaging with AI, and says they're not an AI apologist (P12, describing the book). The post carries no commercial pitch in the captured text. The author does promote their own talk lineage and demo repo, which is ordinary speaker self-promotion. ## 🛡️ DARVO analysis Not applicable to this source. DARVO (Deny, Attack, Reverse Victim and Offender) describes a response pattern to an accusation, and this is a conference recap with no accuser or accusation. Each prong is still checked. - **Deny.** No denial of wrongdoing appears. The author corrects no accusation. - **Attack.** No attack on a person or group appears. The "fire developers before testers" line (P9) is a provocative comparison, not an attack on named people, and the author labels it provocative. - **Reverse victim and offender.** No reversal appears. P11 recasts colleagues' fear of AI as a choice about staying in the industry, which is a persuasion move and not a victim-offender reversal. - **Author's voice.** The post doesn't defend against a charge. It states a position and invites engagement. ## 🎯 Conclusion Nicole van der Hoeven's post recaps a HUSTEF 2026 keynote arguing that AI systems must be testable, not only observable, because seeing what a system did doesn't produce trust. The argument rests on Asimov's Speedy story and on an instrumented AI Dungeon Master that showed evals force teams to state hidden requirements. The Q&A adds risk and budget as the test for "enough," a claim that testers gain importance as code gets easier to write, and persona-driven multi-turn evals. What the post doesn't establish: any measured result from the evals, how "passing" is defined for a non-deterministic response, or that the Speedy pattern applies to AI systems in general. It is opinion and practitioner commentary, and the author's claims about AI engineers and staffing carry no source in the captured text. **Next steps for readers:** open the demo repo (https://nicole.to/asimov) and read the eval definitions. Write one eval for a non-deterministic behavior you own and note which requirement it surfaces. Watch the HUSTEF recording when it's published and check whether the slides give numbers the post leaves out. ## 🔄 Refactor Appendix — Asimov's Zeroth Law of Robotics: Testing for AI (HUSTEF 2026) > Density: 2–5 Literature atoms (H3 pad), 0–3 Permanent candidates (H4 pad). > Emitted: 5 Literature, 2 Permanent. Resonance filter applied: the venue lineage, the > book recommendation, and the staffing provocation were dropped as context or > rhetoric that will date quickly. > > Konik claim-header rules: present tense, declarative, ≤10 words, searchable, unique. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Split Pad #### [H1] Knowledge of a system is not trust > [!quote] [¶3] > But I’ve come to think that pure knowledge isn’t the same as trust. **Context & use**: - ¶3, the reason the Zeroth Law moved from "observable" to "testable" between iterations of the talk. - It separates what observability gives you (what happened) from what testing gives you (grounds to rely on the system). **Tags**: #xref #articleseed #aphorisms <!-- atomicity: 1 idea ✓ --> #### [H2] Speedy was untestable by design > [!quote] [¶4] > he was untestable because he was never built to be tested. **Context & use**: - ¶4, Nicole's reading of Asimov's "Runaround." His owners weren't incompetent and had tools, yet couldn't predict or reason about him. - The author applies this to AI systems shipped now. The article offers no count of such systems. **Tags**: #xref #storystem <!-- atomicity: 1 idea ✓ --> #### [H3] Testing is the durable discipline of trust > [!quote] [¶5] > AI is rewriting how software gets built, but it doesn’t rewrite the discipline of trust. **Context & use**: - ¶5, the through-line for a testing audience: trust means the system does what we say and failures are explainable and fixable. - An opinion stated as fact. Keep it as the author's claim. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> #### [H4] Writing evals forces real requirements > [!quote] [¶6] > writing evals for something non-deterministic forces you to confront your real requirements. **Context & use**: - ¶6, from the AI Dungeon Master demo, where the rule for calling a dice roll turned out to be implicit. - A mechanism claim backed by one personal example. It is testable by counting requirements surfaced. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H5] Testers already translate across teams > [!quote] [¶9] > What made a good developer good was never the coding; **Context & use**: - ¶9, the premise behind the "fire developers before testers" line, which the author calls provocative. - The claim is that translation and communication skills carry the value, and testers already use them. No evidence is offered. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> ### 🧠 Atomic Split Pad #### [P1] Trust needs tests, not only traces **Claim** (one sentence, Courtney's voice): Seeing exactly what an AI system did gives me an explanation, and only running it against foreseen and unforeseen cases gives me grounds to trust it. **Evidence pointer**: [[#H1]] · [[#H2]] · [[#H3]] **Scope & conditions**: Holds for systems with non-deterministic output where no single answer can be asserted. Weakens for narrow deterministic components, where a trace and a unit test overlap. The article supports the claim with one fiction example and one hobby project, so treat it as a framing. **Links**: - [[Observability for AI]] — because extends - [[Evals as test suites]] — because evidence-for - [[Trust versus transparency]] — because contrasts on what visibility alone provides <!-- atomicity: 1 idea ✓ --> #### [P2] Evals are a requirements-discovery tool **Claim** (one sentence, Courtney's voice): Writing an eval for a non-deterministic feature makes me state rules I'd otherwise discover in production, so the eval is a design step before it is a safety net. **Evidence pointer**: [[#H4]] **Scope & conditions**: Holds when the author knows the domain well enough to attempt the rule and finds it hard to articulate. One example (the dice-roll rule) supports it. Counterexample: a feature with requirements already fixed by a spec. **Links**: - [[Requirements elicitation]] — because applies-in - [[Multi-turn evals with simulated users]] — because extends - [[Testing before shipping AI features]] — because evidence-for <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Open the demo repo at https://nicole.to/asimov and read how the dice-roll eval is written #fleeting #inbox - [F2] Find out how "passing" is defined for a non-deterministic response in the talk #fleeting #inbox - [F3] Idea: try a persona-driven simulated user (adversarial, cooperative, beginner) on an assistant I maintain #fleeting #inbox - [F4] Article seed: "Observable is not the same as trustworthy," using Speedy as the opening #fleeting #inbox #articleseed - [F5] Check the HUSTEF recording and slides when published for eval numbers the post omits https://hustef.com/nicole_van_der_hoeven_2026/ #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Read the eval definitions in the AI Dungeon Master demo repo and note the pass criteria — research, 30 min #things - [ ] Write one eval for a non-deterministic behavior I own and record which requirement it surfaced — practice, 45 min #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Asimov's Zeroth Law of Robotics Testing for AI.md|Asimov's Zeroth Law of Robotics: Testing for AI by Nicole van der Hoeven]] ## Highlights - The big shift in this version is right there in the Zeroth Law itself. In earlier iterations I argued that a robot must be observable. That’s still true — observability is the only way to see the reasoning behind a system and find out what actually happened. But I’ve come to think that pure knowledge isn’t the same as trust. You can know exactly what a system did and still not trust it. The only way to trust something is to put it through its paces: to know how it behaves in the situations you foresee, and even the ones you don’t. So the Zeroth Law has become a robot must be testable. ([View Highlight](https://read.readwise.io/read/01m4raev6bghad7nk404zvm9fe)) - Note: [H1] Knowledge of a system is not trust - Tags: atom/literature/h1 - I framed the whole thing around Asimov’s short story Runaround (from I, Robot) and its robot, Speedy. Speedy’s smuggler owners sent him to collect selenium on Mercury, and he got stuck in a loop — circling the selenium pool, unable to resolve the conflict between obedience (the second law) and self-preservation (the third). His owners couldn’t predict his behaviour and couldn’t reason about it, so they had to do the only thing left: go out into the danger zone and fix him in production. Speedy wasn’t untestable because his owners were incompetent or lacked the tools — he was untestable because he was never built to be tested. That’s the trap I think a lot of AI systems are walking into right now. ([View Highlight](https://read.readwise.io/read/01m4raexez0dsbgv66edy8m9bg)) - Note: [H2] Speedy was untestable by design - Tags: atom/literature/h2 - The through-line for a testing audience: AI is rewriting how software gets built, but it doesn’t rewrite the discipline of trust. Trust that a system does what we say it does, and that when it breaks we know why and can fix it — that’s always been the job, and it isn’t going anywhere. There’s a whole generation of AI engineers shipping software they haven’t tested and can’t explain, and when someone says “the agent does this,” our job is still to ask how do you know? Testing isn’t just going to survive the age of AI — testing is the reason AI gets to survive, if we make it testable. ([View Highlight](https://read.readwise.io/read/01m4raezq72t46vwr52p8kbf7m)) - Note: [H3] Testing is the durable discipline of trust - Tags: atom/literature/h3 - I demoed this with my TTRPG side project: an AI Dungeon Master, instrumented and put under test. It turns out that writing evals for something non-deterministic forces you to confront your real requirements. I thought I knew exactly when a dungeon master should call for a dice roll — I GM myself! — but trying to put it into words (“in this situation I’d roll, but in that one I wouldn’t, because I want to keep the story moving”) surfaced decisions I’d never had to make explicit. Those are things we’d normally discover much later, in production. Having to figure them out up front is a win. ([View Highlight](https://read.readwise.io/read/01m4raf2ejgdms38wst46dgggd)) - Note: [H4] Writing evals forces real requirements - Tags: atom/literature/h3 - - Testers vs. developers in the age of AI. I said I’d fire developers before testers — provocatively, but the point stands: anyone can write code now. What made a good developer good was never the coding; it was communicating with business and engineers, translating requirements, finding creative-but-safe solutions. Testers already think at that level and translate across teams, which makes them more important in the age of AI, not less. ([View Highlight](https://read.readwise.io/read/01m4raf4pvst4434gxgzdzgyws)) - Note: [H5] Testers already translate across teams - Tags: atom/literature/h3