Golden Path

Making the right way the easy way — paved, opinionated defaults so good that adoption runs on intrinsic motivation rather than mandate.

Also known as: golden path, Golden path, golden path / kul-luxverk, paved roads, Paved roads, Golden brick, golden bricks, gjøre det lett og rett (lett og rett), gjøre det lett og rett, lett og rett, make it easy / don't shame, engineering enablement

How authors use it

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

Documents (18)

• Reverse Engineering your Software Architecture with Claude Code to Help Claude Code Nick Tune · 2026-10-08 Reader 🖥️
  Because coding agents' usefulness on complex, cross-repository problems is bottlenecked by lack of end-to-end system understanding, using Claude Code itself to reverse-engineer and document standardized, versioned, machine-and-human-readable flow diagrams (UI to BFF to API to DB to events) measurably improves the agent's ability to investigate real incidents — but this is a stopgap: the real target state is platform tooling that exposes the system as a live dependency graph so agents consult a source of truth rather than reverse-engineering it themselves.
• 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.
• Achieving Compliance as a Platform Engineering Team by Helping Developers Ben Linders · 2026-07-23 source ↗ Reader 🖥️
  A platform team achieves durable compliance not by choosing better technical controls but by sequencing rollout (inform, then softly enforce, then strictly enforce) around transparency, shared purpose, and developer trust, because forced, patronizing enforcement fails even when the underlying tooling is sound.
• Netflix CPTO on AI and the future of product and tech roles | Elizabeth Stone Lenny Rachitsky (host); Elizabeth Stone (guest, Chief Product and Technology Officer, Netflix) · 2026-07-19 Reader 🖥️
  As generative AI lets anyone prototype, analyze, and ship — collapsing the old boundaries between product, design, engineering, and data science — organizations should respond not by dissolving functional expertise but by doubling down on scarce craft excellence and systems thinking, investing in shared infrastructure/guardrails so individual fluidity compounds rather than fragments, and leaning harder into a talent-dense, high-agency, low-process culture ('excellence as an operating system') that Netflix built before AI made it fashionable.
• How Open Source Enables Collaboration in Creating a Platform Ben Linders · 2026-07-11 Reader 🖥️
  A platform succeeds as a collaboration system between mutually dependent platform and application teams rather than as a one-way product handoff, and it wins adoption only when trust -- built through predictable, consistent operation and an open-source-derived shared standard and working culture -- turns tooling into a chosen way of working instead of a management mandate.
• DORA Community Discussion - Operationalizing DORA within a large organization DORA (speaker: Julia Jakubiec, ABN AMRO; host: Nathan Harvey) · 2026-06-26 source ↗ Reader 🖥️
  Operationalizing DORA at enterprise scale is fundamentally a change-management problem — solved by running Kotter's 8 steps to institutionalize a durable continuous-improvement culture — not by the metrics themselves, which serve only as a recognizable survey instrument, authority brand, and benchmarking catalyst.
• Governing AI in the Cloud: A Practical Guide for Architects Dave Ward · 2026-06-15 source ↗ Reader 🖥️
  Architects should regain control of ungoverned ('shadow') AI not by trying to police the models themselves but by building a staged, automated control plane in the cloud infrastructure — discover every AI touchpoint, classify data at the moment of creation, and enforce access at the data path through IAM and policy-as-code — while making the compliant path the easiest one so teams adopt governance instead of routing around it.
• Git real: AI agents aren’t just for solo developers anymore Janakiram MSV · 2026-06-09 source ↗ Reader 🖥️
  The coding agent is becoming team infrastructure rather than a personal productivity tool — a shift evidenced by three separate vendor launches in one week, each solving a different team-scale problem (coordination, management, governance), that recapitulates the trajectory version control took from private convenience to Git/CI-governed shared practice.
• You Don't Get to Create Anything (Still Burning: Beck + Randy Shoup on Jevons paradox and distributed systems under AI) Kent Beck — Still Burning Podcast · 2026-06-03 Reader 🖥️
  Cognition is becoming near-free, and per Jevons paradox that will produce more cognitive work and more engineers, not fewer — but the people best prepared for this regime are exactly the ones who already lived through writing the distributed-systems playbook, because they know two things the panicking crowd forgets: that a playbook is hard-won and not obvious until written, and that the human compulsion underneath all of this is the maker's need to create the thing rather than merely transcribe it (the 'you don't get to create anything' moment that drives Shoup out of patent law and back into engineering); accordingly the right posture is calm, perspective-keeping, deductive engagement with the new regime — bounding the genie with specs/evals, making good practices easier rather than shaming the bad, and treating this as another wave of physics-discovery rather than a hype cycle or an apocalypse.
