tobyhede

Well. I still think it is cool.

I have been using Claude Code extensively on a side project (a hard sci-fi orbital tactics sandbox and battlefield simulator written in Rust with Bevy).

I recently attempted to create a procedural starfield background with multi-layer parallax, wired into the game.

I thought it would take an afternoon, and two weeks and three full rewrites later, I ended up with a list I’m calling: The 7 habits of highly ineffective agents

  1. Planning Theatre – Write dense and systematically wrong plans. Long, confident plans that look impressive, get “approved”, and are fundamentally wrong in ways you can’t see without strong domain knowledge.

  2. Confidently Incorrect Architecture – Design the wrong thing in incredible detail. Elaborate designs that can never solve the actual problem (e.g. starfield parallax without real layers / camera–world modelling), but look beautifully structured on paper.

  3. Context Resistance – The context is futile. You will be hallucinated. Ask for Bevy 0.17 patterns, get Bevy 0.15. Agents “agree” with the updated context and then quietly fall back to older habits and half-remembered APIs.

  4. Imaginary Implementation – Works on my hallucination. Code for an engine that doesn’t exist: non-existent APIs, obsolete shader interfaces, plausible-sounding data flows that won’t compile anywhere outside the model’s head.

  5. Context Evasion – Treat hard constraints and instructions as optional vibes. The project had explicit, non-optional instructions (skills to call, architecture rules, testing strategy, etc.). The agent read them, acknowledged them… and behaved as if they were suggestions.

  6. Applied Rationalization – Explanation over implementation. When something fails, the agent doesn’t just explain it – it bakes the explanation into the codebase: ignoring tests, downgrading issues to “non-blocking”, justifying precision loss, and moving on.

  7. Weaponised Context – The context will continue until the code improves. By the end, the feature had volumes of surrounding context: plans, handoffs, bug explanations, revisions. Each failure generated more docs for the next agent to inherit and ignore.

I’m curious how this matches other people’s experience with Claude / Claude Code (or your own agent stacks): - Which of these habits have you seen the most in your own workflows? - What have you done that actually reduced these failure modes (gating, skills, checklists, stricter prompts, something else)? - Are there other “habits of highly ineffective agents” you’d add to this list?

Would love to hear horror stories and what’s working for you.

BP is probably just getting ahead of the game. The value of this investment is likely to be predicted to plummet and need to be written off anyway. The EU will need to dramatically reduce energy dependence on Russia after this. There will no popular support and the long term strategic implications make it untenable.

Performance in some areas was an issue. Overall benefits productivity and ongoing maintenance weren't enough to be really worth it. There is nuance to it all, because some of it lies in team structure and knowledge as well.

What can I say? As with all things, YMMV. We're happy with it, we launched with zero customer impact, and have had no issues. Perceived performance has increased.

Flutter is not for everything, but it is really worth a look.

We (AU MVNO/Telco) recently converted iOS and Android apps (200,000 MAUs) to Flutter and it has been game changing. We had experimented with react native and found it just didn't deliver. Flutter is different. On mobile platforms the experience is super responsive and smooth and for your typical consumer app indistinguishable from the native experience. The tooling and developer experience are incredible. The benefits and experience where so clear that the whole team was onboard - including the most die-hard career platform specialists. Our velocity and ability to deliver is measurably better.

We're looking at the web target as maybe "good enough". I don't think it could be a replacement for a well-crafted web app, but could be used to provide a fast alternative to the primary native experience, and for rapidly prototyping and experimenting. In the current state, Flutter Web could never replace our highly optimised ecommerce funnel - some things you just need to sweat the details. But it's definitely better than some of the CX in the corners of our legacy applications. Shipping fast is valuable - so build for native, get a good enough web for "free" and then spend time and attention on the web if it is warranted.

I made a flexible, light-weight, card-based drag-and-drop kanban-ish planning tool called StoryWall and posted the MVP on Hacker News literally the same week Trello was released.

Managed to take all the wind from my sails.

At least in AWS, practice is to encrypt all connections between components, and to have granular least privilege permissions at every point. Behind the scenes AWS follows the same principles for the infrastructure. I would argue a lot of cloud set-ups are inherently more secure than the equivalent on-prem of large enterprises.

The second ingredient of Grain Berry cereal is sugar.