Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AI: Accelerated Incompetence

slater.dev

Post reply on HN
Print view View original

181–190 of 287 posts

Re: AI: Accelerated Incompetence

#181

Post by CuriouslyC »

rTX5CMRXIfFG wrote: post #111
CuriouslyC wrote: post #11

Earlier quoted context omitted.

The people who write AI slop would have written human slop, they're just much faster now, and the people who are really good tend to be so set in their ways that they resist AI when they could quadruple their productivity if they just put half as much time into learning how to use it as they put into their current skillset.

Honestly there are good reasons to resist AI even as a senior. If prompting an LLM cannot be easily integrated into your existing workflow or demands a huge change in tooling, it's just distracting or crippling. I don't think we need to have a long discussion as to why distractions and context switches are counterproductive.

You can say that, but when the principle down the hall from you who's got a highly tuned agentic AI workflow is outproducing half your team by himself while leading engineering direction on multiple projects, it's hard to justify that to management.

Re: AI: Accelerated Incompetence

#183

Post by ecshafer »

jvanderbot wrote: post #115
Artgor wrote: post #65

You know, sometimes I feel that all this discourse about AI for coding reflects the difference between software engineers and data scientists / machine learning engineers. Both often work with unclear requirements, and sometimes may face floating bugs which are hard to fix, but in most cases, SWE create software that is expected to always behave in a certain way. It is reproducible, can pass tests, and the tooling is…

This has been about 50% of the time my experience as well. There are very good SWE who know how to use ML in real systems, and then there are the others who believe through and through it will replace well understood systems developed by subdomain experts. As a concrete example, when I worked at Amazon, there were several really good ML-based solutions for very real problems that didn't have classical approaches to l…

The lack of knowledge of and application of fundamental engineering principles is a huge issue in the Software world. While its great that people can pick up programming and learn and get a job, I have noticed this is often correlated with people not having a background in Hard Science and Mathematics. Even amongst CS graduates there are a lot of who seem to get through without any mathematical or engineering maturity. Having a couple people in a team with Physics, Mathematics, Mechanical or Electrical Engineering backgrounds, etc. can really be a big asset as they can fight back and offer a classical solution that will work nearly 100% of the time. Whereas someone who just did a Bootcamp and no formal scientific training seems less likely to be able to grasp or have prior knowledge of classical approaches.

I think that this is one reason Software has such a flavor of the month approach to development.

Re: AI: Accelerated Incompetence

#184

Post by photochemsyn »

LLMs are great tools for assisting learning - but this is not an area where it's easy to extract large profits from users interested in learning. For example, if you want to understand the risks of floating point calculations given the limitations of computer hardware by analyzing how LAPACK and BLAS manage the problem, you can have an LLM write up a whole course syllabus on the subject and work your way through examples provided by the LLM with pretty good certainty that it's not hallucinating you into a corner. This is a well-studied topic, so one feels fairly confident that the LLM, properly prompted, is going to give you good information and if you cross-check with a textbook you won't be surprised.

In practice, I find this approach reduces productivity in favor of gaining a deeper understanding of how things work - instead of just naively using LAPACK/BLAS based libraries, one 'wastes time' diving into how they work internally, which previously would have been very opaque.

These are tools, it's up to you how you use them. Kind of like compilers, really.

Re: AI: Accelerated Incompetence

#185

Post by ecshafer »

dingnuts wrote: post #175
palmotea wrote: post #155

Earlier quoted context omitted.

> So, for MLE, working with AI that isn't always reliable, is a norm. They are accustomed to thinking in terms of probabilities, distributions, and acceptable levels of error. Applying this mindset to a coding assistant that might produce incorrect or unexpected code feels more natural. They might evaluate it like a model: "It gets the code right 80% of the time, saving me effort, and I can catch the 20%." And given…

[flagged]

The GP wasn't making a political argument just pointing out statistics.

Re: AI: Accelerated Incompetence

#186

Post by dingnuts »

rak111esh wrote: post #78
Etheryte wrote: post #38

Earlier quoted context omitted.

This is an easy quip to make, but it's also pretty wrong. 3D printing has been a massive breakthrough in many industries and fundamentally changed the status quo. Aerospace is a good example, much of what SpaceX and other younger upstarts in the space are doing would not be feasible without 3D printed parts. Nozzles, combustion chambers, turbopumps etc are all parts that are often printed.

OP's comment and your response could both be true at same time