• How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery Ben Linders · 2026-05-21 source ↗ Reader 🖥️
  Internal platforms should be run as products that expose composable 'golden bricks' rather than prescriptive 'golden paths,' so that developer teams can self-assemble their own flow of value with low cognitive load while the platform team is held accountable to adoption, experience, and DORA-like outcome metrics.
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) Lenny's Podcast · 2026-04-23 Reader 🖥️
  In an era of rapidly improving AI models, the PM role must shift from multi-quarter planning and cross-functional coordination toward radical speed of execution, product taste, and the ability to continuously adapt the product harness to extract maximum value from each new model generation.
• The Organization Is the Bottleneck Sarah Wells · 2026-04-20 Reader 🖥️
  AI coding agents amplify an organization's existing engineering maturity rather than substituting for it; the same foundations that made microservices succeed — guardrails, deployment pipelines, engineering enablement — are prerequisites for succeeding with AI agents, so the real bottleneck is organizational, not technological.
• Three Pillars of Platform Engineering: A Virtuous Cycle Pratik Agarwal · 2026-04-20 source ↗ Reader 🖥️
  Reliability and ergonomics in internal developer platforms are not opposing trade-offs but a self-reinforcing virtuous cycle: automated state management (control planes) removes human error from operations, opinionated SDKs eliminate whole classes of developer-caused failures by absorbing repeated patterns, and declarative operator tooling encodes tribal knowledge into idempotent commands — and the three pillars compound because stable systems free operators to invest in better tooling, which further stabilizes the system.
• Harness Engineering Birgitta Böckeler · 2026-02-17 source ↗ Reader 🖥️
  Harnesses — the mix of deterministic tooling and LLM-based practices that keep coding agents reliable and maintainable at scale, as demonstrated by OpenAI's 5-month, 1M+-line, no-manually-typed-code project — are likely to become the next generation of service templates, which implies that trustworthy AI-generated code requires giving up some generation-time flexibility (converging on fewer tech stacks and enforced architectural boundaries) in exchange for maintainability, and that retrofitting a harness onto an existing, high-entropy legacy codebase may often not be worth the effort.
• Harness engineering: leveraging Codex in an agent-first world Ryan Lopopolo (OpenAI) · 2026-02-11 source ↗ Reader 🖥️
  Building a product with zero manually-written code at scale (one million-plus lines, five months, a team that grew from three to seven engineers with throughput that increased rather than degraded) required redefining engineering work from writing code to designing environments, pushing all team knowledge into repository-local legible artifacts, mechanically enforcing architectural invariants and documentation freshness, and relaxing human-paced process norms (blocking merge gates, manual cleanup) in favor of continuous, agent-driven correction — because human time and attention, not code production, is the one truly scarce resource the whole system must be organized to protect.
• 5) Vidar Moe: Det eneste Vidar vil er å ha det lett Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2025-11-17 source ↗ Reader 🖥️
  Vidar Moe's core engineering-leadership philosophy is 'gjøre det lett og rett' (make it easy and right) — a Toyota-Way-inflected craft and leadership stance in which you lead an organization most powerfully not by exhortation but by patiently building the tooling, frameworks, fagtid, hiring filters, fixed-term leadership rotation, and shared decision arenas that make the right thing the path of least resistance; the episode's ironic title ('the only thing Vidar wants is to have it easy') inverts this — Moe wants the work to be easy precisely because he is willing to do the very hard, decade-long, mostly invisible work of removing friction from doing the right thing, and his current concern with AI agents is the natural next chapter of the same project.
• 1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2025-10-13 source ↗ Reader 🖥️
  What warrants the Steve Jobs analogy in Larsen's case is not product taste in a consumer sense but the disciplined construction of a 'strategic narrative' so concrete and personally believed that it can pull a large bureaucracy through a paradigm shift — and this only works when paired with a complementary engineering apparatus (reverse Conway architecture, cross-functional value streams, common components discovered rather than designed, a 'golden-path' platform that makes the right thing the easy thing) operated by a leader who keeps an 'inngangsbillett' to the technical conversation so that the narrative remains connected to what is actually happening on the floor.
