The "Code Athlete" Developer

I used to do hundreds of programming exercises a year. Last year, for example, I practiced TDD with data structures, F#, thread synchronization, and various other things, because I always needed to have coding agility and be able to handle exceptions, configurations, libraries, and all that practical part of development.

I grew up learning programming through exercise lists and deadlines. I always had in mind the mantra based on the famous:

"Talk is Cheap. Show me the Code."

And also in the old:

"Practice makes perfect."

For me, being a good programmer meant practicing a lot. The more code I wrote, the faster I could solve problems.

My interview tests, in fact, were often literally hours of coding in person in front of everyone. Later, as I gained experience, the tests became much more about discussing concepts broadly.

But even so, I still needed to have a great implementation skill. I needed to know by heart APIs, libraries, .NET features, configurations, and be able to quickly turn an idea into code.

I was, in a way, a "code athlete".

🚀 The Reality Shock

Then came the shock.

When I met Claude Code, it made me strongly rethink this way of viewing programming.

I saw it implement things like login with Microsoft and Google in less than an hour, with very few things to fix and often it fixed the problems itself.

That is something that previously could easily take me several days or even a week.

I would have to think about the layout, figure out how the endpoints worked, read the documentation, understand which APIs should be configured, figure out the necessary configurations, implement, test, and fix.

Suddenly, a relatively generic prompt was able to implement a huge amount of that work.

And it wasn't simply working code.

The produced code followed patterns, applied Clean Code, used design patterns, and, mainly, the agent was able to analyze its own errors and fix them.

That's when an uncomfortable question arose:

If the manual skill of writing code quickly ceases to be the main differentiator, what does it mean to be an excellent programmer?

🧠 The Turning Point "Talk is Cheap Show me the Code" vs "Cognitive Coverage"

It was then that I saw a YouTube video presenting the concept of "cognitive coverage".

At that moment I practically restructured my way of practicing.

Instead of continuing to spend a huge amount of time trying to master every implementation detail, I started to organize my practice into topics aiming to increase the breadth of concepts I know.

That became my new mantra.

Today I'm not a cloud specialist, but I know many cloud services and can set up infrastructure on two clouds.

I'm not an AI specialist, but I know many concepts, tools, and platforms like Azure AI Foundry.

I also started studying new techniques such as Spec-Driven Development, Machine Learning, Data Engineering, and agent orchestration.

My concern began to change.

Now I don't care about knowing how to code an API with gRPC or a .NET MAUI screen by heart, but I care about cognitive coverage.

I want to have a great breadth of concepts to elaborate specifications in the prompt for the agent. And understand what the agent is doing to be able to guide it toward my goals and those of the company I work for.

⚙️ The Bottleneck of TDD and SDD

It was in this process that I began to understand better why so many people don't strictly follow certain methodologies.

I remember a survey or estimate I saw that attributed to Kent Beck the idea that approximately 92% of developers wouldn't use TDD rigorously. I don't remember the exact source, so I don't want to state that number as a definitive fact.

But the reasoning behind it caught my attention.

The problem is simple:

thinking about the design before implementing is difficult.

In complex features, writing tests before implementation requires you to anticipate behavior, think about interfaces, use cases, and how that code should work before even building it.

That is cognitively very heavy.

And I started to notice something similar happening with Spec-Driven Development.

I had understood SDD as a way to specify everything: requirements, design, implementation, and tasks organized in order, going all the way to an extremely detailed tasks.md file.

Only there is a problem.

Specifying low-level implementation can be even harder than implementing.

You need to think in advance about how that solution will be built, break everything into tasks, organize the sequence, and predict details that might only be discovered naturally during implementation.

That's why I started to realize that many people end up working mainly with high-level specifications, without necessarily describing all the low-level implementation.

🛠️ The Practical Example: When I Got Stuck

This became very clear to me on my own website.

I was developing features related to Audiobook and ePub and started trying to apply Spec-Driven Development in an extremely perfectionist way.

I wanted to map everything.

I wanted to describe each step.

I wanted to go down to the level of implementation tasks.

And I simply got stuck.

It was one of those moments when I realized that the process that should help me was starting to prevent me from moving forward.

It was then that I thought:

Why am I trying to manually do a part that an agent can do much better and much faster?

I started delegating low-level implementation to Claude Code.

I continued to control the intention, the architecture, what I wanted to build, and the expected outcomes, but I let the agent navigate much of the implementation.

The result was a productivity gain of dozens of times.

That's when it clicked.

I no longer needed to compete with the machine at what it was getting absurdly good at doing.

🎯 The New Reality

Instead of seeking to be an exemplary coder, writing code daily and practicing hundreds of exercises, I need to expand my range of concepts and fundamentals. I need to develop a broad enough vision to understand and cover what AI is capable of doing, know how to review its implementations, guide it toward the right objectives, and often learn from the code it produces, understanding its pros, cons, and limitations.

A great advantage of working at a high level now with specifications is that I can expand what I'm able to deliver.

The great advantage of shifting focus to high-level work, grounded in clear specifications, is the exponential scaling in what I can deliver.

Before, integrating a new ecosystem required days poring over documentation to map endpoints, handle exceptions, and build the interface from scratch. Today, by conceptually understanding solutions like Azure AI Foundry or the Microsoft Agent Framework, it's enough to structure a well-defined specification establishing the expected inputs, behaviors, and outputs of the agent for the AI to generate the necessary implementation.

With very few clicks and commands, I turn an architectural concept into a functional, high-value tool, without drowning in the low-level details that would take weeks.