AI Is Changing Software Engineering. The Fundamentals Still Matter.

Abby Bangser · article · 2026-07-07 source ↗ Reader 🖥️

Agent-Native Design Context Engineering Ironies of Automation MCP (Model Context Protocol)Modularity & Coupling Non-Engineers Building Platform Engineering Right-Sizing Boundaries & Primitives Software Design Fundamentals SRE & Incident Response They Build It, You Run It Vibe Coding

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.

practical · mixed — A field report summarising the European Future of Software Engineering (FOSE) retreat, written under the Chatham House Rule. Primarily expository (a synthesis of themes from many sessions and hallway conversations) but woven through with argumentative advocacy — 'support don't restrict', 'APIs first', and 'fundamentals still matter'.

Structure

Part	Role
Opening frame: the FOSE takeaway is boundaries, not models	Reframes the question of who moves fastest with AI away from better models or autonomous agents and toward investment in better boundaries and right-sized primitives ('slow is smooth and smooth is fast')
Primitives and right-sizing across teams, code, and agents	Establishes right-sizing/modularity as a single cross-cutting discipline — illustrated by right-sized teams, chunked codebases for token efficiency, and scoped agent access — and grounded in a hallway-track refactor experiment
We can't slow down consumption, but we can enable it safely and efficiently	Argues that non-engineers building software (vibe-coding, shadow IT) is inevitable and that platform/SRE/ops teams must support it via API-first, MCP-accessible backend services rather than resist it
Day-2 operations: gold rush versus maintenance burden	Tempers the self-healing-agent enthusiasm with cautions that automated remediation removes organisational learning, and points to deterministic, scoped, role-controlled operations as the path to automatable support at scale
Closing thesis and call to continue	States the central claim that fundamentals are becoming more important, not less, and calls for more cross-regional conversations to keep AI effective, supportive, and sustainable

Key terms

