I've spent the last few months pointing AI coding agents at real Swift and Xcode work and watching where they come apart. Not "write me a login screen" demos. Tasks with a build, a test target, and a finish line the agent has to reach on its own.

Start with the part that surprised me: the first draft is usually fine.

Give a capable model a reasonable Swift task and the code it writes on the first pass is often correct, or close. The view is sensible. The types line up. If writing Swift were the bottleneck, these tools would already be done.

A certain kind of post likes to claim the models can't write Swift. They can. They're good at it and getting better. So the interesting question is what happens after that first draft, in the gap between "looks finished" and "is actually right."

The loud version of the build-loop complaint also gets something wrong: on a modern harness, the pure "won't compile" loop is mostly handled. Claude Code and Codex won't accept their own work while the build is red. They churn on a compile error quietly and hand you something that builds. If your agent still ships you red builds, that's a harness problem with a known fix.

The failures that survive are the ones the compiler can't see. Those are the ones that cost me time.

It builds fine and isn't what I asked for. The most common one now. The code compiles, the tests it wrote pass, and the behavior is subtly or completely wrong against what I actually wanted. The agent has no way to check intent. Green is not the same as correct, and green is the only thing the agent knows how to chase.

It compiles and races. Concurrency is the sharp version of this. Swift's compiler catches a lot, but you can still get code that builds clean and has a data race that only shows up under certain timing. The agent reads the green build as success and moves on. When the failure does surface, it usually wants a small redesign rather than a one-line fix, and the redesign is exactly the move the agent won't reach for.

It fixes one thing and quietly breaks another, then loops. This is the one that eats the most of my afternoon. The agent lands a real fix, hits a different problem, and while chasing the second problem it undoes the first. A few turns later it's back to something it already solved. Left running long enough I've watched it oscillate between two broken states: A breaks B, the fix for B brings back A, around and around. It has no durable sense of "I tried that and it didn't work."

It writes code I wouldn't ship. Compiles, runs, still the wrong shape. A pattern that fights the framework. A structure that ignores how the rest of the app is built. Fine for a throwaway. Not fine in code I have to live with.

None of these are language problems. The model knows Swift. What it's missing is everything the compiler can't tell it: whether the result matches what I meant, whether it holds up at runtime, and whether it's the kind of code an experienced developer would keep.

That last gap is where the real expense lives, and it's not the one people reach for first. The talk is usually about token cost. What I actually feel is attention. An agent that writes good Swift and then needs me watching it, stepping in every few turns to keep it from circling, hasn't saved me the work. It's converted writing into supervising. Some days that's a fine trade. A lot of days it means the thing only really runs when I'm sitting next to it.

I don't have this solved. What I can say is that the failure modes are consistent enough to name, which is more than I expected when I started measuring them. The progress I've made has come from changing the loop around the model, what it checks and what it remembers between turns, more than from swapping in a smarter model.

So I want to know whether this matches your experience. For those of you running agents against real Apple work: where does it actually break for you now that the build mostly takes care of itself? The intent mismatches, the races that compile, or something I'm not watching for yet?