AI Is Not Changing Professions. AI Is Changing Processes

Everyone is talking about new models. Over coffee, in elevators, at conferences, and in work chats, people compare which one writes better code, which generates interfaces more accurately, which thinks faster, and which has the larger context window.

But the more I work with AI, the less the final result depends on the choice of model. Increasingly, the difference between a strong result and a weak one lies a level higher — in how the process around the model is designed.

The model is only one layer

Even the strongest model starts making mistakes if it does not know the project architecture, uses outdated documentation, or does not understand where the source of truth lives. It can generate a polished screen while creating yet another button instead of using a design‑system component. It can write working code that violates the team’s internal rules. It can confidently recount a decision that no one ever made.

That is why, today, I am interested not only in “which model to choose,” but in other questions:

how project context is stored and updated;
where the record of decisions lives;
which Skills are available to the agent;
which MCP servers and work systems it can access;
which actions it can perform independently;
where human approval is mandatory;
how the result is validated before it reaches production.

The model is responsible for reasoning and generation. The process ensures that both happen with the right data, within acceptable boundaries, and with predictable validation.

One specialist becomes a multitool

Digital tools used to enhance one part of a profession. Figma helped designers create interfaces, an IDE helped developers write code, and Jira helped teams manage tasks. An AI agent can cover an entire sequence of actions: read a task, find the context, modify files, run checks, and prepare the result for review.

This changes the specialist’s role. They do not necessarily perform every step by hand. Increasingly, they define the goal, assemble the context, distribute the work, set constraints, and evaluate the result. The result is a human multitool who manages several modes of production at once.

This does not mean that one person suddenly becomes an expert in every profession. On the contrary, domain expertise is still required to frame a task correctly and notice an agent’s mistake. What changes is not the value of knowledge, but where it is applied — from manually performing every step to designing the entire system of work.

Not one universal agent, but several roles

One long prompt quickly turns into a mess. Task definition, implementation, visual validation, documentation, and tests all get mixed together. The agent has to be both the author and the reviewer of its own work.

It is much clearer to divide the process into roles:

Research agent gathers context, finds existing solutions, and identifies constraints.
Development agent writes code within the chosen architecture.
Design‑system agent assembles the interface from real components and tokens.
Review agent checks the diff, rules, accessibility, and edge states.
Documentation agent updates specifications and examples after an API change.
Validation agent runs tests, builds, and visual comparisons.

You do not necessarily need to run six separate models. What matters is the separation of responsibilities: every stage has a specific input, an expected output, and a definition of done. The process can then be improved one part at a time, and errors are easier to isolate.

What one such process might look like

Imagine a typical task: adding a new state to a complex component.

The first agent reads the task and related decisions, then finds the component in the code and the design in Figma.
It checks the design‑system documentation, available tokens, and existing patterns.
The implementation agent modifies the component and adds the state without creating a parallel API.
A separate validation step compares the result with the design, looks for raw values, and checks keyboard navigation.
The testing stage runs type‑checking, unit tests, accessibility checks, and the build.
After all checks pass, the component documentation is updated and a short summary of the changes is prepared.
A person reviews the solution, any debatable points, and the final diff.

The value here is not that the agent can write JSX. The value lies in the connected chain, where context is not lost between stages and the output of one step becomes a verifiable input for the next.

Context becomes infrastructure

For this kind of work, pasting a fragment of a task into a chat each time is not enough. The agent needs a map of the project: the repository structure, accepted decisions, component APIs, naming conventions, validation commands, and the boundaries of permitted changes.

Some of this context is static and can live alongside the code:

AGENTS.md or project rules containing a map of the repository;
design‑system and component documentation;
machine‑readable tokens;
Skills containing repeatable workflows;
tests and linters that formalize constraints.

Another part changes constantly: task statuses, decisions made in meetings, owners, and current goals. It cannot be written once in Markdown and forgotten. What is needed is a living working‑memory layer that gathers data from source systems and returns it with links and dates.

That is why I am also building Halo: I want to explore how a single context layer can support both people and agents.

Skills turn experience into repeatable workflows

A prompt often remains a one‑off instruction. A Skill is an attempt to package a proven way of solving a task: when to use it, which sources to read, what sequence of actions to follow, and what counts as a finished result.

For example, a Skill for modifying a component might require finding existing variants first, then checking tokens and accessibility, and finally running a specific set of tests after implementation. This does not make the agent infallible, but it removes the need to explain the same process again in every chat.

Over the past few weeks, I have been working on exactly this kind of infrastructure: assembling LLM‑ready documentation, documenting design‑system rules, writing Skills, and testing them in Cursor and Claude Code on real projects.

MCP connects reasoning to work systems

Documentation in the repository is not enough when a task depends on Figma, Tracker, Wiki, or build results. MCP servers give an agent standardized access to tools and data: it can do more than read prepared text; it can retrieve the current structure of a design, find a task, or invoke an approved action.

But more connections do not always produce a better process. For every tool, you need to define:

which data the agent can read;
which changes it can make;
what requires explicit approval;
how the user’s permissions are inherited;
where the source of the completed action is recorded;
what happens when an error occurs or data is incomplete.

Without these boundaries, an agent with many tools becomes not more useful, but more dangerous and less predictable.

Predictability matters more than an impressive demo

Almost any modern model can look impressive on a single, carefully selected task. It is much harder to build a process that works reliably across dozens of routine team tasks.

That requires feedback loops:

automated code and interface checks;
evals based on real scenarios;
source links in responses;
an observable history of the agent’s actions;
a clear handoff to a person;
error analysis and subsequent rule updates.

A good AI process does not promise that the model will never make a mistake. It makes mistakes visible, limits their impact, and prevents them from passing unnoticed into the next stage.

What is changing most in design

This is especially clear in design. It is no longer enough to ask a model to “draw a screen.” It must understand the product structure, use real components, know the patterns, work with semantic tokens, and account for states, accessibility, and responsiveness.

The design system therefore becomes not only a library for people, but also an interface for agents. The more clearly its components, decisions, and constraints are documented, the less the agent improvises where the team needs consistency.

That is why working on an AI‑ready design system is not an attempt to replace the designer. It is a way to make the team’s accumulated experience available within a new workflow.

A new foundational skill

The ability to use AI will probably soon become as foundational as working in Figma, an IDE, or Jira. Simply using a model will no longer distinguish a strong specialist.

The difference will lie elsewhere: whether a person can assemble context, divide work into roles, define the boundaries of autonomy, connect the right tools, and build a system for validating results. In other words, whether they can design a process in which a person and several agents work as one system.

AI is changing more than the set of tools within a profession. It is changing the way work itself gets done. And that is the level I find most interesting right now.