Back to the three questions from the earlier posts. What kind of programming profile do you have, tactical or strategic? How do you see yourself? And where are you: prompts, loop, or graph?

Still in prompts

Whoever is still in prompts asks for one thing, reviews all of it, then asks for the next. It is faster than working without an agent, and that is where the improvement stops. Every one of the decisions we have been looking at passes in front of you and depends on you spotting it by eye, in that moment, with nothing to remind you it was there. It works while the volume stays low and your memory holds.

Working in a loop

Whoever is in a loop has stopped trusting the agent when it says something works, and has put something outside it that checks. A test, a compilation, a run against real data. The loop does not remove the decisions nobody asked for. It removes the blindness about whether they turned out well.

But not all loops are worth the same, and that is the trap. A green test suite is a loop. So is comparing against a customer’s real month. Only one of the two would have caught the rounding error, the kind a green suite waves straight through. Being in a loop without asking yourself what you are checking against is stopping halfway.

Thinking in a graph

Whoever is in a graph has decided in advance where each type of decision lives and who has to see it before it moves on. They do not review everything by eye, as in prompts. They do not only check that the result works, as in a loop. They have placed a point in the flow where an architecture decision stops before it turns into code.

And this is not a ladder of merit. It is a diagnosis of which decisions you control and which ones the agent is taking without you noticing. You can be in a graph on the technical side and still be in prompts for everything that touches the business. In fact that is the most common case of all.

Where the line actually is

Cherny may end up being right. Models will probably get to the point of designing systems and delivering code without errors, and he certainly has more information than I do to say so. But in Business Central the system is not the code. The system is an ERP with twenty years of decisions inside it and a company using it every day to invoice. That context is not in any repository the agent can read.

Out of everything I have reviewed these last months, the piece of data that made me think hardest is not any particular failure. It is an asymmetry I did not expect to find. The agent caught practically every design decision that slipped past me without asking permission. I caught almost all of its own. But of mine, the agent caught exactly one. The rest were caught by whoever had the business in front of them, or by execution against the real system.

That is the frontier Cherny was talking about, at least in our world. Not in writing AL, which we already lost. Not in reviewing code, which we are losing. It is in knowing what is being decided and what gets lost with each option, in a domain where the right answer depends on data only you have. Ng calls it supplying the context. I would call it, plainly, remaining responsible for what gets shipped.

And now the question I will leave you with, which is the same one I asked myself. Next time an agent hands you an extension that compiles, passes the tests and does exactly what you asked for, go and find a single decision it took that nobody asked it to take. A field type. An event to hook into. A test that does not clean up after itself.

If you cannot find one, it does not mean it did not take any.

It means you are not looking yet.

Graph Saga

This post is part of the Graph Saga, a series about what I am learning and needing around agentic AI applied to code, and to projects like ALDC. The aim is always to bring it closer to Business Central. Not every post will do that on the surface, but underneath and between the lines it is there.