A lot of the debate here swings between extremes. Claims like “AI writes most of the code now” are obviously exaggerated especially coming from a nontechnical author but acting like any use of AI is a red flag is just as unrealistic. Early stage teams do lean on LLMs for scaffolding, tests and boilerplate, but the hard engineering work is still human. Is there a bubble? Sure, valuations look frothy. But like the dotcom era, a correction doesn’t invalidate the underlying shift it just clears out the noise. The hype is inflated, the technology is real.

▲

artur44 2 days ago | parent | next [-]

I think some wires got crossed. My point wasn’t that LLMs can’t produce useful infra or complex code clearly they can, as many examples here show. It’s just that neither extreme narrative AI writes everything now vs. you can’t trust it for anything serious reflects how teams actually work. LLMs are great accelerators for boilerplate, declarative configs, and repetitive logic, but they don’t replace engineering judgement they shift where that judgement is applied. That’s why I see AI as real, transformative tech inside an overhyped investment cycle, not as magic that removes humans from the loop.

▲

Daishiman 3 days ago | parent | prev | next [-]

> Early stage teams do lean on LLMs for scaffolding, tests and boilerplate, but the hard engineering work is still human.

I no longer believe this. A friend of mine just did a stint a startup doing fairly sophisticated finance-related coding and LLMs allowed them to bootstrap a lot of new code, get it up and running in scalable infra with terraform, and onboard new clients extremely quickly and write docs for them based on specs and plans elaborated by the LLMs.

This last week I extended my company's development tooling by adding a new service in a k8s cluster with a bunch of extra services, shared variables and configmaps, and new helm charts that did exactly what I needed after asking nicely a couple of times. I have zero knowledge of k8s, helm or configmaps.

▲

xdc0 3 days ago | parent | next [-]

If you are in charge of that tooling, how do you ensure the correctness of the work? Or is it that at this point the responsibility goes one level higher now where implementation details are not important or relevant at all and all it matters is it behaves as described?

▲

yunnpp 3 days ago | parent | next [-]

Just look at what they are stating:

> that did exactly what I needed

> I have zero knowledge of k8s, helm or configmaps.

Obviously this is not anything resembling engineering, or anything a respectful programmer would do. An elevator that is cut lose when you press 0 also works very well until you press 0. The claims of AI writing significant chunks of code come from these sort of people with little experience in programming or engineering in general, SPA vibe coders and what not. You should tremble at the thought of using any of the resulting systems in production, and certainly not try to replicate that workflow yourself. Which gives you a sense of how overblown these claims are.

▲

Daishiman 3 days ago | parent [-]

> The claims of AI writing significant chunks of code come from these sort of people with little experience in programming or engineering in general, SPA vibe coders and what not.

I'm sorry man but I've been doing this for 25 years and I've worked and studied with some extremely bright and productive engineers. I vouch for the code that I write or that I delegate to an LLM, and believe it or not it doesn't take a magician to write a k8s spec file, just patience to write 10 levels of nested YAMLs to describe the most boring, normal and predictable code to tell your cluster what volume mounts and env variables to load.

▲

noodletheworld 2 days ago | parent [-]

> I have zero knowledge of k8s, helm or configmaps

…

> I vouch for the code that I write or that I delegate to an LLM, and believe it or not it doesn't take a magician to write a k8s spec file…

I have been writing code since 1995.

That has zero relevance to my skill at rolling out deployments in a technology I know nothing about.

One of the two things you’ve said is false:

Either a) you do know what you’re talking about, or b) you are not confident in the results.

It can’t be both.

It sounds to me like you’re subscribed heavily into a hype train; that’s fine, but your position, as described, leaves a lot to desired, if you’re trying to describe some wide trend.

Here my anecdote: major cloudflare outages.

Hard things are hard. AI doesn’t solve that. Scaffolding is easy; ai can solve that.

Scaffolding is a reliable thing to rely on with ai.

Doing it for K8s configuration, if you don’t know k8s is stupid. I know what I’m talking about when I say that. Having it help you if you do know what you’re doing is perfectly legit.

Claiming it did help when claiming you have, and I quote, “zero knowledge” (but you actually do) is hype. Leave it on LinkedIn dude. :(

	▲	Daishiman 2 days ago \| parent [-]
		> Either a) you do know what you’re talking about, or b) you are not confident in the results. It can’t be both. You've been coding for a lifetime yet you don't seem to get that certainty in software is a spectrum? I have sufficient confidence in the output of LLMs to sign my name under the code it writes when putting up a PR for a specialist to read. That's good enough for 90% of the work that we do day-to-day. You think that's not hype-worthy? > Doing it for K8s configuration, if you don’t know k8s is stupid. I know what I’m talking about when I say that. Having it help you if you do know what you’re doing is perfectly legit. "Knowing" k8s is an oxymoron. K8s is a profoundly complicated piece of tech that can don insanely complicated things while also serving as a replacement for docker-compose or basic services that could have been hosted on ECR. The concepts behind basic k8s functionality are not difficult, but I saved myself two weeks of reading how to write helm spec files, a piece of knowledge I have no interest in learning because it doesn't add any appreciable value to the software I produce, and was instead able to focus on getting what I needed out of my cluster automation scripts. This really isn't that complicated to understand. I don't care for being a k8s expert and I don't care for syntactical minutiae behind it. It isn't hype that I now I only need to understand the essential conceptual basics behind the software to get it working for what I need instead of doing a deep dive like I had to do years ago in when reading similar docs for similar IaC producs to get lesser functionality going.

