abahgat

I bought a pretty powerful desktop computer for gaming in late 2025. It came with an RTX 5080, which I started using to run some local LLMs and run some experiments (most recently, I was trying to get agents to get better at playing Zork I).

I've mostly enjoyed having WSL to leverage Linux dev tools, but it seems like it's still adding overhead that prevents me from taking advantage of the GPU in full, so I'll likely get another drive and install Linux.

I tried Qwen, Llama, Mistral and Gemma. Gemma 4 was pretty impressive.

I can see how this is a great building block for what Zed is doing around collaboration.

One thing I would really love to see, however, is a way to better attach code review comments to the specific version of code they were left on. I find it quite difficult to do with git and github, considering that commit hashes change every time one is forced to rebase (say, for example, to handle a merge conflict).

Do you expect DeltaDB to help address this problem?

Some programming is the equivalent to designing a factory, some programming is the equivalent to carving out wood pieces.

I've worked in large organizations where a small number of staff+ engineers were approaching programming as factory, while many more engineers were obsessing about the details of their own narrowly-focused work and liked it that way.

It feels like the scale is tipping more towards the factory model and, understandably, not everyone is excited about that.

To be fair, shipping these guidelines as AGENTS.md/CLAUDE.md in the repo that contains the assignments will make it so that agents will pick this up without needing students to opt in explicitly. Seems like a reasonable first step to me

Hi HN, I wrote this post after an experiment over the holidays. I had Claude write a cross-stack feature touching our database, cloud infra, mobile app, and the embedded application running on our hardware devices at work. What would usually take me a week took an afternoon to generate.

But it still took weeks to test and merge.

The takeaway for me was that for teams operating with legacy debt, or teams where verification requires physical interaction (you can't throw prompt engineering at a hardware test bench), AI doesn't solve the bottleneck; it just shifts it. We are making code generation incredibly cheap, but the cost of verification and code review isn't shrinking, and the burden is falling on our most senior engineers.

I’d be curious to hear how others managing complex or non-standard codebases are adapting their CI/CD and review processes to keep up with the volume of AI-generated code.

The original architectures are based on Google's offering by many of them generalize well beyond GCP.

I was asking because if you optimize for pitches response rate, you end up with better pitches but not necessarily good matches between candidates/companies.

I'm curious: in

"Every pitch received improves our personalized matching algorithm, making pitches get even better over time."

how would you distinguish a "good" pitch from a "bad" one?