Evolutionary Architecture & Fitness Functions

Expressing architectural intent as executable, continuously verified constraints so both humans and agents get fast feedback on whether implementations conform to design.

Also known as: fitness functions, Architecture as Code, architecture as code, deterministic constraints, feedback framework (vs. testing framework), konversasjonell arkitektur (conversational architecture), conversational architecture, fart og flyt (speed and flow), behavioral verification vs. capability verification, nine intersections, CALM, CALM Hub, Common Architecture Language Model (FINOS)

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (13)

• Presentation: APIs for Agents: Rethinking API Programs in the MCP Era Jim Gough, Andreea Niculcea · 2026-09-23 Reader 🖥️
  As agent protocols (MCP, then A2A, then whatever comes next) reshape how consumers reach enterprise systems, Morgan Stanley argues platforms should keep APIs as the stable, governed foundation and use Architecture-as-Code (CALM) to encode, version, and automatically enforce security/governance controls and deployment gates across every protocol adapter built on top — so the organization can adopt new interaction protocols quickly, and evolve already-deployed services at scale, without sacrificing safety or consistency.
• Strategy Making Gets an AI Boost Gretchen Gavett · 2026-08-18 Reader 🖥️
  As curator of The Insider, Gavett presents two arguments that senior leaders should trade fixed, precomputed plans for continuous option-generation under protected human judgment: AI dissolves the bounded-rationality limits that forced strategy-making into static frameworks like SWOT and Porter's five forces (per Felipe Csaszar), and longer, less predictable careers require small low-stakes experiments plus deliberately protected reflection time rather than a single career plan (per Lynda Gratton).
• Article: Agentic Fitness Functions: Extending Evolutionary Architecture Beyond Deterministic Rules Hemant Kumar Mahato, Łukasz Sieczkowski, Vijayasenthilkumar Kuppusamy · 2026-08-17 source ↗ Reader 🖥️
  Deterministic fitness functions should remain the primary architectural governance mechanism, but calibrated, evidence-scoped, escalation-capable AI 'agentic fitness functions' should be added as an advisory judgment layer for architectural concerns that are evidence-bound but not reducible to a rule — boundary fidelity, semantic contract drift, stale ADR assumptions — so that architectural judgment itself becomes observable, auditable, and, where patterns repeat, convertible back into deterministic guardrails.
• The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices Prashanth Pasham · 2026-07-28 source ↗ Reader 🖥️
  By imposing an absolute rule -- never modify the legacy HCM monoliths again, only add new domain microservices -- and pairing it with three platform investments (self-service provisioning, an API-gateway routing seam, and a cached feature-flag rollback layer) that keep the resulting per-story cost tax affordable, a team can fund and execute a full monolith-to-microservices migration as a side effect of ordinary roadmap work, with no dedicated migration budget or program.
• Presentation: Clean Architecture for Serverless: Business Logic You Can Take Anywhere Elena van Engelen · 2026-07-27 source ↗ Reader 🖥️
  Structuring Function-as-a-Service applications with a simplified Clean Architecture — a domain and application layer with zero cloud dependencies, whose separation from infrastructure is enforced not by convention but by Gradle module boundaries, wired to cloud entry points via Spring Cloud Function's dependency injection — lets a team write business logic once and deploy it, materially unchanged, to multiple serverless cloud providers, eliminating vendor lock-in without giving up native cloud capabilities.
• An Evolutionary Architecture Pattern for Managing AI's Pace of Change Joe Price, Branimir Đurek, Pavlos Migkiros, Trevor Dearham · 2026-07-27 source ↗ Reader 🖥️
  Because AI capabilities, protocols, and threats now change faster than enterprise systems can safely absorb — a gap the authors treat as permanent rather than a phase to wait out — organizations should deliberately concentrate the fastest-moving AI concerns (model routing, identity, action policy, segmentation, content guarding, and audit) into one architectural seam, the AI gateway, so the rest of the enterprise can remain stable, and should build that seam proactively rather than at the higher cost of building it after an incident forces the issue.
