← Back to Hari’s portfolio
HARI KRISHNAN N.S.ON LEARNING & WORK

Learning by building

From Prompting to Delegation

A childhood game, a weekend build, and a shorter distance between intention and execution.

Over the long weekend, I put GPT-6 Astro to work on several things. But one personal build blew my mind: bringing Dave, the PC game I played as a kid, onto my Android phone.

I had been looking through the Play Store for that familiar feeling. I just wanted to feel nostalgic and play Dave the way I remembered it. I wasn’t finding what I wanted, so I described the experience and handed over the build.

It built the game, even adding audio I hadn’t thought to ask for. That detail stayed with me. I had described a feeling, and it filled in a piece of the experience I hadn’t specified.

A 23-second recording of me playing the result on my Android phone. Use the player controls to play with sound or watch full screen.

There is plenty of content around Astro already. After this build, I understand the excitement. For me, the hype felt real in the execution and the pace at which an intention became something I could actually play.

An idea that might otherwise have stayed on my “someday” list became a working personal application over the weekend. The agent carried much of the work between intention and execution. My role was to bring the intention and decide whether the result delivered on it.

Start with something you care about

In Keeping Pace with Learning AI, I wrote about consuming something useful and rebuilding it. This time, the starting point was something I wanted that I couldn’t find.

That is a useful place to look for ideas. A use case does not have to begin in a strategy workshop. It can begin with a repeated task, a small frustration or a game you miss. Your own experience gives you context that a generic request cannot supply.

With Dave, I already had a sense of what I wanted to feel when I played. That gave me something to judge the result against. A functioning game was part of the requirement; the familiar experience was the reason for building it.

As execution gets faster, deciding what is worth building deserves more attention. Ideas rooted in what you feel or understand give you a reason to care about the outcome, and a better chance of noticing when something is missing.

Ask why before specifying how

Thinking from first principles starts with examining the need. Why was I looking for another game? What did I actually miss about Dave? What would make the experience feel right on a phone?

Those questions give a clearer brief than “build me a game.” They help separate the outcome you want from assumptions about how it has to happen.

The same habit applies to less nostalgic projects. A request for a dashboard might begin with someone struggling to make a decision. A request for automation might begin with repeated handoffs. Understanding the underlying need gives you a way to assess whether the thing you build helps.

It also leaves room for useful interpretation. I had not specified audio, but the agent included it. That was a welcome addition in this build. It still needed my judgement: an agent filling in an unspecified detail is making a choice, and that choice needs to fit the experience you intended.

Delegate the work and keep the judgement

Handing over a build changes your role. You describe the outcome, review what comes back and decide what needs another pass. The quality of that review matters more as the agent takes on more execution.

Does it work? Does it feel right? What is missing? Would I actually want to use it again? These are ordinary questions, but they keep the work connected to a person who will use it.

The agent can produce something quickly. I still have to decide whether the result is any good. Taste, context and care remain part of the job. So does recognising the difference between something that is enjoyable for me and something I would be ready to hand to other people.

This was a personal weekend build. The recording shows a slice of gameplay, and that was enough to make the experience exciting for me. A wider release would raise more questions about reliability, device behaviour and support. Faster execution gives me a first version sooner; it does not answer every question about that version.

A smaller gap, a more practical starting point

What I took from this weekend was the opportunity to act on an idea while I still cared about it. The gap between wanting something and trying a version of it had become small enough to cross.

That makes experimentation feel more accessible. Look at something in your own day that you have accepted as inconvenient, unavailable or too much effort to make. Pick one. Explain what better would look like. Delegate a first version and judge the result.

Keep exercising the human part as the tools improve: choosing the problem, asking why and deciding what deserves another pass.

What would you finally build if the gap between intention and execution became substantially smaller?