kspetkov79

no profile record

Submissions

[untitled]

1 pointsby kspetkov79letzten Monat0 comments

[untitled]

1 pointsby kspetkov79letzten Monat0 comments

comments

vor 2 Monatendiscuss

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

vor 2 Monatendiscuss

[dead]

vor 2 Monatendiscuss

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?

vor 2 Monatendiscuss

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

vor 2 Monatendiscuss

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.

vor 2 Monatendiscuss

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

vor 2 Monatendiscuss

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

vor 2 Monatendiscuss

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

vor 2 Monatendiscuss

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

vor 2 Monatendiscuss

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

vor 2 Monatendiscuss

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.

vor 2 Monatendiscuss

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.

vor 2 Monatendiscuss

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

vor 2 Monatendiscuss

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.

vor 2 Monatendiscuss

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.

vor 2 Monatendiscuss

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.

vor 2 Monatendiscuss

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

vor 2 Monatendiscuss

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.

vor 2 Monatendiscuss

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

vor 2 Monatendiscuss

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