• Comprehension at AI Speed: Building a Context Store for Evolutionary Architecture Stella Berhe, Stephan Bragner, Vikram Maran, Anand Jayaraman · 2026-07-14 source ↗ Reader 🖥️
  Because AI has decoupled writing code from understanding it, engineering organizations must run spec-anchored specification-driven development, test-driven development, and architectural fitness functions together as one verification system so that their combined artifacts form a versioned, queryable "context store" — making comprehension a lifecycle property of evolutionary architecture that both human reviewers and AI agents can draw on, rather than a pre-merge concern that AI-generated speed otherwise outruns.
• Podcast: Formal Methods for Every Engineer in an AI-Powered Future Gabriela Moreira (guest); host Shane Hastie (InfoQ) · 2026-07-10 Reader 🖥️
  Formal methods are a practical tool for reasoning about the edge cases of complex distributed and concurrent systems, and because AI in 2026 collapses the historic barriers to writing specifications and the glue code that binds them to real implementations, the profession's enduring human work shifts to defining which system behaviours are correct — the judgment AI cannot take over.
• What Survived Contact Sam Ruby · 2026-07-01 source ↗ Reader 🖥️
  When agents write the code, rigor does not vanish but migrates to the objective and its evaluation; directing an agent is therefore a management act (a hire, not a tool-use) whose one non-delegable duty is owning the objective and the oracle that checks it.
• Three more static code analysis sensors Birgitta Böckeler (published on martinfowler.com) · 2026-05-20 source ↗ Reader 🖥️
  For maintainability concerns that cross file and module boundaries, computational static-analysis sensors (dependency rules, coupling metrics) can usefully enforce a few structural invariants but cannot judge what coupling is appropriate; the most productive sensor is an inferential, prompt-driven AI modularity review that reads the code itself, with the deterministic tools relegated to enforcement of known rules and to triage of review attention.
• Architecture as Code to Teach Humans and Agents About Architecture Neal Ford and Mark Richards · 2026-04-15 Reader 🖥️
  Software architecture should be defined as code — capturing structural constraints deterministically — so that both human developers and AI agents can receive fast feedback on whether implementations conform to design intent.
• 14) Øystein Ulseth pendler mellom å lede og levere Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2026-04-07 source ↗ Reader 🖥️
  The best technology leaders pendle (commute) deliberately between leading and delivering — driven not by career ambition but by the joy of building at the right level of abstraction — because crossing that boundary in both directions is what makes you precise: a hands-on background gives leaders pragmatism about complexity and trade-offs, while a leadership background gives builders the holistic, risk-aware perspective that lets them choose what to build.
• Agents don't know what good looks like. And that's exactly the problem. Luca Mezzalira · 2025-01-01 source ↗ Reader 🖥️
  Agentic AI systems lack the judgment to distinguish correct behavior from merely passing checks, which means that deterministic architectural guardrails — fitness functions, capability verification, explicit boundary definitions — are not optional but imperative; and the sociotechnical readiness of the humans and organizations that must own the generated systems is the overlooked bottleneck.

Propositions touching this concept (18)

By publication month, oldest first (extraction month when no publication date is known).

2025-01

• explicitestablishedDeterministic guardrails (fitness functions, capability tests, boundary definitions) around nondeterministic agents are not optional but imperative.
  Agents don't know what good looks like. And that's exactly the problem. · p5

2026-04

• explicitdevelopedDefining architecture as code creates a fast feedback loop that lets architects detect when implementation diverges from design.
  Architecture as Code to Teach Humans and Agents About Architecture · p1
• explicitestablishedAI agents can only work toward acceptable solutions when deterministic constraints exist to define success.
  Architecture as Code to Teach Humans and Agents About Architecture · p3
• implicitdevelopedArchitecture can be objectively and precisely defined across all nine intersections of the development ecosystem.
  Architecture as Code to Teach Humans and Agents About Architecture · p7

2026-05

