Let it cook. Then check the results.

I hate doing diagnostics. That is probably a strange place to start a post about AI, but it explains more about why I use it than a screenshot of generated code would.

In my DrivEngine experiments, I wanted to explore how to make simulated traffic behave better. Writing a driver was only part of the problem. I also needed a way to tell whether a change actually improved its behavior.

Starting from scratch gave me room to try different approaches. But how could I compare them beyond watching cars and deciding that one looked better?

The useful part of working with agents was getting a test harness built: a set of driving scenarios with measurements to check the behavior. In DrivEngine, it helped shape the driving behavior in about a week.

There is a catch. At first, the harness measured the wrong things.

I played the scenarios it tested and could see that its judgment did not match the driving. I had to explain where it was wrong and steer the diagnostics toward behavior that mattered. Only then did those measurements become useful evidence for the next change.

That is a much more interesting result to me than "AI wrote some code." It helped me do work I dislike, gave me a way to test ideas, and made an expensive assumption cheaper to question. It also needed correction before I could trust what it reported.

I used to expect it to read my mind

When I first started using agents, I would give them work and get annoyed that they did not do exactly what I wanted. I had a picture in my head of what the result should be, without explaining enough of the details or why those details mattered.

I also assumed my approach was better. If the agent did something differently, that difference was often enough for me to reject it.

Both habits got in the way. I needed to explain the goal and the constraints better. I also needed to leave room for an approach I had not considered.

For example, I generally preferred subsystems over actors for managing parts of gameplay. An actor is an object placed in the game world. A subsystem handles work more centrally. Then I let an agent build a manager as an actor and found a practical benefit: someone could edit its settings per level or area, directly on the actor or through a referenced data asset.

For that case, it was a better fit. My preference had hidden a useful option from me.

When I review an approach I do not know, I try to learn about it before deciding whether it is bad. That sometimes costs more time and tokens, the units the model processes and charges for. I get something out of it beyond finished code, though. I learn a way of doing things that I would otherwise have dismissed.

There are still plenty of results I reject after understanding them. Too many comments. Too much machinery around a simple feature. A custom solution where the engine already provides what we need. Being open to a different approach does not mean accepting every approach.

One failed attempt tells you less than you think

Someone told me they had tried talking to Sonnet about project architecture and it was bad. My response was that different models and effort settings work better for different tasks.

That came from experience with Cradle. At first, we let Sonnet design the code changes for the tasks it would implement. In that setup, I kept finding designs that needed rework. Some oversimplified the problem. Others invented poor replacements for features the engine already had.

We changed the workflow. A model that handled the design work better would inspect the engine and prepare the changes. Sonnet would implement that clearer plan. The quality improved a lot.

That is why I am skeptical when someone tries one setup, gets a bad result, and concludes that AI is useless. Read about the tool. Experiment with it. Find its limits. Opening Blender without knowing the controls would not give me much basis for judging Blender either. I have made that mistake too.

But I had not seen this person's prompts or results. I recognized a pattern from my own experience and assumed it applied. I should have asked to see what they did.

My Cradle experience gives me a reason to choose that division of work for that project. It does not establish a permanent rule about every model or every architecture task. Models change. So do their useful limits.

"Skill issue" is a tempting shortcut. Sometimes I do need to learn the tool. Sometimes the model is not good enough. Sometimes the workflow is wrong. Sometimes the test is wrong, as it was with my driving harness. Finding which one failed is part of the work.

I do have a stopping point. With older tools, two or three bad attempts or a loop of repeated failures was usually enough for me to take over. Copilot was useful to me as autocomplete when handing it larger tasks was not. I kept the part that worked.

Learn enough, build, learn more

Before I started my storm chasing game, I did not know much meteorology. While agents worked on engine and scripting tasks I understood, I studied weather.

Once I knew enough to design a simulation and check its behavior, I started building it with agents. While they worked, I learned more about traffic simulation. Then I could work with them on that too. I still study both subjects while the work continues.

I did not wait until I was an expert. I got familiar enough to take the next step, tested it, and kept learning.

