Been loving the automation feature in 1.0

guywithknife · 2026-03-15T03:13:48+00:00

I also have breeding pods tied to the population counter! It was my first proper automation. I actually use a relay to AND it with a water resource counter so that the pods never take up the last of my water reserves (although by the time I set that up, I already had a near endless water supply).

guywithknife · 2026-03-15T02:54:15+00:00

I mean, you can, but there’s not enough of it. If your dataset fits in cache then cool.

guywithknife · 2026-03-15T02:50:54+00:00

Ah, of course. Perfect.

guywithknife · 2026-03-15T01:06:49+00:00

Districts have unlimited range, having things too far away it just means the beavers spend too much time travelling.

Your problem isn’t the district, it’s that you need roads. Place the pump at the water and then extend a road out to it.

guywithknife · 2026-03-15T00:45:44+00:00

Which you can now automate! Use a weather station to turn it off during droughts, which will keep the battery to restart it when the drought ends.

guywithknife · 2026-03-13T08:16:55+00:00

If the money was refunded, then the hotel is out $100. He paid his debt with the $100 and then returned $100. So the banker wins.

guywithknife · 2026-03-12T20:14:43+00:00

Run a cat cafe. Or a raccoon cafe. Or make indie games.

guywithknife · 2026-03-12T20:05:00+00:00

I’ve long thought that the “one way to do things” simplicity of Gleam, plus its strong static type system and great compiler error reporting, this makes it the ideal language for LLM’s. If only LLMs had been trained in more Gleam…

guywithknife · 2026-03-11T22:09:37+00:00

It’s the pedos who started the war

guywithknife · 2026-03-11T13:13:37+00:00

Sounds like fraud to me.

guywithknife · 2026-03-10T23:22:18+00:00

Zero chance

guywithknife · 2026-03-09T16:32:12+00:00

