Clear Specifications Are Becoming Everyone's Job

AI makes it possible to tell a computer what you want in ordinary language. That lowers the barrier once created by code, but it does not remove the need to think precisely. In fact, it exposes imprecision faster.

Yash Tekriwal’s original statement argues that computational thinking is becoming a general requirement for work.[1] When agents handle execution, a person’s contribution increasingly sits in the specification: defining the goal, breaking it into steps, naming inputs and outputs, and deciding what the system may infer.

For people new to AI, this is less about becoming a programmer than learning to make their own reasoning usable.

Plain English lowers one barrier

Before AI, Tekriwal says, code was the barrier to using the power of systems thinking. People first had to learn a computer language. Now they can direct systems in plain English, which opens that power to far more people.[1]

The access is new, but the underlying habits are not. Tekriwal points to first-principles frameworks, MECE strategy, and edge-case testing. He defines MECE as mutually exclusive and collectively exhaustive, a way of dividing a problem into categories that do not overlap and together cover the relevant ground.

These habits matter because much work consists of turning a messy goal into steps. A person must decide what information enters the process, what result should leave it, and where the machine should stop rather than infer.

My interpretation is that natural language can conceal this discipline at first. A conversational interface feels forgiving, so it is easy to write a vague request and expect the system to resolve everything omitted. The resulting output may sound complete while depending on assumptions the requester never intended. Plain English makes access easier, but it also makes the quality of the requester’s thinking more visible.

Specification becomes the human contribution

Tekriwal’s central claim is that when agents perform execution, human contribution “collapses into specification.”[1] The person who can describe the desired result precisely, in a form a system can act on, gains much more leverage than someone who only possesses information.

This is not the same as writing a long prompt. Length does not guarantee clarity. In my interpretation, a specification has to make the work actionable. It identifies the objective, required inputs, sequence or constraints, expected output, and conditions that count as failure.

The source does not provide a template, so the following is an interpretation of its logic. Before assigning work to an agent, write five short statements:

1. The result that is needed.
2. The information the system may use.
3. The steps or constraints that cannot be skipped.
4. The cases that require human review.
5. The form in which the result should be returned.

The value of this exercise is not bureaucratic completeness. It is to reveal decisions that were previously carried in someone’s head. Once those decisions are explicit, a machine can act more reliably and another person can inspect the process.

Instructions audit the quality of thought

Tekriwal describes machine instructions as an audit of the writer’s thinking. Every unexamined step and missed edge case can surface as a failure that slows the work.[1]

That can feel frustrating because a person may understand a task intuitively without being able to explain it. Familiar work often depends on quiet judgments: which request looks unusual, when a rule should bend, or what information is missing. Asking an agent to perform the task forces those judgments into view.

This is one reason automation attempts can be useful even before they are deployed. The attempt reveals whether the process is actually understood. If no one can state the inputs, decisions, exceptions, and acceptable result, the problem may be unclear rather than technically difficult. This is my interpretation, not a separate claim made in the source.

Tekriwal also links lazy writing to lazy thinking. His point is not about elegant prose. It is about hand waving. A machine cannot reliably execute an instruction whose crucial choices remain implicit, and a confident output does not repair the missing reasoning.

Engineering habits become universal

Engineers have long written specifications before coding because computers require precision. Tekriwal argues that this habit of mind, once an engineering necessity, is now a universal one.[1]

The word “universal” does not mean every person must use the same technical methods. It means more roles will face the same basic challenge: translating intent into a structure a machine can follow. Marketing, research, administration, sales, and other forms of knowledge work all contain goals that can be described badly or well.

A rigorous specification also helps with evaluation. If the expected output is undefined, a person can only react to the agent’s answer by instinct. When criteria are stated in advance, the reviewer can compare the result with the requirement. That does not eliminate judgment, but it gives judgment something concrete to inspect.

My interpretation is that this changes training priorities. Memorizing a tool’s interface may help briefly, while learning decomposition, boundary setting, and edge-case analysis remains useful across tools. Tekriwal’s thesis is about a durable way of thinking, not a particular product.

Precision is a form of responsibility

Computational thinking can sound mechanical, but Tekriwal’s argument gives people a larger role in deciding how systems act. If an agent executes the instructions, the person writing them must consider where errors will appear and who will be affected.

A useful specification therefore names uncertainty rather than hiding it. It tells the system when information is insufficient. It defines which decisions are safe to make automatically and which should be returned for review. It also avoids asking the machine to infer sensitive intent from weak signals. These are applications of Tekriwal’s emphasis on limits and edge cases.

The future he describes is not one in which clear instructions replace all expertise. It is one in which expertise must become communicable. Knowing something privately is less useful when the work depends on directing systems that need explicit goals and boundaries.

The practical starting point is simple: take one repeated task and try to write it so that someone without your background could perform it. Notice every place you rely on supposedly obvious context. Those gaps are where an agent is also likely to struggle. Improving the specification improves the thinking behind the work, whether or not the entire task is eventually automated.

If you want to turn a repeated task into a clear, testable specification, review the workflow with Agentic Workers.

Sources

[1] https://every.to/thesis-statements/yash-tekriwal