kspetkov79

Less code helps, but fewer unclear decisions probably helps more.

Nice side project. The thing I’d be slightly nervous about is the football-data cron. On small apps like this, it’s often not the app crashing, it’s some scheduled job quietly stopping and the data going stale. How would you notice that here? GitHub Actions notifications, logs, or just manual checking?

I would not treat it as code to merge. It is closer to a rough spec that happens to compile.

Mostly I try to understand the code around the change. If I cannot review the diff afterwards, the agent did not really save me much time.

The hard part is not packaging the knowledge. It is keeping it current and knowing when it does not apply.

Cloud cost problems are often just ownership problems with a bill attached.

They are not stealing the package. They are using it as a door into developer machines, CI, tokens, and customer systems.

For mail servers, readable configuration is a feature, not just aesthetics.

AI output is fine as a draft. The mess starts when people ship it without being able to explain the diff.

The missing part is usually the real workflow. If there is no output and no cost for being wrong, the AI tool just becomes another toy to maintain.

The account recovery story says a lot. At some size, companies start handling people as tickets. Sometimes it only gets fixed because one person inside still cares.

Postinstall hooks are a footgun. The bad part here is that people reviewing a PHP package may not even look closely at package.json.

This kind of project is useful because it shows that containers are not magic. Not something I would run in production, but good for understanding the parts.

On-call makes the boring parts hard to ignore: alerts, ownership, rollback, and knowing what changed. A clean design matters much more when someone has to debug it half asleep.

The format is less important than the reason. A neat prefix does not help much if the commit still does not explain why the change was made.

A bad metric can look fine at first. Then people get good at moving the number instead of improving the thing.

The important part is not letting the LLM close the loop on itself. It can suggest bugs, but a real test has to prove them.

They tend to turn a small change into the whole cleanup plan. Sometimes that is useful, but it makes estimates too large.

I’ve seen this too. Asking for the small boring failure modes separately helps.

Probably just a bad exit IP. VPN addresses get abused a lot. I would switch nodes before assuming HN blocks Mullvad.

The useful prompts are usually boring. Give context, say what you want, say what to avoid, and set the tone. Without that it often gets too polished.

This seems useful for local and disconnected setups, but the compatibility wording needs care. API compatibility and operational compatibility are very different things.

Browsers are hard because the switching cost is high even when people like the idea. “Looks interesting” is far from “I will replace my daily browser with it.”

The microkernel argument makes sense in theory, but the real bottleneck has always been driver complexity. If LLMs can reliably generate verified drivers with formal correctness guarantees, that changes the equation significantly. Until then, Linux's ecosystem inertia wins every time.

Karpathy's educational work (nanoGPT, micrograd) probably did more to democratize AI understanding than most research papers. Curious whether he'll continue that at Anthropic or go fully heads-down on pretraining research.

The git-as-coordination-mechanism is clever. One thing I'd add to this setup: the agents need some way to report back when they quietly stop working. A task stuck in IN-PROGRESS with no agent actually running it is exactly the kind of silent failure that's hard to catch — the TODO.org looks fine but nothing is happening. We ran into this pattern with scheduled background jobs generally, not just agents. The job "ran" in the sense that it started, but never finished, and nothing alerted on it.