That has gone wrong too. My first approach to weather fronts used simpler simulation pieces that I thought would be enough. Experiments showed something was missing. Talking it through with an agent pointed me toward larger weather processes that the simulation did not represent. I studied those, revised the design, and experimented again. The behavior started to make more sense.

There was no single source of truth in that process. I noticed a problem. The agent helped suggest an explanation. Studying helped me judge that explanation. Experiments helped me check the revised design.

This is why expertise matters so much to me. Without enough knowledge, I can look at a result, say "looks good to me," and miss something that will backfire later. But my knowledge is incomplete too. Another developer might see a risk I missed. An agent might suggest an idea that shows where my own understanding was wrong.

I want better results more than I want my first idea to win.

A prototype is allowed to be thrown away

In my recent game prototypes, I do not closely review every piece of agent-written code. We brainstorm the design, turn it into tasks that I review, and then I let the agents work. I judge the playable result and dig into problems as needed. So far, the results have often been good, with code I consider acceptable for that purpose.

The point of those prototypes is to find the fun. The design can be wrong. The code can be wrong. In my experience, changing either has become much cheaper with agents, including throwing away an approach and rebuilding it.

That changes which decisions feel affordable. I am less willing to bend an entire game around a bad idea just because changing the implementation used to take a long time. Testing traffic approaches from scratch in DrivEngine helped me question that cost too.

It does not mean I have proved this workflow will maintain a shipped game well for years. That is a different result to establish. A prototype gives me evidence about the prototype.

I also do not miss writing every line myself. When I want to code for fun, I do. When I am making a product, code is one of the tools that gets it made. I have bought art and music without feeling that the project stopped being mine. I can distinguish the work I authored from the product I shaped.

As a player, I care whether the game is good and whether I have fun. Knowing AI was involved does not, by itself, change that judgment.

Please stop turning demos into layoff plans

The opposite extreme bothers me just as much as dismissing the tools after one attempt. Someone gets a convincing result from one prompt and jumps to "we do not need these people anymore."

A good-looking surface can hide a bad product. Completing a small task does not establish that the same setup can run a larger project, maintain it, and catch its own failures. My own diagnostics initially gave me the wrong judgment. Automating that judgment without checking it would have made the problem worse.

Even if AI could reliably do the same work with fewer people, layoffs would not be my goal.

In game development, I would rather explore what the same people could make with better tools. Instead of 30 people working on one project, could we try several smaller teams? Some could make prototypes. Some could take a promising game further. Specialists would still matter. People from a failed project could move to the next experiment.

That is the direction I want to explore, not a staffing formula I have proved. Finding a game worth finishing is already hard. Testing several ideas for the same budget could help us find it sooner than trying every idea one after another.

And some of the time can go into learning. I would want that to be part of the plan, rather than filling every available hour with delivery. I now learn while agents handle work I already understand. I want more people to have that opportunity. More output is useful. More capable people are useful too.

Trust can grow, but it has to be earned

I am comfortable giving agents more freedom when their decisions earn it. Show me the options, explain the recommendation, and let me check the result. If that keeps working, I need to intervene less.

Agreement alone does not earn that trust. The actor example was useful because it challenged my preference and gave me a reason to change it.

What worries me is treating AI as an oracle because making a decision is uncomfortable. I worry especially about decisions affecting health, security, law, finances, and people's livelihoods. A confident answer is not enough evidence to hand over that authority.

I am not saying humans must keep every decision forever. We already automate limited decisions with things like traffic lights. If studies and real use showed that an AI system reliably made better decisions in a particular area, I would want us to benefit from that. I would also want the evidence to stay open to scrutiny and correction. Studies can be wrong. Finding that out and improving our understanding is part of science.

I do not miss my old workflow. I worry about what happens when people turn better tools into permission to stop questioning results, or react to those failures by rejecting useful tools entirely.

My own workflow still takes work. I learn the tools, build experiments, correct measurements, and change my mind. Agents have made much more of that affordable. They have also given me more time to learn things I could not do before.

I want to keep doing that, with people who get the same chance to grow.