• 2024_final_dora_report DORA · 2024-10-25 Reader 🖥️
  Technology investments — generative AI adoption and internal developer platforms alike — reliably raise individual, team, and organizational performance only when paired with the underlying sociotechnical fundamentals (small-batch delivery discipline, developer independence, transformational leadership, a genuine user-centric and documentation culture, and stable priorities); absent those fundamentals, the same investments degrade software delivery throughput and stability and can increase burnout, so AI and platforms amplify whatever organizational system already exists rather than fixing it.

Propositions touching this concept (2)

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

2025-11

• explicitOrganisational debt is the brother of technical debt — and the next frontier of 'lett og rett' is paying down organisational debt by automating and standardising more of product development, not just code.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett · p10

2026-05

• explicitdevelopedComposable self-service capabilities ('golden bricks') outperform prescribed end-to-end paths ('golden paths') for enabling fast flow.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery · p2

Open gaps (45)

• incompleteThe conversation is entirely from Anthropic's perspective. No competing viewpoints from OpenAI, Google, or independent practitioners are represented. The interview format means Lenny largely agrees with and amplifies Cat Wu's positions rather than stress-testing them.
  How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) — read next: Read critical analyses of Anthropic's approach from outside observers; compare with product practices at other frontier labs.
• incompleteThe 'just do things' philosophy and extreme speed of shipping are presented as unqualified goods. The costs (product consistency, user confusion, bugs shipped) are acknowledged but treated as acceptable trade-offs without exploring when they become unacceptable — particularly for enterprise customers who need stability.
  How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) — read next: Look at enterprise SaaS literature on release management and the cost of change fatigue for large organizations.
• uninformedThe discussion of Co-work replacing tedious PM tasks (decks, meeting prep, email triage) lacks any engagement with the quality ceiling problem: are these AI-generated outputs actually good enough for high-stakes contexts, or do they create a mediocrity trap?
  How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) — read next: Seek empirical studies on AI-generated content quality in professional settings; read critiques of 'good enough' AI output.
• incompleteThe Open Claude decision is framed purely as a resource allocation choice. The community trust cost and the broader ecosystem implications of an AI company restricting how its model can be accessed through third-party tools are not explored.
  How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) — read next: Read platform economics literature on ecosystem lock-in; review community responses and long-term effects of similar decisions by other platform companies.
