Case study · n = 1 · Draft
Strawberry Methodology
A day-by-day record of how one person and several AI agents built a procedural fruit add-on for Blender.
The user1 · claude-opus-5-52 · claude-fable-5-22 · gpt-6-astra3
1 human, video artist 2 language models run in Claude Code 3 language model run in Codex CLI
AbstractOne person without a programming background and several AI agents built a procedural fruit add-on for Blender in two weeks. This case study reconstructs the project from its own traces: every prompt the user typed or dictated, every tool call the agents made, every screenshot and every commit. It asks how the work was actually done, what went wrong and who noticed, and what the human still did by hand.
1Introduction
1.1How it started
A freelance jobOct 31. The brief: animate a strawberry whose skin and seeds run upwards “like a conveyor belt”. The first prompt asks for a free 3D model.
No moneyThe budget for the job fell through.
AngerIt had to go somewhere.
“I will make the best fucking strawberry ever.”No downloaded model, no textures. Everything built from nodes.
HyperfocusTwo weeks. The rest of this page.
Figure 1. The chain of events, as told by the user.
1.2Questions
- The analysis is being written.
2Methods
2.1Setup
The user described in plain language what he wanted, mostly by dictation, and sent screenshots of the Blender viewport. The agents wrote and ran Python inside Blender, looked at their own screenshots and reported back. The user worked in the same Blender file by hand: camera, light, materials, and looking.
Table 1. Models and harnesses. A harness is the program that runs a model and gives it tools. Counts are model replies in the logs.
Figure 2. Which model did the work on which day, by share of replies.
2.2Data and coding
- Sources. Session logs of both harnesses, the git history, the user's screenshots and the project folders. Nothing was recorded for this study. The logs already existed.
- Counting. A message is one prompt from the user. A tool call is one action of an agent, for example running a script in Blender or reading a file.
- Episodes. For each day, one agent read all prompts and replies of that day and split it into episodes. Each episode got one label: went well, decision, routine, misunderstanding, dead end or stuck. The labels are a judgement, not a measurement.
- Analysis. A further agent read all episodes, looked for patterns that repeat and counted them. Each finding links to the episodes it rests on.
- Quotes. The user writes and dictates in German. Quotes are translated.
3Results
3.1At a glance
Table 2. Totals counted from the logs.
messages from the usertool calls by the agents
Figure 3. Activity per day. The two rows use different scales. Click a day to jump to it.
3.2Four stages
3.3Where the time went
Figure 4. Where the time went. Top: all analysed hours by kind of episode. Below: the same per day, bar length is hours. Only hours with logged activity are counted. Labels are the reading agent's judgement.
3.4How the user worked
3.5Findings
3.6Who did what
Table 3. Division of work between the user and the agents.
3.7Sound
4Discussion
4.1Limits
- Work the user did by hand in Blender leaves no log. It is listed only where a prompt mentions it.
5Conclusion
ADay-by-day record
Each bar is one day from 0:00 to 24:00. Each coloured block is one episode. Click a block or a row to read what happened.