Hacker News

points by nfw2 1 day ago | 0 comments

UI is one thing, but agentic UX is actually really hard I've found.

I have had some success with this by using a distinct agent profile for this role in my agent team.

The agent is instructed to use Laws of UX[0] when reviewing application flows and cite specific laws with changes to the builder agents. Look-and-feel in general still requires some tuning, but I have found that: 1) using a discrete agent in this role that only looks at the flow and is given the end-user context, 2) pointed to a set of guidance has really improved autonomy for UX.

[0] https://lawsofux.com/, https://lawsofux.com/llms.txt

[–] XenophileJKO 1 day ago

This is still generally a good rule when building with agents, the models are capable of many behaviors. The key is to simply set some bounds on what their "job" is so that most of their finite attention can be spent organizing around the what that role is expected to do.

It certainly is less important as the models get better at meta planning, but this approach is still very useful.

Often all you need to do is define a set of beliefs and values for the role and it will operate much better than rules or guidance.

[–] CharlieDigital 1 day ago

Yes, 100%. There's some recent research that backs this up.

Adaptive Auto-Harness: Sustained Self-Improvement for Agentic System Deployment on Open-Ended Task Stream (https://arxiv.org/pdf/2606.01770) talks about this and the efficacy of role- and objective-based agents on unbounded streams of heterogeneous tasks.

I recently wrote down some of my own experience with this: LARPing with Agents (and Why It Works) (https://chrlschn.dev/blog/2026/10/larping-with-agents-and-wh...) after someone called out my role-based agents as "larping". Short of it: role-based, fully "JIT" agents have increased autonomy in my coding workflows end-to-end. I get very good outputs with few skills required and less human instruction input.

[–] unsloppable 1 day ago

Thanks for linking this. I've reached a point I need to overhaul one of my MacOS apps and these laws are the perfect find.

What's the best approach to applying these in practice? Should I evaluate every screen with each of these laws in mind or should I evaluate the app entirely one law at a time?

[–] CharlieDigital 11 hours ago

Give and agent the llms.txt and ask it to read.

I have a dedicated agent profile that specifically owns this task and I tell the other agents to only send screenshots to it and ask for feedback.

[–] fuzzy2 1 day ago

Even "human" UX is actually really hard, mind you. If we haven't figured it out, how would an agent/LLM trained on human output?

From my perspective, the issue is that there can be no formulaic/algorithmic approach to good UX.

[–] x3haloed 1 day ago

Here's the thing. As you're indicating, UI and UX are not the same thing, but they're both subjective.

You can ask the model to implement common patterns for both UI and UX. You can ask the model to correct obvious UI errors.

But you can't really ask the model to have UI taste unless you supply that taste, and you can't ask a model to "do UX" in a vacuum. UX work requires user testing. So any UX workflow that is going to be handled by agents must also include observational data of humans using the software.

There is no set of instructions that can do "UI/UX" without also incorporating human feedback.

[–] andyfilms1 1 day ago

The problem I've been having is they just have no sense of systems, which is exhausting once your app scales to anything beyond 1 page. It will happily write features that can't interact together at all, despite being in the same piece of software, and burn tokens to glue them together when you point out the problem.

And obviously you can say, "hey these features need to work together make no mistakes." But for really big projects like professional software, that's a LOT of features with a LOT of possible interactions.