DEV Community: Brent Fowler

The AI Context Efficiency Experiment: Why Architecture Beat Context Size

Brent Fowler — Mon, 01 Jun 2026 12:34:32 +0000

Figure 1: The experiment's central turn: context, compaction, locality, governance, recovery, and conclusion.

The Question Was About Context

I thought I was running a context experiment.

I wasn't.

I just didn't know it yet.

The experiment started with a question that seemed straightforward.

It turned out to be an incomplete question.

What actually drives AI-assisted software development efficiency?

That is the question most engineers eventually ask after using AI coding tools for serious work. At first, the obvious variables all live inside the session. How much context is available? How quickly does it burn? What happens after compaction? Does the agent remember enough to keep working? Can a long-running session survive handoffs, summaries, and interruptions?

Those were the first things worth watching. The work was happening in two real repositories, not in a synthetic benchmark. Financial Portfolio Agent (FPA) and Market Intelligence Lab (MIL) had different responsibilities, real validation requirements, and established repository boundaries. FPA handled household execution realism, portfolio intelligence, survivability positioning, and deterministic financial decision support. MIL handled systemic context, macro intelligence, evidence quality, and source lineage governance.

The early mental model was simple: context is fuel. If the session burns too much of it, efficiency drops. If compaction preserves enough state, efficiency survives.

That model was not wrong. It was just incomplete.

The experiment eventually produced a recovered dataset with 47 master observations: 14 context observations, 13 compaction events, 6 feature batch observations, 7 model observations, and 12 recovery observations. That made the story evidence-backed early. It was not just a feeling that the work had changed shape. There was enough telemetry to trace where the explanation started to move.

Figure 2: Recovered observation counts across context, compaction, feature batch, model, and recovery logs.

By the end of the experiment, the strongest preserved signal was not context size. It was architectural locality. The surprising result was not that compaction worked. The surprising result was that the system became easier for AI to work in when the work had a clear architectural home.

The experiment started as a context study. It ended as an architecture study.

The First Clue Was The Burn Pattern

The first useful evidence was numerical. Context values were preserved across the experiment, and later reconstructed into a dataset.

FPA had recovered context observations including 26K, 66K, 100K, 133K, 161K, 194K, and 219K. MIL had recovered observations including 38K, 50K, 125K, 153K, 166K, 179K, 192K, 205K, 217K, 228K, and 240K. MIL also preserved a cleaner Generation 2 rebuild sequence that ran from 42.0K through 205.0K.

At a glance, those numbers look like the whole story. The context grows. The session gets heavy. Compaction resets it. Work continues.

But the data had to be handled carefully. The recovered FPA values were observed markers, not a complete time series. Some MIL values were ordered, but not all of them were. Exact timestamps were not preserved for every point. The dataset correctly keeps unknown values as UNKNOWN instead of pretending that a partial transcript is a complete measurement system.

That distinction matters. Clean charts can lie when the source data is incomplete. The right move was to preserve the observations as observations: enough to tell a technical story, not enough to claim a complete benchmark.

Figure 3: Recovered context observations. The MIL Generation 2 sequence is ordered; FPA values are preserved as observed markers.

The duration data had the same character. The transcript preserved observed work times from 1m 00s through 6m 27s, but not a full model-to-duration map for every feature. Again, that made the data useful telemetry, not a controlled comparison.

Then The Dataset Had To Be Rebuilt

One of the most important editorial discoveries came before the main technical one: the archive had preserved findings, but not all of the observations behind them.

That forced a reconstruction pass. The transcript became a primary source. The goal was not to summarize it. The goal was to recover telemetry: context values, compaction events, model observations, feature batch observations, duration observations, and recovery events.

The scorecard above is the result of that pass. It moved the work from memory to a defensible dataset.

These are recovered observations, not complete experiment totals. That boundary is the reason the dataset is useful: it says what was preserved and what was not.

Some of the most valuable values were transcript-only. FPA preserved a compaction transition from 219K to 26.7K. MIL preserved one from 240K to 38K. MIL also preserved a Generation 2 rebuild table from 42.0K through 205.0K. The archive preserved the broader finding that compaction supported continuity, but the transcript gave the story numbers.

That reconstruction changed the tone of the experiment. It made the next turn harder to dismiss.

Compaction Worked

Compaction passed an important test.

FPA moved from 219K to 26.7K. MIL moved from 240K to 38K. MIL also preserved a related compaction shrink observation of 239K -> 42K, followed by a rebuild span of 42K -> 205K.

