Viewing profile — kspetkov79

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

[dead]

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 stop…

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.