"top out at a couple of hundred lines of tested, production-ready code per day" + " productively review a couple of thousand." + LLM agents that write code for you = apparent contradiction with your first paragraph.
Then please explain, to me he brought up an unrelated point about ethanol (which is often poorly understood and mischaracterized anyways) consuming a portion of agriculturally productive land. Which BTW this agricultural land that produces ethanol is probably not even close to the best place in the country for industrial scale solar from a LOT of perspectives.
What does the 1% of land used to grow corn have to do specifically with solar and batteries? Solar doesn't need to be on the 15% arable land at all.
The corn doesn't just produce ethanol, which just utilizes the starch/sugar. The protein, fat, fiber is eaten by livestock in some form like distillers grains.
And governments like to have food security , and having secondary uses for an abundance of food in the good times is more convenient than storing cheese in caves , and in case of an emergency shortage the production is already there without having to rip up solar panels to grow food.
My conclusion is you're conflating issues (solar and ethanol) unnecessarily.
> I should know bc I have a whole house battery and solar system
This is not really a qualification to speak on how the grid works, at all.
Actually having panels on your roof doesn't give you unique insight into how solar panels operate - there is extensive data out there, any PV installation can become a data source trivially.
> The reality is that battery/solar requires major quality of life and activity time shifting trade-offs.
One residence powering itself is not representative of how the grid works, and is not a good way to evaluate any power generation technology whether its PV, coal, nuclear, etc.
> if that's all you are doing, why should the maintainers spend time considering your contribution as opposed to prompting the models themselves?
Plenty of reasons:
- Maybe the maintainers don't have enough credits to run the LLM themselves
- Maybe the maintainers don't value fixing the issue which is why it sits in issue tracker
- Maybe LLM user has a different model or harness that produces different outcomes
- Maybe the LLM user runs the model over and over and gets lucky
Why does it matter if the I understand the ticket and solution? THe LLLM writes the code not me. If you want to check the LLM understanding i'll be happy to copy and paste your gatekeeping questions to it.
Hey I thought you were a proponent of "no one needs to look at the code" ? dark factory, etc etc.
I don't deny it. When I said "mess around with making a password manager suit your taste" feel free to append " while using and getting experience with an LLM". nothing changes.
im glad you're dogfooding your pw manager now. I'm glad vibe coding met your own standard of quality.
I will leave it as an exercise to you to think about all the edge cases and usability issues that have been solved in mainstream pw managers that you've never thought about. I hope you keep your LLM subscription active so you can fix them as they come up. And to keep up with updates from IOS and firefox as they come out.
If we're talking about goalposts, lets also recognize the Motte and Bailey of initial claims of "20 years professional software engineer actually good password manager" to "hee hee toy project testing how LLms work not complete not even for personal not recmmond for others"
I don't think your password manager is good, and I don't think you think it's good either or you'd be using it.
I'm not trolling. It's way cheaper and faster to just clone an existing project if you want to mess around with making a password manager suit your taste.
If you didn't like me telling you about search engines you probably won't like me telling you how git clone works BUT...
For all intents and purposes, (in the context of diddling around with a password manager you might use yourself and wouldn't recommend to anyone), Any/all of those existing open source password managers can ALSO be yours just as much as the output from any LLM.
I'm serious, not only can you tweak them to "your tastes and your tastes alone", you don't have to even tell upstream maintainers what you're doing let alone get it merged.
This whole reply, and every other "anecdote" reply is more worthless than the pixels its printed on, without a link to your "actually did a good job" password manager.
(wow funny how these vibe code apps always are copies of something theres many open source versions of already)
once all interactions appear instantaneous to a human, which is usually possible even with python et al, reducing CPU usage doesn't matter in 99.9% of cases that the app never gets popular enough that the savings in running the app would even add up to the cost of a LLM subscription.
Also, in most instances CRUD apps could run with their own data structures and filesystem data persistence. Not to say its a good idea,But I'd wager you could get on the frontpage with "show HN: I build a ToDo app that's 10x cheaper to run on AWS than Django".
In reality SQL databases, along with programming languages, OS utilities, webservers, crytography, and probably a few other technologies are basically bedrock technologies that LLM builds upon and have durable value, unlike Dev Tools / Frame Works / Simplified Human Interface wrapper projects, such as django ansible and the thousands of similar projects .
The more LLMs *CAN* code, human oriented coding tools and concerns become worthless.
>I think it makes sense for full stack monolithic frameworks to be used more frequently.
Why? I believe full stack frameworks solved a problem for human coders, not AI coders. In fact they are only a limitation for AI going between programming language and runtime.
Suit yourself really. maybe there's more training data for CRUD apps in python than C, but I don't think it's too hard to implement the fundamentals of a web app in any language if you're also using a web server.
Most webapps aren't that popular therefore don't use that much computation anyways, so theres a point of diminishing returns on making your CRUD as efficient as scientifically possible. some prefer a managed runtime so that a bug causes EG python to crash instead of the consequences of a bug in native code, but that can be mitigated easily enough as well.