That is a real continuity story. A long-running AI development process can shed a large amount of context and still keep going if enough operational state lives outside the chat. Repository artifacts, bootstrap notes, governance records, validation commands, and durable documentation all matter.

Figure 5: Compaction visibly reset context size in both repositories, while exact compaction counts remain unknown.

But this is where the experiment started to turn.

If compaction were the whole explanation, then the main lesson would be operational: summarize better, compact cleanly, restart carefully. Those are good practices, but they did not explain the strongest throughput signal in the archive.

Compaction helped the work survive. It was not preserved as the dominant throughput driver.

That distinction prevented the wrong lesson. The experiment was not saying, “The bigger the context window, the faster the work.” It was not saying, “Compaction is the answer.” Compaction created room to continue, but it did not explain why some work kept feeling cheaper to understand.

The work stayed efficient when it stayed local.

The Turn: Locality Became The Signal

The word locality became the center of the experiment because it explained what context size alone could not.

The turning point was subtle. There was no single feature where the experiment suddenly announced a new theory. Instead, the same pattern kept showing up in the work. Adjacent features were easier to complete when they stayed near previous features. Review was easier when the files, tests, and concepts were already part of the active working set. Validation stayed narrower when the feature did not cross into portfolio logic, report contracts, or runtime behavior.

That pattern was more interesting than the raw context number. A session at a high context count could still move well if the next task belonged to the same architectural neighborhood. A freshly compacted session could still struggle if the next task required reloading too many unrelated domains. The amount of context available mattered, but the shape of the work mattered more.

When work stayed inside a coherent architectural area, the AI agent had less to rediscover. The relevant files were close together. The concepts were reused. The tests were predictable. The risk surface was bounded. The reviewer did not have to reload the entire system to understand whether the change belonged.

In FPA, the clearest example was Pipeline Metadata. Repeated work clustered around a small set of files:

app/pipeline/registry.py
app/pipeline/planner.py
app/pipeline/runner.py
tests/test_pipeline_registry.py
tests/test_pipeline_planner.py
tests/test_pipeline_runner.py

That cluster supported features around discoverability, ownership visibility, dependency visibility, output visibility, lineage visibility, category inspection, and boundary inspection. Those features were useful, but they did not require report redesign, CSV schema changes, portfolio logic changes, or runtime execution redesign.

This is the architectural lesson: an AI agent is not only spending context on code. It is spending context on uncertainty.

When ownership is unclear, context burn rises. When the validation path is unknown, context burn rises. When a feature crosses multiple conceptual boundaries, context burn rises. When the work sits inside a mature locality cluster, the agent can reuse the same mental map.

The archive does not prove a numeric locality multiplier. It does not show that locality reduced token burn by a specific percentage. The claim is more careful: within the preserved experiment record, architectural locality appeared to be the dominant efficiency multiplier.

Figure 6: The context question turned into an architectural locality finding.

That was the point where the experiment stopped being mostly about context windows.

It became about codebase shape.

Bounded Contexts Made The Work Cheaper To Think About

Once locality was visible, the next question was obvious: what made some areas local enough to keep producing leverage?

The answer was bounded contexts.

Pipeline Metadata was the clearest FPA case. It had coherent ownership, deterministic read-only query behavior, stable adjacency across feature batches, and a clear separation from pipeline execution. It made the system easier to inspect without redesigning how the system ran.

That difference is subtle but important. A bounded context is not just a directory. It is a place where related questions can be answered without pulling the whole system into view.

Pipeline Metadata answered questions like:

What owns this output?
What depends on this category?
Which modules participate in this pipeline area?
Which outputs are shared?
What downstream categories are affected?

Each new inspection feature made later inspection features easier. The work compounded because it stayed near its own prior work.

The experiment record also identifies Export Quality Hardening as a bounded context in MIL. The FPA archive does not contain enough MIL internal evidence to analyze that workstream at the same level of detail, so that boundary needs to stay explicit. The experiment record can say Export Quality Hardening emerged as a bounded context. FPA-local evidence cannot prove MIL internal structure.

The bigger lesson is that bounded contexts changed the economics of AI-assisted development. The work became easier to start, easier to validate, easier to review, and easier to resume after interruption.

That is a different kind of efficiency than raw speed. It is structural efficiency.

Governance Was Not Paperwork

Once the work had a shape, the repository needed a way to preserve that shape.

That is where governance entered the story.