• explicitRituals and predictability calm the human brain and create the conditions for trust; they function as social infrastructure that persists even when team composition changes.
  Presentation: The Human Scalability Problem: Why Your Teams Don't Scale Like Your Code · p10

2026-07

• implicitcorroboratedGuardrails, fitness functions, and CI/CD pipelines are not optional overhead but the mechanism that converts AI-driven velocity into safe value rather than accumulated debt.
  The "funhouse mirror": How AI reflects the hidden truths of your software pipeline · p14
• explicitRunning spec-anchored SDD, TDD, and architectural fitness functions together, on one cadence, as a single verification system produces the context store as an emergent byproduct; none of the three disciplines is individually new, but their deliberate integration is.
  Comprehension at AI Speed: Building a Context Store for Evolutionary Architecture · p6
• explicitEach of the three disciplines collapses into a specific, named failure mode when its accompanying social practice is absent: specs decay into "spec-first-then-discard" documentation theater, TDD becomes a coverage-gate tax written after the fact, and fitness functions get bypassed by a synchronous review board or an overloaded single senior engineer.
  Comprehension at AI Speed: Building a Context Store for Evolutionary Architecture · p7
• explicitA leader should maintain 'happy high status' — projecting calm and control under chaos — because the team feeds off the leader's emotional state and panic cascades.
  Why product feels so hard right now - Charity Ibhadon (WPP) · p8
• implicitThe composure a leader projects is a deliberate performance decoupled from felt experience — calm is manufactured internally and then displayed, not experienced.
  Why product feels so hard right now - Charity Ibhadon (WPP) · p9

2026-08

• explicitDeterministic fitness functions should remain the primary enforcement mechanism for measurable architectural invariants — dependency direction, contract shape, latency budgets, security posture, policy checks.
  Article: Agentic Fitness Functions: Extending Evolutionary Architecture Beyond Deterministic Rules · p1
• explicitAgentic fitness functions add value specifically where architectural risk is evidence-bound but judgment-heavy — boundary fidelity, semantic contract drift, workflow coupling, stale ADR assumptions — not where a rule or threshold already suffices.
  Article: Agentic Fitness Functions: Extending Evolutionary Architecture Beyond Deterministic Rules · p2
• explicitA life can be modeled as eight threads — four of productivity (mastery, knowing, cooperating, amplifying/AI) and four of nurture (relationships/friendship, calm, adventure, and managing energy) — that are present at all times; people, usually unconsciously, choose which threads to strengthen and which to leave fragile, and over-investing only in productivity threads is what produces burnout.
  Living and Working in the Age of Longevity · p4
• explicitdevelopedLonger working lives (50-60 years) combined with AI-accelerated change mean careers are becoming both longer and harder to predict, and leaders should respond with three practices rather than a single fixed plan: prepare before you need to (small, low-stakes experiments), commit to what lasts (durable capabilities and relationships), and protect time for judgment (deliberately protected reflective 'calm').
  Strategy Making Gets an AI Boost · p4

2026-09

• explicitBecause architecture, patterns, and deployments are held as versioned, machine-readable data (CALM Hub as 'golden source'), a platform team can push a new 'platform opinion' across all existing production deployments as a zero-downtime 'operational rollout' without the owning teams initiating anything.
  Presentation: APIs for Agents: Rethinking API Programs in the MCP Era · p5
• explicitAutomated deployment gates (pattern-conformance lookup, CALM CLI JSON-schema + spectral validation, later smoke tests/security review/drift detection) give developers PR-style feedback before promotion and apply identically whether it's the 1st or the 100th deployment.
  Presentation: APIs for Agents: Rethinking API Programs in the MCP Era · p6
• explicitcontestedTime-to-production for a new Morgan Stanley API dropped from roughly two years (the first API) to about six months, and now to one to two weeks, which Jim attributes to CALM's automated security approvals.
  Presentation: APIs for Agents: Rethinking API Programs in the MCP Era · p8
