From Coder to Curator

tosh1 pts0 comments

André Staltz — From coder to curator

Skip to content

← Blog

Last year I was vocally against LLM-produced code. It felt frankly counterproductive. Before Opus 4 arrived in the middle of the year, the models were weak, the code was low quality and buggy, and fixing it through the model was frustrating because it often couldn't understand my instructions either. It was faster to fix things by hand than to chat and wait.

By the end of the year, I had to fix the output less often. Fast forward to today, and in most cases I no longer have to fix the AI pull request. The change has happened very fast.

There is now a lot of talk about AI coding, and it is certain that it has made its way into most companies producing software. Developers everywhere can see that there is no turning back. If you were still coding by hand in 2024, that was probably the last full year that you did it professionally. Going forward, everything will be different.

For some, this is a cause for concern, or nostalgia. Something feels wrong, you miss how things used to work, or you're worried about what your job will become. Writing software was the core part of the job for many engineers. When that core is taken away, what is left?

I want to share a few thoughts that may give you hope. This post is specially for younger developers who are a little confused or terrified.

The genie in a lamp

I feel energized. I can finally revive projects that I never had time for, and take on endeavors I never thought I could. Renewing this blog was one of those projects. As I work on these side projects, I am starting to see the same pattern:

The AI does the building. I am the curator.

The best analogy for AI is not a sentient robot, it is a genie in a lamp. It is magically capable of almost anything, but subordinate by design . Companies such as Anthropic and OpenAI are incentivized to build agents that do precisely what the user asks them to do. The genie can build both your great ideas and your mediocre ideas, and it is not going to stand in your way.

This means that AI tools delegate quality to you. Not because they cannot produce high quality software, but because people want different things. Now that all sorts of things can be easily built, the difficulty is no longer in building in itself.

So the real question is what should get built? What do you want? And the even more important question which will define the careers of many of us is: "What is worth building?"

Bundling of roles

My mother used to work as a typer for programmers. She did not understand what she was typing. She received code from someone else and typed it into a mainframe.

That job disappeared because typing became bundled into the programmer's responsibilities. A programmer should design their algorithms and also type them out. We did not need one person to design the program and another person to press the keys.

Now the role of the coder is disappearing, and I think that is totally fine. We are bundling that responsibility into another role. That role may be product designer, solutions architect, cloud architect, founder, or something that does not yet have a common name. We no longer need such a clear separation between the architect and the builder, because the building can be bundled into the architect's tools.

To be clear, understanding code is still important, and will remain so. The managers and the designers today who never knew how to code have the opportunity of finally independently giving their ideas life. However, they will inevitably compromise on software quality if they don't get this one thing right: understanding and shaping the code and architecture internally.

Quality is complex. I remember the CEO of a consultancy where I worked saying that quality is a combination of many factors. It is not enough that software is fast. It also has to be user-friendly, reliable, correct, and internally maintainable. Improvements to one of these can even make another worse. There is no single benchmark that tells the genie "make it good".

The quality imperative

At the moment, in 2026, I see my job as filling my software with as many AI tokens as possible and as much quality as possible .

Why is quality now an imperative? Because low-quality software can be built by anyone. If all I do is copy-paste user requirements into an LLM prompt, then I truly add no value and there is no job left for me.

So I have shifted my thinking to: how can I make this really good?

And I believe we also have a responsibility to add value between the needs expressed by people and the software that gets built. If you just copy-paste what people say they want and feed it to an AI, you don't get good software. You may short-term address a local issue, but in the process it is easy to add confusion elsewhere, present incorrect information, or give too much emphasis to something irrelevant.

Programmers have always been prone to fixing problems that they themselves experience....

quality software code because year things

Related Articles