Craft Community

Self-organizing professional communities and protected craft time through which engineering practice is transmitted and renewed.

Also known as: fagmiljø / community, fagmiljø, fagtid, communities of practice, tech-møtet, the playbook

How authors use it

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

Documents (9)

• Collective problem solving in music, art, science, and software Jessitron · 2026-09-12 Reader 🖥️
  Great teams and great individuals are produced (not assembled from pre-existing talent) by group processes — camerata-like communities across music, art, science, and software — because such groups form a 'symmathesy': a living system of mutually learning people, tools, and (in software's unique case) the running software itself, and therefore growing individual and collective capability requires cultivating and sharing mental models within that system rather than optimizing individual output or hoarding recognition.
• 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.
• Future Of Software Development Martin Fowler · 2026-07-07 source ↗ Reader 🖥️
  Thoughtworks convened invitation-only 'Future of Software Development' Open Space retreats in 2026 to examine how AI and LLMs will reshape the profession, and Fowler deliberately captured the discussions as unattributed fragments rather than one coherent narrative — the fragmentary form itself signalling that the profession's future is too unsettled to reduce to a single thesis.
• 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.
• Developing Your Leadership Skills toward Principal Engineering Ben Linders · 2026-04-15 source ↗ Reader 🖥️
  Becoming a principal engineer requires deliberately cultivating leadership skills beyond technical expertise — especially by bringing skills from outside work, engaging in tech communities, and public speaking — and these activities create compounding positive feedback loops that accelerate career growth.
• 13) Tobias K. Torrissen om kodekvalitet, konferanser og AI Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2026-03-16 source ↗ Reader 🖥️
  In the age of LLM-generated code, the durable value of an engineering leader is not in writing code but in cultivating the engineering practices, explicit design discipline, and craft community that determine whether a long-lived system can be understood, maintained, and adapted — and code quality, understood as 'obvious over clever,' matters more in this era, not less.
• How to Turn Individual Talent into Organizational Excellence Harvard Business Review · 2026-03-12 Reader 🖥️
  Sustained organizational excellence is produced not by individual talent, hiring, or motivation but by a deliberately designed system in which talent development, socially-enforced team standards, and disciplined recurring routines reinforce one another.
• 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.
• Leading your engineers towards an AI-assisted future Pete Hodgson · 2025-06-26 source ↗ Reader 🖥️
  An engineering leader should drive AI-coding adoption the same way they'd drive any major capability shift — by setting a clear, phased goal (Experimentation, then Adoption, then Impact) measured with lightweight KPIs, giving teams real autonomy over how they get there, and backing that autonomy with concrete organizational support (training, budget, protected time, a community of practice, empathetic communication) — rather than mandating a usage percentage from day one.

Propositions touching this concept (10)

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

2025-11

• implicitFlat structure is impossible above ~5 people; the right response is not to pretend it is flat but to design the social arenas (tech-møtet, fagavdelinger, åremål, distributed personalledelse) so that the inevitable hierarchy is humane and productive.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett · p9
• explicitSkalert smidig (scaled agile) at SpareBank 1 was not the product of a framework adoption but of consistent fagtid plus deliberate hiring for mindset over years.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett · p12
• explicitLanguage and architecture decisions can be left to organic team uptake (Java → 90/10 Kotlin) when the underlying decision arena (tech-møtet) is healthy.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett · p14

2026-03

• explicitConferences and fagmiljø are formative substrate for engineers — single encounters (a lunch at Roots Bergen with Cockburn and Fowler) can determine a whole career.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI · p12
• implicitSaying yes by default — having '100 words for yes and none for no' — is an underrated career-building strategy in fagmiljø work.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI · p21

2026-06

• diagnosticThere is a playbook for distributed-systems work at scale (and for software more broadly) that took a generation to write; people have gotten used to turning to a page and applying the technique; the AI moment has 'wiped a lot of the playbook clean.'
  You Don't Get to Create Anything (Still Burning: Beck + Randy Shoup on Jevons paradox and distributed systems under AI) · p3
• diagnostic / sociologicalThe people panicking about AI are mostly playbook-appliers who have never not had a playbook; they don't realize they're allowed to write the next one. The playbook-writers (those who lived through writing the original distributed-systems playbook) aren't panicking, because they know what writing one feels like.
  You Don't Get to Create Anything (Still Burning: Beck + Randy Shoup on Jevons paradox and distributed systems under AI) · p4
