upvote
> The higher paid engineers i've worked with are always worth their salary/hourly rate because of the way they approach problems and the solutions they come up with.

I'm honestly just happy at the moment, because our two junior admins/platform engineers have made some really good points to me in preparation for their annual reviews.

One now completed his own bigger terraform project, with the great praise of "That looks super easy to maintain and use" from the other more experienced engineers. He figured: "It's weird, you actually end up thinking and poking at a problem for a week or two, and then it actually folds into a very small amount of code. And sure, Copilot helped a bit with some boilerplate, but that was only after figuring out how to structure and hold it".

The other is working on getting a grip on running the big temperamental beast called PostgreSQL. She was recently a bit frustrated. "How can it be so hard to configure a simple number! It's so easy to set it in ansible and roll it out, but to find the right value, you gotta search the entire universe from top to bottom and then the answer is <maybe>. AAaah I gotta yell at a team". She's on a good way to become a great DBA.

> Agents are great at building out features, i'm not so sure about complex software that grows over time. Unless you know the right questions to ask, the agent misses alot. 80/20 doesn't work for systems that need 100% reliability.

Or if it's very structured and testable. For example, we're seeing great value in rebuilding a Grafana instance from manually managed to scripted dashboards. After a bit of scaffolding, some style instructions and a few example systems, you can just chuck it a description and a few queries, it just goes to successful work and just needs a little tweaking afterwards.

Similar, we're now converting a few remnants of our old config management to the new one using AI agents. Setup a good test suite first, then throw old code and examples of how the new config management does it into the context and modern models do that well. At that point, just rebuilding the system once is better than year-long deprecation plans with undecided stakeholders as mobile as a pet ferret that doesn't want to.

It's really not the code holding the platform together, it's the team and the experiences and behaviors of people.

reply
It makes sense for junior admins and junior platform engineers to leverage LLM's but I'd be highly skeptical for the future skillset of any junior software engineer who leverages LLM's right off the bat, unless we have already moved that goalpost.
reply
Ya, this is the issue. LLMs are not great for developing minds. A lot like the internet presently, to be frank.

For fully developed and experienced minds, both can be useful.

reply
You’re not wrong. You’re not the only one saying this either. Though, I’m currently of the mind that the concern is overblown. I’m finding Opus 4.6 is only really capable of solving a problem when the prompt explains the fix in such concrete detail that coding is incredibly straightforward. For example, if the prompt has enough detail that any decent human programmer would read it and end up writing basically the same code then Claude can probably manage it too.

While I haven’t used other models like Codex and Gemini all that much recently, Anthropic’s is one of the top-tier models, and so I believe the others are probably the same in this way.

A junior’s mind will not rot because the prompt basically has to contain detailed pseudocode in order to get anywhere.

reply
Also, I have been called a bit of a hard-ass for this, but if the junior author of some piece of code is not able to explain to me why it is written that way or how they would extend it in a few reasonable cases, I consider that a problem.

This is orthogonal to both if it is well thought-out/naive/really strange code, or LLM generated/LLM assisted/hand written code. If there is a good understanding of the task and the goals behind it, the tools become secondary. If skills are lacking, it will end up a mess no matter the tools and it needs teaching.

Most of us could run stable servers with just ssh and vi. Would suck a lot though.

reply
> He figured: "It's weird, you actually end up thinking and poking at a problem for a week or two, and then it actually folds into a very small amount of code. And sure, Copilot helped a bit with some boilerplate, but that was only after figuring out how to structure and hold it".

Let me just get you that Fred Brooks quote, now where was it...? Ah, yes, here's one:

https://news.ycombinator.com/item?id=4560756

reply
We didn't even have to offshore for lots of bad code to be written.

Looks at the scores of Ycombinator startups that wrote a shitload of awful code and failed. Good ideas, pretty websites, but not a lot of substance under the hood. The VC gathering aspect and online kudos was way more important to them than actually producing good code and a reliable product that would stand the test of time.

Pretty much the most detestable section of the HN community. IMNHSO. I notice they're much quieter than usual since the whole vibe coding thing kicked off.

reply
> Looks at the scores of Ycombinator startups that wrote a shitload of awful code and failed.

This can also be restated as, look at all the startups that wrote a shitload of awful code and succeeded.

That’s an indicator code quality doesn’t matter at macro scales. We already knew this though even if we didn’t explicitly say it. It’s more about organization, coordination, and execution than code.

reply
This seems like it's reading too much into things. I'm sure driving an ambulance slower vs faster doesn't make a difference to survival in most cases, but on the margins it absolutely does.

Startups are also quite different from ambulances; surviving and minimising patient harm isn't the most important thing for a startup. Instead, it's building a profitable and valuable business. You're not just worrying about the margins, you're also hoping to squeeze out every bit of growth you can.

reply
> That’s an indicator code quality doesn’t matter at macro scales.

I think it can though. It just depends. Having high quality code and making good technical choices can matter in many ways. From improving performance (massively) and correctness, to attracting great talent. Jane Street and WhatsApp come to mind, maybe Discord too. Just like great design will attract great designers.

I also think it might matter even more in the age of AI Agents. Most of my time now is spent reviewing code instead of writing code, and that makes me a huge bottleneck. So the best way to optimize is to make the code more readable and having good automated checks to reduce the amount of work I need to do, like static types, no nulls, compilation, automated tests, secondary agent reviews, etc.

reply
I mean, look at all the startups that succeeded despite being complete shitshows behind the scenes... the baseline for leadership, organization, coordination or, hell, execution for a startup to succeed isn't exactly high either.
reply
They left ages ago, around the time PH got big.

I can't remember the last time I saw a '10 ways to fit 25 hours in 24 hours' type article on here, which were rife 10 years ago.

reply
What's PH?
reply
Product Hunt (I assume)
reply
I think it is a misnomer to attribute startup failure to bad code. There are so many other factors at play that are more powerful.

Not to say the crowd u speak of doesn’t exist, they do.

reply
One thought experiment I keep having when I see LLM hype: imagine if our outsourcing companies could be as blasé about copyright as OpenAI, and how profitable they could be.

I mean, rename some dudes over there to ‘transformer’, and let them copy & paste from GitHub with abandon… I know we could get a whole browser for less than a few grand.

We wouldn’t, because it’d be copyright-insane. But if we just got it indirect enough, maybe fed the info to the copiers through a ‘transforming’ browser to mirror the copyright argument, I bet we could outperform OpenAI in key metrics.

Coding is formalizing for the compiler. The other 99% of the job is softly getting the PHB not to fuck the entire company and being unique in not doing dumb shit everyone thinks is popular now but will regret soon. It’s all like IT tribal tattoos. Barely cool for a couple of years, and then a lifelong source of shielded regret.

reply
I'm surprised you think this hasn't been happening for years, in smaller offshore shops.
reply
PHB = pointy-haired boss?
reply