The question of whether we can trust AI agents keeps coming up. How competent are they? Do they understand the task? Can we rely on what they suggest?
For me, that has gradually turned into a different question: how do I organize the work so I can tell when I’ve actually checked the result and when I’ve just accepted something that looked good enough?
It’s tempting to just say yes
In memes, working with an agent usually goes like this: you give it a task, it disappears, spends some time “thinking,” and comes back with an answer full of technical language you can barely understand. It offers two options and marks one as recommended. You pick that one.
Because you’ve already gotten lazy and used to how fast everything happens. And properly understanding the proposed solution would take forty years. So you agree, hoping the agent probably won’t do anything too bad. You’re basically playing roulette: betting that the system won’t make a mistake with irreversible consequences, even though you can no longer check what it’s actually doing.
Then a result appears, and that’s much easier to work with. There’s something concrete in front of you. You can look at it, give feedback, and ask the agent to fix what you don’t like. Sometimes that’s the first moment you begin to understand what you wanted in the first place.
That got me interested in the process itself. What should the agent know before it starts? Which decisions can it make on its own? Where do I need to step in? And how can I measurably improve the chances of getting the right result, at the quality I need, with fewer attempts?
An agent makes you much faster when you already have practical experience
When I first designed a wallet setup flow a few years ago, I had no idea how long it would take to understand everything and put a solution together. It was a complicated task. Beyond the flow itself, I had to understand cryptography, how blockchains work, and all the different states involved. There was also a much greater level of responsibility toward the user. I had to consider how access was stored and recovered, what risks came up at each step, and what the user needed to understand and confirm.
Now an agent does that work from a spoken request. I also specifically asked it to add the states in the registration flow that needed to account for how the passcode works. The agent did a great job, and I didn’t feel threatened or anxious about it. I felt relieved: I’d just saved myself a lot of time and noticed important details I might have missed even with my experience.
When you understand the task yourself, the value of an agent is especially clear. You have the experience to evaluate the solution, spot mistakes, and recognize what’s missing. In that kind of work, an agent makes you much faster.
But you also need that experience to check what the agent considers finished. For example, it might understand the technical side of a task: figure out how a particular tool or library works, build individual screens correctly, and even explain the result. Yet it might have a poor grasp of how the interface behaves: how users move between screens, how different user flows connect, and which transitions should happen between states.
If you hand that straight over to development, the result can be pretty bad. And often, it will look exactly like AI-generated work. Without practical experience, it’s easy to miss disconnected screens, illogical transitions, and a user journey that falls apart. So experience matters both when you set the task and when you review the result: it helps you see those mistakes, correct the agent, and point it in the right direction.
But an agent also helps with tasks I’ve never done before
I had another experience while we were working on a loyalty program for a financial service. We needed to come up with access tiers and assign limits to each one. I’d never done anything like that before.
I could have studied how other products handled it, looked for examples, and gradually figured it out myself. Instead, I asked the agent to do the research. It found how a major competitor handled it, gathered the information, and proposed the product logic and interface. It laid out what was available at each tier and when restrictions would kick in. I wouldn’t even have thought to look for some of those things.
I was happy with the result. I couldn’t assess every detail based on experience with that particular kind of task. But I still had enough general experience in design and product work to read the proposal, follow the logic, and judge whether it seemed realistic and made sense.
If I’d assigned the task to another designer, it would have gone much the same way. After their presentation, I probably wouldn’t have repeated the entire research process: looking at the same products, checking their tiers and limits, and doing all that work again. I would have looked at what they brought me, tried to understand their reasoning, and decided whether we could move forward with it.
That’s exactly what happened with the agent. I didn’t become a loyalty program specialist, but I got a solution I could review and accept.
Some details might not have been perfect. But sometimes it matters more to ship and get more objective feedback than to keep digging in search of complete certainty.
At that point, I can say: I can live with it. And we move on.
It’s easier to evaluate something you can try
In one experiment, the agent came up with some pretty strange interface concepts. I wouldn’t have called them finished solutions, but individual ideas could have been a starting point. You look at them and think: this part is overcomplicated, this interaction doesn’t work, but there’s something interesting in that detail. Even an unsuccessful concept can get you moving: you can already explain what needs to change and what to try next.
Once you find an interesting direction, you want to see how it works in a user’s hands. The usual routine used to be drawing the screens in Figma, wiring them together into a prototype, and testing it with partners or customers.
Now you can ask an agent to build an interactive prototype. For someone taking part in a test, it will be indistinguishable from a new version of the product, even though it might only be a few HTML screens linked together. The user interacts with the interface, goes through a flow, and encounters different states. You can test more complex scenarios and spend less effort adapting the test itself to what a Figma prototype can do.
After a test like that, it becomes clearer what needs to change. You can update the solution and try again. Throughout those iterations, I keep the change history in Git. A couple of times, I’ve actually needed to go back to an earlier version. That history helps the agent too. If it loses some context, we can look at what changed earlier and how we arrived at the current solution.
I generally find it easier to evaluate something concrete. So I try to get to something I can interact with as quickly as possible, then use it to figure out what worked and what to do next.
You need to explain how you work
I started figuring out agents through ordinary conversations. I asked what they could do, how things worked, whether we could do something a certain way, and what it would take. Those conversations gradually helped me understand how I preferred to work with them.
For example, I keep projects separate. Each has its own folder, materials, rules, and history of decisions. A work product lives separately from a personal project. I want the agent to understand what we’re working on right now and avoid carrying over agreements from another task.
Before design starts, we also need to gather context. What are we making? Who is it for? What problem are we solving? What constraints do we have? I use skills that help the agent ask clarifying questions. If I notice we’ve agreed on everything too quickly, I ask it to go back through our decisions and look for weak spots.
The same goes for references. I collect examples that are close to what we need in terms of purpose and style, and give the agent access to them. But having a folder doesn’t mean the agent will look inside. So I add a specific rule: before designing anything, find out whether there are references and study them.
It’s the same with a design system. If one exists, I want the agent to first understand which components are available and how they’re used. Otherwise, it might start building everything from scratch or copying parts of a neighboring screen, even though the right solution is already in the library.
Mistakes gradually turn into rules
Of course agents disappoint me. Quite often, actually. It almost always happens when we need to create something new. I run into fewer problems when refining a solution or improving something that already exists.
The mistakes are usually familiar, the kind you’d expect from a junior designer. The agent misses how screens should work together, doesn’t think about the system as a whole, or forgets what problem we’re trying to solve. The same things you write in a junior’s performance reviews for the first three years.
Some mistakes are very specific. For example, instead of setting proper spacing between elements, the agent inserts an empty frame as a spacer. I explain why it shouldn’t do that and ask it to save the rule.
Or a task takes suspiciously long. I ask what happened, and the agent explains that it made lots of individual calls where a single operation would have been enough. We work through that and record it too.
That’s how my skills came about. They gradually grew out of real tasks, mistakes, and things that worked. First, we worked on a project. Then I asked the agent to review what we’d learned and put it into a form we could use on the next one.
So “you can teach an agent with one file” is a practical idea for me. But that file doesn’t appear on its own. First, you need to do the work, understand what isn’t working, explain how it should work, and check the next attempt.
Sometimes, after a session, I ask the agent to review its mistakes and suggest what we should add to the rules. But I have to read those suggestions too. It might generalize from a case that’s too specific or write far more instructions than we need.
With a junior designer, you give feedback, wait a week for the changes, and may then have to discuss the mistakes again. Here, the next attempt takes up to ten minutes. You see the result right away and can tell whether your explanation helped.
So I can say “yes, go ahead” more often
I want to agree with the agent’s suggestions more often. I want speed, fewer explanations, and a result I’m happy with on the first attempt. I don’t see anything wrong with wanting that. Agents are already useful enough for that way of working to feel achievable.
But first, I need to put in the time. Figure out what the agent should know before starting a task, what it can decide on its own, and when it should come back to me with a question. Get something I didn’t expect a few times, understand where we misunderstood each other, and agree on how to work from there. Saving an instruction isn’t enough, either. I need to see that it actually helped on the next task.
Some of that time goes into my own learning. I get better at noticing which context I forgot to provide, where I left too much room for guesswork, and which decisions I’m not ready to hand over completely. Meanwhile, the agent has saved rules and examples to draw on. We don’t have to get to know each other all over again on the next task.
That’s why I’m interested in building this process. The time I spend on explanations and corrections now should help with future tasks too. I want to repeat myself less and have the agent suggest what I need more often.
Then a quick “yes, go ahead” will have our experience of working together behind it. I understand what the agent has taken into account, we’ve already worked through the common mistakes, and I have reasons to expect a suitable result. That’s the kind of speed I want.