• dispositionalThe right meta-disposition toward the current moment is to take it seriously without panicking. History and perspective — reading the 20th century, studying authoritarianism, knowing that worse has happened — license the playbook-writing temperament instead of the playbook-panic temperament.
  You Don't Get to Create Anything (Still Burning: Beck + Randy Shoup on Jevons paradox and distributed systems under AI) · p12

2026-07

• implicitThe Playbook implicitly assumes firms have the market power, brand equity, or mission-driven customer base needed to survive genuine Sacrifices-quadrant costs (Apple could absorb a $10B ad-revenue hit to Meta; Patagonia's customer base pays a loyalty premium) — no guidance addresses firms without comparable leverage, for whom the same 'sacrifice' could simply mean losing to a less scrupulous competitor.
  Responsible AI Is Becoming a Growth Strategy · p12

2026-09

• explicitNot all refactoring attempts succeeded — some made Code Health worse — and documenting these failures in the playbook alongside successes was treated as essential to the process's effectiveness, not an embarrassing footnote.
  Case Study: Refactoring at Scale with Agents · p6

Open gaps (38)

• incompleteThe essay never addresses survivorship bias: it draws its entire inductive base from groups that are famous precisely because they succeeded (Camerata, Impressionists, Manhattan Project physicists, the London Agile group, early Spring). It offers no comparison to the base rate of similarly-diverse, similarly-talkative, similarly-practicing groups that produced nothing notable, so the claim 'camerata structure causes exceptional outcomes' is not actually distinguished from 'exceptional outcomes retroactively get called a camerata.'
  Collective problem solving in music, art, science, and software — read next: Literature on survivorship bias in studies of success/innovation (e.g., critiques of 'best practices from famous companies' research); sociology-of-science work on the base rate of research collaborations/invisible colleges relative to how many are later celebrated.
• uninformedThe essay treats the Camerata's ignorance of actual ancient Greek musical practice as a harmless, even useful, legitimizing fiction ('like citing computer science papers from the 70s'), without engaging with the epistemic risk that such founding myths pose when a group's shared 'ground truth' is simply wrong — a risk directly relevant to software teams whose shared mental models can be confidently wrong in the same way.
  Collective problem solving in music, art, science, and software — read next: Work on how groups sustain false shared beliefs / groupthink despite (or because of) shared practice and mutual reinforcement — e.g., organizational research on 'espoused theory vs. theory-in-use' (Argyris), or on collective illusions.
• incompleteVendor risk is structurally absent. The playbook never names that 'AI-native' as defined here means 'Anthropic-native'. Customers building this way inherit Anthropic's pricing, capability, rate-limit, and product-strategy decisions as critical-path dependencies — exactly the workflow lock-in pattern the Scale chapter prescribes against competitors.
  The Founder's Playbook: Building An AI-Native Startup — read next: Contrast with Cloudflare 'Mythos' retro (already extracted) on what depending on a single AI vendor's pricing and capability surface looks like under stress; read multi-model / model-portability discussions and 'OpenRouter-style' abstraction-layer arguments.
• incompleteNo unit economics. The playbook celebrates leanness in headcount but is silent on token cost at company scale. A 5-person AI-native startup serving 100k users may have COGS that look nothing like the 200-person SaaS company they're imitating. Margin structure, model-price exposure, and gross-margin scenarios are absent.
  The Founder's Playbook: Building An AI-Native Startup — read next: Read recent inference-cost analyses (Baseten, public AI-startup tear-downs); compare to a SaaS gross-margin baseline. Useful: any first-hand founder writing on token-economics post-PMF.
• incompleteRegulatory and data-sovereignty depth is absent. Compliance is treated as a Launch-stage to-do (SOC 2, GDPR, HIPAA) rather than a structural constraint. The EU AI Act, Norwegian public-sector procurement, data residency obligations, on-prem requirements, and sector-specific (finance, health, defence) constraints are not discussed and would invalidate or substantially reshape parts of the playbook.
  The Founder's Playbook: Building An AI-Native Startup — read next: EU AI Act practitioner guides; Norwegian DigDir / NSM guidance on third-party AI; Healey's AI-advisory-board piece (already extracted) on AI governance inside organisations.
• incompleteThe model-capability-curve assumption is unnamed but everywhere. The whole playbook implicitly assumes models keep getting better, cheaper, and more available at current rates. If that curve plateaus or regresses, the orchestrator-without-team model becomes much weaker, but the playbook gives no scenarios for that.
  The Founder's Playbook: Building An AI-Native Startup — read next: Gary Marcus and other capability-skeptic writing; cost-curve and scaling-limit discussions; Anthropic's own harness-engineering paper (already extracted) which is more candid about current limits.
• incompleteArchitectural-coherence prescription (CLAUDE.md, specs before code) is good advice but is reintroducing classical software-engineering discipline (formal specs, ADRs, design docs) without acknowledging the lineage. The implicit message — 'this is new' — undersells how much of the prescription is rediscovery.
  The Founder's Playbook: Building An AI-Native Startup — read next: Re-read Kent Beck (Tidy First?), structured-design literature (Yourdon & Constantine), and ADR/design-doc practice writeups against the playbook's reframing.
• illogicalThe non-technical-founder claim and the architectural-discipline claim are in tension. If the prescribed engineering practice (CLAUDE.md, security review, debt remediation, observability) requires architectural judgement, then 'non-technical founder' is doing a narrower kind of work than the document suggests — likely 'prototype and validate', not 'run a Scale-stage company solo'. The playbook never reconciles this.
  The Founder's Playbook: Building An AI-Native Startup — read next: Non-technical-founder case study autopsies; the 'who survives the MVP-to-Launch transition without an engineer' empirical question.
• incompleteAttention and institutional memory of the founder herself is unaddressed. The playbook moves the founder from execution to orchestration but never asks what kind of attention infrastructure the orchestrator needs, what cognitive failure modes emerge when one person owns judgement across all domains, or how a solo orchestrator builds organisational memory beyond their own head. This is precisely the hidden-layer concern (Bailey, Stolen Focus, Cutler on overload) the reader cares about.
  The Founder's Playbook: Building An AI-Native Startup — read next: Cutler TBM 412 (institutionalised overload + AI), Bailey on attention infrastructure, anything on cognitive load of high-context orchestration roles.
• incompleteThe argumentative framing — 'AI-native is the right framing' — is never set against its alternative ('AI-augmented' as integration into existing patterns; 'AI-using' as a feature choice). The playbook treats 'AI-native' as the default future rather than as one strategic posture among several.
  The Founder's Playbook: Building An AI-Native Startup — read next: Read alternative framings: AI-augmented engineering writeups, smallcode-style minimalism (already extracted), and the broader 'is AI-native a category or a marketing label?' debate.
• incompleteBecause the retreat was held under the Chatham House Rule, the insights are unattributed, so a reader cannot trace claims to their sources or weigh them against the speakers' contexts and track records.
  Future Of Software Development — read next: Seek on-record accounts from named participants who wrote their own posts or granted permission to be quoted.
• incompleteSurvivor bias: every named case is a success. No accounting of failed Chinese acquisitions of Western brands, base rates, or selection effects (e.g., Ding's board roles at H&H and JS Global, disclosed, may shape the case mix). Without a denominator, the playbook may be retrofitted to winners.
  How Chinese Firms Are Saving Western Brands — read next: M&A failure-rate literature on Chinese outbound deals (e.g., Lenovo-Motorola, HNA, Anbang); academic work by Peter Williamson, Eden Yin.
• 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).
• incompleteTorrissen's frame is largely Norwegian consultancy and public-sector. The 30-year-lifespan argument is anchored in NAV/Skatt/politi; he gestures at differential quality bars for low-stakes consumer apps but does not engage with product-company contexts (startup, scaleup, SaaS) where the relevant time horizon is 3-5 years and the relevant readers are 5-10 engineers, not 70 forvaltere.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Read this against the Pocock workshop extraction (product-company AI workflow) and Vidar Moe (Heis), to see how product-company engineers calibrate quality differently.
• incompleteThe 'engineering practices matter more under AI' claim rests on one cited Telenor talk. Strong intuition, weak evidence. A serious version needs DORA-style measurement of practice maturity × AI uplift.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: DORA 2025 (already in user's library); the Entur AI adoption piece; Addy Osmani's agent patterns; any rigorous productivity studies.
• incompleteThe 'obvious over clever' principle is presented as inheritance from NAV's tekniske retning but the tradeoff against domain-modelling power, type-system expressiveness, and idiomatic language use is not explored. A 'maximally obvious' codebase in a functional language with strong types may look obscure to a Java-trained 70-forvalter pool.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Greg Young / Vlad Khononov on domain modelling; Ousterhout's 'A Philosophy of Software Design'; Rich Hickey's 'Simple Made Easy' (vs. 'easy ≠ obvious').
• incompleteTorrissen acknowledges he's about to participate in a recursive case (reviewing code that was itself generated agentically) and only jokes. The methodology gap — how does code review change when the developer's intent is partially encoded in prompts, ADRs, and context files rather than commit history — is left for next time.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Anthropic 'harness design' talk and the Pocock workshop already in this corpus.
• incompleteThe advice to juniors assumes the fundamentals taught today are the right ones; doesn't engage with the possibility that fundamentals themselves need re-curation for a world where LLMs are the second author. What does TDD even mean when test generation is also automated?
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Kent Beck's recent 'Tidy First?' work on AI and design; 'starving genies' series; DORA on AI testing practices.
• uninformedTorrissen disclaims familiarity with the formal 'distribution law' he invokes (Parnas/Helland-style). He gets the spirit right but doesn't engage with the literature on when distribution is forced (latency, regulatory, fault isolation).
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Pat Helland's papers; Parnas on module boundaries; Vlad Khononov directly.
• incompleteCode quality discussion is silent on data and persistence design — arguably the longest-lived and hardest-to-change layer in 30-year systems. The whole conversation is about behavioural code.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Stripe-style schema evolution practice; Martin Kleppmann's data engineering work; event-sourcing reflections from CQRS practitioners.
• illogicalThe piece argues both that AI's pace of change is unlike anything the author has seen in 20+ years, and that established change-management patterns from prior technology waves (DevOps, cloud, CD) will straightforwardly transfer — without reconciling why a genuinely unprecedented shift would be well-served by a non-unprecedented adoption playbook. The claim that 'proven methodologies' suffice is asserted, not argued against the claim of novelty made two paragraphs earlier.
  Leading your engineers towards an AI-assisted future — read next: Look for arguments specifically about what, if anything, is structurally different about AI adoption that would break a Mission Command-style rollout — e.g. the rate of tool obsolescence outpacing a Community of Practice's ability to stay current.
• incompleteThe article never addresses the tension between breadth (community, speaking, diverse skills) and depth (deep technical mastery). Principal engineers are typically expected to have both, but the article focuses entirely on the breadth side. An engineer following this advice exclusively might develop excellent leadership skills while falling behind technically — which would undermine their credibility in the role.
  Developing Your Leadership Skills toward Principal Engineering — read next: Will Larson's 'Staff Engineer' or Tanya Reilly's 'The Staff Engineer's Path' for the technical depth dimension; also the original talk video for potential coverage of this balance
• incompleteThe feedback loop claim is asserted via metaphor ('systems thinking terminology') but not demonstrated. There is no evidence that these activities actually compound rather than merely accumulate. The mechanism by which speaking leads to organizing leads to centrality is never specified — it could equally be a survivorship bias narrative.
  Developing Your Leadership Skills toward Principal Engineering — read next: Research on career capital theory (Cal Newport's 'So Good They Can't Ignore You') for a more rigorous framework on how skills compound
• uninformedNo acknowledgment of structural barriers to community involvement and public speaking: geographic isolation, caregiving responsibilities, financial constraints, neurodivergence, visa/immigration constraints that limit professional visibility. The advice assumes a degree of privilege and freedom that many engineers don't have.
  Developing Your Leadership Skills toward Principal Engineering — read next: Literature on equity in tech careers; Lara Hogan's work on sponsorship as an alternative path for underrepresented engineers
• incompleteThe article is a journalistic summary of Weston's talk, not an independent analysis. The real intellectual content is in the original QCon presentation, which likely contains more nuance, caveats, and audience interaction than this compressed version captures.
  Developing Your Leadership Skills toward Principal Engineering — read next: Watch the original talk: 'The Principal Engineer's Path' by Sophie Weston, QCon London
• incompleteAn unreconciled internal tension: the article claims both that 'changing only the tools, not how people think, will hit a wall' and that 'the culture shifted because tools demanded a certain way of working.' The necessary-but-not-sufficient reconciliation (tools create the pull; people must still internalize the practices) is left implicit, and what determines whether a tool's community norms actually transfer versus stall is never examined.
  How Open Source Enables Collaboration in Creating a Platform — read next: Conway's-law re-readings and sociotechnical systems theory (Skelton & Pais; the original Conway paper); diffusion-of-practices and communities-of-practice literature on when norms embedded in tooling actually take hold in an adopting organization.
• incompleteThe two-sided contribution model is asserted -- users contribute, communities form, Genius Bar sessions draw teams in -- but never operationalized. How contribution is governed, who keeps quality from degrading as multiple teams contribute, how the producer (contributor) experience is designed, and how the platform team avoids becoming the bottleneck it replaced are all left open.
  How Open Source Enables Collaboration in Creating a Platform — read next: Platform-as-product producer-experience and governance (Evan Bottcher's platform-thinking work; Gregor Hohpe on platform architecture governance); Team Topologies on the enabling-team interaction mode and contribution/collaboration boundaries.
• 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.