Live data from Hacker News

A year of vibes

lucumr.pocoo.org

51–60 of 128 posts

Re: A year of vibes

#51
post #14
post #4

I really feel this bit: > With agentic coding, part of what makes the models work today is knowing the mistakes. If you steer it back to an earlier state, you want the tool to remember what went wrong. There is, for lack of a better word, value in failures. As humans we might also benefit from knowing the paths that did not lead us anywhere, but for machines this is critical information. You notice this when you are…

> There is, for lack of a better word, value in failures Learning? Isn't that what these things are supposedly doing?

No, we’re the ones who are learning.

There’s some utility to instructing them to ‘remember’ via writing to CLAUDE.md or similar, and instructing them to ‘recall’ by reading what they wrote later.

But they’ll rarely if even do it on their own.

Re: A year of vibes

#52
post #46

A really interesting point that keeps coming up in discussions about LLMs is “what trade-offs need to be re-evaluated” > I also believe that observability is up for grabs again. We now have both the need and opportunity to take advantage of it on a whole new level. Most people were not in a position where they could build their own eBPF programs, but LLMs can One of my big predictions for ‘26 is the industry followin…

Do you have any example repos of these OSS projects? I'm being reminded of this post every time people keep extolling how "productive" LLMs are:

https://mikelovesrobots.substack.com/p/wheres-the-shovelware...

Where is the resulting software?

Re: A year of vibes

#53
post #45

Earlier quoted context omitted.

You can export all agent traces to otel, either directly or via output logging. Then just dump it in clickhouse with metadata such as repo, git user, cwd, etc. You can do evals and give agents long term memory with the exact same infrastructure a lot of people already have to manage ops. No need to retool, just use what's available properly.

With great love to your comment, this has the same vibes as the infamous 2007 Dropbox comment: https://news.ycombinator.com/item?id=9224 I'd also argue that the context for an agent message is not the commit/release for the codebase on which it was run, but often a commit/release that is yet to be set up. So there's a bit of apples-to-oranges in terms of release tagging for the log/trace. It's a really interesting pr…

I get where you're coming from, having wrestled with Codex/CC to get it to actually emit everything needed to even do proper evals.

From a "correct solution" standpoint having one source of truth for evals, agent memory, prompt history, etc is the right path. We already have the infra to do it well, we just need to smooth out the path. The thing that bugs me is people inventing half solutions that seem rooted in ignorance or the desire to "capture" users, and seeing those solutions get traction/mindshare.

Re: A year of vibes

#54
post #4

I really feel this bit: > With agentic coding, part of what makes the models work today is knowing the mistakes. If you steer it back to an earlier state, you want the tool to remember what went wrong. There is, for lack of a better word, value in failures. As humans we might also benefit from knowing the paths that did not lead us anywhere, but for machines this is critical information. You notice this when you are…

Emacs gptel just produces md or org files. Of course the agentic capabilities are very much on a roll-your-own-in-elisp basis.

> agentic capabilities are very much on a roll-your-own-in-elisp basis

I use gptel-agent[1] when I want agentic capabilities. It includes tools and supports sub-agents, but I haven't added support for Claude skills folders yet. Rolling back the chat is trivial (just move up or modify the chat buffer), rolling back changes to files needs some work.

[1] https://github.com/karthink/gptel-agent

Re: A year of vibes

#55
post #4

I really feel this bit: > With agentic coding, part of what makes the models work today is knowing the mistakes. If you steer it back to an earlier state, you want the tool to remember what went wrong. There is, for lack of a better word, value in failures. As humans we might also benefit from knowing the paths that did not lead us anywhere, but for machines this is critical information. You notice this when you are…

Over time, do you think this process could lock you into an inflexible state?

I'm reminded of the trade off between automation and manual work. Automation crystalizes process, and thus the system as a whole loses it's ability to adapt in a dynamic environment.

Re: A year of vibes

#56
post #4

I really feel this bit: > With agentic coding, part of what makes the models work today is knowing the mistakes. If you steer it back to an earlier state, you want the tool to remember what went wrong. There is, for lack of a better word, value in failures. As humans we might also benefit from knowing the paths that did not lead us anywhere, but for machines this is critical information. You notice this when you are…

there's some research into context layering so you can split / reuse previous chunks of context

ps: your context log apps are very very fun

Re: A year of vibes

#57
post #50

Earlier quoted context omitted.

I know what you mean, it's the uncanny valley. But we don't need to "pretend" that it is a machine. It is a goddamned machine. Surely, only two unclouded brain cells can help us reach this conclusion?! Yuval Noah Harari's "simple" idea comes to mind (I often disagree with his thinking, as he tends to make bold and sweeping statements on topics well out of his expertise area). It sounds a bit New Age-y, but maybe it's…

LLMs can produce outputs that for a human would be interpreted as revealing everything from anxiety to insecurity to existential crises. Is it role-playing? Yes, to an extent, but the more coherent the chains of thought become, the harder it is to write them off that way.

It's hard to see how suffering gets into the bits.

The tricky thing is that it's actually also hard to say how the suffering gets into the meat, too (the human animal), which is why we can't just write it off.

Re: A year of vibes

#58
post #52
post #46

A really interesting point that keeps coming up in discussions about LLMs is “what trade-offs need to be re-evaluated” > I also believe that observability is up for grabs again. We now have both the need and opportunity to take advantage of it on a whole new level. Most people were not in a position where they could build their own eBPF programs, but LLMs can One of my big predictions for ‘26 is the industry followin…

Do you have any example repos of these OSS projects? I'm being reminded of this post every time people keep extolling how "productive" LLMs are: https://mikelovesrobots.substack.com/p/wheres-the-shovelware... Where is the resulting software?

>Where is the resulting software?

Everywhere.

Remember Satya Nadella estimating 30% of code at Microsoft was written by AI? That was March. At this point it's ubiquitous—and invisible.

Re: A year of vibes

#59
The very first thing I did vibe-coding was commit my prompts and AI responses. In Cursor that's extremely easy—just 'export' a chat. I stopped for security concerns but perhaps something like that is the way.

Re: A year of vibes

#60
post #9
post #2

It is nice that he speaks about some of the downsides as well. In many respects 2025 was a lost year for programming. People speak about tools, setups and prompts instead of algorithms, applications and architecture. People who are not convinced are forced to speak against the new bureaucratic madness in the same way that they are forced to speak against EU ChatControl. I think 2025 was less productive, certainly for…

>>"I think 2025 was less productive" I think 2025 is more productive for me based on measurable metrics such as code contribution to my projects, better ability to ingest and act upon information, and generally I appreciate the Anthropic tax because Claude genuinely has been a step-change improvement in my life.

> more productive for me based on measurable metrics such as code contribution to my projects

Isn‘t it generally agreed upon that counting contributions, LoC or similar metrics is a very bad way to gauge productivity?

Post reply on HN