Frontier models are starting to change the shape of AI work. The earlier pattern was mostly conversational: ask, receive, correct, ask again. The newer pattern is more agentic: give the model a goal, let it work through multiple steps, and bring the human back when the condition is met or when intervention is needed.
That shift matters for knowledge workers. It starts to solve one of the old frustrations of working with AI: the need to keep prompting every small step. Instead of repeatedly nudging the model through a sequence of tasks, the user can define the outcome and let the agent carry more of the execution.

That is the shift worth paying attention to. I can see why it matters. I can also see why I am not ready to use it for every build.

In an AI-assisted build, the brief is often discovered after the work begins.
That sounds inconvenient because it is. It is also normal. A project can start with a clear direction and still lack the level of specification needed for an agent to build the whole thing correctly from one instruction.

That was the case while building the below4k.ai website. I knew broadly what I wanted. Some parts were already quite detailed in my head. But the details were not yet organised into a complete build specification. If I had tried to hand the whole thing to an agent at once, I would have left out important requirements. The agent would then have had to fill those gaps with assumptions.
That is the practical reason I stayed very human-in-the-loop.
The loop was simple: prompt, inspect, notice what was missing, clarify, continue. Each output became a review object. It showed where the instruction had been vague, where a decision had not been made, or where I had assumed context that only existed in my head.

This is not just correction after the fact. It is part of the thinking process. The work reveals the requirements.

I also kept the build segmented. In ChatGPT and Codex, I used similarly named projects and broke the work into smaller sessions with numbered, descriptive titles. That made the project easier to revisit. When something needed fixing, I had at least a rough map of where the relevant work had happened.

One small example: the session structure itself became part of the build method. I did not just ask for "the website" and wait for a finished result. I worked through smaller components in separate sessions, gave them titles that matched the job, and kept enough context to know where decisions had been made. That is not elegant automation. It is basic project legibility. But it meant a later fix had somewhere to start.

This may look slower than giving an agent a goal and letting it run. In the short run, it is slower. It requires review, re-prompting, side notes, and a certain amount of supervision. But it keeps the build legible.
That legibility matters. A project that becomes hard to understand becomes hard to continue. The problem is not only that something breaks. It is that the owner no longer knows where to look, what to change, or how to judge whether the fix is sound.
This is where `/goal` and `/loop` become a useful contrast.
Those modes are attractive for good reasons. If the target is clear, the acceptance criteria are explicit, and the boundaries are well understood, it makes sense to let the agent handle more of the iteration. That is part of the point of using an agent at all.

The risk is using that pattern before the work is ready for it.
A long-running agent loop with an under-specified goal can produce a lot of movement. Files change. Errors get fixed. Components appear. The work looks active. But if the direction is wrong, the activity compounds the wrong assumptions. The cost is not only tokens. It is also the cost of untangling a build that no longer matches the user's intent.
Worse, once the build becomes opaque, the user has to rely on the agent not only to build, but to understand, diagnose, and repair the system. That can work. It can also leave the user with very little independent judgement over the project.

So the trade-off is not simply speed versus slowness. It is autonomy versus specification. The more autonomy the agent has, the more important it is that the goal, constraints, and acceptance criteria are clear.

For this website build, close involvement was the more sensible trade-off. It preserved understanding while the project was still taking shape. It made each prompt a chance to refine the brief. It kept future fixes from becoming too mysterious.

That does not mean human-in-the-loop should be the permanent ideal. A better workflow would let the agent take on more mundane iteration once the direction is stable. That requires better goals, sharper acceptance criteria, and review points that make it possible to step back without losing the thread.

Until then, `/goal` can be too early. Not because agents cannot work autonomously, but because autonomy needs something solid to aim at.

Frontier models are starting to change the shape of AI work. The earlier pattern was mostly conversational: ask, receive, correct, ask again. The newer pattern is more agentic: give the model a goal, let it work through multiple steps, and bring the human back when the condition is met or when intervention is needed.
That shift matters for knowledge workers. It starts to solve one of the old frustrations of working with AI: the need to keep prompting every small step. Instead of repeatedly nudging the model through a sequence of tasks, the user can define the outcome and let the agent carry more of the execution.

That is the shift worth paying attention to. I can see why it matters. I can also see why I am not ready to use it for every build.

In an AI-assisted build, the brief is often discovered after the work begins.
That sounds inconvenient because it is. It is also normal. A project can start with a clear direction and still lack the level of specification needed for an agent to build the whole thing correctly from one instruction.

That was the case while building the below4k.ai website. I knew broadly what I wanted. Some parts were already quite detailed in my head. But the details were not yet organised into a complete build specification. If I had tried to hand the whole thing to an agent at once, I would have left out important requirements. The agent would then have had to fill those gaps with assumptions.
That is the practical reason I stayed very human-in-the-loop.
The loop was simple: prompt, inspect, notice what was missing, clarify, continue. Each output became a review object. It showed where the instruction had been vague, where a decision had not been made, or where I had assumed context that only existed in my head.

This is not just correction after the fact. It is part of the thinking process. The work reveals the requirements.

I also kept the build segmented. In ChatGPT and Codex, I used similarly named projects and broke the work into smaller sessions with numbered, descriptive titles. That made the project easier to revisit. When something needed fixing, I had at least a rough map of where the relevant work had happened.

One small example: the session structure itself became part of the build method. I did not just ask for "the website" and wait for a finished result. I worked through smaller components in separate sessions, gave them titles that matched the job, and kept enough context to know where decisions had been made. That is not elegant automation. It is basic project legibility. But it meant a later fix had somewhere to start.

This may look slower than giving an agent a goal and letting it run. In the short run, it is slower. It requires review, re-prompting, side notes, and a certain amount of supervision. But it keeps the build legible.
That legibility matters. A project that becomes hard to understand becomes hard to continue. The problem is not only that something breaks. It is that the owner no longer knows where to look, what to change, or how to judge whether the fix is sound.
This is where `/goal` and `/loop` become a useful contrast.
Those modes are attractive for good reasons. If the target is clear, the acceptance criteria are explicit, and the boundaries are well understood, it makes sense to let the agent handle more of the iteration. That is part of the point of using an agent at all.

The risk is using that pattern before the work is ready for it.
A long-running agent loop with an under-specified goal can produce a lot of movement. Files change. Errors get fixed. Components appear. The work looks active. But if the direction is wrong, the activity compounds the wrong assumptions. The cost is not only tokens. It is also the cost of untangling a build that no longer matches the user's intent.
Worse, once the build becomes opaque, the user has to rely on the agent not only to build, but to understand, diagnose, and repair the system. That can work. It can also leave the user with very little independent judgement over the project.

So the trade-off is not simply speed versus slowness. It is autonomy versus specification. The more autonomy the agent has, the more important it is that the goal, constraints, and acceptance criteria are clear.

For this website build, close involvement was the more sensible trade-off. It preserved understanding while the project was still taking shape. It made each prompt a chance to refine the brief. It kept future fixes from becoming too mysterious.

That does not mean human-in-the-loop should be the permanent ideal. A better workflow would let the agent take on more mundane iteration once the direction is stable. That requires better goals, sharper acceptance criteria, and review points that make it possible to step back without losing the thread.

Until then, `/goal` can be too early. Not because agents cannot work autonomously, but because autonomy needs something solid to aim at.