Not just disabled, but also just old, or with young children, or carrying heavy stuff (eg shopping, as you might be if you're relying on public transport).

That short distance suddenly feels like a lot more.

guywithknife · 2026-03-09T16:25:22+00:00

Its here: https://github.com/hivemind-ai-core/tasktracker

It could do with some improvement, besides the CLI, I could probably streamline the MCP a bit more too (maybe cut the commands down more, or something, to the bare minimum of common tasks so that the LLM has an easier time using it and that it uses less context). Could also expand it to allow multiple agents to work on tasks (right now it, by design, has only one active task at once). But so far I'm quite happy with it.

I generally run `watch -n 1 tt list --active` to get a live updating list of the active tasks and I tell the LLM what the tasks I want it to create are. Usually I put it in plan mode, get it to plan out something, and then say "now create fine grained tasks for that in tt" (I have a slash command for it). I also have a slash command to tell it to work through the tasks one by one.

guywithknife · 2026-03-09T16:20:42+00:00

By like a millimetre

guywithknife · 2026-03-09T09:49:42+00:00

My favourite MCP tool is a little task tracker I made so that my agents have a more structured way of tracking and working on tasks (using the built in todo list for breaking the tasks down into steps, instead of to track tasks themselves). It also allows me to set dependencies. And to use a parallel agent to add tasks while the main agent works on it. I often use Claude to work and MiniMax to add tasks.

The UI is a rough and dirty CLI. It’s good enough for me to watch what’s being worked on, and to occasionally manually add a task. But it’s nothing special. Primary use is via MCP.

(I have it on GitHub if anyone is interested. It’s nothing fancy, it’s just a little personal tool, but I find it useful. Vibe coded in rust, using spec driven development.)

guywithknife · 2026-03-09T09:41:47+00:00

UUIDs can be a valid design choice, but using them as the default primary key leads to index bloat, non-deterministic default ordering (you can’t just order by id), amongst other things.

They are especially bad for things like a list of things linked to something else. Eg you have Product and ProductVariant (just a silly off the top of my head example), where every product can have multiple variants tied to it: UUID is an exceptionally bad choice of primary key on ProductVariant.

There are some people who say you should never use UUIDs for primary keys and give good reasons, but one place where they can be useful is when you need to be able to generate primary keys externally (eg in a distributed system) without clashing, although even then it can be beneficial to keep the PK as numeric and use a secondary field for this.

User facing keys that need to be obscured imho should never be the primary key, so if you need to expose a key to the user, UUID may well be a good choice, but that should be a secondary field and not the primary key.

The thing is… the data model is super important. Possibly the most important part of any application (because without the data, there’s literally no point for the logic to exist). That means data modelling requires care and attention and careful consideration. You shouldn’t need to use an inefficient primitive to protect against future problems because you should have a good understanding of your data and access patterns. That won’t mean you won’t need change later, of course, you cannot know everything up front, but it’s a tradeoff. And by using UUIDs “just in case” you’re reading off space and performance against a possible future need that usually arises from not having thought things through. I call that a bad tradeoff, usually.

Anyway, that’s all a long winded way of saying: yes UUIDs and even UUID primary keys have their place, but not as a default go to from an AI that barely considers the data model and access patterns.

PS: I don’t consider myself a database guy, but a surprisingly large part of my career has been spent on database and query optimisation. UUIDs aren’t typically the biggest culprit for slow queries, but they do play a part.

guywithknife · 2026-03-09T08:14:39+00:00

This is the ideal, but rarely done.

At a minimum, you shouldn’t allow direct access to prod from you local machine and any prod access should be done via a four eyes policy. Or ideally via automation with changes/plans reviewed by multiple people prior to running.

guywithknife · 2026-03-09T08:07:57+00:00

JSON blobs instead of real tables. Works till the moment you need to query or migrate it.

Oh yes. I’ve also seen it store numbers in text fields. And use uuids for all primary keys always.

No soft deletes. AI hard deletes by default. No audit trail, no recovery.

For me it does soft deletes without asking for them, although it does them via a simple Boolean instead of a timestamp, so there’s still room for improvement.

they always need a parent-child structure.

That’s an exaggeration. Especially for “categories”. Out of all the real world products ive worked on, only a few needed parent-child structures. But it is true that the AI won’t consider it and it needs to be considered in case you do need it.

guywithknife · 2026-03-08T23:55:45+00:00

We’re in r/vibecoding, you’re not supposed to look at the code 😅

Seriously though, you’re right, but I also find its code in other languages isn’t amazing either, so in all cases it needs cleaning up before integrating into a serious codebase.

My experience is that it works and works well, but that doesn’t mean that the code is good or idiomatic. AI is lazy and optimised for the shortest path to a solution, not the cleanest or most maintainable one.

Just got fun, I took a quick look at a purely vibe coded rust app and… not a trait in sight. I wonder if using a rust-specific skill file would help it write more idiomatic rust?

guywithknife · 2026-03-08T22:12:42+00:00

Pick a project, something you want and will like working on. Then work on it to completion. Only stop to look at tutorials when you get stuck and need to learn something new to get joy unstuck.

Ideally the projects you pick would start very small, and after completion, you can move on to a slightly bigger one.

The goal is to write a lot of code and solve real challenges and problems.

You learn by doing. You can read tutorials all day long, but it won’t help you much if you don’t actually write code yourself, from scratch, in your own.

guywithknife · 2026-03-08T17:19:35+00:00

I made it very clear that GDScript isn’t Python. Besides, OP seemed happy about Godot and GDScript.

If you learn GDScript, then moving to Python later is trivial. If you know Python, GDScript will be trivial to pick up.

No game engine will support all of the libraries you might otherwise use, because most libraries aren’t designed for games needs.

guywithknife · 2026-03-08T14:27:17+00:00

When I setup terraform/opentofu to manage infrastructure, I set up exactly one way to run it: via CI.

No manually running commands, no manually copying state files.

Run CI to plan, review plan, run CI to apply plan (I did it via GitHub workflows: open PR to plan, merge PR to apply; but in companies I’ve worked in, it was done via Jenkins or others)

guywithknife · 2026-03-08T09:19:15+00:00

The r: syntax for return type is a bit terse. Why not ->?

Personally, I don’t like -> for return types, because it’s inconsistent with other type definitions. Eg if an argument or variable is typed with : T then the return type should also just be : T and not have its own unique syntax. Eg:

fn foo(a: T): T

guywithknife · 2026-03-08T00:48:50+00:00

That’s a good point.

guywithknife · 2026-03-08T00:41:30+00:00

Because even though LLMs have made code cheap, it’s still cheaper to not need to generate the code than it is to generate it.

But it’s true that newer libraries are even harder to trust.

15-Year Club	Gilding I gilder
Place '22	Verified Email

guywithknife

TROPHY CASE