Moving at the Speed of Articulation

Software used to move at the speed of implementation. You had an idea, then you had to translate that idea into code and, for some, this was the largest bottleneck. You needed to understand the language, the framework, the libraries, the APIs, the deployment process, the database, the error states, the edge cases, and all the small details that sit between imagination and a working system. That friction was annoying and protracted, but it had a purpose. It forced you to stay close to what you were building. Instead of becoming more intimate with the code, we are being distanced from the source of truth. Code is truth for computers, and eventually for humans too.

Now that is changing. With AI agents, software can increasingly be built at the speed of articulation. As fast as you can describe something, an agent can begin turning it into code. You can explain a product, a feature, a backend service, a UI, a script, or an internal tool, and within minutes there is something real in front of you. The bottleneck is no longer just typing, remembering syntax, or knowing every library by heart. The new bottleneck is the clarity of the idea itself. How deep is the thinking? How divergent is it? And how much motivation do you have to actually deliver on the vision?

This is where the danger starts, because articulation is not the same as understanding. Being able to describe what you want is not the same as understanding what should exist. Being able to generate software quickly is not the same as engineering software well. Agents can compress the distance between thought and implementation, but they do not remove the need for judgement. They may even make judgement more important. The faster software becomes to create, the easier it becomes to create too much of it.

The slowdown moved

Before agents, code had a natural resistance to it. If you wanted to build something, you had to touch the system directly. You had to write the files, wire things together, read the errors, inspect the database, understand the behaviour, and slowly form a mental model of what was happening. This was slow, but it made you aware of the system’s shape. You felt the complexity as you created it. Complexity was a mental dial you could turn up and turn down depending on the environment you were operating within.

Now an agent can create that complexity for you. It can generate interfaces, APIs, routes, tests, authentication, schemas, middleware, background jobs, deployment files, documentation, logging, retries, abstractions, and helper functions before you have even fully decided whether the system needs to be a CLI tool or a web app. That looks like speed, and sometimes it is speed. But sometimes it is just deferred cost.

The bottleneck did not disappear. It moved from writing code to understanding the consequences of code. This is the part that gets missed in a lot of conversations around agentic engineering. The value is not simply that agents can produce software. The value is that agents can produce software under human direction. But if the human direction is vague, lazy, or detached from the actual code, the agent fills in the gaps. Agents are very good at filling gaps and every time a gap is filled that you are numb to, your engineering edge erodes. It is useful when the gap is mechanical. It is dangerous when the gap is conceptual and abstract.

Agents do not have strict_mode=true

Agents do not naturally stop at the smallest useful implementation. They expand, infer, complete patterns, and generate things that look like they belong in a mature codebase, even when the project is still at the stage where one clear function would have been enough. A simple script becomes a mini-framework. A basic CRUD app gets service layers, repositories, DTOs, validators, adapters, config managers, and dependency injection. A landing page becomes a design system. A local automation gets queues, workers, retries, telemetry, plugins, and an admin interface.

None of these things are inherently bad. In the right context, they are useful, and sometimes they are necessary. But the issue is not whether those patterns are valid in general. The issue is whether they were earned by the specific system in front of you. Agents do not have strict_mode=true. They do not naturally ask whether an abstraction is needed, whether the solution could be one file, whether the control flow will still be understandable in six months, or what the smallest version is that solves the actual problem.

Unless you force those constraints, the agent will often produce the most plausible implementation rather than the most necessary one. That is a subtle but important difference. Plausible code is code that looks like it could belong. Necessary code is code that has a reason to be there. Agentic engineering becomes dangerous when we confuse the two.

The fast car and the long road

Using agents can feel like driving a fast car. You press the accelerator and things happen. Files appear, components form, APIs connect, tests run, and the repo starts to look alive. But speed by itself is not efficiency. A fast car on the wrong road can arrive at the same time as a slow car on the right road. It may even arrive later. It burns more fuel, creates more stress, and gives the illusion that speed solved the problem, when really the route was bad.

That is what agentic engineering can become. You can use the fast car, generate an entire architecture, and feel like you moved quickly. But if the result has twice as many files as necessary, five abstractions you do not need, unclear control flow, and a mental model that only the agent seems to understand, then the cost has not disappeared. It has just moved down the road.

You pay it when you debug. You pay it when you return to the project two weeks later and have to rebuild the system in your head. You pay it when a small change touches six files, when the test suite passes but the behaviour is wrong, or when production breaks and you realise you do not understand the system deeply enough to fix it without asking another agent. That is cognitive fuel, and agentic software can burn a lot of it. The mistake is thinking that because the car is fast, the route no longer matters. The route matters more now than ever before.

Engineering is constraint, not generation

The act of producing code is not the same as engineering. Engineering is not just creation; it is constraint. It is deciding what should not exist. It is resisting unnecessary structure. It is choosing the boring path when the boring path is correct. It is understanding the failure modes. It is knowing which abstraction will help and which abstraction will quietly poison the codebase.

Agents are very good at generation, but engineering is not generation. Engineering is judgement under constraints. The real work is often subtractive: removing code, collapsing layers, refusing premature abstractions, keeping the system small enough to reason about, and building the version that solves the problem without trying to impress anyone.

A good engineer does not just ask whether something can be built. They ask whether it should be built, whether it should be built now, what the simplest version looks like, what will break and when, who has to maintain it, what assumptions are being made, and what can be removed. This is where agentic engineering needs discipline. The agent can produce options, but the engineer has to constrain them.