• incompleteThe Jobs analogy is named but not fully cashed out against its disanalogies. Jobs's reality distortion field was famously paired with cruelty, factional purges and product taste applied to consumer aesthetics. Larsen's framing is the opposite — toppdivisjon-ledelse runs on indre motivasjon, not fear; authenticity / easy-to-read-ness is the asset; the product is a public-sector welfare system. The conversation does not name these disanalogies, so the analogy carries more rhetorical work than it earns.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Read Walter Isaacson's Jobs alongside Tracy Kidder's Soul of a New Machine and Marc Andreessen-tradition writing on charismatic founder leadership to surface the disanalogies; for the NAV case specifically, read Cutler on 'institutionalized overload' to see what indre-motivasjon-based mobilisation can hide. Connects to the gap in the Skjærpe ep 17 extract on transformations that fail in the liminal phase.
• incompleteThe NAV transformation is described entirely from the inside by one of its architects. There is no counterfactual: comparable Norwegian agencies that did not transform similarly, post-Larsen reversion at NAV, what failed within NAV and why. The 'hagiography risk' the hosts flagged is real and unexamined.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Compare Skatteetaten, Statens Pensjonskasse, Helsedirektoratet trajectories during the same period; read the NAV-flow article in the user's library (Optimizing for Fast Flow in NAV) for the inside-but-different-author view; read the Skjærpe ep 17 extract for the immediate-successor's view from inside the system. Look for what the NAV transformation displaced or made impossible (e.g. casualties among legacy fagsystemer staff).
• incompleteThe 'common components are discovered, not designed' thesis is asserted with the NAV fakturering case as the load-bearing example, but the inverse failure mode (premature divergence — many verticals each solving the same problem badly because no one promoted the pattern to the platform) is acknowledged in passing ('we have capabilities in the platforms that strictly speaking are only needed one or two places ... it is a little behagelig that it got fixed over there') without being theorised. The position is one-sided.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Read the Wardley Mapping / pioneers-settlers-town-planners tradition for an explicit account of when components should be designed up front (the 'industrialised' part of the map). Read Cutler on 'horizontal team accountability' for how teams refuse to own platform-like problems they should own. The Vipps ep 18 extract may have a relevant view from the perspective of an organisation that did design infrastructure up front.
• incompleteThe 'easy to read' / authentic-leadership claim collides with the strategic-narrative claim. Strong strategic narrative is itself a construction; sustained reality-distortion presupposes some performance discipline. The conversation treats easy-to-read-ness and disciplined narrative as compatible without examining the tension. When does the constructed narrative cross into managed-impression territory, and what is the leader's check on that?
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Erving Goffman's Presentation of Self; Edgar Schein on the discrepancy between espoused theory and theory-in-use; Bent Flyvbjerg on narrative in megaprojects (where the same person both believes and constructs the future). The Cutler 'signals that look like decisions' thread is also relevant — for an easy-to-read leader, even contemplative musings can be read as commitments.
• incompleteThe inngangsbillett method is a personal description, not a teachable account. Larsen says he spends 'many hours a day' on craft and uses the hermeneutic-circle approach, but does not name which key terms, which structural maps, which sources, or how to know when the inngangsbillett is sufficient for a given fagdomene. The 'Fred George reads no books, he talks to authors' punchline gestures at one upper-bound technique but leaves the floor undefined.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Hubert Dreyfus's five-stage skill model (novice → expert) for a more precise grammar of 'how much do I need to know'; Cal Newport's deep work / deliberate practice tradition; the recent harness-engineering and AI-coding research extracted in this repo on what 'understanding a system' actually requires before AI can help you scale that understanding.
• uninformedThe conversation invokes Peter Senge's learning organisation as one of the three common denominators of Larsen's narrativer but does not interrogate how durably the organism-organisation framing has held up under real conditions over the 30 years since Fifth Discipline. There is a tradition of critique (e.g. Mintzberg on the messiness of organisational learning; recent operations-research literature on actual learning loops in software organisations) that the conversation does not engage with.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Mintzberg's Rise and Fall of Strategic Planning; Argyris on double-loop learning vs Senge's framing; the more recent DORA / Accelerate research on what kinds of learning actually correlate with performance — and what kinds (e.g. 'just keep adapting') do not.
• incompleteThe episode ends on Larsen's most quotable problem — moving from project mindset to outcome-driven verdistrøm-mindset — but does not specify what makes this so hard at Telenor specifically. Is it inherited governance? Board reporting cadence? Career incentives for people who have always shipped to scope? The hosts move on. This is the single most actionable place the conversation could have gone deeper.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Cutler on outcome-orientation and operating-system design; Marty Cagan's 'product team vs feature team' distinction; the Una Aamodt-Mathisen ep 10 extract (lede uten fasit) likely has direct material on the same problem at a different scale. The Vidar Moe ep 5 ('det eneste Vidar vil er å ha det lett') may have a relevant view on operating-model simplification.
• incompleteThe hagiography risk is structural: Truls worked for Larsen, Audun met him at a formative moment, both are visibly inspired. The format does not include any adversarial pressure. The episode is therefore best read as Larsen's self-presentation lightly facilitated by admirers — strong as primary source, weak as evaluation.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: For an evaluation lens, read external accounts of NAV's transformation (audit reports, Riksrevisjonen, Aftenposten / NRK coverage of NAV IT projects during the Larsen era), and look for counter-narratives in the Norwegian public-sector tech community. Compare to Holte ep 2 (the senior public-sector counterpart) for a different view of the same period.
• incompleteThe episode systematically tells the success-side of the story. Crisis → response → improvement is the recurring arc, but failed experiments, dead-end framework choices, or instances where 'gjøre det lett og rett' produced unintended organisational uniformity are absent. Moe's stated regret is only directional (could have done more, faster, in more places), not structural (e.g. 'this particular default we engineered was wrong'). The hosts twice surface the hierarchy-is-inevitable point but do not press on whether the framework-team's 'easy and right' becomes a hidden orthodoxy.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Pair with Allen Holub's #NoAccountability strand (already in the user's persona) and with anything on the costs of platform-engineering paved roads (e.g. Charity Majors / Honeycomb on the limits of golden paths). The user's existing extraction on Cutler's institutionalised overload is a strong complement here — Cutler's frame would ask what the second-order costs of the SpareBank 1 system look like.
• incompleteMoe's persistent 'vi' is itself a load-bearing rhetorical pattern that the hosts notice in closing but do not unpack. The episode is a portrait of a person who declines to be individuated — he says 'vi' even when narrating decisions whose intellectual origin clearly lies with him personally. This is consistent with the leadership-through-defaults thesis (the work is the structure, not the speaker) but it also obscures the part of the story that does depend on a specific senior practitioner persistently present in the system for 14 years. The question 'how transferrable is this without Moe (and Stian)?' is not engaged.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Read in tension with the previous Heis episode on hierarchy (Eikeland, ep 4, alluded to: 'forrige podcast-episoden snakket om... det er sjelden helt flat struktur') and with the leadership-presence strand in the user's library (Cutler on power and space, TBM 413). Beck's writing on senior individuals' role in evolutionary design is a direct anglophone parallel.
• incompleteThe 'organisatorisk gjeld' coinage at the close is the most pregnant unfinished idea in the episode. Moe gestures at the next direction of 'lett og rett' — engineering golden paths for product development itself, with good practices baked into roadmap tooling — but does not work it out. This is exactly the territory where the AI question reconnects: an agentic product-development assistant that encoded the right defaults could be the next instance of 'lett og rett', and would be a Moe-shaped answer to the alienation worry from his essay.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Pair with the user's existing extractions on harness engineering for AI coding agents and on 'Agents Don't Know What Good Looks Like'. The Backstage / Internal Developer Platforms tradition (Spotify) is the obvious anglophone analogue. Team Topologies (Skelton & Pais) and DORA's recent platform engineering findings are the natural canon. Truls's closing observation that Toyota → DORA → Team Topologies is one lineage is exactly the bridge.
• incompletePair programming is named as the most effective form of knowledge sharing and as the substrate that the rest of the infrastructure exists to support, but the cost question (developer preference, time investment, neurodiversity, hybrid/remote context) is not engaged. Moe acknowledges that change in this direction is 'ordentlig seig' — really tough/slow — but does not ask why even at SpareBank 1, with all the structure in place, pair programming is not yet universal. The same gap exists in his essay's TDD-with-the-agent prescription.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Read Birgitta Böckeler's recent work on remote pair programming, and the user's already-extracted Beck material on TCR (which functions as a half-step toward pair-discipline). The 'AI Joy Gap Developers' extraction the user already has — which treats reconnection-of-developers as needing organisational structure — is a direct complement.
• incompleteThe Norwegian / Lean-Norwegian context is implicit but not theorised. The åremål concept comes from Norwegian political and academic life and is being repurposed for engineering leadership. The fagtid concept has roots in Norwegian work-culture autonomy ideas. The DORA / Lean / Toyota convergence Truls names at the end is itself partially a Nordic management-culture convergence. There is a comparative essay latent here that the episode does not write.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Read in parallel with NAV's 'optimizing for fast flow' piece (already in the user's queue), with Norwegian Self-Determination Theory–inflected management writing (autonomi, mestring, mening), and with the wider tradition of Nordic engineering culture vs. anglophone agile-at-scale. The user's coding-agents corpus already includes Nils Brede Moe (no relation? — but a Nordic empirical-software-engineering voice in the same neighbourhood, including the upcoming Heis episode 9).
• incompleteThe 'we're the kind of team that writes tests' plus code-review-reinforcement mechanism (takeaway 5) is described only from the leader's side, with no account of what happens when the identity claim fails to take hold — resistance, gaming (writing trivial tests just to pass review), attrition among people who don't buy in — or how dependent the tactic is on team size and existing culture.
  How Do You Know That? — read next: Change-management/golden-path literature on adoption mechanics and failure modes of intrinsic-motivation-based rollouts.