• implicitEncoding platform opinions as versioned, machine-readable architecture — rather than as documentation or discretionary policy — is what simultaneously enables both automated per-deployment gates and mass, centrally-triggered operational rollouts; both draw on the same underlying CALM data model.
  Presentation: APIs for Agents: Rethinking API Programs in the MCP Era · p11

Tensions

Open gaps (27)

• incompleteThe article never addresses who reviews and maintains the calibration set and rubric over time, across potentially many fitness functions (boundary fidelity, semantic contracts, ADR drift, and whatever else a team adds) — this could reproduce, at the rubric-review layer, exactly the finite-senior-reviewer-capacity bottleneck the pattern is proposed to relieve at the code-review layer. This corpus already flags a structurally identical concern about spec-authoring capacity in extract-context-store-evolutionary-architecture#g1.
  Article: Agentic Fitness Functions: Extending Evolutionary Architecture Beyond Deterministic Rules — read next: Look for treatments of AI-eval/rubric maintenance cost at scale — how many rubrics one architecture team can realistically own and keep current.
• illogicalThe article treats judge disagreement as valuable signal of a real architectural trade-off that should always escalate to a human, but also recommends promoting recurring agentic findings into deterministic rules once the team 'agrees they represent real violations.' No criterion is given for distinguishing a finding that has become stable enough to deterministic-ize from one where persistent disagreement is itself the correct, ongoing state — the two prescriptions pull in opposite directions without a stated tiebreaker.
  Article: Agentic Fitness Functions: Extending Evolutionary Architecture Beyond Deterministic Rules — read next: Look for a worked example or decision procedure for when to stop escalating a recurring disagreement and instead write a rule.
• unasked questionThe essay uses the Dreyfus model to characterize agents as novice/advanced-beginner but never asks whether the Dreyfus model, developed for human skill acquisition, is even the right frame for AI systems that learn in fundamentally different ways. Agent capabilities may not map onto a linear human progression scale at all.
  Agents don't know what good looks like. And that's exactly the problem. — read next: Literature on AI capability evaluation frameworks that are not anthropomorphic (e.g., benchmarks, formal verification, capability elicitation research).
• implicit premiseThe argument that 'more context degrades output' treats current LLM context-handling limitations as a stable architectural constraint rather than a temporary engineering limitation. If context handling improves significantly, the 'deterministic guardrails' prescription may need rebalancing.
  Agents don't know what good looks like. And that's exactly the problem. — read next: Research on long-context model performance, retrieval-augmented generation, and structured context management.
• incompleteThe cost of this approach relative to its benefit is never argued. Extra interfaces, Gradle module boundaries, DI wiring, and CDK complexity have a real engineering cost, but the talk never weighs that against the — for many teams, mostly hypothetical — benefit of actually being able to switch or dual-run cloud providers, when most organizations pick one primary cloud for reasons (pricing, existing platform investment) unrelated to code portability and rarely execute a true migration even when the code is portable.
  Presentation: Clean Architecture for Serverless: Business Logic You Can Take Anywhere — read next: extract-outsourced-ai-still-own-the-risk#p10 raises the structurally identical unresolved premise in the AI-vendor-lock-in context ('portability is achievable enough to function as a real hedge') — worth reading together to test whether 'engineered portability' claims generalize across domains or share the same unexamined cost side.
• uninformedThe Q&A's observability answer treats 'generic logger + cloud-specific sink config' as basically solving cross-cloud observability, but doesn't address the harder problems: correlating a single business transaction's logs, traces, and metrics when parts of it run on AWS and parts on Azure, distributed tracing across clouds, or cost/retention differences between CloudWatch and Azure Monitor.
  Presentation: Clean Architecture for Serverless: Business Logic You Can Take Anywhere — read next: extract-infoq-data-driven-platform-engineering (platform engineering and observability federation across a real multi-cloud platform) and writing on OpenTelemetry's cross-cloud adoption as the actual mechanism for correlating traces, not just directing log lines.
