AI gives me speed. My job is to give it direction.

I can keep several agents busy. The harder job is making sure their work adds up to a product I actually want.

That distinction has become the center of how I build. I run multiple AI sessions as part of my daily work on All Is Vanity, a game I have been bringing toward a commercial release. I use it as a place to exercise the whole engineering loop: choose a problem, build something, test it, look at it, change my mind, and try again.

I can delegate implementation, tool changes, and investigations in parallel. That also makes weak direction expensive very quickly.

If I ask for six improvements without deciding which problem matters, I can get six polished answers to questions I should never have asked. Someone still has to choose the target, recognize a good result, and decide when another iteration is worth doing. That is my job.

Direction has to describe a result

“Make this better” leaves almost every important decision unresolved. “Add these three features” can be just as bad if the features are guesses about a problem I have not understood.

I get better results when I describe what someone should experience. For example: the player should recognize an incoming threat before taking damage, understand what happened afterward, and be able to respond without studying a manual. Those are observable goals. Increasing a glow effect or adding another animation is an implementation option.

Once the goal is clear, I can ask an agent to inspect the current behavior, identify where the signal gets lost, and propose a bounded change. I can also reject a technically correct result because it makes the screen busier without making the action clearer.

That is a useful rejection. It tells us something about the product. A vague request followed by “still doesn’t feel right” tells us much less.

Speed becomes useful inside a feedback loop

My workflow has developed three complementary parts. I set the intended outcome and the constraints. Agents explore and implement within a defined scope. Tools make the result cheap enough to inspect that I can keep steering.

The tools matter as much as the conversation. I have built editors, preview surfaces, repeatable scenarios, runtime probes, and capture workflows around the game. They let me get back to a specific state and compare a change instead of spending the next session reconstructing the previous one.

This is where the work compounds. A better iteration surface helps with the current change and the next hundred changes. Another long prompt usually helps with one conversation.

More agents require fewer competing priorities

I have already tried broad mandates with lots of files changing at once. The guardrails essay describes the failure that made me reconsider that approach.

My current rules are more specific. One owner controls an overlapping write scope. Read-only investigation can happen in parallel. Tasks have a defined outcome and a verification path. Changes to shared contracts require coordination. A second agent needs a reason to exist beyond the fact that another session is available.

These rules make it easier to use the speed. I spend less attention reconciling competing assumptions and more attention judging whether the product is improving.

There is still an uncomfortable part: deciding not to build something. AI lowers the cost of trying ideas, but maintenance, interaction complexity, and user attention remain expensive. A feature that is cheap to generate can still be costly to own.

Why this matters to my day job

At Samsara, my scope spans Safety and Telematics, including firmware, quality engineering, automation, and services connecting devices to the backend. The constraints are different from a game: physical hardware, constrained compute, system reliability, and teams that need to make decisions together.

But the leadership question is familiar. How do I give people a shared target and enough feedback to make good decisions without routing every detail through me?

My hands-on agent work gives me a fast way to examine that question. I can see what happens when ownership is fuzzy, when testing is too expensive, when the wrong metric becomes the goal, or when a tool makes an entire class of work easier. These are lessons I bring to organizational design; the game is not a benchmark for Samsara’s productivity.

I want substantially more capacity from the teams and systems I lead. The way to pursue it is to improve the path from a useful idea to a verified result, then measure what actually changed.

AI gives me more opportunities to act. Direction determines which actions are worth taking. The feedback loop tells me whether we are getting anywhere.

This is the opening essay in my series on building with AI. The next piece covers the guardrails that make parallel work useful.