From Designer to Agent Builder: See, Make, Think

I just finished reading Rokoshi.How to Be a Good Designer.I'm sorry. This talk is not long, it doesn't give people the illusion of having the design secret after hearing it, but it's honest: look, do, think. Imitation, learning, and finally slowly growing up.

The questions in this article can also be addressedFrom Engineering to Builder: A person's company and product thinking、Model Is Good End: 2026, AI, which is really scarce, is an application rather than a larger model.How the concept of a relatively close read together is developed in different contexts.

I'm not a designer in the strict sense of the word. But after that, it's AI Agent. Doing Agent is not a plane or an interactive script, but both things depend on a feeling of hand: Know what's good, know what's wrong, know why you're so different. Tools and frameworks become fast, how can a person never arrive, from a point to a real judgement, go around or these stupid ways?

Let yourself be consulted.

And the design "see," of course, is not a few nice drawings. It's more like training eyes and brains. It is enough to know what is ordinary, what is precise, what is simple at first glance, and what is hidden behind it. The aesthetic is not made out of space, but it needs to be calibrated by a lot of good work.

When I was doing Agent, I thought there was a similar "system aesthetic." It depends on real products, open source frameworks, papers, failure cases, tool protocols, and how users work. And then after looking at it, you'll find out a person who's actually actually a person, okay? Not how much of it is a planner, memoory, reflection. Many times, good Agent is very simple: borders are clear, interfaces are stable, and when it fails, we know where to park.

So it's important to imitate at the initial stage. Designers need to get their work done, and Agent Builder should read people's systems, recreate others' processes, unplug the prompt, unplug the tool interface. Imitation is not a disgrace. The real danger is to look too little, to take a new term as an answer too early and then gradually lose themselves in the growing concept.

The real problem is the education.

But it's not enough to look at it. When he talks about design, he emphasizes "doing" what is real, which is even more evident on Agent. The curriculum/dissertations/Blogs will be very clean: what is entered, what is the tool, what is the evaluation indicator. The real world will not cooperate that way.

Once the real problem starts, friction will come. The tool is timed out, the web page is re-edited, the privileges fail, the user says half a sentence, the task is deformed in the middle, and the model is a serious error. Too long a context can contaminate judgment, too short and key information is missing. Automatic execution would cross borders and make users feel useless.

These things only hit when they were done. After the crash, looking back at other people's designs, many of the details suddenly become reasonable: Why is the tool schema so conservative? Why are you going to expose it to the user? Why do some steps have to be retained for manual confirmation? What I used to think was that it was all left behind by real problems.

So learning Agent can't stop just reading frame documents and reading front pages. What really grows is to make a less clean issue into a working stream that can be used repeatedly. It can be small or imperfect, but it's more training-oriented than a beautiful, but non-crush-free demo.

Don't rush the copying.

The third step is "think." Seeing and doing without thinking can easily become material accumulation and manual labour. The design asks: Why do we leave this place white? Why is the button here? Why is this color set up in this scene?

Same thing happened to Agent. It is not just about how this process works, it is about why it works. Why does it need Planner here, not just execution? Why is it introducing memory instead of re-researching? Why does this mission fit into a human-in-the-load?

I'm gonna do this myself. After a paper or frame, the first reaction is to load the keyword into its own system: Multi-agent, reflection, RAG, memoory, as if it were more complete. But in many cases, the problem may be to clean up the interface and clear the feedback. The question is why it is a process of turning experience into judgement. We know why we do this, so when we have a new problem, we find it nothing new.

Learning, not re-graving.

From 0 to 1, imitation is necessary. Without enough imitations, it is difficult to build a basic sense of hand. But from 1 to 100, the focus has been on grouping, learning and adaptation. Good Arts Copy, Great Arts Steel, which is often attributed to Picasso, and quoted by Jobs, probably says the same thing. The real absorption is not a copy, but an understanding of why it is set up and then puts it into its own problems to transform.

Design isn't cut, and neither is Agent. A good Agent may borrow permission boundaries from the operating system, feedback rhythms from product design, state management from databases, task decomposition from organizational collaboration, and new Agent architecture scenarios from new model technological changes. The more multiplicity of things you see, the more likely it is to create a new combination in a real problem.

But no matter how wide-sighted, it's going to end up doing it. You do virtual projects, you do competition projects, you do real problems, you do little tools that people don't look big enough to do, but you're willing to grind them over and over again. Many times, the ability to move a thing from being able to run to being useful is already crossing a very important line.

Good is not enough, and it's set up in Agent. An Agent can run, doesn't mean it deserves to be relied on; a demo is amazing, doesn't mean it can get into real work. Excellence is not the latest tool, but the evolving judgement: know what is worth seeing, what must be done by hand, and stop somewhere to ask why.

Look, do, think, it doesn't sound new. Maybe it's because they're not new that they're more reliable. The technology industry always likes to speak of new things as a paradigm revolution, and then change once in a few months, but people grow less quickly. The designer and the agent Builder end up going back to a very ordinary thing: Keep watching, acting, understanding and doing better next time than this in the real world.