upvote
It is entirely likely that with AI, you could just spin up the whole 'stack' as you need it without depending on external services. AI will truly drive the cost of software generation to zero.
reply
Well, no you have it completely backwards. The scenario where every large institution generates their own software stack using AI is one where the sale price of software is zero (there is no demand) but there is a cost (it's whatever the AI companies want to charge, with almost infinite leverage since this organization can't do it alone)
reply
Nope, it's you that is completely wrong. I can already run Qwen-3.8-27B on my 2021 64GB M1 Max Macbook Pro at a totally acceptable tok/s. The hardest part was waiting for the download to complete. It's free modulo cost of electricity.

I can build almost any piece of software I can dream up, the data never leaves my machine, and there's literally no way for anyone to charge me any price ever.

reply
Yes, but can you verify that it is what you wanted it to be for free? If you're making a framework out of thin air it'll still be an undertaking to check that.
reply
Yes? My time is a cost, yes. But otherwise, not really an issue? Does that change my answer to the previous question? Not at all?

I'm struggling to understand the point of your comment. Why would that affect whether or not I am over the pricing barrel with a frontier lab? Like is it easier to verify Opus code than Qwen code? The code is the code.

reply
That would hold only if they are creating their stack over and over again. For the vast majority of what people want to do, make their purpose bound app once and go to work. Advancing tech for the sake of a new font loading do-dad or whatever is pointless. Look at all this crap we made over the last 30 years, and here we are back to preferring text.
reply
Programmers are "program reviewers" now, more and more.

But the tools we have to do this suck. We don't have much beyond "here's the source code as text, look at it, and think really hard".

Another comment[0] suggested having AI generate "code walks" through the code. This seems better than our current approach of "my PR contains a diff, good luck".

I'm working on a tool in Emacs that allows me to mark certain lines, or entire projects, as needing review, and then helps me track which parts have been reviewed. I need something to help me find parts of the code I have never reviewed before.

[0]: https://news.ycombinator.com/item?id=50410493

reply
As PRs get beefier I find myself using the LLM to ask pointed questions and do general surveys of the diff to flag architectural violations, smells, etc. before I read through the entire thing by hand. If you put all of your architectural and business decisions in the repo via spec-driven tools or otherwise then this becomes quite useful. It also helps if you have a vision in your head of what the system is supposed to look like structurally so you can ask the LLM specifically how the PR is handling things that you'd be on the lookout for anyway.
reply
I've been thinking about a workflow where PRs just get automerged into a staging environment of some kind, and then tooling helps ensure that all code, ALL the code in the entire project, is regularly reviewed together.

When lines change, they are put up for review. When lines haven't been reviewed for awhile, they are put up for review. Lines are ranked based upon the complexity of the context they are in, and complex areas of the code are reviewed more often.

Basically, stop focusing on individual PRs and instead focus on continuous review of the entire system with tooling that helps identify those parts of the code that are most in need of review.

Reviewing PRs is wasteful because the optimal way to review a system does not match the way a system naturally grows through individual commits.

reply
> Programmers are "program reviewers" now, more and more.

Our job, much like a locomotive operator, is to make sure the agents don't go off the rails. We call ourselves software engineers in recognition of that.

reply