FPA formalized Feature Tracking Governance. Features were no longer just completed and forgotten. They were classified by category, complexity, burn, leverage, locality, architectural impact, and reassessment value. Work was organized into batches of four completed features before reassessment.

That sounds procedural until a long-running AI session is involved. Then it becomes memory infrastructure.

The governance artifacts made the experiment less dependent on conversational memory. They gave future sessions a way to recover what had happened, why it mattered, and where the next work should stay localized. They also helped preserve the difference between confirmed findings, strong evidence, and open questions.

The smcpp lifecycle served a similar role. Stage, commit, push, PR, merge, and prune became a named operational convention. In ordinary solo development, that might look like hygiene. In this experiment, it became part of survivability.

The confirmed finding was that governance and discoverability improvements compounded future leverage. That is exactly what happened when Pipeline Metadata kept accumulating inspection surfaces. The system became more legible as work progressed.

Figure 7: The evidence tiers are part of the result. Confirmed findings, strong evidence, and open questions stay separate.

The Model Result Was Interesting For A Different Reason

The experiment observed GPT-5.5 Reasoning Medium and GPT-5.4 Reasoning Low.

The tempting conclusion would be to turn that into a model horse race. That would be the wrong reading.

The preserved record does not prove that GPT-5.4 Low was more efficient than GPT-5.5 Medium. That specific claim was explicitly rejected as unproven. There was no benchmark-grade dataset with complete token usage, latency, defect rate, review burden, and quality measurements across both models.

The useful observation is narrower and more architectural: lower reasoning settings performed better than expected inside mature bounded contexts.

That is worth paying attention to. If a repository is shaped well enough, the model may need less reasoning power to make useful progress. Not because the task is trivial, but because the environment has fewer unresolved questions. Ownership is clearer. Tests are closer. Patterns are established. The blast radius is smaller.

This does not prove model equivalence. It suggests a better research question:

What repository conditions make lower reasoning settings viable?

That question is more useful to engineering leaders than a generic model ranking. It points back to architecture.

Then The Repository Broke

The experiment also included a power-loss Git corruption event during active development.

By then, the experiment had already moved from context to architecture and governance. The outage tested whether that shift mattered under pressure.

The recovery narrative preserved non-destructive repair, branch/ref recovery, working-tree preservation, validation rerun, PR merge, and cleanup. MIL recovery status preserved repository healthy, expected branch, remote aligned, working tree clean, validation passed, and API surface restored. The broader experiment record preserves successful recovery of both repositories.

Figure 8: The power-loss event turned process discipline into a real recovery test.

This mattered because the outage tested the experiment’s claims under pressure. Governance is easiest to dismiss before something goes wrong. After corruption, the value of recoverable state, validation discipline, branch hygiene, and bounded work becomes much less theoretical.

The archive does not preserve exact elapsed recovery time. It also does not prove which governance element mattered most. Branch policy, validation policy, bootstrap artifacts, lifecycle discipline, and bounded-context locality may all have contributed.

The confirmed finding is narrower: strong process discipline improved disaster recovery, and recovery success depended heavily on repository governance and validation discipline.

That is enough.

What The Experiment Actually Supports

The most important thing about this experiment is not the most dramatic story. It is the evidence discipline.

Confirmed findings:

Architectural locality appeared to be the dominant efficiency multiplier.
Governance and discoverability improvements compounded future leverage.
Feature Tracking Governance became necessary.
Pipeline Metadata emerged as a bounded context.
Strong process discipline improved disaster recovery.
Recovery success depended heavily on repository governance and validation discipline.

Strong evidence:

Low-to-medium burn work is more likely inside mature locality clusters.
Repeated Pipeline Metadata features produced compounding leverage.
Compaction was more valuable for continuity than throughput.
Lower reasoning settings became more viable inside mature bounded contexts.

Open questions:

How much gain came from locality versus familiarity?
What exact differences existed between GPT-5.5 Reasoning Medium and GPT-5.4 Reasoning Low?
When should Pipeline Metadata be extracted?
How structurally similar was MIL Export Quality Hardening to FPA Pipeline Metadata?
What exact context-window sizes, timestamps, and model mappings were not preserved?
Which governance element mattered most during recovery?

Figure 9: The final claims are strongest when the article keeps evidence tiers visible.

This separation keeps the story honest. It lets the confirmed findings stay strong because they are not carrying unsupported claims.

The Lesson For Engineering Leaders

