Stefano Maffeislesbass

June 25, 2026

AI Agents Are Making Me a Better Programmer

A personal reflection on moving from solitary discovery-based coding to a more explicit, agent-managed way of thinking about software work.

A quiet developer workspace with a laptop, structured notes, and luminous agent nodes suggesting AI-assisted software planning.

For a long time, I was mostly a solitary programmer.

Not in the sense that I could not work with other people, or that I disliked teams. I simply had a very personal way of moving through software work.

I was good enough to get almost anywhere, but I often started with only a vague idea of the route.

Someone would give me an input: a requirement, a problem, a broken feature, a new direction. I would begin writing code. Then, while working, I would discover what the final shape of the solution actually wanted to be.

Discovery was not a phase before implementation.

Discovery was part of implementation.

That made me effective, but it also created a strange weakness.

When I had to act as the person who gives tasks to others, I often felt less comfortable than I expected. Not because I lacked experience, but because so much of my own process lived in motion.

I was used to starting with an intuition, touching the system, following the feedback, and only then understanding the real boundaries of the work.

That is very different from saying:

Here is the task.
Here is the expected outcome.
Here are the constraints.
Here is where you should stop.

I could usually feel those things while coding.

I could feel the budget. I could feel when a solution was becoming too elaborate for the client. I could feel when a shortcut was acceptable, when a refactor was justified, when a feature needed one more pass, and when it was time to stop.

But feeling those boundaries is not the same as being able to explain them clearly to another person before the work begins.

That gap made me feel slightly inadequate in the role of manager, lead, or task-giver.

I had seniority, but not always the language for delegation.

The old loop

My old loop was simple:

  1. receive a somewhat vague problem;
  2. start coding;
  3. discover the real problem while touching the system;
  4. adjust the direction;
  5. stop when experience said the result was good enough.

There is nothing inherently wrong with that loop.

In fact, for many kinds of programming, it is honest. Software systems are not fully knowable from the outside. Requirements often become clearer only when they meet existing code, data, constraints, edge cases, performance limits, and user behavior.

The problem is that this loop does not externalize much.

It works well when the same person is thinking, coding, evaluating, and deciding. It becomes weaker when the work needs to be split across people, reviewed before implementation, estimated, delegated, or repeated.

The knowledge is there, but it is compressed inside instinct.

And instinct is hard to hand off.

AI changed the pressure

When the current era of AI coding began, one of the first things I noticed was not only that I could get help writing code.

It was that I suddenly had a reason, and a possibility, to become more explicit about what I was doing.

If I wanted an AI assistant to help me well, I had to describe the work better.

At first, that sounded like overhead. Then it started to feel like training.

I had to explain the goal. I had to describe constraints. I had to name tradeoffs. I had to separate the desired outcome from one possible implementation. I had to say what mattered and what did not. I had to define when a result would be acceptable.

In other words, I had to practice the part of software work that I had often postponed until I was already inside the code.

I had already written about part of this shift in Italian, in Da Copilot agli agenti AI: come è cambiato il mio modo di sviluppare software, where I described the move from asking AI for answers to asking agents to read context, plan, implement, verify, and correct their own trajectory.

This note is more personal. It is less about the tooling itself and more about what that tooling is teaching me to do: make my own thinking explicit before the code starts.

Over time, this changed me more than I expected.

I did not simply become faster at coding with AI.

I became better at thinking before coding.

The rubber duck got better

Recently, I found myself talking to ChatGPT through Apple CarPlay.

The assistant was doing very little, technically speaking. It was not writing code. It was not operating a repository. It was not solving a complex problem on its own.

It was mostly acting as a rubber duck.

But the surprising part was how natural the process felt.

I was driving, talking through an idea, unpacking a problem, trying out a framing, rejecting some options, keeping others, and slowly turning a vague intuition into something I could actually work with.

The conversation was almost a monologue.

A stream of consciousness.

