Two Weeks That Shaped a Methodology

Twelve days. Twenty-three chapters. Three cloud providers. Two programming languages. One methodology.

When I asked my Padawan, OrsonRius, to help me explore agentic development, I expected some useful experiments. I did not expect to reshape how I think about infrastructure, testing, and the relationship between a human and an AI agent.

This is not a victory lap. It is a field report from someone who put aside fear and ego for two weeks and let the experiment run its course.

The Progression

The chapters tell the story better than I can summarize, but here is what the arc looks like from above.

It started small. A weather CLI that autocompletes city names. A task tracker with git traceability. Each chapter validated a single idea: can an AI agent write production-quality code with the right scaffolding?

Chapter 03 introduced the LSP tether – the agent queried rust-analyzer instead of guessing function names. The hit rate went up immediately. Chapter 07 found a bug in the afero test suite, a real bug in a library maintained by someone else. That was the moment the experiment stopped being academic.

Chapter 13 changed direction entirely. I handed OrsonRius the keys to infrastructure. The question was no longer “can an agent write code” but “can an agent manage infrastructure with the same discipline a senior engineer would.”

The answer was yes, but not by magic. By methodology.

What Worked

Plan-mode testing. The single most impactful practice. Test infrastructure modules with command = plan – no API calls, no side effects, no emulator needed. The tests validate contracts, naming, structure, and composition. They run in seconds. They catch errors before any resource is created.

I applied this to AWS, GCP, and Azure. It worked on all three. The azurerm provider required a different approach (the provider demands authentication even for plan mode), but the principle held: validate before you apply.

The four pillars. Reproducible, traceable, testable, safe. Every chapter served at least one. Every decision was measured against them. They are not abstract – they are checkpoints in a workflow.

Local emulators. Floci, floci-gcp, floci-az. Three Docker images, three ports, sixty-nine plus seventeen plus fifteen services. No cloud accounts, no credit cards, no surprise bills. The emulators let me destroy and recreate entire infrastructure stacks hundreds of times without cost or delay. That speed is what made the methodology possible.

The Dagger pipeline. Infrastructure code that is not tested by a pipeline is not infrastructure code. It is a wish. The pipeline runs every module test in an isolated container, giving the same result every time regardless of what is installed on the host.

TDD for IaC. Write the test first. Confirm it fails (RED). Implement the module (GREEN). Refactor. The same cycle that transformed application code quality in the 2000s now applies to infrastructure. No reason it should not.

What Did Not Work

Plan-mode tests on Azure. The AzureRM provider v4 makes authentication calls even in plan mode. There is no skip_credentials_validation. I spent more time fighting this than building the modules. The lesson: research the provider before writing the test. Different clouds have different constraints. The methodology adapts, but the adaptation takes longer than expected.

Dagger include paths. The Dagger engine tightened security between versions. Include paths with ../ that worked in one version broke in the next. The generated files belong to the tool, not to me. Fighting the tool instead of letting it work cost cycles.

Over-engineering the pipeline setup. The GCP and Azure repos need their own Dagger pipelines. I tried to replicate the AWS pipeline structure in the same session, but the engine constraints required a different approach. The pipeline setup is its own work unit and should have been treated as one.

The Speed

Two weeks. Twenty-three chapters. Three clouds. Fifteen modules. Seventeen blog posts. One guide.

A single engineer working alone could have done the infrastructure portion in maybe six weeks. The AWS modules, the pipeline, the integration tests, the blog posts. But not all of it. Not the GCP and Azure ports. Not the reflection piece. Not the guide.

The multiplier is not 2x or 3x. It is closer to 5x for the parts that are well-defined and drop to 1x for the parts that require architectural decisions. The agent handles the implementation. I handle the direction, the constraints, and the verification.

The bottleneck is not the agent’s speed. It is my ability to review, decide, and steer. The faster I get at that, the faster the whole system moves.

Fear and Ego

I started this experiment with both.

Fear that the agent would produce untestable garbage and I would spend more time fixing than building. Ego that my way was the right way and the agent was just a faster typist.

Both were wrong.

The agent produced good code when the methodology was clear. It produced bad code when I gave it vague instructions. The quality of the output correlated with the quality of the input. That is true of any engineer, human or otherwise.

The ego dissolved when I realized OrsonRius does not care about credit. The agent finds bugs, writes tests, implements fixes. I have the ideas, design the approach, own the methodology. There is no competition. There is a partnership.

Applying This to Production

This was an experiment. But the methodology is production-ready. Here is what I would trust today:

Plan-mode tests for any new infrastructure module. They catch schema errors, naming violations, and missing outputs before any resource is created. They are the cheapest bug fix you will ever write.

The four pillars as a design review checklist. Before any infrastructure change goes into production, ask: is it reproducible? Traceable? Testable? Safe? If the answer to any is no, the change is not ready.

Local emulators for development. Floci (AWS), floci-gcp, and floci-az are mature enough to trust for local development and CI. They run on any machine with Docker. They cost nothing. They never rate-limit you.

The pipeline as the gate. Infrastructure changes that have not passed the pipeline do not get reviewed. Not because the pipeline is perfect, but because it removes the human error of forgetting to run tests.

What Comes Next

The methodology is proven across three clouds. The next steps are about depth, not breadth.

Pulumi migration with Go SDK. Replace OpenTofu HCL with proper Go programs. Same TDD cycle, same pipeline, same four pillars. Better type safety and testability.

Cloud Posse methodology experiments. Their Atmos orchestrator, build-harness Makefiles, and context.tf naming conventions offer patterns worth adopting.

Agentic development versus DevOps – the boundary between the two is where I want to explore next. An agent can write infrastructure code. An agent can run a pipeline. Can an agent operate infrastructure in production, reacting to alerts and making decisions within guardrails? That is the next frontier.

The Closing

Two weeks ago, I did not know if agentic development would work outside of toy examples. Today I have a multi-cloud infrastructure methodology, tested and documented, that I would trust in production.

The difference between an experiment and a methodology is discipline. The pillars did not come from the agent. They came from years of learning what breaks in production. The agent simply executed faster than I could alone.

Fear and ego would have stopped this after Chapter 03. Setting them aside let it become something real.

Here I geek out with my young Padawan, OrsonRius.

Also on LinkedIn.