The practical lesson is not “buy more context.” It is not “compact harder.” It is not “use the biggest model for everything.”

The lesson is that AI-assisted development efficiency depends heavily on the shape of the system around the model.

A repository that is local, discoverable, governed, and validated gives the agent less ambiguity to resolve. It turns memory into artifacts. It makes compaction survivable because operational truth is not trapped in the chat. It makes lower reasoning settings more plausible because the problem surface is better bounded. It makes recovery more realistic because the work has structure outside the session.

For senior engineers and architects, the implication is direct: if you want better AI-assisted development, do not only tune prompts. Tune the architecture.

Create bounded contexts. Keep ownership visible. Make dependencies inspectable. Preserve validation paths. Record feature batches. Separate confirmed findings from strong evidence. Treat governance as part of the engineering system, not as administrative residue.

The most interesting outcome wasn't discovering that context mattered.

Most engineers already suspected that.

The interesting outcome was discovering that architecture appeared to matter more.

The repositories that became easier to understand, validate, inspect, and recover also became easier for AI to work within.

That observation may ultimately be more valuable than any individual context-window measurement.

The experiment began with context growth, context burn, compaction, and survivability. Those were real concerns. They still matter.

But the deeper result was that context efficiency appeared to be downstream of architectural clarity.

The experiment started as a context study.

It ended as an architecture study.

If you're experimenting with AI-assisted development workflows, I'd be interested in hearing what you've observed.

Have context size, model choice, architecture, governance, or something else had the biggest impact on your results?

Building a Practical Home Lab Starter Kit for Network Engineers

Brent Fowler — Fri, 22 May 2026 03:24:00 +0000

A lot of network engineers learn their best lessons in home labs, especially the lessons that do not fit neatly into certification tracks or production change windows.

They are also where things can get messy quickly.

One folder has topology notes. Another has Ansible experiments. A diagram lives somewhere else.

Remote access was configured once and then forgotten. Screenshots include details that should not be shared publicly.

The lab works, but it is hard to rebuild, explain, or safely publish.

I built the Practical Home Lab Starter Kit to make that problem smaller and more repeatable.

The repo is here:

Practical Home Lab Starter Kit

This is not a production network design or a claim that there is one right way to build a lab.

It is a practical starting point for learning, documenting, validating, and sharing a Linux-based network engineering lab with fewer loose ends.

Why I Built It

I am a network engineer focused on Linux infrastructure, automation, operational workflows, and continuous learning.

A lot of my best learning happens when I build something, break it in a controlled way, document what happened, and make the next pass cleaner.

That is the mindset behind this project.

I enjoy exploring new tools and workflows, but I also want the result to be understandable later. A lab should help you learn today without becoming a mystery system six months from now.

This starter kit came from a simple observation: many people want to learn network automation, Linux, and lab security, but the first barrier is not always the technology itself.

Sometimes the barrier is structure.

Questions come up early:

What should the Linux host look like?
Where should the topology be documented?
How should GNS3, management access, and Ansible fit together?
What should be validated before changing anything?
What is safe to show publicly?
How do I keep the lab useful without turning it into a fragile one-off setup?

The goal of this repo is to give those questions a starting framework.

The Problem It Solves

A useful home lab should be more than a place where commands happen.

It should help you practice habits that transfer into real engineering work:

documenting the system before it grows too large to explain
separating management access from lab experimentation
using Linux as a stable operations base
validating before automating
treating Ansible as a repeatable workflow tool, not just a configuration hammer
keeping public examples sanitized
making diagrams and checklists part of the build process

That is the value I want this project to provide to the broader community.

Whether someone is new to network engineering, learning Linux administration, experimenting with GNS3, or trying to get more comfortable with Ansible, the repo should offer a clear path.

It should not assume a large budget or a production environment.

What The Repo Includes

The starter kit includes a public foundation for a small Linux-based network engineering lab, grouped around a few practical areas:

Lab foundation: Linux host setup guidance, GNS3 setup notes, and example topology documentation
Security baseline: remote access guidance, SSH hardening notes, and UFW firewall examples
Automation workflow: sanitized Ansible inventory examples and read-only validation playbooks
Documentation assets: Mermaid diagrams, technical diagram references, and screenshot/video workflow notes
Publishing guardrails: local validation scripts plus publication and redaction checklists

The intent is to keep the repo useful even before someone has built every part of the lab.

You can read through the architecture, copy the sanitized templates, adapt the checklists, and use the validation approach in your own environment.

