Where AI Agents Still Get Stuck

I want to talk about what agents are still bad at. During the day I set tasks, leave the agents working overnight, accept the result in the morning and set new goals. Two problems keep coming up in that cycle.

The first is visual acceptance. Anything that needs to be displayed is a painful problem. My project has a style guide and a brand book. I ask the agent to put a function on the site in a neat, understandable block. Then I open the result and, honestly, it almost hurts to look at it. It feels as if the agent was working apart from the existing page. The result may not match its structure or my expectations. Sometimes it also damages what already looked good.

I cannot always describe the final appearance precisely in words. At the same time, AI can already replace one detail in an image while preserving the other elements, text and numbers. So I have come to a simple order of work: agree on a mockup first, implement afterward. The agent takes a screenshot of the page and shows the future block on it. I look at its place, size, neighboring elements and presentation. Once it works for me, we shake hands on it. Then I am more likely to see what we agreed on. With only verbal descriptions I too often have to redo the work, even after strong modern models.

The price of autonomy is also that an agent may do good work, or it may make a mess, create unnecessary folders or change something nobody asked it to change. I try to manage that with rules and settings. For visual work I added one more rule: agree on the place and appearance of the result before implementation.

There is a broader principle here. Every function needs an end consumer. If its result goes to the next module, we need to know how it gets there and what it becomes afterward. If it goes to a person, we need to know where that person will see it: on the site, in an image, or through an interface for another program. A function that leads nowhere and produces no further output is easy to lose, even if the code has been written.

The second problem is a task that quietly stretches to 10 or 20 hours. You may think the agent is working hard and getting closer to a solution all that time. I don't think it is normal to just wait and hope. I mean a realistic component of a project with a clear brief, not an attempt to build a whole big 3D shooter in one go. People build serious projects in parts too. If a part is well described and does not require processing billions of parameters, the agent can already write a lot of code in one, two or three hours. When that work stalls for 10 or 20 hours, it is my first sign that something is wrong with the brief or the plan. The requirements may be too rigid, the boundaries poorly defined, or the agent may have wandered into unnecessary engineering.

So I am developing a different way of working. When I set a goal for an agent, a senior agent watches it and wakes up roughly once an hour. It looks at progress and time spent. What I have caught workers doing most often is drifting into overengineering for no reason. The senior agent should stop that worker and ask what is really blocking it. For me, a plan is a way to reach a goal. If it stalls, we need a fallback route. If that also fails, we can ask a stronger agent for help, move the model to deeper reasoning, or use an appropriate tool. Sometimes it is enough to simplify the plan to a deliverable part and resume. After every stage, check again whether we moved closer to the result and how many hours it took.

I have seen many times that even a strong model admits it got stuck on the proposed plan although the task can be solved another way. If a stage keeps stalling, it is not worth burning tokens for 20, 30 or 40 hours just because something is still running. It is better to stop the agent, take two steps back and replan the work. With a well-defined task, it can do a large useful part in a few hours, especially when it has helpers. In my experience, a long wait without oversight too often ended in a result that still needed to be redone.