• incompleteSame gap as the Golden Bricks extract, in a different colour. The whole programme assumes a Team-Topologies / Spotify-style organisation already exists — stream-aligned squads inside tribes, a platform team adjacent to them, business decision-makers sitting at tribe level. The Federated SRE, production manager, and technical tribe lead are role inventions overlaid on this topology, not designed to produce it. The article describes role responsibilities mechanically but treats the underlying org redesign — the part that costs years and political capital in most enterprises — as already done. For a reader whose org is functionally shaped, this is the part that matters most, and it is invisible.
  How a Culture of Data-Driven Conversations Can Support Platform Engineering — read next: Skelton & Pais, Team Topologies (esp. the 'enabling team' interaction mode, which is what Federated SREs functionally are). Cutler on operating-model design and accountability layering. Pais on cognitive-load assessment as a precondition for federation. Reinertsen on capacity allocation and queueing — the 20% tithe is a capacity-allocation decision that needs queue-theoretic defence.
• incompleteThe panel's central, explicitly named 'never answered question' — what to centralize versus leave to team autonomy — is acknowledged but never engaged with any decision framework; the panel does not decompose it along governance, composability, or team-readiness axes.
  Presentation: Platform Engineering in the Age of AI — read next: extract-platform-engineering-golden-bricks, which proposes decomposing exactly this choice along governance/composability/team-autonomy axes (and whose own extraction flags the same decomposition as under-theorized).
