Always assumed Pac-Man was an easy solve for modern AI. Guess those ghost patterns are trickier than they look for one-shot learning.

The game mechanics are shockingly hard for them to get right. You also reveal some of their personality traits. The GPT‑6 and Astra models tend to include a lot of cringe copy as well as their own personal graphics style.

Yeah I noticed that (the extra copy) as soon as I started playing each of the GPT-6 ones... Its gross!!!

oh god, yeah. Thats difficult to look at

I did a variant of Pac Man using Claude and pointed it at a thorough blog post about the patterns and that greatly helped.

Adds a whole new layer of paranoia, but for some things, it's probably the only way to genuinely stay off the grid.

Spent days tracking down a deadlock that only manifested under specific load. Definitely hard, even with good tooling.

What kind of tooling were you using? IMO, deadlocks are some of the easiest concurrency bugs to diagnose. If you can see the thread stacks, it is easy to see threads are blocked from acquiring a lock. If you can attach a debugger, it is easy to see which locks are involved. Then you can pretty much figure things out using the straightforward guideline that if multiple locks are involved, they must be acquired in the same order in all code paths.

I don't want to devalue your experience, but I am surprised to hear that. Livelock is harder to debug. Silent data corruption caused by missing or wrong synchronization is way harder to debug.

Agree completely. But they become harder when you eschew standard constructs like threads and mutexes and bring-your-own losing nice things like debugger supports and stack traces. Now your logical tasks might be deadlocked, while your threads appear to be running correctly. This is surprisingly common this day with async runtimes and less than stellar debugging support.

> Silent data corruption caused by missing or wrong synchronization is way harder to debug.

Reminds me of being a young and ambitious C++ programmer 25 years ago, discovering that when you have a map and do “return m[k]”, it is not, in fact, a read-only operation when k does not exist. After which I learned that const-correctness is not just a nice-to-have, especially in multithreaded applications.

But yeah deadlocks are hardly ever a difficult issue to diagnose. They may potentially be difficult to resolve, but at that point, it very much suggests that there’s an architecture / design issue.

They are, if you can attach a debugger. If only one thread is stuck and in production... Not so much (but there are still much harder bugs).

Just drain the traffic (make the load balancer temporarily not send traffic to it) and attach a debugger. I hope your load balancer has that feature because health checking also needs it.

ah, that's probably a missed wakeup problem! Much nastier. Still seeing where your thread is blocked might hint you to where the missing signal should have been.

I didn't mean literally a single thread, just that not the whole application is hang.

So I actually had this exact issue where we suspected a deadlock, but the application was limping along and we couldn't justify attaching a debugger. I managed to confirm my suspicions with judicious use of perf and /proc/<pid>/task/<tid>/wchan .

Always great to see folks modding their audio interfaces. How's the power draw with NAM running on that hardware?

Guess someone finally pushed that 'deploy to production' button on orbital defense. Always assumed this was already live for years.

Skills files only help when the model can't infer the procedure from the repo. Most of the time a good prompt does the same job.

Been curious about the M4 Pro for local models. My M3 Max machine still chugs on larger LLMs, definitely eyeing an upgrade.

The revert safety net is what makes agentic coding tolerable. Without version control, every AI mistake becomes permanent, and that alone kills the workflow.

Also the linters and unit tests that keep the agent on track.