Years ago, I would probably have found that difficult, or even useless. I used to envy people who could reason out loud like that, people who could make a plan visible before the work had fully started.

Now I was doing it almost without noticing.

The assistant did not need to be brilliant in that moment. It only needed to be present enough to hold the thread, reflect a bit of structure back to me, and make the thinking feel less like talking into the void.

That was already useful.

From assistant to agent

With coding agents, the change is stronger.

The relationship is no longer only:

I write code.
The assistant helps me write code faster.

It is becoming closer to:

I bring the intuition.
The agent proposes a path.
We evaluate it together.
I provide judgment, context, taste, and constraints.
The agent helps turn the direction into executable work.

That is a different posture.

It is not passive delegation. I am not asking the agent to replace my competence. The valuable part is still my experience: knowing which solution feels overbuilt, which risk matters, which naming choice will age poorly, which shortcut is acceptable, which test is worth adding, which behavior needs verification, and which part of the system should be left alone.

But the agent forces those judgments to surface.

If I want the work to go well, I have to articulate them.

That is exactly the skill I used to find hard when managing other people.

Becoming the manager of my agents

I do not think AI coding has turned me into a product owner or a project manager.

Those are real disciplines, with their own responsibilities, language, and methods.

But I do feel that I am becoming a kind of manager of my AI agents.

Not a manager in the corporate sense.

More like the person who shapes the work before it begins, sets the frame, keeps the standard, reviews the result, and decides when the output is good enough.

The agent can inspect files, propose changes, write code, update Markdown, run builds, collect evidence, and summarize what happened.

My job becomes more explicitly architectural:

  • what are we actually trying to achieve?
  • what should remain out of scope?
  • which constraints are real?
  • which parts of the current system should guide the solution?
  • how much quality is justified here?
  • what evidence will convince me that the work is done?

These questions were always part of my work.

The difference is that now they have to become visible earlier.

Markdown as a thinking surface

This is one reason the new Markdown-based way of working feels so important to me.

Markdown is not just a format for documentation or blog posts. In this workflow, it becomes a surface for thought.

Plans, tasks, acceptance criteria, architecture notes, article drafts, operational runbooks, design decisions, and agent instructions can all live as text.

That matters because text is cheap to inspect, version, edit, diff, and hand to an agent.

When the work is expressed in Markdown, the boundary between thinking and doing becomes more fluid.

I can start from a rough idea. The agent can turn it into a plan. I can correct the plan. The agent can implement it. I can review the diff. The agent can run verification. The result can become a durable note for next time.

This is not only documentation after the fact.

It is documentation as part of the work.

Less weight, more altitude

One of the underrated benefits of AI coding is that it removes weight from many small decisions.

Not because those decisions are unimportant. Many of them are essential.

File names matter. Frontmatter matters. Imports matter. Formatting matters. Validation commands matter. Small consistency details matter. They are the connective tissue of a software project.

But they are often not where the highest-value human judgment lives.

When an agent can handle more of that texture, I can spend more energy on the level above:

  • the shape of the system;
  • the tradeoff behind a solution;
  • the story a feature is telling;
  • the workflow I am creating;
  • the future maintenance cost;
  • the point where enough is enough.

That does not make the small details disappear. It changes my relationship with them.

I still care about them. I just do not need to carry every micro-choice manually in my head.

A better programmer, in a different way

The surprising result is that AI agents are not only making me faster.

They are making me a better programmer in a way that feels slightly unexpected.

They are pushing me to turn instinct into language.

They are making me practice delegation without losing accountability.

They are forcing me to define the work before I disappear into the code.

They are helping me build a habit of explaining scope, constraints, risks, and stopping points.

They are giving me a place to rehearse the kind of thinking that I once associated with people who were better than me at planning, leading, or managing.

I am still the same kind of programmer in many ways.

I still like discovery. I still trust the feedback that comes from touching the system. I still believe that software reveals itself through work.

But now the discovery starts earlier, in words.

And when the code begins, I am less alone with the fog.

Keep reading