Introduction#
In last week’s post, I promised to write about code agents. A code agent is a tool, such as Claude Code, Mistral Vibe or OpenAI Codex, that reads and changes the files in your project and runs commands, all from a prompt. In class we went through how agents can help with architecture, debugging, refactoring and testing, and the focus was on how the developer and the agent work together.
Then we got to try it ourselves. The exercise was to solve a programming task with a code agent and reflect on how it went. For us, that meant adding a feature to our own portfolio sites.
Picking a Feature#
Our teacher had a few suggestions, dark mode among them. The problem is that this site runs on Blowfish, and Blowfish already ships with dark mode. The theme covered the other suggestions as well, so I would have been asking the agent to build something I already had.
So I picked Tetris instead.
For the agent, I used Mistral Vibe, Mistral’s coding agent, which runs in the terminal. Vibe usage is included in the student subscription I described in the first post.
One Prompt#
We were encouraged to see how far a single prompt could get us, so I treated it as an experiment. Instead of building the game step by step, I gathered all my ideas into a single prompt and let Vibe take it from there. The prompt asked for:
- Tetris on a single page of my Hugo portfolio
- A responsive layout
- Intuitive controls
- No highscores persisted
That was the whole design, and I sent it off.
Half a Tetris#
What came back looked like Tetris, and I could play it. Just not properly.
- The game was taller than my screen. On a desktop, the game did not fit inside the browser window.
- The arrow keys moved the page too. They moved the piece, but they also scrolled the page.
- The game logic had faults. Tetris has simple rules, and they were not all followed.
Everybody knows what Tetris is supposed to look like, which made it easy to see where this one fell short. It was harder to admit that a lot of it started with my prompt. “Responsive” said nothing about the height of a desktop window. “Intuitive controls” did not say that the keys should only control the game. And the prompt did not describe the rules of Tetris at all.
Who Owns the Design#
The agent wrote the code. What it could not do was decide what I wanted, because I had not decided that myself. I thought I had handed over a complete idea, but the prompt had holes in the design, in how the game should behave and in the implementation details. I did not notice them until the game was in front of me. A better prompt would have said how much space the game gets on a desktop, which keys belong to the game and which rules it has to follow. None of that is hard to write down. I just had not thought about it until I saw what was missing.
I could have kept going from there, but it felt like I would be wasting tokens going back and forth with the agent when I did not have all the details ready myself.
Fixing it that way would mean pointing out the scrolling, waiting for a fix, testing it and moving on to the next thing. That works, but it is slow, and every round costs tokens. My Vibe allowance would have covered it, but that is not really the point. It goes against what I wrote about in the first post, giving a model only what it needs and calling it as little as possible.
So my takeaway is that the developer has to own the idea and the design, even when the agent writes every line. With an agent doing the typing, the spec and the concept work matter even more than I expected before this class. If the idea is not clear before the first prompt, the agent fills in the gaps, and I only find out what it chose once the code is written.
Good design and the software principles we have learned over the past three semesters do not go away either. An agent writes code faster than I do, but whether that code is easy to change and test still depends on decisions somebody has to make. With one prompt, I had left those decisions to the agent without noticing.
Conclusion#
Tetris never made it onto the site. It was in too bad a shape to be implemented, and I will not be going back to fix it. I would rather use it as a learning experience for the work ahead.
The one-prompt experiment showed me quickly where my idea had gaps. The next time I work with an agent, I want the idea worked out before the first prompt, and the work split into steps small enough that I can check each one.
Since that class, I have been looking into a more structured way of working with agents, based on Matt Pocock’s workflow, where most of the work happens before any code is written. More on that in a later post.
This week’s two classes were about working with a language model through its API, and that is the subject of the next post.
- Daniel