Experience report · May 23, 2026

Knowing and living are not the same thing

I had watched the videos. I had followed the discussions about spec-first development, structured thinking before writing code, the discipline of making decisions explicit and traceable. Intellectually, I agreed. Enthusiastically, even.

And then a developer I know showed me how he worked with AI — without calling it anything, without labeling it a methodology or a framework. He just did it. Skills to orient the agent. Templates for recurring artifacts. A clean separation between ideation, analysis, design, and implementation. Nothing complex. Nothing over-engineered. Just a clear, repeatable practice.

I was floored. Not because it was sophisticated. Because it was right. And because I immediately recognized the gap: I had understood the principle. I had never truly lived it.

The hat I had been missing

A previous article on this site traces a path that many developers have walked over the past year: using AI first as a code generator, then as an analyst, then gradually as a product vision partner. Each stage was a genuine elevation. Each one changed how the collaboration worked.

But watching my friend, I saw a stage I had not named. Not the analyst. Not the architect. The methodologist — the person who designs and maintains the process through which all the other roles operate.

Once I saw it, I could not unsee it. And the moment I decided to put on that hat, things started moving in a direction I had not anticipated.

Putting it into practice: the first real test

Building the methodology was itself a joy. Skills, templates, artifact conventions, naming schemes, workflow rules. Each piece fit together with an intellectual pleasure that is hard to describe. The design emerged from dialogue — shaped by the videos I had watched, those conversations, and an enormous amount of back-and-forth with my AI partner.

Then came the real test: applying it to an actual implementation for the first time. What I expected was friction — a new layer of process slowing down work I already knew how to do.

And, to be honest: that friction existed. Not for the wrong reasons — but it was there. The grilling session surfaced assumptions I had not articulated. The tracer bullet forced me to define what “done” actually meant before writing a single line. There was a real lengthening of the process, which I first challenged. Then accepted. Because it was legitimate.

But something else happened that I had not anticipated: the AI, once equipped with an explicit methodology, showed a natural tendency to want to go further. To add another layer. To structure more deeply. A methodology, in the hands of an advanced statistical tool — however powerful — could become its own spiral.

I had to exercise careful judgment. Not push the AI brutally toward implementation — that would have cancelled the benefit of the whole approach. But set clear convergence criteria: how “structured enough” was enough to move forward? That recalibration was initiated by the human. It has to be. AI has a propensity to generate quickly and abundantly, sometimes beyond what is useful. The quality the developer must demonstrate is staying neutral: not becoming an echo chamber for the machine’s methodological enthusiasm, while not clipping its creative wings either. Establishing explicit convergence criteria between human intent and AI output: that is where genuine steering lives.

In the end, the blitz intake gave a clean home to every stray idea that would have otherwise dissolved into a chat thread. Each step felt less like ceremony and more like a conversation I should have been having all along. The methodology did shorten the path — but only after navigating that balancing act first.

AI addressed exactly my weaknesses

I should say something honest about this. I am, by nature, someone who struggles with organization. Naming things consistently, linking concepts together, maintaining structured documentation — these have been the bêtes noires of my career. I produce solid code and sometimes genuinely innovative designs, but the road there can be long and winding. I have frustrated myself more times than I care to count.

What I discovered — with some real emotion — is that the areas where AI adds the most value are exactly the areas where I am weakest. Structure. Naming. Cross-linking. Maintaining consistency across a growing body of artifacts. Catching things I would have forgotten to connect. The AI does not do the thinking for me. But it systematically converts my hesitations into productive interactions.

The weakness stops being a wall. It becomes a conversation opener.

For someone who has spent decades quietly frustrated with their own disorganization, this is not a minor thing. It is a kind of liberation. And I say that without exaggeration.

The meta-methodology: recording decisions about the methodology itself

One of the most unexpected moments came when I realized that the methodology itself deserved the same rigor I was applying to the product.

We were refining a naming convention during a working session — whether to use a slug or a sequential number for artifact file names. The reasoning that emerged was clear, deliberate, and grounded in real trade-offs. And I thought: this reasoning should not disappear into a chat scroll. This is a decision about how we work. It belongs somewhere traceable, just like any architectural or product decision.

So we introduced methodology decisions — small records of the reasoning behind non-obvious workflow choices. Why a date-plus-slug instead of a sequential counter. Why the iteration posture of a tracer bullet needs to be declared before scoping begins. Why simple cases must stay simple.

A meta-methodology. I had not imagined, at any point in my career, that I would one day find myself designing such a thing. And yet here I am, finding it genuinely thrilling.

The parallel work discovery

Another moment caught me off guard. Working across multiple branches, or across multiple worktrees on different topics simultaneously, creates a class of coordination problem the methodology had not addressed. Naming collisions. Index files becoming contention points. Two simultaneous sessions potentially conflicting over the same sequential identifier.

The problem, once named, was not hard to solve. Date-plus-slug identifiers. Deferred index updates. An explicit assumption of topic orthogonality across branches. The kind of answer that feels obvious only after you have found it.

What struck me was the dynamic: I noticed the gap, named it, and the collaborative reasoning that followed closed it in a single session. Neither I alone nor the AI alone would have arrived there as cleanly or as quickly. The human saw the friction; the AI structured the solution space; together we produced something neither would have authored independently.

That is what the methodology enables. Not just structure for its own sake. A living, adjustable frame for a collaboration that genuinely learns and improves as it goes.

A paradox I can live with

← Related: Back to Foundations — The Developer in the AI Era

← Related: From Code to Intent — One Year of AI Workflow