I think one of the most frustrating things about AI agents is when they make changes without really understanding the codebase. The code might look right at first, but it can end up causing other problems.

Another annoying thing is when an agent makes a mistake, you explain what went wrong, and it still repeats the same mistake. Sometimes it feels like you're spending more time correcting the AI than actually solving the problem.

I'd like to see agents get better at learning from previous attempts, understanding the context of a project, and checking their work before saying they're done. I don't think generating code faster is enough if you still have to double-check everything yourself.

Scope drift with a convincing success signal is frustrating: an agent completes a plausible adjacent task, but nobody checks it touched the intended target or produced the expected evidence. Tying completion to a diff or command output helps catch it. I work on Orke at BOMTOBE.

Answering from the point of view of someone who builds small AI automations for clients (email triage, lead intake, support assistants) and uses coding agents daily.

1. Most frustrating problem. Confident completion without evidence. The agent says "done, tests pass" when it never ran the tests, or ran a different command from the one that matters. Hallucinated APIs and wrong library versions are cheaper to catch than a false "done", because the false "done" is what makes me stop trusting the whole run, not just that step.

2. Coordinating multiple tools manually. Constantly: one tool is good at reading a large codebase, another at running things, a third has the integration I need (CRM, email). The hard part is not the handoff, it is state. Each tool has its own memory of the task, and the moment I move to tool B, everything tool A learned (which files matter, what we already ruled out) is gone unless I retype it. Multi-agent frameworks mostly recreate this problem internally: the orchestrator summarises, the worker loses the detail.

3. When the agent lacks a tool. I write it myself as a 20-line script with a clear CLI and hand it over. "Create and test a missing tool" sounds great in a pitch, but the tool the agent writes is then the thing I have to review, and a tool written under time pressure inside a task is the least reviewed code in the project. If you build this, the generated tool has to be a first-class artefact: visible, versioned, tested on its own, reused next time, not buried inside one run's transcript.

4. Repeating mistakes. Yes, and the pattern is specific: the mistake is repeated across sessions, not within one. Within a session, correction works. Next day, same model, same project, same mistake. The fix that works for me is boring: a project-level notes file (conventions, "do not do X", known traps) loaded every time. An agent that maintains that file itself, with my review, is the one I would pay for.

5. One thing to improve. Make "I am not sure" cheap. Today an unsure agent guesses, because guessing looks like progress and asking looks like failure. An agent that stops after the first uncertain step with "here are the two readings, which one?" would save me more time than any speed improvement.

A practical note for the competition: what separates a usable agent from a demo is the audit trail. For every claim ("tests pass", "migrated 40 records"), show the command and the output that proves it. If your platform does only that well, it is already ahead of most.