Photo by NEW DATA SERVICES on Unsplash
Recently, while adapting a side-by-side visual testing skill, I had a strong feeling.
There are many skills, prompts, and workflows available in the public square. Many of them look complete. They have inputs, steps, checklists, output formats, and evaluation rules. But once you actually use them, most of them do not directly solve the problem.
Not because they are useless, but because they are not yours. They carry someone else's judgment, someone else's taste, and someone else's default way of working. The useful move is rarely to use them as they are. It is to take them apart, keep what works, and rebuild them into a tool that fits your own workflow.
I increasingly feel that today's software production still carries the shadow of physical manufacturing.
It looks like an assembly line.
The Assembly Line Still Shapes Software Work
A lot of today's software workflow still carries the shadow of physical manufacturing. It is organized like an assembly line. PMs translate user needs and business judgment into PRDs. Designers translate functional descriptions into experience design. Engineers translate requirements and design into executable code. Analysts then translate shipped behavior into experiments, metrics, and the next round of decisions.
Historically, this sequence was necessary because the bandwidth between people was limited. Product had to clarify the requirement before design could start. Design had to produce the experience before engineering could implement it. Engineering had to ship before analysis could measure it. Sequence was not just a management preference. It was a production constraint.
But if one of AI's core functions is to make these translations almost real-time, the sequence itself starts to lose meaning.
From Sequential Handoff to Synchronized Production
If a high-quality PRD can almost instantly produce the design spec, technical spec, implementation, and experiment spec, then finishing the PRD does not mean one stage is complete, nor does it simply trigger the next stages. It means the production system has reached a verifiable result almost synchronously.
The same should be true from other directions. A strong design spec should not merely be a handoff document for engineers. It should be able to produce product logic, technical breakdowns, experiment plans, and the final implementation almost at the same time. A strong technical spec should not merely describe implementation. It should also produce product constraints, experience boundaries, validation paths, and the resulting product.
That is the real promise of agent-powered digital production. It is not about making the old assembly line faster. It is about making multiple stages of the assembly line happen almost simultaneously in digital space.
This also changes what each role needs to become good at. The point is not for product managers to master design, engineering, and analytics all at once. It is not for designers or engineers to absorb every upstream and downstream capability. The point is to understand what a good artifact means.
A good artifact is not only legible to humans. It is also hard to mistranslate. It carries enough judgment, constraints, context, and validation logic for agents to translate it reliably into the specs other roles need, and in some cases directly into the production result.
So the core capability of each role may not be mastering the whole assembly line. It may be two things: producing the highest-quality artifact from the role's own strongest point of view, and owning translation tools that fit that role's style of delivery. Different roles can enter from different points. If the artifact is strong enough, the system can translate it, complete it, verify it, and produce from it.
This discussion is about the production of already defined ideas, not the discovery or definition of the ideas themselves. Finding the right problem is still a different process, and probably a harder one.
You can already see an early version of this pattern in simple web-based products. Each step looks small on its own. But together, this is no longer the old process of writing a document, handing it to someone to design, and then handing that design to someone else to implement. It is a clear expression being translated into different levels of representation. In simple web products, the shape of this future is already visible.
Tools Should Become Our Own Versions
The point is not merely about personal tools in the narrow sense of private scripts or individual workflows. The larger shift is that almost every tool we use today should be understood as something that can be produced, modified, and reshaped with AI.
In the past, tools were usually environments defined by someone else. The public version, the team version, or the vendor version shaped how people worked. AI changes that. Tools themselves become producible objects. A skill, an agent, a testing framework, a markdown-to-html pipeline, or a UI generator constrained by a design system is no longer just something to use. It is something that can be rebuilt into a version that fits the user, or created from scratch when needed.
This is why relying heavily on public, generic, or someone else's version of a tool may become less sufficient over time. Public tools can be references and raw material, but they should not be treated as the final form. A valuable tool should understand the user's judgment, expression habits, quality bar, and taste.
This is not only about efficiency. It is also about experience. A person's work is probably made of three things: capability and experience, personal taste, and agency. AI will flatten the first one. The third one, agency, still cannot be outsourced. The easiest one to ignore is taste.
AI systems and public templates both carry default taste, and often that taste is mediocre. If tools cannot be reshaped into versions that fit their users, workflows will gradually be taken over by those defaults. Custom tools and custom workflows are, in a very real sense, ways of preserving taste.
Design Frameworks with Autonomy in Mind, Not Agent-Powered SoPs
So the thing to be careful about is not whether to use AI in the process, or whether a tool calls itself agentic. The real issue is an old imagination of production. It assumes work must first be decomposed into a fixed SoP, and then AI or agents can be inserted into each step to make that path faster. Many so-called agentic tools still think this way. They replace people inside the assembly line with agents, but the assembly line remains the underlying model.
If people and agents are really becoming a more autonomous and decentralized system, we should not design that system from the perspective of SOPs. SOPs care about sequence. Complex systems care more about boundaries, interfaces, feedback, constraints, and evolution.
Future software production may look less like a line and more like a field. What is shared is the framework, the quality bar of the spec package, the translation protocol, and the way outcomes are verified. Different roles can enter from different points. If their artifact is strong enough, the system can translate it, complete it, verify it, and produce from it.
If AI truly changes how software is made, it will not only change speed. It will change the sequence itself.