It’s this, and it’s fairly simple: the better I understand, on a fundamental level, what the solution is actually for - the business outcome, how it should behave, and why - the easier building gets.
Why?
Well, if I know the purpose, I can define what “done” looks like. And once “done” is defined, testing the solution end to end and validating that it actually works stops being guesswork.
And here I’m not primarily talking about automated tests, TDD and all that, as I believe those are a given when writing code, and agents are generally good at writing tests. I’m talking more about thoroughly testing the solution out, as a user, and being able to say “right ok, this works well, and the expected outcome is met”.
That sounds obvious until you watch what happens when a clear purpose and definition is missing. The problem (and the blessing) of working with agents is that they are exceptional at scope creeping. Agents are brilliant at finding additions you didn’t think of, things that sound great but aren’t really must-haves. The popular “Plan Mode” that exists in basically every agent harness is a good example - not because it’s a bad feature, but because it amplifies whatever clarity you bring. Arrive with a clear outcome in your head, and it sharpens it. Arrive vague, and the agent happily fills the vacuum for you - and the initial scope balloons. This is why knowing the business purpose, what the expected outcome should be, and generally having somewhat of a plan in your head already, before talking to an agent, is crucial.
Personally though, I tend to stay away from Plan Mode. If I need to plan anything with my agent, I just talk to it, and we flesh out the ins and outs of what I need it to build. “Isn’t that what Plan Mode is?” Not really - when we just talk, the plan stays in my head and I remain the filter for what makes the cut. In Plan Mode, the agent becomes the author of the plan, and agents optimise for plans that look complete, not plans that are right. It’s not more complicated than that, and I’ve had amazing results with it.
And let’s not even go into SDD (Spec driven development), SpecKits and all that, which tends to produce an ocean of markdown documents with 20 different “perfectly defined” phases, which no one reads. And you wonder in the end, “why on earth was this built?”. Surely, this isn’t the way to build software…
Clarity flows downhill
When you actually know the outcome, two things that used to be hard stop being hard.
You can steer the agent properly. Nowadays, most of the work of prompting isn’t clever wording, it’s knowing what you want clearly enough to specify it. In my experience, most of the hard architectural calls resolve themselves the moment the direction is clear to me. And to make sure that the agent actually understands what we aim to do and why, I sometimes tell it to explain it to me, in a “talk out loud” style, in short. This way, I am able to quickly catch if there are any misunderstandings.
You can test end to end, and validate that the solution does what the user needs - and this is the big one. If you know what the outcome should be, you can actually verify it: run it through the variations, the edge cases, the inputs you didn’t think of first, and check it against a real bar instead of just trusting that it works. Once you have tested it, a simple “Is there anything I’ve missed in testing, any edge cases I should be aware of?” goes a long way - more often than not, the agents have something clever to add.
Why this matters more now
Someone will say QA, testing, and clarity always mattered. True, but agentic engineering changed the stakes at a pace we’ve never seen before.
Before, code was written by humans, at human speed. Ironically, the pace was a safety net on its own - you could only ship so many bugs in a day, and the friction of typing it all out caught some of them. As for the “human reviewed it line by line” story - that was always half a myth: in plenty of big organisations, reviews were just classic approve, merge, move on - we test in production, right?!
Agentic engineering didn’t break that, it removed the slack that was hiding how thin it already was. Output now arrives faster than the old safety nets were built to catch. The bar didn’t move, the margin for missing it did. Miss it now, and you’re shipping slop at inference speed.
The driver should know the destination
Agents write the code, good code. It’s fine at that now, given a decent setup and a bit of guidance. What it can’t do is decide where you’re going, because you never gave it the whole picture - the business context, the users, the outcome that makes one solution right and another merely functional. That picture is yours to supply, and it doesn’t stop at context. If I give an agent the right tools and the freedom to research, explore and debug a solution end to end on its own, it gets the full picture and produces much better results. It’s a big part of why I built a CLI for Umbraco - giving the agent first-class tools to explore the system it’s building against, instead of guessing.
We’ve outsourced some of the thinking, and that’s fine. But some critical aspects still need to remain with us, such as being the drivers of the “Why”.
That’s the job that didn’t get automated, and won’t any time soon. Not typing the code, remembering the syntax and all of that, it’s knowing the destination clearly enough that you can tell, when the agent gets you somewhere, whether it’s actually where you needed to be, and if it’s good enough or not.