• illogicalThe talk frames Terraform CDK's cross-cloud reuse as a portability win ('same lingo... different dialect'), while simultaneously showing that the actual resource definitions are provider-specific (an AWS Lambda + API Gateway + IAM permission block looks nothing like an Azure Function App block). What's actually portable is the tooling/metalanguage (write infra in Kotlin instead of HCL), not the infrastructure-as-code itself — only the business-logic layer, not the infrastructure layer, is genuinely portable. The talk doesn't name this distinction, which risks readers concluding CDKTF gives infrastructure portability it does not.
  Presentation: Clean Architecture for Serverless: Business Logic You Can Take Anywhere — read next: Compare with writing that distinguishes tooling-level multi-cloud consistency (shared IaC language) from artifact-level portability (the same deployable config running on either cloud) — e.g. Gregor Hohpe on multi-cloud strategy and exit costs.
• incompleteThe Amazon outage is presented as an outcome of the exact context gap this article diagnoses, but the article's own cited source (CNBC) attributes the outage to "changes merged without proper review" — a review-gate failure — not to a documented absence of persisted intent, behavior, or conformance records specifically. The causal attribution to the context gap, versus a more generic review-diligence lapse, is asserted rather than demonstrated from the available reporting.
  Comprehension at AI Speed: Building a Context Store for Evolutionary Architecture — read next: Follow further Amazon incident reporting or post-mortems, if published, to see whether investigators identified a missing intent/behavior/conformance record specifically, or a simpler story of a skipped approval step that a context store would not by itself have prevented.
• incompleteNo treatment of the social-and-organisational fate of the artefacts themselves. Dependency-cruiser configs, custom coupling-analyser CLIs, and imported Modularity Skill packs are all new load-bearing artefacts. Who owns them? Who updates them when the architecture should change? In the absence of an owner, the rules outlive the intent behind them and become either silently violated or silently obsolete — the classic linter-suppression-debt pathology, scaled to architecture.
  Three more static code analysis sensors — read next: Cutler on institutionalised overload and waste; Fearless Change (Manns & Rising) on what it takes for organisational invariants to survive; Tornhill's Software Design X-Rays on attaching social/ownership data to code-quality signals; Vlad Khononov's modularity work directly (since his Skills are now part of the harness).
• incompleteThe article treats the dependency-cruiser rule set as a substitute for a markdown structure guide, but it skips the question of whether enforcement and explanation are interchangeable. A rule that says 'clients cannot import services' enforces a constraint but does not teach why the layering exists — and the moment the constraint is wrong, the team has no shared prose to reason with. This silently relocates design intent into tooling that few people maintain, and few people can read.
  Three more static code analysis sensors — read next: Ousterhout 'A Philosophy of Software Design' on the role of design documents; Parnas on module specifications; Hickey 'Simple Made Easy' for the distinction between rules-as-policy and rules-as-understanding.
• incompleteHeavy reliance on Khononov's externally maintained Modularity Skills pack as the thing that makes Sensor 3 work. The article does not examine: skill-pack versioning, drift, security/supply-chain assumptions, or what happens when the skill author changes their mind. The harness now has a third-party dependency at the level of taste, not just at the level of code.
  Three more static code analysis sensors — read next: Khononov's Learning Domain-Driven Design and his coupling talks; literature on prompt drift; the emerging 'skills-as-dependency' discussion (Osmani's agent-skills writing).
• incompleteThe coupling-analyser is described as a vibe-coded custom CLI. The article acknowledges it would benefit from suppression of legitimate high-coupling hubs but does not engage with the more interesting question: if your coupling tool requires hand-curated exceptions for every architectural pattern, you are effectively encoding architectural intent in two places (the rules AND the exception list). At that point, why not skip the metric layer and go directly to the inferential review?
  Three more static code analysis sensors — read next: Tornhill, Software Design X-Rays; the dependency-cruiser community's own discussion of when DSM-style tools earn their keep.