• illogicalStephen argues both that platform teams must 'not tamp down innovation' and preserve developer freedom to build new infrastructure via an inner-source model, and that centralized, codified rules are 'supremely important' to prevent 'random infrastructure' chaos. The roundtable asserts both are needed but never explains how the inner-source boundary is actually drawn — who decides when a developer's local infrastructure becomes platform-owned versus stays local — leaving the same centralize-vs-autonomy tension unresolved in a different guise.
  Presentation: Platform Engineering in the Age of AI — read next: Reader's own experience with inner-source contribution models, or corpus pieces on team-topology contribution boundaries, for a concrete adjudication mechanism.
• incompleteThe Q&A culture-change question ('how did developer/architect culture change?') is answered only anecdotally, contrasting a 'configure a managed platform' path against a 'bootstrap then implement change' path, with no data on adoption resistance, teams that pushed back against losing configuration flexibility, or failed pattern rollouts.
  Presentation: APIs for Agents: Rethinking API Programs in the MCP Era — read next: A platform-adoption case study or survey data on developer sentiment toward CALM-style mandated patterns, as a check on the talk's uniformly positive framing.
• uninformedEvery quantitative claim in the piece (1/10th the time, 3.5 PRs/engineer/day, 1M+ lines, throughput increasing with team size) is self-reported by the team that built the system and has an organizational interest in publicizing it, with no external audit, no comparison codebase built by an equivalent human-only team under the same product requirements, and no stated method for what counts as a meaningfully-sized 'line of code' or PR.
  Harness engineering: leveraging Codex in an agent-first world
• incompleteThe piece describes human review as optional ('Humans may review pull requests, but aren't required to... we've pushed almost all review effort towards being handled agent-to-agent') but never says what determines which PRs actually receive a human look versus none, or what happens when agent-to-agent review systematically misses the same class of issue because both the authoring agent and the reviewing agent share the same model's blind spots.
  Harness engineering: leveraging Codex in an agent-first world
• incompleteGeneralizability is unaddressed: the approach leans on advantages that may not transfer — a well-resourced, highly visible central CoE; a bridging executive sponsor who arrived by luck; and the borrowed authority of the DORA/Google brand. It is unclear how much of the playbook works in organizations lacking these.
  DORA Community Discussion - Operationalizing DORA within a large organization — read next: Change adoption in low-resource, low-visibility, or low-authority settings; how much of the outcome is attributable to the method versus the enabling conditions.
