kspetkov79

9 ms·

1.
by kspetkov79 4mo ago
Less code helps, but fewer unclear decisions probably helps more.
2.
by kspetkov79 4mo ago
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 her
3.
by kspetkov79 4mo ago
I would not treat it as code to merge. It is closer to a rough spec that happens to compile.
4.
by kspetkov79 4mo ago
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.
5.
by kspetkov79 4mo ago
The hard part is not packaging the knowledge. It is keeping it current and knowing when it does not apply.
6.
by kspetkov79 4mo ago
Cloud cost problems are often just ownership problems with a bill attached.
7.
by kspetkov79 4mo ago
They are not stealing the package. They are using it as a door into developer machines, CI, tokens, and customer systems.
8.
by kspetkov79 4mo ago
For mail servers, readable configuration is a feature, not just aesthetics.
9.
by kspetkov79 4mo ago
AI output is fine as a draft. The mess starts when people ship it without being able to explain the diff.
10.
by kspetkov79 4mo ago
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.
11.
by kspetkov79 4mo ago
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.
12.
by kspetkov79 4mo ago
Postinstall hooks are a footgun. The bad part here is that people reviewing a PHP package may not even look closely at package.json.
13.
by kspetkov79 4mo ago
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.
14.
by kspetkov79 4mo ago
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.
15.
by kspetkov79 4mo ago
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.
16.
by kspetkov79 4mo ago
A bad metric can look fine at first. Then people get good at moving the number instead of improving the thing.
17.
by kspetkov79 4mo ago
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.
18.
by kspetkov79 4mo ago
They tend to turn a small change into the whole cleanup plan. Sometimes that is useful, but it makes estimates too large.
19.
by kspetkov79 4mo ago
I’ve seen this too. Asking for the small boring failure modes separately helps.
20.
by kspetkov79 4mo ago
Probably just a bad exit IP. VPN addresses get abused a lot. I would switch nodes before assuming HN blocks Mullvad.
21.
by kspetkov79 4mo ago
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.
22.
by kspetkov79 4mo ago
This seems useful for local and disconnected setups, but the compatibility wording needs care. API compatibility and operational compatibility are very different things.
23.
by kspetkov79 4mo ago
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.”
24.
by kspetkov79 4mo ago
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 the
25.
by kspetkov79 4mo ago
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.
26.
by kspetkov79 4mo ago
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