We read it constantly lately: "I used an agent and did in one hour what used to take days." The "good old days" of writing syntax are fading. We are entering the era of vibe coding—where we skip the boilerplate and stay in the creative flow. The situation has changed, and agents are here to stay. The question is no longer if we use them, but how we stop them from making a mess.
In this post, I want to focus on why a strict Design System is more relevant than ever in the age of Agentic Programming.
Agents love patterns
If agents excel at one thing, it’s pattern matching. LLMs are trained to predict the average of the data they consume. Therefore, boilerplate code is easy for them to predict, while unique, "clever" business logic is harder.
This means the best thing we can do for our AI agents is to normalize our code. We need to reduce the cognitive load not just for humans, but for the models. If the codebase is standard, the agent can replicate it. If it’s chaotic, the agent will hallucinate.
The "Just create a new one" trap
We all know how the story goes. Product comes with a new use case. The user needs to choose from a list, but the options are complex. Design provides a perfect solution: "Let's add a description and icons to the Select component."
Then Engineering faces reality. We have a similar component, but it can't handle icons. We can't update the current one without breaking ten other pages. We don't have time to refactor. So, the decision is made: "Let's create a new component. We’ll clean it up later."
Big corporate codebases are graveyards of these decisions. It is incredibly hard to maintain consistency as teams scale.
Inconsistency breaks the "Vibe"
Until now, we could work around these issues. A senior developer could mentally parse the difference between SelectDropdown and SelectDropdownV2. We could survive the tech debt.
However, Agentic programming changes the math. Agents look at the environment to understand how to build. If an agent sees three different versions of a Select component, it creates friction. This is where AI wrangling begins—you stop coding and start babysitting the agent because it doesn't know which pattern to follow.
Suddenly, the productivity promise of vibe coding vanishes.
Design Systems are a language, not a UI Kit
A Design System is not just an engineering problem. It is a language definition. It defines how the business is expressed. It is the common ground between Product, Engineering, and Design.
Time is precious and shortcuts are tempting, but everything has a cost. The importance of consistency starts at the design phase. If we allow for slight variations in UI, we force the creation of new component variants in code. This "drift" degrades the accuracy of the agent later on.
Conclusion
The boundaries between Product, Design, and Engineering are dissolving. It is becoming obvious that optimizing earlier in the process—creating a rigid, clear system—brings massive performance gains in the implementation step.
Clarity and alignment are our human responsibility. If we handle the definition, we can let the Agents handle the implementation.
Top comments (0)