Without that constraint, the agent becomes a complexity amplifier more than a productivity one. It takes vague intent and turns it into a large, polished, coherent-looking structure. The output may feel productive, but productivity is not measured by how much code exists. It is measured by how much useful behaviour exists relative to the complexity required to support it. A thousand lines can be progress. A hundred lines can be better engineering.

Humans are also terrible at measuring their own productive strides. You can feel insanely productive on one day and spend the rest of the week paying for it because the things you marked as complete were actually poor decisions that birthed complexity.

Coherent does not mean correct

One of the more dangerous things about AI-generated code is that it often looks good. The naming is clean, the formatting is consistent, the folder structure seems sensible, the comments sound professional, the tests look like tests, the error handling looks responsible, and the abstractions appear familiar. This is exactly why it can be risky.

Humans are vulnerable to polish. When something looks coherent, we are less likely to interrogate it. We give it the benefit of the doubt. We assume there is a reason for the structure because the structure looks like something we have seen before. But coherence is not correctness.

A test can look useful while testing the mock instead of the behaviour. An auth check can look sensible while missing the real privilege boundary. A database migration can work locally while breaking existing production data. A retry system can hide the actual failure. An abstraction can look mature while making every future change harder. AI-generated code can be coherent in the same way a hallucinated essay is coherent: structured, readable, and wrong in ways that are easy to miss.

This does not make agents useless. It means their output should be treated like an untrusted pull request. Readable code still needs to be understood. Passing tests still need to be inspected. Clean architecture still needs to be justified. Every abstraction should have to earn its place, especially when it arrived instantly. It is time the magician reveals his tricks.

Prompting is not engineering

There is a temptation to think that because prompts can produce code, prompting is becoming engineering. It is not. Prompting is the expression of intent. Engineering is the process of turning intent into a reliable system under real constraints.

A prompt can say, “Build a scalable SaaS platform.” Engineering asks: scalable to what, for whom, with what budget, against what failure modes, with what data model, and under what security assumptions? It asks what happens when payments fail, when the database is slow, when a background job dies, when a customer does something unexpected, when the system has to be maintained by someone who was not there when it was generated.

Agents can help answer these questions, but they cannot remove the need to ask them. This is the difference between a builder and an operator. A builder wants to see the thing exist. An operator wants to know what happens when the thing breaks. Agentic engineering makes building easier. It does not make operating optional.

That is why staying close to the code matters. If you let an agent build too far ahead of your understanding, you become dependent on the agent not just to create the system, but to interpret it for you. At that point, you are not really engineering. You are supervising a machine that is producing complexity on your behalf. That can work for prototypes, and it is remarkably useful for prototypes. It is dangerous for systems that matter or systems that will exist for a long time.

Staying close to the code

The answer is not to reject agents. Agents are useful and it is the modus operandi for many teams today. They compress implementation, reduce boilerplate, explore options quickly, and help with tests, refactors, documentation, migrations, scripts, debugging, and unfamiliar APIs. The issue is not using agents. The issue is using them in a way that moves you away from the code.

The best use of an agent is not to build beyond your understanding. It is to help you move faster while remaining inside your realm of understanding. That requires a different style of working. Ask for smaller diffs. Ask for the simplest working version. Ask the agent to explain tradeoffs. Ask what can be removed. Ask it to justify every abstraction. Ask it to write tests that prove behaviour, not just implementation. Ask it to show failure cases. Ask it to avoid frameworks until they are necessary. Ask it to use boring code. You are the operator, not the passenger. Do not let the minion overrule the mind that summoned it.

Review the output as if it came from an uninformed but capable junior developer who is fast, confident, and occasionally wrong. Treat it as acceleration, and acceleration needs constant steering.

The danger of building ahead of comprehension

The darkest version of agentic engineering is not that the software fails. Failure is normal. Bugs are normal. Bad code is normal. The darker risk is that the software works. It works well enough to ship, demo, sell, and build more on top of. But nobody really understands it.

The system becomes a place people can operate but not see, the codebase becomes a walk in a mirror maze instead of a walk in the park. They can deploy it, patch it, prompt against it, and ask another agent to modify it. But the human mental model gets weaker as the machine-generated structure gets larger. That is how you end up building a world for the blind: a world of systems that function, scale, and impress, while the people responsible for them slowly lose sight of their inner shape.

The problem is not that AI writes code. The problem is when AI writes the map, builds the roads, changes the signs, and the human in charge is only reading summaries. At that point, speed has turned into dependency, and dependency is not power.

The new engineer

The best engineers in the agentic era will not be the people who generate the most code. They will be the people who can think clearly enough to constrain generation. They will know how to articulate what they want, but more importantly, they will know how to define what they do not want. They will understand when to use an agent and when to stop. They will be able to read the code, challenge the structure, simplify the system, and keep the machine from turning every prompt into a cathedral of unnecessary potential.

The new engineer is not just a coder. They are an editor, a reviewer, a systems thinker, a constraint-setter, an operator, and an architect with a delete key. Agentic engineering changes the surface area of the job, but it does not remove the core responsibility. Someone still has to understand the system. Someone still has to know the road. Someone still has to decide whether the fast car is actually helping.

Software can now move at the speed of articulation. That is powerful. But articulation without understanding is just acceleration into fog. In the agentic era, speed belongs to the person who can articulate. Power still belongs to the person who understands.