Right-Sizing Boundaries & Primitives
The discipline of investing in correctly-scoped boundaries and right-sized primitives — across human teams, code modules, and agent access — as the key enabler for building safely and effectively with AI.
Also known as: better boundaries, right primitives, right-sized primitives, right-sized for use, composition, and orchestration, Right-sizing the human teams, chunking context to the right size
Part of: Software Design Fundamentals
How authors use it
Oldest first (extraction date when no publication date is known).
| Author | Their term | Their meaning |
|---|---|---|
| AI Is Changing Software Engineering. The Fundamentals Still Matter. Abby Bangser · 2026-07-07 | better boundaries | Correctly-scoped separations — between human teams, code modules, and agent access/ecosystems — that organisations invest in to move fast and safely with AI |
Documents (5)
- The Orchestrator's Tax Rahul Garg (martinfowler.com; edited/guided by Martin Fowler) · 2026-07-28 source ↗ Reader 🖥️
The real value of a subagent is not the wall-clock time it saves through parallel execution but what it keeps out of the orchestrator's context, so multi-agent workflows should be designed and governed around protecting the orchestrator's limited working memory — via task splits that respect 'cognitive locality' and via minimal, fact-justified standing rules — rather than around maximizing delegation, agent count, or governance. - Stop Overengineering Your Agent Harness Hugo Bowne-Anderson · 2026-07-22 source ↗ Reader 🖥️
Most builders should reject the coding-agent-derived harness checklist (memory, compaction, sub-agents, hooks) as a default and instead size their harness to where a given task actually falls on two independent axes — action complexity and context complexity — because harness features are provisional, encoding assumptions about model limitations that expire as models improve (the 'Kirby effect'), so the discipline is to build the minimum viable harness for the job and prune it as capability arrives. - How to Manage Privilege Drift in Multi-Agent Systems Janet Wagner · 2026-07-14 source ↗ Reader 🖥️
Privilege drift — the incremental, individually-reasonable accumulation of an AI agent's permissions beyond its original purpose — multiplies across the agents, shared resources, and communication channels of a multi-agent system into an attack surface no single decision ever consciously approved, and it can only be managed (never eliminated) through continuous cross-agent inventory, runtime-enforced least privilege, just-in-time access, and behavioral monitoring. - mattpocock/skills v1.1: does /wayfinder beat grill-with-docs? Matt Pocock (AI Hero) · 2026-07-08 source ↗ Reader 🖥️
Pocock announces that v1.1 of his Claude Code skills repo now composes a complete agentic coding lifecycle (Grill -> Spec -> Tickets -> Implement -> Code Review), whose headline addition, /wayfinder, decomposes a plan too big for one session into agent-sized chunks mapped as GitHub issues with blocking edges so the work can be parallelized. - AI Is Changing Software Engineering. The Fundamentals Still Matter. Abby Bangser · 2026-07-07 source ↗ Reader 🖥️
AI is transforming who produces, consumes, and maintains software, but the organisations moving fastest succeed by doubling down on engineering fundamentals — right-sized boundaries, modular abstractions, clear interfaces, and operational discipline — as the foundation that lets humans and AI build together safely and sustainably.
Propositions touching this concept (3)
By publication month, oldest first (extraction month when no publication date is known).
2026-07
- implicitOld prioritization frameworks implicitly treated urgency as a personal leadership failure (fixable by clearer values, better boundaries, or better time-management tools); ambient urgency reframes urgency as the objective operating condition itself, shifting the locus of responsibility from individual discipline to conscious, structured tradeoff-making.
- explicitThe organisations moving fastest with AI are investing in better boundaries, not primarily in better models or more autonomous agents.
- explicitcorroboratedInvesting in right-sized primitives — including repeatedly chunking context to the right size when working with AI — is what unlocks the biggest opportunities.
Tensions
How much of the build pipeline should run with no human reading the code (the 'dark factory')?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
- Looking back at the Future of Software Engineering unconference (Bartosz Ocytko): Toward a largely self-evolving software factory where a feature request is 'magically built' into the system; humans build and operate the factory and intervene only at explicit hand-off points.
- AI Is Changing Software Engineering. The Fundamentals Still Matter. (Abby Bangser): Deliberately bounded autonomy — keep humans in the loop.
- Software Design in the Agentic Age: Place Your Bets (Mathias Verraes): Dark factories are only safe for organisations that already have high test coverage, skilled engineers, and a high-quality engineering culture; most should cover their fundamentals first.
Assessment: Not simple optimism vs pessimism but a disagreement about preconditions and hidden costs. Ocytko's is a projection of where tooling is heading; Bangser and Verraes both supply reasons the projection is unsafe by default — learning-loss and missing prerequisites. Bangser has the stronger argument that the loss is structural (you cannot buy back organisational learning), which even an improving platform does not address.
How far can day-2 operations be handed to self-healing / autonomous remediation?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
- Looking back at the Future of Software Engineering unconference (Bartosz Ocytko): A self-healing platform foundation should make whole classes of failure 'disappear', with increasingly autonomous background 'guardrail' agents refactoring, adding tests, and protecting invariants.
- AI Is Changing Software Engineering. The Fundamentals Still Matter. (Abby Bangser): Detection, context, and suggestion are safe wins, but automated remediation must remain an intentional, context-specific decision, not a default end state.
- What Survived Contact (Sam Ruby): Self-healing has, in practice, only moved halfway: diagnosis is automated while remediation is deliberately withheld from the machine.
Assessment: Ruby's report is descriptive (where practice actually stands) and Ocytko's is aspirational (where platforms could go); the gap between 'remediation is withheld' and 'failure modes disappear' is precisely the distance the optimists are projecting across. Bangser supplies the reason the gap may not close on efficiency grounds alone — the withheld human step is also the learning step.
Where is the locus of safety for non-engineers / citizen developers building software?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
- Looking back at the Future of Software Engineering unconference (Bartosz Ocytko): In a tightly-constrained self-healing platform — not universal upskilling.
- What Survived Contact (Sam Ruby): In the director's management skill — a non-engineer steering an agent has made a hire, and the requirement is that they can manage by objective.
- AI Is Changing Software Engineering. The Fundamentals Still Matter. (Abby Bangser): In API-first, MCP-accessible tooling that supports rather than restricts the new builders.
- Why did Martin Fowler invite 60 engineers to a ski resort? (Ivett Ördög): It is genuinely unsolved — the tension between democratisation and its risks is an open question.
Assessment: Four different answers to the same governance question: the platform (Ocytko), the director's discipline (Ruby), the tooling interface (Bangser), or nobody-knows-yet (Ördög). Ruby and Ocytko are the true opposites — Ruby puts the burden on a human management skill, Ocytko designs the human out by making failure modes disappear in the platform. That both are held by attendees of one retreat is a measure of how unsettled the citizen-developer problem is.
Where does the non-delegable human asset now live — the harness/platform, the oracle, the fundamentals, or the developer's understanding?
from: What is the future of software development in the agentic/AI age?
- Notes from FOSE Europe (Giles Edwards-Alexander): In the harness — the continuously-evolving scaffolding of architecture guidance and rigour around the agents — though it must stay team-distributed, not centralized.
- What Survived Contact (Sam Ruby): In the oracle — the objective's evaluation is the single thing the person directing the model cannot delegate back to it.
- Jimmy Nilsson's Post — reflections after the Thoughtworks 'Future of Software Development' retreat (Jimmy Nilsson): In the fundamentals plus a renewed 'Extreme Humanism' — the durable disciplines and the conspicuously human element.
- AI Is Changing Software Engineering. The Fundamentals Still Matter. (Abby Bangser): In right-sized boundaries and the operational loop — humans must stay in operations because their learning is the irreplaceable asset.
- Fragments: February 9 (Martin Fowler (Feb 9)): In the developer's model-building and shared understanding — the craft of devising abstractions to reason about the domain.
Assessment: This is the deepest structural disagreement — every author agrees a human residue remains but nominates a different residue, and the choice determines what to invest in and what to teach. The harness-centric (Edwards-Alexander), oracle-centric (Ruby), fundamentals-centric (Nilsson/Bangser), and understanding-centric (Fowler) camps are not merely emphases: they imply different career ladders, different hiring, and different failure modes. Ruby's oracle and Bangser's operational-learning are the most operationally concrete; Nilsson's is the least argued. The absence in the corpus of anyone who holds 'nothing is non-delegable' is itself telling (see unexamined assumptions).
Should the harness/platform and its safety be centralized or left distributed across teams?
from: What is the future of software development in the agentic/AI age?
- Notes from FOSE Europe (Giles Edwards-Alexander): Distributed — dedicated harness-engineering teams are a mistake; per-team friction in building harnesses is creative and generative.
- Looking back at the Future of Software Engineering unconference (Bartosz Ocytko): Centralized — safety for non-engineers should come from a tightly-constrained, self-healing platform that ships access and data guardrails.
- AI Is Changing Software Engineering. The Fundamentals Still Matter. (Abby Bangser): Centralized enabling layer — platform, SRE, and ops teams should provide API-first, MCP-accessible tooling that others safely consume.
- Fragments: February 18 (Martin Fowler (Feb 18)): Centralized golden path — platform teams should provide fast-but-safe 'bullet trains' with security built in by default.
Assessment: A real operating-model split. Edwards-Alexander's distributed stance rests almost entirely on the DevOps-team analogy (his own extraction flags it as asserted-on-intuition, not argued), whereas the platform camp has the stronger concrete case for the citizen-developer safety problem — you cannot distribute production-data guardrails to non-engineers. The tension is partly reconcilable: Ocytko himself concedes a platform tight enough for non-engineers may be too constraining for expert engineers' identity and innovation, which is exactly the freedom Edwards-Alexander is protecting. The unresolved question is whether one platform can be both.
How far should software be automated — toward the fully-autonomous dark/software factory, or held back to bounded autonomy with humans in the loop?
from: What is the future of software development in the agentic/AI age?
- Why did Martin Fowler invite 60 engineers to a ski resort? (Ivett Ördög): Full automation is genuinely viable in context and she is 'ironically' being pulled toward the dark-factory camp.
- Looking back at the Future of Software Engineering unconference (Bartosz Ocytko): The aspirational endpoint is a largely self-evolving software factory; humans build and operate the backbone rather than the application.
- AI Is Changing Software Engineering. The Fundamentals Still Matter. (Abby Bangser): Bounded autonomy — keep humans in the operational loop; automated remediation must stay an intentional decision.
- What Survived Contact (Sam Ruby): Self-healing has stalled halfway on purpose: diagnosis is automated, remediation withheld from the machine.
- Software Design in the Agentic Age: Place Your Bets (Mathias Verraes): Dark factories are safe only for orgs that already have high test coverage, skilled engineers, and a quality culture; most should cover fundamentals first and stay revertible.
Assessment: The spectrum runs from Ördög/Ocytko (full automation is arriving and desirable) to Bangser/Ruby/Verraes (deliberately withhold the last step). The decelerationists have the better of the safety argument today — Ruby's 'nobody will cede the blast radius' and Bangser's 'removing humans removes learning' identify concrete, unmet prerequisites — but Ördög's context-dependence (backends, COBOL) shows the boundary is domain-specific, not absolute. The real disagreement is less about capability than about who absorbs the blast radius when an autonomous fix goes wrong.
How should newly-empowered citizen developers be made safe — constrained platform, human stewardship, or supported API-first tooling?
from: What is the future of software development in the agentic/AI age?
- Looking back at the Future of Software Engineering unconference (Bartosz Ocytko): A tightly-constrained, self-healing platform — not universal upskilling — should absorb citizen developers.
- The "funhouse mirror": How AI reflects the hidden truths of your software pipeline (Rachel Laycock (interviewed by The New Stack)): Senior technologists must act as stewards — teaching the 'why' and building guardrails, not gatekeeping or replacing juniors.
- AI Is Changing Software Engineering. The Fundamentals Still Matter. (Abby Bangser): Support, don't restrict — provide API-first, MCP-accessible tooling that non-engineers can safely consume.
Assessment: All three agree citizen developers are inevitable and must not be blocked, but the safety mechanism differs — encode it in a constraining platform (Ocytko), transfer it through human relationships (Laycock), or expose it as consumable interfaces (Bangser). Ocytko's platform-first case is strongest on the specific failure mode both he and Ördög name (non-engineers leaking or bypassing production-data access), which stewardship alone cannot prevent at scale. Laycock's stewardship answers a different problem — sustaining the junior-to-senior pipeline — that a platform does not. The positions are complementary in principle but compete for the same finite investment, and none supplies a concrete governance model for vibe-coded shadow IT.
Open gaps (4)
- incompleteThe piece never specifies the actual decision procedure an orchestrator should run to detect 'cognitive locality' before spawning agents — i.e. how it recognizes, in advance, that two tasks will require reconstructing the same mental model of a codebase. Rules 1 and 4 (prefer 2-4 agents; treat overlapping file ownership as a consolidation signal) assume this diagnosis is already available; they don't produce it, and file overlap is only a weak proxy for shared mental-model requirements (two tasks can need the same understanding without touching the same files, or touch the same files with genuinely independent context needs).The Orchestrator's Tax — read next: This is the exact gap the task brief flagged and the piece's most productive incompleteness: look for task-decomposition or dependency-analysis frameworks that could operationalize 'shared mental model' as a measurable property rather than a post-hoc diagnosis (e.g. right-sizing-boundaries / chunking-context literature, or explicit action-complexity/context-complexity rubrics).
- incompleteNo diagnostic or decision procedure for scoring a task's position on the action-complexity/context-complexity axes. The framework is presented as the deciding factor but is never operationalized — no rubric, thresholds, or worked example for a borderline case — so two builders looking at the same task could reasonably disagree about where it falls.Stop Overengineering Your Agent Harness — read next: Read a treatment that operationalizes the framework with measurable proxies (e.g., tools invoked per successful run, tokens retained across turns) or validates it against outcome data.
- incompleteThe Maven Assistant case study — the essay's single detailed low-complexity example — describes an already-live consumer health product with meaningful compliance stakes (self-harm handoffs, withheld high-cost benefits questions). The essay never shows a genuinely minimal internal/low-stakes agent receiving the 'keep it small' advice, leaving open whether even Maven's 'moderate action complexity' harness (routing, bounded tools, guardrails, handoffs) is itself already more than many builders need.Stop Overengineering Your Agent Harness — read next: Read case studies of minimal single-tool, single-turn internal agents to test whether even Maven's harness is over-built for lower-stakes use cases.
- incompleteThe essay names but doesn't explain the skew whereby public harness-engineering discourse is dominated by coding/personal-agent problems even though support, sales, and enterprise agents are described as the majority of what builders actually build — leaving unaddressed whether this reflects genuine attention bias, differing incentives to publish, or something else.Stop Overengineering Your Agent Harness — read next: Read industry-adoption surveys on where AI agents are actually deployed (support/sales/enterprise vs. coding) to check whether the discourse mismatch tracks a real minority-attention bias.