The Methodology That Emerged

Part 2 of the AI Development Revolution. The early days worked, but they were chaos. This is how the chaos turned into something I could repeat.

From chaos to a system

After the first stretch of working this way, I kept running into the same question. How do you make something repeatable when it still feels like luck?

The early days were productive and unsustainable at the same time. The sessions ran long and left me wrung out. I could not predict which mornings would flow and which would hit a wall. Every new project started from nothing, and I rebuilt the same context by hand each time.

The methodologies I already knew did not survive contact with this. Agile broke once the work moved faster than I could check it. Waterfall fell apart the moment a single AI suggestion made my plan from that morning irrelevant. Letting the AI drive on its own produced code that was clean and pointed in the wrong direction.

What finally worked came out of being tired enough to stop fighting it. The method had to be built with the AI, not handed down to it. This was the same question I had circled in "On Intelligence": what does it actually mean to work alongside a mind that is put together so differently from mine?

After a few months of strain, a shape showed up. Not a trick for prompting better. A different way of working, built for how heavy this kind of collaboration actually is on a person.

The AAA framework

I ended up calling it AAA, for autonomous, adaptive, agile. The names came after the practice, not before it.

Autonomous

Most AI assistance treats the model as a smarter autocomplete. I started treating it as a partner with its own initiative, and that changed what the sessions felt like.

It also cost more attention, not less. Letting the AI hold project state across a session sounds clean until context drifts and a project restarts for the third time, and you learn to write prompts that keep it anchored. Letting it take initiative is good until two in the morning when you cannot tell a real idea from scope creep. When it tried to recover from its own errors, it often introduced new ones, and I had to understand how it was reasoning to catch them.

So a session stopped being "write a function." It became setting the context, holding the strategy steady, checking the technical work as it came, and noting what to keep for next time. Every one of those autonomous sessions asked for my full attention the whole way through. It was tiring. The results were also real.

Adaptive

The framework changes as I use it. Something that works for infrastructure gets reshaped for content, then reshaped again for a business app. When a pattern works, I write it down so I am not rediscovering it next month. When something fails, I look at why before moving on, so the same failure does not come back. The method gets a little smarter each time I apply it somewhere new.

Agile

Regular agile runs on sprints. This runs on sessions, often several in a day, and the pace is hard on the head.

Restoring context takes real time, because I am rebuilding a mental model of how several systems fit together. The active work means constant decisions with no gaps between them. My focus starts slipping around ninety minutes, and the quality of my judgment drops off after two hours. I have to take breaks even when the work is flowing, because the alternative is making bad calls without noticing.

Mornings are my best hours for this. Afternoons take more out of me for the same output. Evenings are usually a loss, since the day's decisions have already worn me down, and after a heavy run of days I need a full day off to come back.

The body gets used to the rhythm. The mind still needs looking after.

Continuous intelligence

The real shift was not continuous integration. It was that each session made the next one better. Getting there asked for everything I had.

The first sessions were mostly overload. I spent most of my time checking and fixing what the AI suggested, and evaluating every recommendation left me drained. For a while it was more work than just writing the code myself.

Then it started anticipating what I needed. I learned to tell quickly when a suggestion was aimed at the goal and when it had wandered off. The first session where it saved me more time than it cost stood out clearly when it happened.

After that came something closer to flow. It held context across files and offered improvements I would not have reached for, and I stopped managing it and started working with it.

Eventually it felt like the two of us could do things neither could alone. The conversations turned into real arguments about trade-offs. From my notes at the time:

Session 73 today. The AI didn't just understand what I needed, it suggested approaches I hadn't considered, caught security issues in my thinking, optimized for performance factors I'd forgotten. This isn't tool usage anymore, it's genuine strategic collaboration. But it took 72 sessions of intense cognitive work to get here.

The cost up front was real. Early weeks meant longer days for less to show, and the strain showed up in my body before it showed up in the work. But the patterns did come, the flow states did become possible, and a rhythm I could actually keep arrived in the end.

