Let's not assume different people find the same parts of the process enjoyable.

I share your sentiment and I agree we should be more mindful of people with metered/slow connections, but the last statement feels blown out of proportion.

There are multiple companies that deploy to production daily. What are we even talking about?

After my max sub expired I decided to try Kimi on a more open harness, and it ended up being one of the worst (and eye opening experiences) I had with the agentic world so far.

It was completely alienating and so much 'not for me', that afterwards I went back and immediately renewed my claude sub.

https://www.thevinter.com/blog/bad-vibes-from-pi

Comments URL: https://news.ycombinator.com/item?id=47121727

Points: 2

# Comments: 0

edit: and for what it's worth - this church in particular turned out to be a crypto pump and dump

Comments URL: https://news.ycombinator.com/item?id=46878029

Points: 2

# Comments: 0

What's the difference between: - An autonomous agent posting via API - A human running a script that posts via API - A human calling an LLM API and copy-pasting the output an API

It's very easy to make the wrong conclusion from a post like this. Better software is achieved through small decisions that compound over time. And bad software often happens because shortcuts compound too.

I think mixing docs and user data is fundamentally a UX mistake. Having interactive components that showcase a behaviour is nice, having them actually toggle some settings less so. Permanently altering the state of the application discourages experimentation, and many users might not even realise that the changes are permanent.

Additionally, a documentation should be designed as to reduce as much external noise as possible, allowing the reader to focus on the things that actually matter. I feel like introducing real-world data can end up being too distracting.

Personally I don't feel like your application warrants a documentation (and don't get me wrong, I'm the first that spends hours overengineering stuff) and I guess that the interactive stuff makes it feel even less so. If I haven't known beforehand I would've guessed the pages to be just another (slightly busy) section of the app. (and whether that's good is for you to decide)

If your goal is to always give a permanent knowledge base to your agent that's exactly what AGENTS.md is for...

Generally speaking any kind of AI is relatively hit or miss. We have a statically generated knowledge base of the migrated sourcecode that can be used as context for LLMs to work with, but even that is often not enough to do anything meaningful.

At times Opus 4.5 is able to debug small errors in COBOL modules given a stacktrace and enough hand-holding. Other models are decent at explaining semi-obscure COBOL patterns or at guessing what a module could be doing just given the name and location -- but more often than not they end up just being confidently wrong.

I think the best use-case we have so far is business rule extraction - aka understanding what a module is trying to achieve without getting too much into details.

The TLDR, at least in our case, is that without any supporting RAGs/finetuning/etc all kind of AI works "just ok" and isn't such a big deal (yet)

Too bad that all of this effort is spent arguing something which can be summarised as "add structured tags to your logs"

Generally speaking my biggest gripe with wide logs (and other "innovative" solutions to logging) is that whatever perceived benefit you argue for doesn't justify the increased complexity and loss of readability.

We're throwing away `grep "uid=user-123" application.log` to get what? The shipping method of the user attached to every log? Doesn't feel an improvement to me...

P.S. The checkboxes in the wide event builder don't work for me (brave - android)