Speed Is Easy — Control Is Hard

When Output Finally Caught Up

For a long time, my problem was never ideas.

It was execution.

I could see the shape of a product, a library, an API, a data model, or an article very quickly. What was harder was carrying that first burst of clarity all the way into something finished before my attention moved somewhere else.

That gap—the distance between seeing the thing and actually shipping the thing—has been there for as long as I can remember.

So when AI-assisted development tools started showing up, I was curious.

My first experience with GitHub Copilot was the Technical Preview in 2022. At the time, it felt like a "meh" version of autocomplete—useful in small moments, but not something that fundamentally changed how I worked.

It could help with snippets. It could sometimes save a few keystrokes. But it did not close the gap.

That changed around summer 2024.

Not overnight, and not because the tools suddenly became perfect. But something shifted in how I used them. The interaction became more deliberate. Less about getting answers, more about shaping output.

Around the same time, I also started recognizing a pattern in how I work.

I have never been diagnosed with ADHD, but I’ve had my suspicions. At the very least, I relate to something many technical people will recognize: fast thinking, too many parallel threads, and a constant gap between what feels obvious in your head and what actually gets shipped.

AI did not create it—but it changed how I could deal with it.

Not because it gave me ideas I did not already have. Not because it replaced engineering judgment.

What it changed was the distance between thought and output.

For the first time, output started catching up with thought.

From Intuition to Structure

A lot of my friction has always lived in the space between intuition and structure.

I often knew roughly what I wanted to build before I knew how to explain it cleanly.

I could feel the shape of the thing, but the shape was not yet communicable. It was not yet an outline, a spec, a task list, or a piece of code.

A rough idea has to become something named.
Something named has to become something structured.
Something structured has to become something you can actually act on.

Every transition costs energy.
That is where AI helped me most.

A blank page is heavy. A rough draft is much lighter. Once I have something in front of me—even if it is flawed—I can react to it. I can correct it, trim it, rewrite it, or use it as a forcing function to make a real decision.

That sounds simple, but it changed a lot of my day-to-day work.

Where It First Felt Real

My first real success with an LLM was back in May 2025, when I extended one of my libraries, Cuemon for .NET, with support for SHA-512/256.

That was one of the first times it stopped feeling like clever autocomplete and started feeling like something I could actually work with.

The useful part was much more boring—and much more valuable.

The model could help me reason across the standard, implementation details, and edge cases faster than I would have on my own.

Eventually, that became a working implementation:
Cuemon.Security.Cryptography/SHA512256.cs.

But it was also one of the first times I saw how uneven the models were.

I wrote a unit test first so I had a hard reference point. Either the implementation passed or it did not. That changed the whole interaction. I was not asking the model if it thought the result was right—I had a concrete way to verify whether it had actually succeeded.

ChatGPT got there after four or five tries, as I remember it. DeepSeek never did.

But the important lesson was not that one model was “good” and another was “bad.”

The important lesson was that both could sound confident while being wrong.

That is one of the more dangerous parts of working with LLMs. They do not fail like traditional software. They often fail fluently. They explain. They justify. They produce something that looks plausible enough to pass a quick glance.

And if you do not have a feedback loop—a test, a specification, a known expected result, or some other hard constraint—you can easily mistake confidence for correctness.

That small experiment gave me both lessons at the same time.

The upside was real. I could feel the acceleration immediately.

But so was the unreliability.

That was probably the first time I stopped thinking about LLMs as “smart” and started thinking about them as tools that only become useful inside a feedback loop.

When Threads Became Things

After that, the pattern started showing up everywhere.

Instead of getting stuck in one branch, I started shipping across multiple parts of my ecosystem; always with a holistic view on top of mind.

I was crafting opinionated library extensions for BenchmarkDotNet and Carter, while also expanding Cuemon for .NET to fully support UN M49 StatisticalRegionInfo that ultimately served as a catalyst to make Globalization even more robust while adding support for MCP documentation in yet another opinionated library extension: Swashbuckle.AspNetCore.

At the same time, I was relaunching s13n.info, building a globalization REST API with MCP support, and creating M49 Explorer.

Those projects did not all live in the same corner of my brain.

But they all benefited from the same shift:

Lowering the cost of turning a moving thought into something concrete before the thread disappeared.

Work that would have taken months started taking weeks.

Some of it might not have happened at all.

That was the shift: output had finally started catching up.

The Part Speed Does Not Solve

But more output does not automatically mean better outcomes.

It just means mistakes can travel further before you notice them.

AI is not deterministic.

It does not execute—it predicts.

That distinction matters. Traditional software is usually built around repeatability: same input, same output. If that contract breaks, we look for a bug. AI does not give us that same contract. The same prompt can produce a different answer, a retry can create a new failure, and an output can be syntactically valid while still being wrong in context.

Even with good prompts, guardrails, and structure, it can still drift. Worse, it can drift while sounding completely certain.

If you are not careful, you do not notice until the result matters.
That is where the responsibility comes back to you:

You are still responsible for correctness.

What AI Did Not Change

AI helped me ship more. It did not lower my standards.

I still care about the fundamentals:

• SOLID
• DRY
• Consistency (is key)
• Separation of Concerns
• Measure Twice, Cut Once
• The Beyoncé Rule
• Framework Design Guidelines for .NET
• Microsoft’s Engineering Guidelines

And just as importantly, I still care about the difference between a proof of concept, a minimum viable product, and something that is actually production-ready.

If anything, those distinctions matter more now.

Because AI does not know whether momentum is deserved.

It can help you move quickly into a good design.

It can also help you decorate a bad one until it looks convincing.

The Cost of Always Being in Motion

The cognitive side of this did not disappear.

If anything, it intensified.

A fast-moving mind combined with faster tools does not create calm—it creates pressure. More ideas can be explored. More directions can be followed. More things can be started before others are finished.

To keep up, I started consuming more: more videos, more articles, more experiments, more time spent feeding the machine.

The result isn't clarity. It's intensity. A constant sense of acceleration, of always being "on," of needing to stay ahead of your own thinking before it fragments.

AI didn't just increase my output. It increased the importance of steering.

Closing

AI did not make me a different developer.

It reduced the distance between thinking something and making it real before the thread was gone.

That is the part that changed how I work.

But faster output does not remove responsibility. It increases it.

Speed is easy. Control is hard.

Next: Control Has to Be Designed

If control matters more as speed increases, then it cannot depend on intuition alone.

It has to be designed.

In the next part, I will look at how that plays out in practice—through workflows, structure, and why working with AI quickly exposes something deeper:

It is not just a model problem. It is a protocol problem.