I actually think the response makes the point. LLMs are useful, and will provide certain innovations, but they aren't a panacea. At the top of its height, proponents talked like 3D printing was going to make parcel delivery obsolete, and that's the same hype you see with language models "threatening" all knowledge workers

Re: AI: Accelerated Incompetence

#187

Post by esafak »

viraptor wrote: post #142
zhivota wrote: post #113

Earlier quoted context omitted.

In my experience the difficulty in this kind of task is reading the docs of a bunch of packages I haven't used in months/years and probably won't use again anytime soon, testing things manually and creating all the little harnesses to make that work without running for minutes at a time, etc. Sure for someone who does ETL type work all day, or often enough anyway, they'd scoff, and true LLM won't really save them tim…

Similarly for me, my visualisation pipeline changed from "relearn matplotlib and pandas every single time" to "ask for code, fix up details later". In this case the time saving scales with how much I forgot from the docs and the last time. I need to do the review and debugging either way, so that's moot.

It's not your fault their APIs suck!

Re: AI: Accelerated Incompetence

#188

Post by throw4847285 »

bearjaws wrote: post #171
throw4847285 wrote: post #148

Earlier quoted context omitted.

That's an extremely self-serving narrative. I assume you're part of the 30 percent?

Whether I'm in the 30% or not isn't the core issue, is it? The point is about the impact AI will have based on existing work ethics. Many of us have seen colleagues who barely contribute, and AI is a tool that will either be leveraged for growth by the engaged or used as another crutch by those already disengaged.

I believe AI is going to degrade everybody's work ethic, regardless of current performance. I don't think it's going to act like some kind of Calibration Panel where the bottom performers are knocked out by AI, leaving the higher performers to keep cruising along confident in their skills. I believe it will make everybody worse.

Re: AI: Accelerated Incompetence

#189

Post by Arch-TK »

I think it's more of an issue where the term "engineering" means something very different in the software world than it does in the rest of the world but I find it a bit difficult to take any such article seriously when it makes statements like: "LLMs can't replace human engineering." as a response to "If you're a skilled, experienced engineer and you fear that AI will make you unemployable, adopt a more nuanced view."

If you are able to make such deductions then you should also be able to deduce that almost nobody employed in a "software engineering" role is doing any actual engineering.

The article assumes that software companies are hiring software engineers (where "engineer" actually means what it does everywhere else) when in reality most software companies are not hiring any kind of actual engineer.

And if engineers can't be replaced by AI, but you're not actually an engineer, can you be replaced by AI?

Now I don't know the answer for sure, but I'd say for most people in "software engineering" roles the answer is still no, at least for now. But the reasons definitely can't have anything to do with whether AI can do engineering.

As a final note: I'd recommend anyone in a software engineering role, who thinks they do "actual engineering", to actually study some actual engineering discipline. You most likely have the necessary level of intelligence to get started. But you will quickly find that electrical engineering, electronics engineering, mechanical engineering, structural engineering, drainage engineering, etc, are nothing like your actual day to day job in _very fundamental_ ways.

Re: AI: Accelerated Incompetence

#190

Post by crazylogger »

_shadi wrote: post #130
viraptor wrote: post #120

> it doesn't reason about ideas, diagrams, or requirements specifications. (...) How often have you witnessed an LLM reduce the complexity of a piece of code? > Only humans can decrease or resist complexity. It's funny how often there's a genuine concept behind posts like these, but then lots of specific claims are plainly false. This is trivial to do: ask for simpler code. I'm using that quite often to get a second…

A big problem I keep facing when reviewing junior engineers code is not the code quality itself but the direction the solution went into, I'm not sure if LLM models are capable of replying to you with a question of why you want to do it that way(yes like the famous stackoverflow answers).

Nothing fundamentally prevents an LLM from achieving this. You can ask an LLM to produce a PR, another LLM to review a PR, and another LLM to critique the review, then another LLM to question the original issue's validity, and so on...

The reason LLM is such a big deal is that they are humanity's first tool that is general enough to support recursion (besides humans of course.) If you can use LLM, there's like a 99% chance you can program another LLM to use LLM in the same way as you:

People learn the hard way how to properly prompt an LLM agent product X to achieve results -> some company is going to encode these learnings in a system prompt -> we now get a new agent product Y that is capable of using X just like a human -> we no longer use X directly. Instead, we move up one level in the command chain, to use product Y instead. And this recursion goes on and on, until the world doesn't have any level left for us to go up to.

We are basically seeing this play out in realtime with coding agents in the past few months.

Post reply on HN