• incompleteThe article observes that the AI modularity review found duplicate routes, scattered parameters, and misplaced auth — i.e. exactly the things a senior reviewer would find in a half-hour read of the code. There is no contrastive baseline against human-only review, against pair-review with the original implementing agent, or against a much cheaper rubric like 'review every file changed >X times in the last 30 days'. Without such a baseline, the proposition 'the review is the best available sensor' is unfalsifiable on the evidence given.
  Three more static code analysis sensors — read next: DORA reports' methodology on baselines; Beck on test-commit-revert and 'starving genies' as alternative scaffolds for keeping AI-edited code honest.
• incompleteNo engagement with the relationship between this approach and existing fitness-function / architecture-as-code tooling (ArchUnit, NetArchTest, ts-arch, Modulith, even Structure101). dependency-cruiser is one point in a much larger design space; treating it as 'the' dependency-rules sensor leaves the reader without a sense of where the boundary lies between custom configuration and adopting an established framework.
  Three more static code analysis sensors — read next: Ford/Parsons/Kua 'Building Evolutionary Architectures' on fitness functions (which she links to in the framing); ArchUnit; ts-arch.
• incompleteThe framing assumes the agent is always the implementing actor and the human (plus other agents) are the reviewers. It does not consider the inverse case — where humans implement and the AI modularity review is the rubric against which their code is judged — even though the same tooling would work. This matters because it shapes whether the harness is 'AI guardrails' or 'organisational architecture discipline that happens to use AI'.
  Three more static code analysis sensors — read next: Cutler on operating-system design; Beck on team practices.
• incompleteThe binary 'migrated' metric requires 100% of traffic for 30+ days, but the article never addresses what happens when a fraction of traffic must legitimately stay on the monolith forever (e.g. an old partner integration that will never be upgraded) -- is that endpoint simply never declared migrated, indefinitely, with no path to closing it out?
  The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices — read next: Look for practitioner writing on managing the migration 'long tail' of clients who cannot upgrade -- API deprecation and sunset strategy literature -- to see how others resolve the tension between a strict binary completion metric and an unmigratable minority of traffic.
• incompleteBoth headline numbers -- the ~70% peak-cost savings and the ~50% (4-to-6-hour) upfront tax -- are presented as stable constants across five years, but cloud pricing, wages, and story complexity plausibly shifted substantially between 2021 and 2026; the article gives no methodology or time series, only single-point averages, so a reader cannot tell whether either ratio actually held steady or drifted.
  The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices — read next: Look for any published time-series cost or velocity data from Paycor/Paychex, or for other companies' cost-optimization case studies with longitudinal tracking, to see whether single anecdotal ratios of this kind are durable enough to reuse as planning assumptions.