▲

Daishiman 3 days ago | parent | prev [-]

Because after 25 years of coding and a dozen infrastructure description languages I know that you test your code and you get someone expert in the field to look at your PRs.

LLMs are _really_ good at writing infra code if you know how infra works, believe it or not. And the ultimate responsibility still lies in human beings for code ownership.

▲

biophysboy 3 days ago | parent | prev [-]

It depends on the task though, right? I promise I'm not in denial; I use these things all the time. Sometimes it works immediately; sometimes it doesn't. I have no way of predicting when it will or won't.

▲

Daishiman 3 days ago | parent [-]

* Infra code description languages like Terraform and K8s/helm spec files are like magic; they get 90% of the code right 90% of the time. In my experience that's about half of the work; the other half is spent debugging and correcting details that matter, but still applies to the code that I write myself.

* SQL works almost as good. It's especially useful when you need to generate queries with long lists of fields and complex query criteria. Give it a schema and let it rip.

* Python code works reasonably well. If your description is terse and clear it will generally do the right thing. It has a knack for being excessive in comments and will sometimes do things in ways that feel unnatural, but business code will be as good as the context that surrounds it. For boring, repetitive tasks like setting up program args, annotating types, and writing generic request/response cycles with common frameworks it will do boring old vanilla code. You'll likely want to touch it up and adapt it to your personal preference.

* Debugging is very much or miss. It has been absolutely fantastic at troubleshooting failed and stuck k8s jobs and service configuration issues, having no qualms about creating its own shell or python scripts to investigate ports or logs, and writing JSON parsing scripts that are snoozefest for a human to write. The regexes that I'd barely be arsed to write to parse enormous logs it writes trivially. For business logic, the more convoluted your logic the harder the time it will have, and for most debugging issues I prefer to let it run and list some hypotheses and potential issues and my intent is to learn and understand the problem myself deeply before committing to a fix.

▲

biophysboy 2 days ago | parent [-]

It sounds like it works better for declarative schema than imperative scripting/debugging (speaking loosely here). Do you agree? Seems like a good heuristic for me to keep in mind

	▲	Daishiman a day ago \| parent [-]
		Very much so.

▲

jillesvangurp 2 days ago | parent | prev [-]

The thing to remember about the dotcom era was that while there were a lot of bad companies at the time with a lot of clueless investors behind them, quite a few companies made it through the implosion of that bubble and then prospered. Amazon, Google, eBay, etc. are still around.

More importantly, the web is now dominant for enterprise SaaS applications, which is a category of software that did not really exist before the web. And the web post–dot-com bubble spawned a lot of unicorns.

In short, there was an investment bubble. But the core tech was fine.

AI feels like one of those things where the tech is similarly transformational (even more so, actually). It’s another investment bubble predicated on the price of GPUs, which is mostly making Nvidia very rich right now.

Right now the model makers are getting most of the funding and then funneling non-trivial amounts to Nvidia (and their competitors). But actually the value creation is in applications using the models these companies create. And the innovation for that isn’t coming from the likes of Anthropic, OpenAI, Mistral, X.ai, etc. They are providing core technology, but they seem to be struggling to do productive things in terms of UX and use cases. Most of the interesting things in this space are coming from smaller companies figuring out how to use the models these companies produce. Models and GPUs are infrastructure, not end-user products.

And with the rise of open-source models, open algorithms, and exponentially dropping inference costs, the core infrastructure technology is not as much of a moat as it may seem to investors. OpenAI might be well funded, but their main UI (ChatGPT) is surprisingly limited and riddled with bugs. That doesn’t look like the polished work of a company that knows what they are doing. It’s all a bit hesitant and copycat. It’s never going to be a magic solution to everyone’s problems.

From where I’m sitting, there is clear untapped value in the enterprise space for AI to be used. And it’s going to take more than a half-assed chat UI to unlock that. It’s actually going to be a lot of work to build all of that. Coding tools are, so far, the most promising application of reasoning models. It’s easy to see how that could be useful in the context of ERP/manufacturing, CRM, traditional office applications, and the financial world.

Those each represent verticals with many established players trying to figure out how to use all this new stuff — and loads more startups eager to displace them. That’s where the money is going to be post-bubble. We’ve seen nothing yet. Just like after the dot-com bubble burst, all the money is going to be in new applications on top of the new infrastructure. It’s untapped revenue. And it’s not going to be about buying GPUs or offering benchmark-beating models. That’s where all the money is going currently. That’s why it is a bubble.