It feels like we're doing another lift to a higher level of abstraction. Whereas we had "automatic programming" and "high level programming languages" free us from assembly, where higher level abstractions could be represented without the author having to know or care about the assembly (and it took decades for the switch to happen), we now once again get pulled up another layer.
We're in the midst of another abstraction level becoming the working layer - and that's not a small layer jump but a jump to a completely different plane. And I think once again, we'll benefit from getting tools that help us specify the high level concepts we intend, and ways to enforce that the generated code is correct - not necessarily fast or efficient but at least correct - same as compilers do. And this lift is happening on a much more accelerated timeline.
The problem of ensuring correctness of the generated code across all the layers we're now skipping is going to be the crux of how we manage to leverage LLM/agentic coding.
My point is that the chemical complexity (manufacturing uses) can be reproduced, and the energy storage density also can be. So really the gift of hydrocarbons under the ground is more that readily available energy is under our feet to help propel us towards higher levels sources of energy. IMO it’s a stepping stone and that’s effectively how humanity is using it.
The fact that as many engineers are on payroll doesn't mean that "cloud" is not an efficiency improvement. When things are easier and cheaper, people don't do less or buy less. They do more and buy more until they fill their capacity. The end result is the same number (or more) of engineers, but they deal with a higher level of abstraction and achieve more with the same headcount.
In this year of 2025, in December, I find it untenable for anyone to hold this position unless they have not yet given LLMs a good enough try. They're undeniably useful in software development, particularly on tasks that are amenable to structured software development methodologies. I've fixed countless bugs in a tiny fraction of the time, entirely accelerated by the use of LLM agents. I get the most reliable results simply making LLMs follow the "red test, green test" approach, where the LLM first creates a reproducer from a natural language explanation of the problem, and then cooks up a fix. This works extremely well and reliably in producing high quality results.
You're on the internet, you can make whatever claims you want. But even with no sources or experimental data, you can always add some rational logic to add weight to your claims.
> They're undeniably useful in software development
> I've fixed countless bugs in a tiny fraction of the time
> I get the most reliable results
> This works extremely well and reliably in producing high quality results.
If there's one common thing in comments that seems to be astroturfing for LLM usage, it's that they use lots of superlative adjectives in just one paragraphs.
You can chose to see it as astroturfing, or see it as people actually thinking the superlatives are appropriate.
To be honest, it makes no difference in my life if you believe or not what I'm saying. And from my perspective, it's just a bit astounding to read people's takes that are authoritatively claiming that LLMs are not useful for software development. It's like telling me over the phone that restaurant X doesn't have a pasta dish, while I'm sitting at restaurant X eating a pasta dish. It's just weird, but I understand that maybe you haven't gone to the resto in a while, or didn't see the menu item, or maybe you just have something against this restaurant for some weird reason.
X has a pasta dish is an easily verifiable factual claim. the pasta dish at X tastes good and is worth the money is a subjective claim, unverifiable without agreeing on a metric for taste and taking measurements. they are two very different kinds of disagreements
'It's $CURRENTYEAR' is just a cheap FOMO tactic. We've been hearing these anectodes for multiple current years now. Where is this less buggy software? Does it just happen to never reach users?
"high quality results".
Yeah, sure.
Then I wanted to check this high quality stuff by myself, it feels way worse than the overall experience in 2020. Or even 2024.
Go to docs, fast page load. Than blank, wait a full second, page loads again.
This does not feel like high quality. You think it does because LLM go brrrrrrrr, never complains, says your smart.
The resulting product is frustrating.
AI is increasing the capacity of existing employees and I think we're all still discovering, everyday, better ways to leverage it even more. So when the question comes of hiring a new teammate, the value they'd bring to the table needs to be convincingly more than what I can expect to achieve alone with AI.
I think the glut is ZIRP, but the lack of recovery (or very slow pickup) is AI.
As a counter anecdote, I've yet to try a model where I break even. The output is so untrustworthy that I need to spend as much time coaching and fixing as if I'd just written it myself. When it does produce a working result faster, I still end up with less confidence in it.
What I'm working on doesn't have much boilerplate, though, and I've only been programming for 18 years. Maybe I need to work for another 7 before it starts working for me.
There's definitely a method to using them well. It took me 6 months of trial, giving up, trying again, refining my approach, ... to eventually get fairly good results in a consistent manner. It's useful to know what the LLMs are good at and what type of errors they will do. It's also very useful to be a stickler about software engineering practices to keep the LLMs focused in the right direction.
Example stuff that helps:
- extensive test suites
- making LLMs use YAML for data-intensive files, instead of writing inline
- putting a lot of structural guard rails using type-systems, parse-dont-verify, ...
- having well scoped tasks
- giving the LLM tight self-serve feedback loops
Recently I made it fix many bugs in a PEG grammar and it worked really well at that. I made it turn a test suite from an extensive Go test array to a "golden file" approach. I made it create a search index for documentation and score the search quality using qualitative IR metrics, and then iterate until the metrics met a minimum standard.
Its effectiveness is going to depend on the domain and tech stack used.
You also need to know what chunks of AI output to keep and what to throw away.
For example, Gemini 'Fast' quickly identified a problem for me the other day, based on the stacktrace. But its proposed solution was crappy. So, I was happy with the quick diagnosis, but I fixed the code manually.
My rule on this is that you can only judge your coworker’s productivity never your own. People are horrible at judging their own productivity, and AI makes it really easy to just dump a bunch of work on someone else.
And yet despite being largely obsolete in the specifics, gang of four remains highly relevant and useful in the generalities. All these books continue to be absolutely great foundations if you look past their immediate advice.
I think this depends a lot on the region. I find that forecast quality differs widely from region to region. My guess is that it's a matter of (1) some regions have less advanced models available to them and (2) some regions have fundamentally more complex and unpredictable weather patterns.
Concrete if anecdotal example: weather forecast in SF are fairly accurate but the weather patterns are also simple to predict with the Pacific High and the simpler high level mechanics at play. Weather forecasts in Seoul are quite often completely wrong, but the weather patterns are also much more dynamics at a macro level with competing large systems in China/Gobi desert and the Western Pacific.
I'm not a meteorologist, just a sailor who likes to look at weather.
Future investors can negotiate liquidation preference and participation terms that will give them a bigger part of the pot than their % ownership during a “liquidation event” I.e. basically any outcome other than an IPO will trigger those rights
But aren't the terms of a SAFE that you'll get the same terms as the best terms (MFN) offered to investors in the next round, up to a cap?
Seems like you get just as diluted by future rounds as the professional VCs that will make up the next round, if you get the same terms?
FWIW I don't think angel investments make any financial sense but see them as a minor chance of upside and a significant way to help and connect with people.
Sure. But "liquidation events" are not the events that give you the wins. The point of angel is to get in while the company is cheap. Dilution is part of the math.
People over profit in this case would have been cowardice, not courage. Some had to lose their job for others to keep theirs and for the product to continue serving their customers.
Would you respect a leader who refuses to make hard calls and sinks everyone aboard the ship as a result?
Also people buy databases to do serious stuff. They pay you money to trust you with their data. Being a serious company that makes the hard calls to protect your product is exactly what a serious customer needs.
FWIW I was part of these layoffs and I completely supported them. No glory in putting your head in the sand when people count on you to do the right thing.
We're in the midst of another abstraction level becoming the working layer - and that's not a small layer jump but a jump to a completely different plane. And I think once again, we'll benefit from getting tools that help us specify the high level concepts we intend, and ways to enforce that the generated code is correct - not necessarily fast or efficient but at least correct - same as compilers do. And this lift is happening on a much more accelerated timeline.
The problem of ensuring correctness of the generated code across all the layers we're now skipping is going to be the crux of how we manage to leverage LLM/agentic coding.
Maybe Cursor is TurboPascal.
reply