AI Natives Work the Loop

I am very bullish on humans right now.

For years, my personal why has been helping people reach their potential through technology. That is why I did Teach for America and taught middle school math in Baltimore City. It is why I keep finding myself in rooms with young people and adults, trying to help them use AI.

As I am teaching, I keep seeing the same pattern. Most people use AI like a shortcut to the build step. Write this email. Make this slide. Draft this strategy. Generate this code. Summarize this meeting. Design this workflow. Don't get me wrong, those use cases are useful. But they are only scratching the surface of what LLMs can do.

I think the people pulling ahead in their careers are treating AI as an augmenter. They are applying AI loops to every problem so the work compounds. The framework I have been using and teaching is simple:

Think. Plan. Build. Run. Evaluate.

If it looks familiar, it should. It is basically the scientific method you learned in middle school.

What AI Is Good At

Before we jump into the details of the framework, it helps to name what AI is good at. AI is a ridiculous execution engine with incredible endurance. It can put words on the page, code in the editor, structure around a messy idea, and get options in front of you faster than almost any tool I have used.

That ability makes AI useful at every stage of the process. The problem with most people's approach is that they try to skip straight to building without doing the necessary thinking and planning first. Just because AI can execute does not mean it should execute everything. The human's job is to decide what needs to be built, why it matters, and whether it is any good.

Do not hand that job over to AI. Each step in this framework asks the same question: where does AI fit, and where does the human need to stay in charge?

Think

The first step is thinking, and this is where a plain chatbot is useful if you stop treating it like an answer machine. Use it to understand the problem before you ask it to solve the problem. What are we actually trying to do? Who is this for? What would make this useful? What constraints matter? What are we pretending not to know?

I do this constantly. Before I ask AI to make something, I want it to help me pressure test the shape of the thing. Sometimes I ask it to argue against my first instinct. Sometimes I ask it to name the hidden assumptions in a plan. Sometimes I give it a half-formed idea and ask, "What are the things inside this story that are fighting each other?"

Most weak AI work starts with a fuzzy ask. The model did not fail because it was dumb. It failed because I handed it a foggy thought and asked for a finished artifact. Thinking clears the fog. Use AI to augment your thinking.

This is why I like Claude's and ChatGPT's voice experiences so much. When I am driving, I will talk through an idea out loud and let the model push back on it. I have to watch for agreeableness, because these tools are very good at making a half-baked thought feel profound. But when I use them well, they help me expand the thought before I turn it into work.

Plan

Once the problem is clearer, plan the work. This is the step people skip because it feels slower and requires real human labor. AI can make us feel overwhelmed because it might output eight pages of content, then we have to read it, understand it, and decide what matters. I know. It is tough. But taking this part seriously makes every other part easier.

A good plan tells AI what order to work in, what to ignore, what quality bar to hit, and where a human needs to make the call.

If I am building a strategy deck, the plan might include the objective, the story arc, the audience, and the decision I want the room to make. If I am building a workflow, the plan might include the trigger, decision points, failure cases, and what happens when the output is bad. If I am coding, the plan might include file changes, tests, and the places where I want the agent to stop before moving on.

The point is the same in each case. Stop asking a probabilistic tool to guess what "good" means. It is your job to define it.

Build

This is the part everyone can see, and honestly it still feels like magic. I love it. The prompt. The document. The workflow. The code. The first pass. The version you can react to.

AI is very good at turning a clear plan into an artifact.

For me, this is where the productivity jump feels real. I can move from "I think there might be an idea here" to "here is a draft we can argue with" in minutes. That matters because reaction is easier than creation.

Once something is on the table, you can see the awkward logic. You can see the missing edge case. You can see the sentence that sounds right but says nothing. You can see the workflow step that would break the first time a real person used it. AI gives you the object faster. Your job is to keep your taste awake. Humans define what good is.

Run

Sometimes running is simple. Press go. Send the email. Publish the draft. Run the script. Use the checklist. The AI helped you make the thing, and now you use it. The more interesting version is when the thing starts running without you.

This is where people get loose with the word autonomous. Autonomy is not "AI did a task once." Autonomy means you know how the system behaves when you are not staring at it. What triggers it? What inputs does it trust? What happens when the data is weird? Where does it stop? Who reviews it? What logs are kept? What does it do when it is unsure?

If you do not answer those questions, you did not build an autonomous system. You built a cool demo. Cool demos are fine. I love a cool demo. But a demo is allowed to be fragile because the builder is standing right there. A system has to survive contact with the real world.

Evaluate

The final step is evaluation. This is the part I care about most because this is where the loop either becomes useful or dangerous. You look at what came back and use your judgment. Is this good? Did it do what I needed? Did it solve the actual problem, or just produce something that looks like a solution? What would fail if I put this in front of a customer, a teammate, a student, or a friend?

This is also where intent engineering matters. Prompting matters, but intent sits above it. You have to define what good means before you can ask a system to help you get there. For small work, evaluation can be human judgment. Read it. Try it. Break it. Ask whether you would put your name on it.

For bigger work, you need evaluation that scales. That is why I like building LLMs as judges. I am not trying to replace human judgment. I am trying to turn judgment into a repeatable check. If a workflow is going to run fifty times, five hundred times, or five thousand times, I do not want to inspect every output from scratch. I want a judge that can look for the things I care about, flag weak outputs, and tell the system when to loop back.

The human still owns the standard. The system helps apply it.

Becoming an AI Native Means Being an AI Scientist

One of the most useful skills right now is learning how to build and work the loop.

AI natives think with AI before they ask it to build.

They plan enough that the output has a chance.

They build quickly without confusing speed for quality.

They run the work in the real world and have AI help automate things.

Then they evaluate with enough judgment to know whether the whole thing was worth doing.

That is the skill I am trying to build in myself. It is also the skill I am trying to teach others.

The people who learn the loop are getting faster, but speed is not the interesting part. They are getting better at turning intent into reality without giving up ownership of the intent.

The machine can run the loop faster. The native knows why the loop is running.