• incompleteScale dependence of pendling. The whole career story plays out inside two large Norwegian financial-services organisations (Storebrand, Fremtind) that recognise technical depth as legitimate seniority. The conversation never tests whether pendling is feasible — or how it changes shape — in small startups (no role to come back to), pure consultancies (the IC vs. leader frame may not apply), public-sector hierarchies (rigid grade structures), or US-style stock-comp tracks where stepping back is also stepping out financially.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Pair with Charity Majors' 'Engineer-Manager Pendulum' original essay to see her conditions for it working; pair with Will Larson on staff-engineer archetypes for the IC-track question; pair with Norwegian-public-sector accounts (NAV optimising for fast flow) for the bureaucracy edge case.
• incompleteThe people who can't pendle. Ulseth's account is sympathetic to both directions but assumes the listener has the option of swinging both ways. It does not address those who are only-leaders (lost technical currency) or only-deliverers (no taste for organisational complexity) — and whether they should be coached, paired, or left in their lane. There is a real possibility that pendling is a personality privilege as much as an organisational one.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Camille Fournier on technical-leadership transitions; Cutler on the costs of forcing technical contributors into managerial roles; Allen Holub on accountability and the limits of role-fluidity.
• incompleteThe architect's function is never defined. The talk asserts that architecture has not changed in its core function, only in practice — but it does not say what the function is. The closest thing to a definition is 'enabling speed and flow via loose coupling and high cohesion', which is more a goal than a function and which collapses architecture into platform engineering in some readings.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Vlad Khononov on coupling in distributed systems; Ruth Malan on architecture as 'the design decisions that are hardest to change'; Team Topologies for the sociotechnical framing Ulseth invokes.
• incompleteBredde/dybde sounds clean but is operationally underspecified. How does a sjefsarkitekt choose which initiatives to take as 'mine'? Ulseth nods that they should be 'both important and interesting' and that the two usually overlap — but the harder cases (important-but-boring, interesting-but-marginal) are not discussed. This is the place where pendling-by-design either works or quietly collapses into one side.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Cutler on how leaders allocate attention; deep-dive into 'staff-plus' patterns where senior ICs balance technical and political work.
• incompleteThe claim that AI raises the incentive to live good engineering culture is asserted but not mechanised. Continuous delivery has been well-described for 20 years and only patchily adopted. Why will AI succeed in changing this where the prior decade's tooling, DORA reports, and platform engineering did not? A causal story is missing.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: DORA 2025/2026 specifically on AI's interaction with delivery practices; Birgitta Böckeler and Martin Fowler on AI-coding feedback loops; Kent Beck's TCR work as the practice end of the same idea.
• incompleteNo data on whether pendling actually produces better outcomes. The argument is largely 'I felt better and have heard I do better.' The episode lacks any reference to organisational research on whether engineer-manager pendulum careers correlate with better team or product outcomes — and whether the benefits go to the individual, the team, or the organisation.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Pragmatic Engineer / Newcomer on staff-plus role outcomes; LeadDev surveys on engineer-manager transitions; academic work on bidirectional career mobility in knowledge work.
• uninformedUlseth notes he has not yet seen conversational architecture practiced and that sociotechnical architecture is a new acquaintance — yet these are the frameworks he is now bringing into Fremtind's IT strategy. The talk does not engage seriously with the published critiques of these models (e.g. that Team Topologies under-specifies platform-team funding, or that Harmel-Law's model assumes a maturity teams may not have).
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Andrew Harmel-Law's own book and the Architecture Decision Records literature; critical reviews of Team Topologies (Manuel Pais et al.).
• incompleteThe four-rebuilds story is reported as triumph but never costed. Destroying and rebuilding the platform architecture four times has a cost — for the consuming squads who must re-learn it, for the regulators who must re-approve it, for the institutional memory that bleeds out at each rebuild. The article reports the platform team's experience ('it worked perfectly for us') without checking the consumer side. The same testimony from the squads might read very differently.
  How a Culture of Data-Driven Conversations Can Support Platform Engineering — read next: Ford, Parsons & Kua on evolutionary architecture (the disciplined version of what Petean is describing). Hohpe on architecture decision records and the institutional cost of irreversibility. Naur on programming-as-theory-building — what gets destroyed in a rebuild that isn't in the code.
• uninformedThe talk asserts deployment gates catch non-conformance but never addresses what happens when an architecture is gate-compliant yet still architecturally wrong in a way the pattern didn't anticipate — a limitation the corpus has already surfaced independently for agentic fitness functions (structural conformance checks prove an import exists or a schema parses, not that the change is architecturally sound).
  Presentation: APIs for Agents: Rethinking API Programs in the MCP Era — read next: extract-agentic-fitness-functions-evolutionary-architecture, which explicitly separates deterministic structural gates from judgment-heavy architectural review.
• incompleteThe whole cross-retreat comparison rests on an acknowledged seam: the author read only the public summary of the earlier retreat, so he cannot separate 'the conversation genuinely grew' from 'the earlier summary simply compressed this out.' The central 'what changed' claim is offered on face value with that limitation showing.
  What Survived Contact — read next: Obtain the fuller record (not just the public key-takeaways summary) of the earlier Thoughtworks retreat and re-run the comparison against like-for-like source material.