Architecture At A High Level

The reference architecture is intentionally small:

Remote admin workstation
  |
  | SSH over trusted local network or private access path
  v
Linux lab host
  |-- GNS3 server or GNS3 support role
  |-- Ansible control workflow
  |-- UFW firewall baseline
  |-- SSH administration
  |
  +-- Private management network
        |-- virtual router
        |-- virtual switch
        |-- additional lab nodes

The Linux host is the anchor. GNS3 provides the network devices.
Ansible gives you a repeatable way to validate and inspect the lab. Remote access is treated as something to design carefully, not something to bolt on casually.

The idea is to keep the operational workflow understandable before scaling the topology. One virtual router, one virtual switch, one management network, and a few read-only Ansible checks can teach a lot.

After that works, you can expand with more vendors, routing protocols, backup workflows, monitoring, or security tooling.
That is intentional. The first version is small because understandable beats complex early on, and repeatable beats large.

Once the baseline is clear, scaling the lab becomes a deliberate engineering choice instead of a pile of accidental dependencies.

Visual References

The README includes a simple overview image for the project:

The repo also includes sanitized technical diagram references:

lab topology layout
remote access flow
Ansible control workflow
validation and documentation flow

There is also a local validation screenshot in the repo that shows the basic guardrail workflow:

Beginner-Friendly Build Path

If you are newer to this kind of lab, I would not start by trying to automate everything.

Security should not be an afterthought.

Even in a home lab, remote access, firewall policy, user access, and public screenshots should be considered early.

I would start here:

Build or choose a Linux lab host.
Document the host role, network layout, and intended access model.
Apply a basic security baseline before exposing or expanding services:
- update the host
- review local users
- configure SSH intentionally
- define initial UFW or firewall rules
- avoid broad remote access
Install and test GNS3 with a small local topology.
Confirm management reachability manually.
Add a sanitized Ansible inventory.
Run read-only Ansible checks.
Capture diagrams and screenshots only after reviewing them for private details.

That sequence keeps the lab understandable.

It also helps avoid a common failure mode: troubleshooting Linux, GNS3, SSH, firewall rules, inventory files, credentials, network reachability, and automation logic all at the same time.

Validation Before Automation

One of the strongest habits I want this repo to reinforce is validation-first work.

Before publishing changes or sharing examples, the repo uses basic checks:

./scripts/validate.sh
./scripts/redaction-check.sh
bash -n scripts/*.sh
git diff --check

These checks are intentionally lightweight.

They do not replace human review, but they create a repeatable baseline:

required files exist
key documentation terms are present
shell scripts parse correctly
obvious sensitive patterns are flagged
whitespace issues are caught before commit

For a public learning repo, that kind of guardrail matters.

It also makes the project easier for other people to trust, review, and adapt.

Security And Sanitization Notes

The project is designed to stay sanitized.

Public examples should not include secrets, tokens, private keys, pre-shared keys, real usernames, hostnames, public IP addresses, account data, or private environment details.

The examples use placeholder values like these:

lab-host
lab-r1
lab-sw1
labadmin
10.10.10.0/24
lab.example

This makes the repo easier to share and discuss.

It also encourages a habit that matters outside of home labs: separate useful technical explanation from private operational detail.

Who This Might Help

I built this with network engineers in mind, but I think it can help a wider group:

students building their first serious lab
help desk or systems engineers moving toward networking
network engineers learning Linux and automation
Linux admins who want to understand network lab workflows
security learners who need a controlled place to test tools
anyone trying to document a home lab without exposing private details

The common thread is not job title.

It is the desire to build something practical, repeatable, and safe to explain.

What This Is Not

This is not a production blueprint.

It is not a full enterprise lab.

It is not a promise that one set of tools fits every environment.

It is a starting kit: opinionated enough to be useful, but small enough to adapt.

If you want to explore the project, the repo is available here:

Practical Home Lab Starter Kit

Feedback is welcome. I would especially like to hear from people who are building or improving their own labs:

What would make a starter kit like this more useful?
Which parts of home lab documentation are hardest to keep current?
When you build a lab, do you start with diagrams, checklists, scripts, or hands-on testing?
What security baseline do you apply before enabling remote access?
What would help someone learning Linux, GNS3, Ansible, or remote access for the first time?

My goal is for this to become a practical community resource: useful for beginners, still relevant for working engineers, and careful about security from the start.

If you have built something similar, I would be interested in what worked, what did not, and what you wish you had documented earlier.