better boundaries Right-Sizing Boundaries & Primitives
Correctly-scoped separations — between human teams, code modules, and agent access/ecosystems — that organisations invest in to move fast and safely with AI
primitives
Right-sized building blocks (a human team, a code chunk, an agent's scope) that are most impactful when sized for use, composition, and orchestration
right-sizing / chunking context to the right size
The repeated discipline of sizing units and context to the appropriate granularity so both humans and LLMs can act efficiently and effectively
operational harnesses
Support systems built from deterministic, scoped, and tightly role-controlled actions that can operate any deployed software and its operational and infrastructure dependencies at scale
vibe to value
A tentatively-remembered attendee phrase for turning vibe-coded exploration into safe, coherent, iterable value across human, non-engineer, deterministic, and agentic consumers
gold rush mentality
The prevailing event mood of focusing on doing more with AI while under-investing in the maintenance burden that follows
slow is smooth and smooth is fast
The principle that up-front investment in the right primitives yields greater downstream speed and opportunity with AI

Propositions

explicitThe organisations moving fastest with AI are investing in better boundaries, not primarily in better models or more autonomous agents.conf: high
explicitcorroboratedInvesting in right-sized primitives — including repeatedly chunking context to the right size when working with AI — is what unlocks the biggest opportunities.conf: high
extends ←The Orchestrator's Tax · p7 — Gives a specific name and mechanism ('cognitive locality': tasks needing the same mental model should stay together) to the same underlying claim that right-sizing/chunking context correctly is what unlocks value when partitioning work for AI.
supports ←mattpocock/skills v1.1: does /wayfinder beat grill-with-docs? · p6 — 'Agent-sized chunks' is an instance of investing in right-sized primitives / chunking context to the right size when working with AI.
extends ←Stop Overengineering Your Agent Harness · p3 — Operationalizes the general 'right-sized primitives' thesis with a concrete two-axis rubric (action complexity x context complexity) specifically for sizing agent harnesses.
explicitThe same right-sizing and modularity discipline applies across three layers — human teams, the code base, and agent ecosystem access.conf: high
explicitRefactoring a large single-file codebase into smaller, more modular files improved LLM token usage and solution quality when implementing a new feature.conf: medium
supportsIt Ain't Broke: Why Software Fundamentals Matter More Than Ever · p11 — The hallway-track observation that refactoring a single-file codebase into modular files improved token usage and solution quality is concrete empirical support for Pocock's claim that deep, modular structure makes a codebase AI-friendly.
explicitThe question is no longer whether non-engineers will build software, but how much.conf: high
explicitPlatform, SRE, and operational teams should support non-engineer, vibe-coded software creation rather than try to remove or prevent it, because shadow IT is already happening.conf: high
implicitEach wave of democratised software creation — PaaS and cloud a decade ago, vibe-coding today — must be supported and governed rather than resisted.conf: medium
explicitBackend services and APIs should be built first, with consumer UIs as enhancements, and Agentic AI makes this API-first priority even more important.conf: high
explicitEven non-engineer users now depend on high-quality MCP access to their tools to maintain value, shifting user and vendor behaviour.conf: high
explicitAutomated remediation should remain an intentional, context-specific decision; AI's clear wins are in issue identification, context provision, and solution suggestion, not autonomous fixing.conf: high
explicitRemoving humans from the operational loop also removes organisational and product learning, because AI lacks an embodied mind and human-style learning.conf: high
explicitdevelopedWinning the AI gold rush requires deliberately investing in the growing maintenance burden that follows.conf: medium
extends ←When AI Writes Almost All Code, What Happens To Software Engineering? · p10 — Orosz's 'massive explosion in code... much more maintenance to be done' adds a concrete data point (30% change-failure-rate rise, doubled PR volume) to the other document's more abstract claim that winning the AI gold rush requires investing in the growing maintenance burden.
explicitOperations become far easier to automate and support at scale when actions are deterministic, scoped to specific scenarios, and tightly role-controlled.conf: high
explicitcorroboratedAI is changing who produces, consumes, and maintains software, but the importance of good engineering fundamentals — well-designed abstractions, clear interfaces, modular systems, and operational discipline — is not changing.conf: high
supportsIt Ain't Broke: Why Software Fundamentals Matter More Than Ever · p1 — Bangser's field-report thesis that engineering fundamentals matter more, not less, in the AI era independently corroborates Pocock's claim that software fundamentals matter more now than ever before.
supports ←When AI Writes Almost All Code, What Happens To Software Engineering? · p9 — Both make the article's central 'good news' claim — that good engineering fundamentals matter more, not less, as AI generates more code — independently and from different vantage points (personal practitioner essay vs. platform/SRE essay).
implicitcorroboratedAI amplifies both the payoff of good structure and the cost of bad structure, turning previously-optional engineering discipline into load-bearing infrastructure.conf: medium
supportsIt Ain't Broke: Why Software Fundamentals Matter More Than Ever · p4 — Bangser's implicit amplification premise — good structure raises the AI payoff, bad structure raises the cost — restates Pocock's claim that AI performs well in a good codebase and poorly in a bad one.
supports ←AI Enthusiasts Are in a Race Against Time, AI Skeptics Are in a Race Against Entropy · p10 — Same conclusion in different words: amplification turns previously-optional engineering discipline into load-bearing infrastructure.

Arguments

Good engineering fundamentals — right-sized boundaries, modular abstractions, clear interfaces, and operational discipline — matter more in the AI era, not less. strength: high

Explicit premises:

Investing in right-sized primitives unlocks the biggest opportunities when working with AI.
Refactoring a single-file codebase into modular files improved LLM token usage and solution quality.
Operations automate best when actions are deterministic, scoped, and role-controlled.
Even non-engineer users now depend on high-quality MCP/API access to their tools.

Implicit premises:

AI amplifies both the payoff of good structure and the cost of bad structure, turning good practice into load-bearing infrastructure.
Automated and agentic consumers are even less tolerant of poor boundaries than human consumers are.

Inferences:

Because structure now determines whether AI can work effectively and safely, fundamentals become the foundation that lets humans and AI build together sustainably.

Organisations should support and govern non-engineer software creation rather than try to restrict it. strength: medium

Explicit premises:

The question is no longer if non-engineers will build software but how much.
Shadow IT (now vibe-coded apps) is already happening and cannot be avoided.
Easy PaaS and cloud a decade ago put similar pressure and could not constrain builders.

Implicit premises:

Attempts to prevent democratised creation produce ungoverned shadow IT, which is riskier than supported, well-boundaried creation.
Tooling can be designed to be safely and coherently consumed by humans, non-engineers, and both deterministic and agentic automation.

Inferences:

Therefore platform, SRE, and operational teams should provide safe, efficient, API-first tooling for the new consumers rather than pretend they can be blocked.

Fully automating remediation by removing humans from the loop can hamper long-term harness and product improvement. strength: medium

Explicit premises:

AI lacks an embodied mind and human-style learning.
Removing humans from the loop also removes organisational and product learning.
AI's clear wins are in detection, context provision, and suggestion, whereas remediation needs intentional decisions.

Implicit premises:

Organisational and product learning is a necessary input to improving harnesses and products over time.
The short-term efficiency of removing humans can be outweighed by the long-term loss of learning.

Inferences:

So automated remediation should be an intentional, context-specific choice rather than a default end state.

Narratives

The author joined almost 70 people at the European Future of Software Engineering (FOSE) retreat hosted by Thoughtworks, operating under the Chatham House Rule, and offers this as her personal summary alongside links to other attendees' reflections.
→ Establishes the provenance and authority of the observations as a synthesis of a diverse, invitation-style gathering rather than a single opinion
In a hallway-track moment, an attendee refactored a large single-file codebase into more modular functions and files, then observed that token usage and solution quality improved substantially as file sizes became smaller and more targeted.
→ Serves as concrete 'proof' for the claim that modularity and right-sizing directly improve AI effectiveness
A decade ago, easy-to-deploy PaaS and cloud environments couldn't be constrained and forced organisations to either support the new tools or face shadow IT; the same pattern is recurring now with vibe-coded apps.
→ Historical analogy grounding the 'support, don't restrict' argument for the new wave of non-engineer builders
The day-2 'they build it, you run it' session opened by focusing on AI SRE and self-healing agents, but many participants cautioned that automated remediation still needs intentional decisions.
→ Dramatises the gold-rush-versus-maintenance tension and the human-in-the-loop caution about lost learning

Questions addressed

✅ What distinguishes the organisations moving fastest with AI?
Investment in better boundaries and right-sized primitives (for use, composition, and orchestration), not better models or more autonomous agents.
✅ Will non-engineers build software, and how should engineering teams respond?
Increasingly yes; platform, SRE, and operational teams should support and govern it via API-first, MCP-accessible tooling rather than try to prevent it.
✅ Should day-2 operations be handed to self-healing agents?
Detection, context, and suggestion are safe wins, but automated remediation should be an intentional decision because removing humans removes organisational learning.
✅ What stays constant as AI transforms software engineering?
Good engineering fundamentals — well-designed abstractions, clear interfaces, modular systems, and operational discipline — become the enabling foundation.

Gaps

incompleteThe evidence is anecdotal and constrained by the Chatham House Rule; the one quantified claim — that a modular refactor improved token usage and solution quality — is a single hallway-track data point with no magnitude, methodology, or generality.
Read next: Look for controlled studies on codebase modularity and file granularity versus LLM token cost and solution quality.
incompleteThe article asserts that removing humans from the loop removes organisational and product learning but does not specify the mechanism, nor how to preserve that learning while still automating parts of operations.
Read next: Read on the ironies of automation, joint cognitive systems, and how SRE teams learn from incidents while automating remediation.
uninformedSecurity and governance of vibe-coded shadow IT is acknowledged as inevitable, but the article offers no concrete model for making it safe — only 'safety and efficiency' as a stated goal.
Read next: Read on internal agent governance, policy-as-code, guardrails, and shadow-AI governance patterns.
closed byFragments: July 21 — Supplies concrete mechanisms for making vibe-coded shadow IT safer where that article offered none: putting vibe-coded apps in separate infrastructure with deterministic data-access controls to defuse the lethal trifecta, running board-level threat-modeling sessions, and building an internal platform to formalize and control shadow tools without eliminating their usefulness.
incomplete'Right-sizing' is presented as clearly beneficial, but the author concedes many are 'still figuring out which primitives they are and how best to invest in them' — the piece provides no heuristic for finding the right boundary or context size.
Read next: Read on modularity heuristics such as Ousterhout's deep modules, and on context-window budgeting for LLMs.

AI Is Changing Software Engineering. The Fundamentals Still Matter.

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents