tobyhede

Shameless plug:

If you like install.md, you might love Rundown!

I've made a Rundown version of an install here: https://rundown.cool/explore/install/

Well. I still think it is cool.

I've taken this a step further with https://rundown.cool.

Define runbooks with markdown, and a tool that supports the agent through the workflow.

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.

In all of these threads on Apple, Google, Facebook and friends, its fascinating that the overall tone and position of technologists has changed over time from radical cyberpunk freedom to "monopolies aren't that bad really".

I was wondering of the V8 engine integration would be something to play with, but think ot just adds inefficiency and doesn't really fix some of the core problems.

I've looked quite extensively at Postgraphile and the extensive dependency on database functions and sql is an issue. Really hard to write tests and SQL itself is not the greatest programming language. The whole setup lacks so many of the affordances of modern environments.

I've been doing serverless in anger for years. My vision is to use annotations or decorators to tag functions and have the implementation transparently handled.

@spawn //makes this a lambda

function fn() ... {}

@queue //makes this a queued function sqs or similar

function fn() ... {}

Oh, and other advice is just buy a big roll of filament and experiment - I ran lots of test cubes with different settings to zone in on what worked and understand the relationship between different attributes.

I found it surprisingly accessible. there are a ton of great resources on YouTube, reddit is excellent for advice on tuning and troubleshooting. Thingiverse has too many great models, often with detailed advice and specs for printing.

Tinkercad is a very beginner friendly design app. As someone rolling with a -2 to visual acuity I still managed to work it out.

Heaps of fun to work with your kids, my favourite project has been this clothes rack and hangers for my daughter's Sylvania families https://www.thingiverse.com/thing:3345575

I am in this photo and I don't like it.

A complete history with all the data ... unlike MongoDB. Boom tish etc.

Agree that Open Source is core. This might be something that could get crowd funding support.

A set of concrete principles, a modest plan* and roadmap and a slick vision captured in a video demo.

Modest in that start with 1 or 2 core features of G Suite like email and sheets rather than a claim "we can have it all".

Is it more likely to be a vast global conspiracy involving such unlikely co-conspirators as the prime minister of new zealand and the POTUS ... or a chaotic and rapidly evolving situation?

Importing 5 backups into 6 made the backups unusable. I might still be able to get them with 5, but need to work out how to do it.

After the latest bersion of Arq destroyed my backups, I moved to the AWS CLI and S3 sync. I have buckets in 2 regions at negligible cost. It's not automatic unless you script something, but it works.

You just configure Glacier lifecycle rules via the console.

Rather than thinking of this as a way to get information, a skip level is also an opportunity to be recognised by someone senior. The fact that you have a good grasp of the roadmap gives you a chance to demonstrate strategic thinking and alignment with that strategy. I would tend to ask open ended questions that demonstrate your understanding, show you've thought about the issues, and give the manager a stage to explain and guide.

Have a concrete action that you are proactively working on for your career this year that lines up with something useful. E.g. Completing online course in UX because you've recognised this as important for project blah blah blah.

Making your direct manager look good never hurts either.

Years ago I worked for a startup that provided CMS and ecommerce software for small business. Each of our 3000+ customers had their own MySQL database.

We had a long tail of customers with negligible usage and would run several thousand MySQL databases on a single server. As customers scaled we could migrate the database to balance capacity. We could also optionally offer "premium" and "enterprise" services that guaranteed isolation and higher durability.

Scaling was never a real issue, but the nature of our clients was steady incremental growth. I don't think we ever had a case of real "overnight success" where a shared host customer suddenly melted the infrastructure for everyone.

However, managing and migrating the databases could be a real issue. We had a few ways of handling it, but often would need to handle it in the code, `if schemaVersion == 1 else`. Over time this added up and required discipline to ensure migration, deprecation and cleanuop. As a startup, we mostly didn't have that discipline and we did have a fair bit of drift in versions and old code lying around.

If you are using Rails, have a look at using PostgreSQL schemas. Single "physical" database but the schemas give you distinct logical databases. Perfect for multi-tenant situations.

Slack the company really needs to embrace distributed work practices if they want to actually build a tool for distributed work practices.

Slack has totally become a drag on productivity and a net negative. Channel and message overload is arguably not much better than the email system it is meant to replace.

My prediction is that Slack will be replaced quite quickly by the first tool that really nails remote messaging and coordination. Slack is not it.

JS?

As much as I like retool, it's not open source.

Rails has active admin and a couple of similar options.

I've built quite complex apps with activeadmin, it's worth looking at.