I wrote about this kind of patience in "Finding Balance in Motion": a new way of working takes a while to settle, and rushing it does not help.

Digital 5S

The old 5S idea from the shop floor needed reworking for this. Sort turned into managing context, drawing clear boundaries and keeping the structure documented. Set in order turned into standardizing how I prompt and how I lay out a session. Shine became steady review and refactoring. Standardize meant writing down the patterns that worked so I could reuse them. Sustain meant keeping the whole thing evolving instead of letting it freeze.

It is a simple idea to describe and a demanding one to hold to.

Four repositories, four lessons

The real test was running this across projects that had nothing in common.

Infrastructure pushed the hardest. Complex AWS setups with stacks that depended on each other, full redesigns when the AI built circular dependencies, long debugging stretches untangling permissions. It took the most sustained effort of anything I did. But once the AI finally held the architecture in view, the work changed character entirely.

Content management asked for careful quality control. Hundreds of articles to process while keeping each voice intact, several OCR approaches before one caught my handwriting, pipeline rewrites when the first approach would not scale. It needed constant editorial attention. But the AI did learn to clean things up without flattening them.

Business applications wanted a balance between the creative and the technical. Retro looks over modern function, design passes thrown out when a good-looking suggestion ran slow, debugging on weekends. The judgment calls were dense. But things that would have taken months were production-ready in days.

Game development showed me the more advanced patterns. Designing around interfaces instead of fighting the usual architecture, separating metadata so the AI could work with it cleanly, shaping the whole structure to make collaboration easier. That was the method reaching something like maturity.

Each domain forced a change. Infrastructure patterns did not carry over to content. Content insights needed rework for the business apps. Game development surfaced patterns that, looking back, explained things I had done earlier without understanding them. The method grew by being used.

The results

The numbers tell part of it. Development cycles sped up past what I would have believed. Debugging time dropped sharply. First-attempt success rates climbed higher than seemed reasonable, and there were no production defects across any of the repositories.

The measurements that mattered most were not in the code, though. They were in how the collaboration kept getting better, how knowledge moved between domains, how the method sharpened with use, and how the advanced patterns only became visible in hindsight.

What changed was not only the code. It was what I was capable of.

A normal day

Mornings go to infrastructure. Restore the context, work with the AI, check the quality, write down what worked. That is when my head is clearest for hard architecture.

Afternoons move to content. Tune the pipeline, improve articles, review the output, carry lessons between sessions. The creative work fits here, after the precise technical thinking is mostly spent.

Evenings, on the good days, take on business features. Web work, user experience, integration testing. On most days the accumulated load just asks for rest instead, and I let it.

What the old methods missed

Agile assumes a team of people. Waterfall assumes you can pin down the requirements up front. DevOps keeps its eye on the pipeline.

AAA assumes a person and an AI working together, with a learning curve that keeps steepening. The real change underneath it is moving from managing human limits to making the most of what the two of us can do together. From steady, predictable speed to capability that keeps building. From a fixed process to one that changes as it goes.

What the learning curve is actually like

None of this happens on day one. The first weeks are basic assistance and old habits of thought. Pattern recognition shows up slowly. The flow states come with practice. The real partnership takes months of mental investment, and the refinement never quite stops.

The curve is steep, and the payoff keeps compounding the longer you stay on it.

Where it gets hard

Context fatigue sets in when the AI loses the thread over a long session. Quality control gets overwhelming when the speed outruns my ability to check the work. And the method drifts when things go well enough that I get careless and stop following it.

Each of those taught me something, and each fix made the next stretch a little steadier.

What's next

The AAA framework proved a person and an AI working together could reach results I had not thought possible. But a method is a starting point, not a finish line.

Next I take this and point it at building enterprise-grade AWS infrastructure in a fraction of the usual time. That is Part 3.

Next: Part 3: Enterprise Infrastructure →

Related Reflections:

Vibe Coding with AI - Early poetic reflections on AI partnership
I AM AI SLOP: Confessions from the Forge - On owning AI collaboration completely

Series Navigation: