Non-Deterministic Software
The shift in which software behavior is increasingly elicited via natural-language prompts — raising the level of abstraction while trading away deterministic execution — and the open question of what durable, persistent representation of a system replaces human-readable source code.
Also known as: non-determinism, sideways move into non-determinism, non-deterministic behavior, persistent statement of non-deterministic behavior, non-human deterministic representation, future source code
How authors use it
Oldest first (extraction date when no publication date is known).
| Author | Their term | Their meaning |
|---|---|---|
| Fragments: February 9 Martin Fowler · 2026-02-09 | sideways move into non-determinism | The trade-off whereby eliciting behavior through prompts and natural-language context raises the level of abstraction but yields non-deterministic behavior rather than deterministic execution |
| Fragments: February 9 Martin Fowler · 2026-02-09 | future source code | A speculated durable, non-human, possibly non-textual semantic representation of a system (in the spirit of Language Workbenches' persisted models) designed to maximize expression with minimal tokens, rendered to humans via projectional editors |
| Podcast: Tiger Teams, Evals and Agents: The New AI Engineering Playbook Sam Bhagwat · 2026-04-10 | non-determinism | The property of agentic applications where multiple successful runs can produce different response bodies, unlike traditional software |
| Presentation: Decision Models in Agentic Architectures: From Production to Agent Skills Alex Porcelli · 2026-09-14 | Non-determinism (as feature, not bug) | The variability of LLM output across identical inputs, which Porcelli insists is not a defect to be engineered away everywhere — it is what makes the 'magical experience' of generative AI possible — but which must be walled off from high-stakes decision-making rather than treated as an acceptable trade-off there. |
Documents (13)
- Presentation: Decision Models in Agentic Architectures: From Production to Agent Skills Alex Porcelli · 2026-09-14 Reader 🖥️
High-stakes decisions inside agentic AI systems need a deterministic, auditable decision-model layer (DMN, executed by a rule engine like Drools) sitting beneath the non-deterministic LLM and exposed to it as a skill or guardrail — generated from and owned by business domain experts rather than engineers — because what enterprise AI actually lacks is not mere consistency but full accountability: reproducibility, explainability, and governance together. - Beyond the 200 OK: Architecting Observability for AI Adriano Mota · 2026-09-11 source ↗ Reader 🖥️
Because an AI system can fail silently behind a healthy 200 OK response, traditional infrastructure-focused APM is structurally blind to AI failure and must be supplemented with purpose-built observability that traces cost, quality, and decision-making across the LLM/RAG/MCP/agent stack and feeds a continuous evaluation loop. - Presentation: Platform Engineering in the Age of AI Stéphane Di Cesare, Davide de Paolis, Stephen Cihak, Camila Macedo, Renato Losio · 2026-09-08 source ↗ Reader 🖥️
AI does not change what platform engineering fundamentally is — enabling safe, fast self-service through clear service intent — but it raises the stakes and widens the scope: platform teams must now serve agents as first-class consumers alongside humans, absorb new responsibilities (distributing AI context/skills, governing AI tool licensing and MCP access, guarding against non-deterministic behavior), and answer the standardization-versus-autonomy tension with embedded, evidence-producing governance rather than manual gates — making the platform, not less relevant as AI automates toil, but more central to letting an organization move safely at machine speed. - Beyond Zero: Google Publishes Successor to BeyondCorp Renato Losio · 2026-09-05 source ↗ Reader 🖥️
Google's newly published Beyond Zero model proposes extending Zero Trust from static, application-level, human-speed access control to continuous, resource- and action-level authorization combining static policy with dynamic AI-driven decisions for both humans and AI agents — an aspirational architecture that early practitioner and community reaction meets with skepticism about its maturity, complexity, and the wisdom of non-deterministic access controls. - Podcast: Will Agentic AI Bring Fantasia's Sorcerer's Apprentice to Life?: A Conversation with Tracy Bannon Tracy Bannon · 2026-08-17 source ↗ Reader 🖥️
Agentic AI's risk is not evenly distributed or novel in kind -- it concentrates sharply at the moments an agent crosses from one software/trust ecosystem into another, it is already an extension of existing (not new) security threats, and its most under-appreciated cost is not a security breach but the silent erosion of human cognitive skill and retention as people and society outsource understanding, not just labor, to models they do not fully govern. - Presentation: From Thousands to One: Building LLM-Powered Selection Systems Jendrik Jördening · 2026-08-17 source ↗ Reader 🖥️
When you need an LLM to select one item from among many database-backed options (an ID, a station, a record), you must strip the model down to only the irreducibly textual/semantic step it is actually good at — schema-restricted, range-bounded, and independently validated by a second model call — while pushing every deterministic operation (filtering, comparison, control flow) into ordinary code, recovering a classic model-view-controller separation that a single freeform LLM call destroys. - Stop being skeptical about AI for development with Charity Majors Gergely Orosz (interviewing Charity Majors, CTO/co-founder of Honeycomb) · 2026-08-12 Reader 🖥️
AI skepticism about software development, though rational as recently as 2025 given the industry's track record of over-promised transformative technologies, has become irrational in 2026 because the model-plus-harness combination (Opus 4.5 running inside Claude Code) crossed a genuine, cloud-computing-in-2010-scale capability threshold — so the live question for engineers is no longer whether to adopt AI but how to build the validation discipline (tests, evals, conformance checking, observability) that makes shipping AI-written, unread code safe. - The Problem Is Prompt Debt Drew Breunig · 2026-07-30 source ↗ Reader 🖥️
Because natural language is an imprecise specification language for a probabilistic model, hand-tuning prompts to define durable system behavior accumulates a distinct 'prompt debt' — slowing iteration, becoming illegible to teams, and locking the application to one model's idiosyncrasies — which can only be paid down by specifying behavior with measurable evals rather than prose and letting automated search (e.g. DSPy, GEPA) generate and optimize the prompt itself. - AI Demands More Engineering Discipline, Not Less Charity Majors · 2026-07-27 source ↗ Reader 🖥️
AI's collapse of the cost of writing code doesn't reduce the need for engineering rigor — it relocates that rigor away from the code itself and into the validation, observability, and feedback infrastructure surrounding it, which is why nondeterministic AI-generated systems demand more engineering discipline, not less. - The Economics of Agentic AI: Engineering for Imperfection Artur Huk · 2026-07-24 source ↗ Reader 🖥️
The runaway cost and catastrophic security failures of agentic AI both stem from treating a missing structural constraint (context, authority, evidence, or temporal validity) as a reasoning problem to be solved with more model intelligence, so enterprises must instead wrap probabilistic models in a deterministic governance 'airlock' — syntactic, semantic, and temporal gates that treat model output as an unprivileged claim — which converts model accuracy from a safety prerequisite into a tunable economic variable. - Podcast: Tiger Teams, Evals and Agents: The New AI Engineering Playbook Sam Bhagwat · 2026-04-10 source ↗ Reader 🖥️
Shipping agentic AI applications to production requires organizations to combine software engineering rigor with data science's comfort with statistical uncertainty, using cross-functional Tiger Teams, domain-specific evals built on proprietary data, and a culture of enthusiastic experimentation. - Fragments: February 9 Martin Fowler · 2026-02-09 source ↗ Reader 🖥️
As LLMs absorb more of the work of building software, the pressing questions are less about model capability than about what humans stand to lose — the team's understanding of the system (cognitive debt), the intellectual craft-joy of model-building, and even the meaning of 'source code' as behavior shifts from deterministic text toward non-deterministic natural-language prompting. - How AI will change software engineering – with Martin Fowler The Pragmatic Engineer · 2025-11-19 source ↗ Reader 🖥️
AI's defining change to software engineering is not primarily a jump in abstraction level but a shift from deterministic to non-deterministic systems — and the disciplines that make software durable and legible to teams over time (small reviewable steps, tests, refactoring, shared vocabulary, mentorship) matter more, not less, as a result, even as the field has not yet worked out how teams — as opposed to individuals — should operate with AI.
Propositions touching this concept (5)
By publication month, oldest first (extraction month when no publication date is known).
2025-01
- explicitcontestedThe non-determinism of LLMs is a feature, not a bug — if they were deterministic, they would be pure functions and would not provide the generative capability that makes them valuable.
2026-02
- explicitdevelopedNatural-language prompts and context can elicit a lot of behavior and raise the level of abstraction, but they do so by moving software sideways into non-determinism.
- implicitThe future 'source code' may be a non-human deterministic representation designed to maximize expression with minimal tokens.
2026-04
- explicitcorroboratedLLM non-determinism can be sufficiently tamed for production coding workflows by wrapping AI in a strict hierarchy: hard-coded hooks/scripts first, specialized narrow agents second, project rules/memory third
2026-05
- explicitLLM non-determinism means edits can introduce regressions in unrelated parts of the code.
Tensions
What kind of problem is AI adoption in software development, and who is the responsible actor for fixing it?
from: Is skepticism/rejection of AI for software development still rational in 2026 — and where exactly do practitioner "adopt fully" and "abstain entirely" positions actually diverge: on the facts (does AI work), the values (what counts as harm), or the frame (individual choice vs. systemic problem)?
- Stop being skeptical about AI for development with Charity Majors (Charity Majors): An engineering and organizational-leadership problem, solved inside the firm by building validation discipline and rebuilding trust between camps.
- I'm done using AI (Brett Codes): A personal ethical problem, solved by individual non-participation.
- The growing AI backlash (Gary Marcus): A political/regulatory problem, solved by governments constraining the industry.
Assessment: These aren't competing answers to the same question — they're answers to three different questions about where causal and moral leverage lies (org-technical, individual-ethical, political-collective), and the corpus never stages a direct confrontation between them. The weakest of the three on its own terms is Brett's: his abstention argument depends on an untested demand-signaling causal claim, and Marcus's own regulatory framing implicitly undercuts it — if the effective lever is political, one person's abstention is symbolic rather than causally load-bearing, however psychologically necessary it may be for him. Majors's org-engineering frame is the most operationally developed but explicitly scopes itself to teams that already have the discipline to execute it — it has nothing to offer someone in Brett's actual position (an individual contributor under a leadership mandate, with no control over org-level tooling investment).
Does verification/validation substitute for human care and authorship as the basis of software quality?
from: Is skepticism/rejection of AI for software development still rational in 2026 — and where exactly do practitioner "adopt fully" and "abstain entirely" positions actually diverge: on the facts (does AI work), the values (what counts as harm), or the frame (individual choice vs. systemic problem)?
- Stop being skeptical about AI for development with Charity Majors (Charity Majors): Yes — trust can and should relocate from authorship to process; once validation is good enough, shipping code nobody read is not a quality failure.
- I'm done using AI (Brett Codes): No — quality is constituted by care, which only a human relationship to the artifact supplies; verification does not substitute for it, even AI reviewing AI.
Assessment: A genuine values disagreement, not a disguised factual one, and under-argued on both sides. Majors asserts a substitution (trust moves from person to process) as self-evidently sufficient without ever specifying what validation would need to guarantee to make 'comfortable shipping unread code' true in practice — a gap her own extraction already flags. Brett asserts the opposite from pure introspection, without considering that his felt alienation might be a contingent response to a personal transition rather than a fact about what quality requires in principle — plenty of trusted professional domains (structural engineering, aviation, pharma) run on process-based rather than personal-craft-based trust and aren't usually accused of producing 'uncared for' outputs. Neither side defends its definition of quality against the other's; each asserts its own as obvious.
Does sustained, earnest, disciplined AI use degrade or improve a competent practitioner's skill and output?
from: Is skepticism/rejection of AI for software development still rational in 2026 — and where exactly do practitioner "adopt fully" and "abstain entirely" positions actually diverge: on the facts (does AI work), the values (what counts as harm), or the frame (individual choice vs. systemic problem)?
- Stop being skeptical about AI for development with Charity Majors (Charity Majors): AI use, wielded by disciplined teams, produces real capability gains without degrading quality, provided validation investment keeps pace.
- I'm done using AI (Brett Codes): Sustained AI use degraded his skill, care, and output quality over more than a year, despite being an experienced, motivated, initially-skeptical, earnestly-trying practitioner.
Assessment: Both are single-case evidence dressed as general claims, and the corpus offers a plausible reconciling variable neither author controls for: Parker's joy-gap data shows the split tracks codebase type (greenfield/small-product vs. legacy/enterprise) more cleanly than it tracks practitioner discipline or virtue. Fin is not described as legacy-constrained, and Brett's own most damning anecdote — the Linear/Claude Code project built 'without editing a line of code' — is closer to greenfield vibe-coding than to his day-to-day legacy work. The Majors/Brett disagreement may therefore be less a disagreement about AI's general effect on skilled practitioners and more two data points from different ends of Parker's spectrum, each over-generalized past its actual scope.
Is a moderate, bounded middle path between full adoption and full abstention psychologically and practically stable?
from: Is skepticism/rejection of AI for software development still rational in 2026 — and where exactly do practitioner "adopt fully" and "abstain entirely" positions actually diverge: on the facts (does AI work), the values (what counts as harm), or the frame (individual choice vs. systemic problem)?
- Stop being skeptical about AI for development with Charity Majors (Charity Majors): Yes — bounded, disciplined use is not only viable, it's the responsible default: small deliberate acts of withheld participation (no-AI Wednesdays), a rule against sending unread AI output, and validation discipline are all presented as workable, sustainable practices.
- I'm done using AI (Brett Codes): No — for him, moderate/trivial-only use was tried and did not hold; he kept reverting to using AI for everything, and concluded the choice is effectively binary.
Assessment: The sharpest values/psychology divergence in the corpus, and arguably what the central question is actually asking about, since 'is skepticism/rejection rational' presupposes a real choice-menu with a stable middle rung. Majors's evidence for stability (a team ritual everyone follows together) is a much weaker test than Brett's (a year of earnest solo attempt at bounded use against colleagues' and management's full-throttle adoption) — a shared team policy is a different psychological ask than one individual holding a line alone, which is closer to Brett's actual situation. On the specific question of whether bounded use holds under social/organizational pressure to go further, Brett's case is more probative than Majors's, even though his conclusion ('so it must be all-or-nothing') over-generalizes a personal finding into a universal claim.
Is 'skepticism' (doubting AI's capability) the same stance as 'rejection/abstention' (refusing to use AI), and does 'still rational in 2026' apply equally to both?
from: Is skepticism/rejection of AI for software development still rational in 2026 — and where exactly do practitioner "adopt fully" and "abstain entirely" positions actually diverge: on the facts (does AI work), the values (what counts as harm), or the frame (individual choice vs. systemic problem)?
- Stop being skeptical about AI for development with Charity Majors (Charity Majors): Effectively treats them as one stance: her essay is titled 'stop being skeptical about AI for development,' and her prescription for skeptics is to use AI more, with more validation discipline.
- I'm done using AI (Brett Codes): Demonstrates, without arguing it explicitly, that the two stances are separable: he is not skeptical of AI's capability, yet rejects use entirely on other grounds.
Assessment: This is the central question's own hidden ambiguity, and the corpus resolves it by demonstration rather than argument. Brett is a live counterexample to the premise, embedded in Majors's own title, that 'not being skeptical' (updating on capability evidence) and 'using AI' are the same move. Once separated, Majors's essay is only an argument against doubting-that-it-works, and has nothing to say to someone who concedes capability and objects on different grounds. So 'is skepticism still rational in 2026' and 'is abstention still rational in 2026' are different questions the corpus never poses side by side — and the practitioner discourse largely collapses them into one fight when they aren't the same fight. On the narrower question Majors actually argues (is doubting AI's capability still rational), the corpus evidence favors her: nobody, including Brett, disputes that current tools work. On the broader question the central question is really asking (is abstention still rational), the corpus offers no resolution at all — only two incompatible frames (organizational-engineering vs. individual-ethical) that never engage each other directly.
Where does the non-delegable human asset now live — the harness/platform, the oracle, the fundamentals, or the developer's understanding?
from: What is the future of software development in the agentic/AI age?
- Notes from FOSE Europe (Giles Edwards-Alexander): In the harness — the continuously-evolving scaffolding of architecture guidance and rigour around the agents — though it must stay team-distributed, not centralized.
- What Survived Contact (Sam Ruby): In the oracle — the objective's evaluation is the single thing the person directing the model cannot delegate back to it.
- Jimmy Nilsson's Post — reflections after the Thoughtworks 'Future of Software Development' retreat (Jimmy Nilsson): In the fundamentals plus a renewed 'Extreme Humanism' — the durable disciplines and the conspicuously human element.
- AI Is Changing Software Engineering. The Fundamentals Still Matter. (Abby Bangser): In right-sized boundaries and the operational loop — humans must stay in operations because their learning is the irreplaceable asset.
- Fragments: February 9 (Martin Fowler (Feb 9)): In the developer's model-building and shared understanding — the craft of devising abstractions to reason about the domain.
Assessment: This is the deepest structural disagreement — every author agrees a human residue remains but nominates a different residue, and the choice determines what to invest in and what to teach. The harness-centric (Edwards-Alexander), oracle-centric (Ruby), fundamentals-centric (Nilsson/Bangser), and understanding-centric (Fowler) camps are not merely emphases: they imply different career ladders, different hiring, and different failure modes. Ruby's oracle and Bangser's operational-learning are the most operationally concrete; Nilsson's is the least argued. The absence in the corpus of anyone who holds 'nothing is non-delegable' is itself telling (see unexamined assumptions).
Is preserving human understanding of the system a first-order value, or is comprehension safely offloadable so long as output is verifiable?
from: What is the future of software development in the agentic/AI age?
- Fragments: February 4 (Martin Fowler (Feb 4)): Preserve understanding: it is a first-order value, and practices that force explanation defend it.
- Fragments: February 9 (Martin Fowler (Feb 9)): Preserve understanding and craft: cognitive debt and the loss of model-building are the real costs to guard against.
- Jimmy Nilsson's Post — reflections after the Thoughtworks 'Future of Software Development' retreat (Jimmy Nilsson): Preserve the human: 'Extreme Humanism' and being conspicuously human are load-bearing anchors.
- We've Stopped Arguing About Whether AI Changes Software (Greg Herlein): Offloadable: the quality bar is 'is it verifiable enough,' not whether a human read or understood the code.
- Looking back at the Future of Software Engineering unconference (Bartosz Ocytko): Offloadable for most builders: citizen developers need never read the code if a constrained platform makes failure modes disappear.
Assessment: The optimist-practitioner vs. skeptic-humanist axis. Fowler and Nilsson treat comprehension and craft as intrinsic goods whose loss is a harm even when output is fine; Herlein and Ocytko treat comprehension as instrumental — replaceable by verification and platform guardrails. The humanist camp has the stronger long-run argument (Fowler's cognitive-debt case and Ocytko's own 'who-guards-the-guards' problem both show verification and guardrails are themselves fallible artifacts that someone must understand), but the offloadable camp is describing what is actually happening at scale. The crux is whether verifiability can ever be robust enough to make understanding optional — which Ruby's own Goodhart gap (a passable oracle diverging from true intent) suggests it cannot fully be.
Open gaps (12)
- illogicalThe piece imports the unit-test analogy for evaluation wholesale ('evaluation metrics should be treated like software unit tests') without acknowledging that unit tests are deterministic boolean assertions on deterministic code, while evals are threshold decisions on a noisy, distributional score from a non-deterministic system. Blocking a release on 'increased hallucination rate' is a statistically different decision — subject to sample-size and variance questions — than a unit test failing, and the article gives it the same epistemic confidence.Beyond the 200 OK: Architecting Observability for AI — read next: Statistical treatments of eval-threshold decisions under sampling noise; comparisons of CI gating semantics for deterministic vs. probabilistic test suites.
- incompleteThe central prescriptive claim — engineers 'will' ship unread code to production, and this becomes safe once 'engineering builds the systems that validate this code' — never specifies what those validating systems must actually guarantee (coverage thresholds, formal verification, what evals reliably catch versus miss) to make unread code trustworthy. 'Comfortable shipping without reading' is asserted as an achievable target state without describing what achieving it looks like or how a team would know it had arrived.Stop being skeptical about AI for development with Charity Majors — read next: Majors's own linked essay 'AI demands more engineering discipline. Not less' (charity.wtf) may operationalize the validation bar this interview leaves abstract; also relevant is this corpus's DORA AI Capabilities Model material on quality-platform capabilities.
- illogicalThe 'pets to cattle' analogy assumes code can be treated like infrastructure — interchangeable, statelessly regenerable, verifiable via automated health checks — but code, unlike a server, typically encodes unique business logic and meaning. 'Verifiably correct' for a server means 'responds to health checks'; 'verifiably correct' for a business function is a much harder, domain-specific correctness problem that the piece never distinguishes from the infrastructure case it borrows its confidence from.Stop being skeptical about AI for development with Charity Majors — read next: This corpus's changeability/optionality material on what AI-generated code systematically underdelivers on.
- incompleteRule 6 ('narrow down deterministically') assumes a pre-existing, well-structured backing dataset to narrow into (a station table with EVA numbers). The talk doesn't address what to do when the candidate set itself is fuzzy, unbounded, or must be discovered dynamically — which is exactly the harder procurement-cost-center use case the author mentions in the opening and then explicitly declines to return to.Presentation: From Thousands to One: Building LLM-Powered Selection Systems — read next: Look for techniques for LLM-driven selection when the candidate universe cannot be cheaply pre-filtered by deterministic code (e.g., open-world entity resolution, dynamic vendor/cost-center taxonomies).
- illogicalThe Hacker News syllogism ('Zero trust is deterministic. AI is non-deterministic. Non-deterministic access controls are a terrible idea.') is reported but never examined against Beyond Zero's actual hybrid design — static policies handle baseline enforcement, and AI-driven decisions are reserved for higher-risk scenarios per the paper's second principle — so the article lets an objection to a stronger, purer 'AI decides everything' claim stand unchallenged even though it may not be the claim Google is making.Beyond Zero: Google Publishes Successor to BeyondCorp — read next: A close technical reading of the original ACM paper to establish exactly which authorization decisions are delegated to the AI-driven layer versus kept as static, deterministic policy.
- incompleteCamila's claim that Anthropic's Opus 5 has a code-related benchmark accuracy of '25% to 65%' is stated without citation, methodology, or task definition, and is used to support a general claim about AI's untrustworthiness for autonomous decision-making in a different domain (banking). This mirrors a pattern already flagged elsewhere in the corpus — extract-korbacher-platform-engineering-product-mindset's unsourced, likely-garbled cognitive-load statistic.Presentation: Platform Engineering in the Age of AI — read next: The primary Anthropic model card or SWE-bench-style benchmark report for the model in question, cross-checked against the corpus's more rigorously sourced AI-reliability data such as extract-dora-ai-team-profiles-and-capabilities.
- incompleteEvery control in the 7-pillar architecture is justified by first-principles reasoning about non-determinism and by citing named threat patterns (slopsquatting, invisible payloads, Confused Deputy), but no incident data, overhead measurements, or cost-benefit comparison is offered for any proposed control — e.g., no data on how much the 'Vibe Diff' + hardware MFA step actually reduces blind-approval rates versus a simpler gate, or on the operational cost of running a continuous Red/Blue/Green triad alongside every development workflow.Vibe Coding Agent Security And Evaluation — read next: This corpus's own extract-lulla-loop-engineering-building-blocks-adoption-impact documents, for a structurally similar case (loop engineering's prescribed building blocks), that almost none of a comparably detailed practitioner-prescribed architecture shows up as committed, verified practice in real repositories — worth reading against this whitepaper's unverified 7-pillar prescriptions for the same pattern.
- uninformedFowler attributes the current software-industry downturn and job losses primarily to the end of zero-interest-rate financing rather than AI, but does not engage with the counter-evidence elsewhere in the discourse that some of the layoff wave is genuine AI-driven restructuring (not merely macroeconomic or a cover story) — he states his view confidently without weighing the split causation other commentators report.How AI will change software engineering – with Martin Fowler — read next: Compare against corpus accounts that split the layoff wave into AI-washing/cover-story and genuinely AI-driven restructuring components.
- incompleteThe '3-4x faster' adoption claim is stated without supporting data, methodology, or definition of what metric is being measured. What specific growth metrics are being compared?Podcast: Tiger Teams, Evals and Agents: The New AI Engineering Playbook — read next: Look for empirical studies comparing technology adoption curves (e.g., Thoughtworks Technology Radar data, Stack Overflow surveys, or job posting analysis).
- incompleteNo discussion of how to determine appropriate accuracy thresholds for different risk levels. The framework jumps from 'build evals' to 'hit your threshold' without addressing how to set the threshold.Podcast: Tiger Teams, Evals and Agents: The New AI Engineering Playbook — read next: Risk management frameworks for AI systems, such as NIST AI Risk Management Framework or EU AI Act risk categories.
- incompleteThe Tiger Team concept is described but there is no discussion of how Tiger Teams dissolve back into the organization, how knowledge transfers, or how the org evolves its permanent structure based on what Tiger Teams learn.Podcast: Tiger Teams, Evals and Agents: The New AI Engineering Playbook — read next: Literature on temporary organizations, project-to-product transitions, and Team Topologies by Skelton and Pais.
- misinformedThe distinction between vibe coding and building agentic applications is drawn too sharply. In practice, development workflow agents (the Discord-to-GitHub-issue agent described) are themselves agentic applications that need evals, blurring the boundary Bhagwat draws.Podcast: Tiger Teams, Evals and Agents: The New AI Engineering Playbook — read next: Inner loop / outer loop development frameworks; the concept of 'dogfooding' applied to AI agent development.