Something shifted when AI agents started executing in hours what used to take our teams weeks. Since adopting AI-driven production, the beliefs I had about the role of a designer changed in a couple of days.
I have been building products for a long time, along all my career I kept watching the same failure play out in different industries. Companies were hiring designers only to plate food someone else had cooked. They were constantly tasked to deliver beautiful work against briefs and assumptions that were never questioned. In most of these “agile” environments, everyone sat in its own lane, designers were enrolled for aesthetics while product solved for activation, developers optimized their decisions to supply functionality and marketing focused only on conversion. Everyone technically working, but nobody was owning the customer journey.
Those experiences shaped one version of my beliefs. Then Omny sharpened them into something else.
At Omny Security, we build software for people whose mission is protecting critical infrastructure like power plants and oil facilities. In these environments, a wrong design decision doesn’t just cost a sprint. It costs an operator’s attention. And at scale, it costs safety and potentially hundreds of lives.
When I joined Omny, during the first 6 months I watched us ship an very structured, and rigid workflows in our platform, based on actual user research and with excellent engineering behind it. But the users that were supposed to use our technology abandoned it within five days. Not because it was broken, but because we had moved in the wrong direction at full execution speed. The users that wanted it the solution in one company, were not the same that wanted the same workflow with small changes in another. Making a complex solution equally valuable for all of them at the same time was never going to be an easy task.
That experience, combined with a year of building with AI, broke many of the beliefs I’d held for a decade. Here is what replaced them.
Alignment is a trap at agent speed
After learning from our mistakes with the first version of the Risk Management Platform, I understood that waiting for different teams to align on different customer requirements feels responsible and safe. But in the AI era, it’s an expensive trap.
This problem existed before AI. I watched it unfold slowly in almost every organization. Design was always sitting between marketing and product, belonging fully to neither, each function negotiating across invisible walls. Everyone coming out of a long meeting technically in agreement. Nobody quite sure who made the actual call. The cost was measured in months, in rework, in products that were coherent inside each function but disconnected across the customer journey.
When agents can execute a week of work in an afternoon, that same dynamic doesn’t just drift. It cannot keep up with a design lead moving at an agent speed. However, I’ve seen vague directions fed into a well trained agent produce confident, well-built work going exactly the wrong way.
Clarity has to come first. Alignment is just an outcome.
Strong leaders don’t wait for alignment to emerge naturally. They make the call, hold the line, and let others orient around a decision that’s been made rather than a consensus that has been negotiated.
Clarity before agent action
I used to think that if you framed a problem well enough, execution would follow cleanly. That’s not how complex systems behave. Clarity reveals itself after motion. Trade-offs only become tangible when something exists in the real world and people can express their opinions about it.
I learned from watching other designers fail — they tend to avoid anything real. Instead, I ask three questions before any project starts:
- What business problem are we solving?
- What metric are we trying to move?
- Who gets fired if this doesn’t work?
These questions felt uncomfortable at first. They weren’t design questions. But they were the questions that separated work that mattered from work that looked good and changed nothing. When someone says “we need a website refresh,” those questions reveal whether the actual problem is low conversion, confused positioning, or deals lost to competitors who look more credible. Each of those is a different project, while a PM saying “make it look modern” solves none of them.
Now, vague direction fed to a powerful agent produces beautiful, well-engineered products that solve the wrong problem. The initial workflows implemented at Omny were technically precise but directionally wrong. The difference was a definition about what job operators were actually trying to do that we hadn’t written down and made part of the context for both humans and AI before we started building.
Teams have to move fast to find the direction, and then let the AI agents execute. The sequence matters more than ever because an AI agent is not going to know if it’s going the wrong way.
Scale requires clear owners
I’ve watched consensus break down the same way across organizations of different sizes. The CMO has pipeline numbers. The head of product has activation and retention numbers. Design has brand perception and user research. Everyone is doing real work, producing real output, and nobody is quite accountable for the same outcome. The brief arrives with good intentions. The work gets done. The metric doesn’t move. And in the post-mortem, everyone technically contributed and nobody quite owns what went wrong.
Consensus feels inclusive, but it doesn’t scale.
The larger the team, the more consensus becomes a tax on speed, accountability, and decision quality. Ownership blurs and standards soften. Nobody is quite accountable because everyone technically agreed.
When design decisions cascade through AI-generated components and agent-built features, bad consensus decisions scale instantly. A weak call at the top becomes a thousand downstream executions of that same weak call.
Scale requires clear decision-makers. Input and debate matter, but decisions need owners. If everyone owns it, no one does.
From advocacy to ownership
For a long time, design leadership meant advocating or fighting for the user. In 2026, design leadership has evolved, now it means to be the bulwark protecting quality. Good design leaders are constantly making the cases that point at increasing adoption or diminishing churn so that design (no matter who is doing it) not only deserves a seat at the table, it is mandatory to have its presence.
Designers were protecting the brand while the business were measuring whether the brand converts. Designers wasted energy defending the user while the metric that determines whether the product survives is churn. Even worse, when design was organized as its own function competing for budget and influence, it usually became decorative by default. Designers contribute with something nice but not essential, present at the table but not accountable to the same outcomes as the people sitting next to it.
The strongest design leaders I’ve seen aren’t the ones who won the most arguments. They’re the ones who stopped having them, because they started owning the numbers that made the arguments unnecessary. What that framing produces in practice is to keep you as the person to go to in conversations that not only handle about taste, but also results and therefore strategy.
At Omny, there is no room for advocacy, the outcome of a decision that changes the product, either good or bad, belongs to design leadership. If an operator ignores our alerts because the interface buried the critical signal in noise, that is not a UX problem. That’s a design accountability failure. Advocacy implies you’re trying to convince someone else to care. Ownership means the result is yours regardless they understood you or they just implemented without question. When design leaders act like advocates instead of decision makers, they signal that design is optional. Your influence grows when your responsibility is unmistakable.
Process won’t save you
We had rigorous process at Omny when we shipped that initial workflow for a specific set of customers that other companies immediately wanted to change. We had design reviews, engineering QA, and stakeholder walkthroughs. We followed the book. Customers still abandoned the feature in five days.
Process didn’t save us. Going back to the operators and asking the harder question did. We had to ask them what decision they actually needed to make in the next 30 seconds. That question changed everything about the design, and it had nothing to do with process maturity.
The designers who never struggle to justify their salaries aren’t the ones with the most rigorous process. They’re the ones who diagnose the business problem before opening Figma or Cursor. They push back when the brief is solving for the wrong thing. That judgment — knowing when to challenge the direction, not just execute it — is what separates designers who grow into leadership from designers who perfect their craft and wonder why they’re still waiting to be heard.
Maturity shows up in what the teams ship, what they refuse to ship, and how they behave when trade-offs get real. Everything else is supporting obsolete organizational structures and a dying design process. I’ve seen immaculate processes produce timid work, and I’ve seen scrappy teams make brave calls under pressure.
Design decisions in practice
The most consequential design decision is rarely about visual hierarchy. It is about where a capability lives inside someone’s workflow. The clearest way to see this is through the decisions themselves.
Consider how a Technical Facility Administrator handles a vulnerability alert. The product promises: start from a CVE, trace it through affected software and devices, assess lateral movement risk, create a remediation task — one continuous workflow. If the design fractures that into disconnected steps, forces them to reconstruct context every time they return, and relies on platform knowledge most operators don’t have, they don’t think “this is poorly designed.” They just stop trusting the alerts or question why they have to spend time learning a new tool. In a product where trust determines whether an operator acts on a CVE or ignores it, that break has consequences you can measure: response times, deferred patches, compliance gaps.
This applies beyond cybersecurity. Take for example the case of GitHub Copilot. Github chose inline suggestions — completing the next step inside the developer’s workflow — and saw explosive adoption. Microsoft 365 Copilot chose a sidebar — pulling the user out of their workflow — and reached 3% of its 400 million user base despite massive investment. Same underlying AI capability, completely different outcomes because of where and how it surfaced inside the workflow.
In both cases, the pattern that best fit the user’s workflow was the product. Not the technology, not the engineering quality — the decision about where and how a capability surfaces inside someone’s workflow. These decisions happen before Figma opens, and they require enough depth about the user’s mental model to choose how AI shows up in their world.
The New Design Leadership
Design leadership’s highest-order job is setting direction. Clear enough that both human teams and AI agents can execute with precision, and honest enough to change course when the direction turns out to be wrong.
That shift is quieter than most leadership advice suggests. It shows up in fewer debates about design budgets, sharper calls before sprints begin, and products operators actually use on the days it matters most.
These beliefs hold under pressure. Especially now.
This is part of a series on the future of work with AI agents. Next: The Disappearing Middle of Software Work — when agents compress the execution layer, the judgment at both ends is all that’s left.
Daniel Arevalo is Product Experience Lead at Omny Security. He builds AI-native tools and writes about design, product leadership, and what it means to direct systems that execute at a speed humans never had before.