Moving at the Speed of Articulation — Hisham Thabet

Copy post 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...