Does prompting need the same skills as coding?

This tweet came out of a thread about whether prompting is a skill at all, and it describes how prompting requires the same skills as coding. “Mental models re managing abstractions …, practices to reify toward clarity, … self-skepticism and bias management” — I like this list! But is it the whole story? Does prompting need the “same” skills as coding?

I don’t think so. It’s about … 70% true, but the missing 30% is the interesting part.

First, it’s worth noting the obvious, which is that compared to coding, agentic development via prompting needs less skill in … coding. You don’t need to remember all the APIs, since the AI knows them fine. You probably don’t need to remember how to implement a breadth-first search, or fetch data from a URL, since the AIs know that kind of boilerplate cold.

But what about mindset? Compared to coding, agentic development does need the same epistemic discipline regarding clarity and self-skepticism, especially to validate results and to build incrementally within the limits of one’s own clarity and of the tool’s capability. This discipline is what makes some folks much more effective, and why the best agentic developers are often excellent software developers.

But is this really the “same mental model re abstractions”? Not exactly. Of course agentic tools generate code, so reading the code needs the same code-level abstractions it always did. But who is reading it all? Code is too low-level for it to be worthwhile to read it all, which is why vibecoding exists.

The benefit of agentic development is exactly that it lets you work with higher-level objects than a line of code, objects like features, system components, and the interfaces which connect them. So we need higher-level abstraction, above the level of a line of code, to understand and steer agentic work.

In fact, we need these abstractions urgently, because AIs are so fast at generating code that they create a lot more code which needs higher-level, architectural oversight. And, as others have noticed, AIs are not great at architecture themselves. They love to add code, and resist deleting it. They do not refactor much on their own. They focus single-mindedly on the next thing to do, and do not keep the big picture in view.

So to operate at this higher level and maintain oversight, what do we do? What we actually end up doing is relying on the other thing these tools generate — plain language. That is, we just talk to them.

And how well is that working out? Well, language can be a great abstraction for steering large-scale work. Obviously, many managers have operated at this level very successfully for all of history. But that does not mean it’s optimal. Although the benefit of language is that it can be as abstract or as detailed as you want, the downside is that this also allows it to be vague, so it is only as precise as the speaker who wields it. A drunkard and an analytical philosopher both speak English, but very differently. Language itself does not enforce precision like code or mathematics.

But the problem is worse than sloppy speakers. Even when we try to write precisely, we often simply do not know how to describe these higher-level architectural concerns very crisply. It is much easier to unpack what we mean by “make these tests pass” than “refactor this codebase to be more logical”.

As a result, language is really not as precise and efficient as one would like for software development. This produces many of the frustrations with current agentic development workflows.

But I think we’ll find something better.

One early hint of this is in workflows where agents generate in every turn not only running code and verbal replies, but also one-off, high-bandwidth HTML artifacts, designed for efficient communication, like UML diagrams of module interfaces and internal architecture.

We don’t have mature tools for this, as we do with IDEs or editors for handling code at the text-editing level, because we’re totally unfamiliar with being able to work so rapidly at this level of abstraction. In the past you might sketch a diagram on the whiteboard as part of an exploratory conversation about hours of work to be undertaken later. But you would only generate a complete diagram rarely, maybe to memorialize tribal knowledge for new developers. It would take hours. You couldn’t do it literally every couple minutes as a way to actually represent and steer work underway on such large quantities of implementation. But now we can do this, so we’ll figure out how.

In short, prompting and agentic development does not require some skills which coding needs, but it does require some of the same skills, and it also requires some new skills which we are all still inventing.

• Self-evidently, it requires less skill at detailed line-by-line coding, because the AIs are quite good at it, especially at remembering APIs and at the boilerplate which is most of programming.

• It requires much of the same epistemic discipline as software development, around clarity, testing, and incrementalism.

• It requires more skill in large-scale architectural thinking, because even the best agents are pretty bad at this right now, and because the agents are so fast at coding that suddenly there’s a lot more architectural thinking to do.

• And finally, it requires more of some skill or workflow that none of us have: working at this higher level of abstraction but with speed and precision, using a medium more precise than language but more efficient than code and ad-hoc HTML pages, a medium which we have not invented yet.