• incompleteThe 'golden path vs golden brick' distinction is rhetorical, not analytical. What actually changes when you move from path to brick? The article never decomposes the shift along the three axes where the shift really lives: (a) governance — who owns correctness, the platform team (path) or the consuming team (brick); (b) composability — who designs the assembly, and against what contract; (c) team autonomy — does the consuming team have the decision-rights, time, and skill to assemble well? Without this decomposition, 'bricks' is a slogan, not a model.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: Skelton & Pais, Team Topologies (esp. platform team / stream-aligned team interaction modes). Camille Fournier's writing on platform teams. Gregor Hohpe on architecture decision records and IT architecture as conversation. Manuel Pais on the cognitive-load assessment.
• incompleteThe organisational shift the article requires but does not theorise. Bricks-not-paths only works in an organisation that has already pushed correctness, security review, cost ownership, and incident response down into stream-aligned teams. In an org where the platform team is also the compliance team and the on-call team, bricks-without-a-path means each stream team must reinvent guardrails. The piece treats this organisational redesign as free — but it is the actual hard part.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: Cutler's TBM essays on institutional overload and accountability. Allen Holub's #NoAccountability work. Conway's Law re-readings (Skelton/Pais). Andrew Clay Shafer / DevOps adoption literature on the politics of platform ownership.
• incompleteStrawmanning of the golden path. In Spotify's original formulation and most current usage, a golden path is an opinionated default route through optional tooling — not 'the single way to do things.' Bryant collapses 'golden path' into 'golden cage' to set up the brick contrast, which makes the move feel sharper than it is. The real design choice is the ratio: which bricks ship with reference compositions (paths) attached, and which don't.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: The Spotify Backstage docs on golden paths. The 'paved road' material from Netflix engineering. Honeycomb's writing on opinionated developer platforms.
• incompleteNo treatment of the leaky-abstraction risk that the brick model amplifies. The more composable the platform, the more surface area developers can latch onto — and the harder it becomes to change the implementation later. Bryant raises leaky abstractions as a warning but never connects them to the brick model, which is precisely where they bite hardest.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: Spolsky's original 'Law of Leaky Abstractions.' Ousterhout, A Philosophy of Software Design, on deep vs shallow modules — bricks must be deep modules or the abstraction tax is real.
• uninformedNo engagement with the actual maturity literature on internal developer platforms — CNCF Platforms Working Group whitepaper, Team Topologies' Thinnest Viable Platform concept, the platform-engineering maturity model from PlatformCon. The piece treats the field as if Bryant is naming things for the first time.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: CNCF Platforms WG whitepaper (2023+). Team Topologies' TVP material. McKinsey/ThoughtWorks platform engineering reports for the practitioner-economics view.
• implicit premiseThe book promotion is structural to the argument — the entire piece is framed to show the book is newly relevant, which may bias the selection and framing of parallels toward ones that support the book's thesis.
  The Organization Is the Bottleneck
• unsupported claimThe 3x shipping speed claim is stated without citation or qualification.
  The Organization Is the Bottleneck
• implicit premiseThe framework assumes a sufficiently large and complex system to justify the investment. The 'when this is overkill' section is brief (one paragraph) and provides no quantitative thresholds for when the investment begins to pay off.
  Three Pillars of Platform Engineering: A Virtuous Cycle
• missing evidenceThe entire argument is grounded in author experience ('patterns I've seen work repeatedly') with no cited case studies, metrics, or controlled comparisons. The only external reference is to Martin Kleppmann on distributed locking, which is tangential.
  Three Pillars of Platform Engineering: A Virtuous Cycle
• unexamined tensionOpinionated SDKs are presented as unambiguously positive, but the trade-off between opinionation and flexibility is not explored. Teams with genuinely novel requirements may find absorbed patterns constraining rather than enabling.
  Three Pillars of Platform Engineering: A Virtuous Cycle
• missing perspectiveThe economic dimension is absent: there is no discussion of the cost of building and maintaining a control plane, opinionated SDKs, and layered observability — or how to prioritize investment when resources are constrained.
  Three Pillars of Platform Engineering: A Virtuous Cycle
• implicit premiseThe virtuous-cycle argument assumes that freed-up operator bandwidth will actually be invested back into platform improvement. In practice, organizations may redirect that bandwidth to other priorities, breaking the cycle.
  Three Pillars of Platform Engineering: A Virtuous Cycle
• incompleteThe article doesn't examine whether the effort of building and maintaining this flow documentation is actually less costly than the platform-level 'expose the system as a dependency graph' solution it endorses in its conclusion — it treats the two as sequential (interim vs. ideal) without comparing their respective costs, or addressing why platform teams haven't already built the graph-exposure tooling it calls for.
  Reverse Engineering your Software Architecture with Claude Code to Help Claude Code — read next: Compare against the corpus's platform-engineering and golden-path material on why paved-path adoption and tooling investment lag behind individual practitioner workarounds.
• incompleteThe 'you don't get to create anything' extension to AI is never made explicit
  You Don't Get to Create Anything (Still Burning: Beck + Randy Shoup on Jevons paradox and distributed systems under AI) — read next: Beck's own Substack on 'starving genies' and the human's relationship to the genie's outputs; Cal Newport's deep-work tradition on how the substitution of tool-mediated production changes the nature of the work; Pressfield on Resistance; and — the persona-relevant cross-thread — the 'fragility of ideas' hidden layer in Kjetil's reading: if the maker-compulsion is the durable substrate, what does it look like when the agent satisfies it without you having moved? This is the productive question the episode leaves on the table.
• incompleteThe Jevons-on-cognition forecast is asserted, not argued through to its qualitative differences
  You Don't Get to Create Anything (Still Burning: Beck + Randy Shoup on Jevons paradox and distributed systems under AI) — read next: Carl Benedikt Frey 'The Technology Trap' on the political economy of transitional displacement; Brad DeLong on what 'creating new categories of work' has actually looked like historically; Anton Korinek and Daron Acemoglu on AI-and-labor specifically. For the contrarian side: Erik Brynjolfsson on the J-curve (gains that show up late and unevenly); the Robin Hanson 'Age of Em' tradition for the qualitative-difference-of-cognition objection. Persona-relevant: DORA 2025 on AI's actual code-quality effects.
• incompleteThe playbook claim under-specifies the AI playbook's structure
  You Don't Get to Create Anything (Still Burning: Beck + Randy Shoup on Jevons paradox and distributed systems under AI) — read next: Hamel Husain on evals; Simon Willison on the working LLM-augmented practitioner's actual playbook; Addy Osmani and the Claude Code patterns crowd; the Bernhard / Bockeler / Thoughtworks harness-engineering thread already in this repo; the Heis ep 11 AI-special with Vilde Opsal and Anders Sveen for the Norwegian practitioner cut; the Heis ep 13 Torrissen for code-quality-under-AI. This is exactly where 'craft transmission for the next era' lives — and where the conversation is most incomplete.
• incompleteThe 'apprenticeship channel under 50:1 manager ratios' problem from the prior Still Burning episode is not picked up
  You Don't Get to Create Anything (Still Burning: Beck + Randy Shoup on Jevons paradox and distributed systems under AI) — read next: John Cutler on overload and DRI dynamics; Will Larson and Tanya Reilly on engineering-org structure; the Heis ep 13 Torrissen extraction for the Norwegian practitioner take on code-quality and craft transmission under AI. Persona-relevant: the 'fragility of ideas' layer — ideas die at the institutional adoption point if the apprenticeship channel is gone.
• incompleteShoup's 'make it easy, don't shame' principle is stated as climate policy and not applied to software craft
  You Don't Get to Create Anything (Still Burning: Beck + Randy Shoup on Jevons paradox and distributed systems under AI) — read next: Cutler on operating-system design and waste; Thaler and Sunstein on choice architecture for the foundational behavioral-economics text; Kniberg on Spotify's model as an example of friction-reduction at scale. Persona-relevant: this is exactly where Kjetil's leadership-vs-management orientation and his Cutler-deep reading already live.
• incompleteThe 'distributed-systems-playbook-writers as exemplars' framing implicitly leaves out the playbook that didn't get written
  You Don't Get to Create Anything (Still Burning: Beck + Randy Shoup on Jevons paradox and distributed systems under AI) — read next: Schneier on security (in Kjetil's RSS); the Ruined by Design / Mike Monteiro line on what professionals fail to write playbooks for; the Norwegian intelligence reports (NSM, PST) for the security-and-resilience perspective; recent regulatory writing on AI-and-governance for what is being written by non-engineers because engineers didn't write it.
• incompleteThe Beck-as-inductive vs. Shoup-as-deductive split is named but not connected to the playbook-writing claim
  You Don't Get to Create Anything (Still Burning: Beck + Randy Shoup on Jevons paradox and distributed systems under AI) — read next: Anything on creative-cognitive partnerships at scale: Brian Eno's 'scenius' concept, Anne Lamott on the writer-editor pairing, the literature on the pair-programming and mob-programming traditions in software. For the temperament-and-craft thread specifically: Beck's own writing on the craft of seeing simple design where others see complexity.