Live data from Hacker News

Engineers who dismiss AI

terriblesoftware.org

131–140 of 256 posts

Re: Engineers who dismiss AI

#131

> The engineers refusing to try aren’t protecting themselves; quite the opposite, they’re falling behind. The gap is widening between engineers who’ve integrated these tools and engineers who haven’t. For me, however, there is one issue: how can I utilize AI without degenerating my own abilities? I use AI sparingly because, to be honest, every time I use AI, I feel like I'm getting a little dumber. I fear that excess…

You can always ask it to nudge you in the right direction instead of giving the solution right away. I suspect this way of using it is not very popular though.

This is not a new problem I think. How do you use Google, translator, (even dictionaries!), etc without "degenerating" your own abilities?

If you're not careful and always rely on them as a crutch, they'll remain just that; without actually "incrementing" you.

I think this is a very good question. How should we actually be using our tools such that we're not degenerating, but growing instead?

Re: Engineers who dismiss AI

#133
post #63

Earlier quoted context omitted.

I think we should label devs overreliant on AI as "Engineers who dismiss themselves"

I'll take that, but don't see how it's so different from the intent I've always had of "automating myself out of the job". When I want to do "engineering", I can always spin up Factorio or Turing Complete. But for the rest of the time, I care about the result rather than the process. For example, before starting to implement a tool, I'll always first search online for whether there is already a good tool that would a…

The nondeterminism is what makes LLMs different.

You download a tool written by a human, you can reasonably expect that it does what the author claims it does. And more, you can reasonably expect that if it fails it will fail in the same way in the same conditions.

Re: Engineers who dismiss AI

#135

Earlier quoted context omitted.

The productivity improvements speak for themselves. Over time, those who can use ai well and those who cannot will be rewarded or penalized by the free market accordingly.

0.1x

If only you put half as much effort into learning ai as you do trolling people who are getting gains from it...

Re: Engineers who dismiss AI

#136

> The engineers refusing to try aren’t protecting themselves; quite the opposite, they’re falling behind. The gap is widening between engineers who’ve integrated these tools and engineers who haven’t. For me, however, there is one issue: how can I utilize AI without degenerating my own abilities? I use AI sparingly because, to be honest, every time I use AI, I feel like I'm getting a little dumber. I fear that excess…

> how can I utilize AI without degenerating my own abilities?

Personally I think my skill lies in solving the problem by designing and implementing the solution, but not how I code day-to-day. After you write the 100th getter/setter you're not really adding value, you're just performing a chore because of language/programming patterns.

Using AI and being productive with it is an ability and I can use my time more efficiently than if I were not to use it. I'm a systems engineer and have done some coding in various languages, can read pretty much anything, but am nowhere near mastery in any of the languages I like.

Setting up a project, setting up all the tools and boilerplate, writing the main() function, etc are all tasks that if you're not 100% into the language take some searching and time to fiddle. With AI it's a 2-line prompt.

Introducing plumbing for yet another feature is another chore: search for the right libraries/packages, add dependencies, learn to use the deps, create a bunch of files, sketch the structs/classes, sketch the methods, but not everything is perfectly clear yet, so the first iteration is "add a bunch of stuff, get a ton of compiler warnings, and then refine the resulting mess". With AI it's a small paragraph of text describing what I want and how I'd like it done, asking for a plan, and then simply saying "yes" if it makes sense. Then wait 5-15m. Meanwhile I'm free to look at what it's doing and if it's doing something stupid wrong, or think about the next logical step.

Normally the result for me has been 90% good, I may need to fix a couple things I don't like, but then syntax and warnings have already been worked out, so I can focus on actually reading, understanding and modifying the logic and catching actual logic issues. I don't need to spend 5+ days learning how to use an entire library, only to find out that the specific one I selected is missing feature X that I couldn't foresee using last week. That part takes now 10m and I don't have to do it myself, I just bring the finishing touches where AI cannot get to (yet?).

I've found that giving the tool (I personally love Copilot/Claude) all the context you have (e.g. .github/copilot-instructions.md) makes a ton of difference with the quality of the results.

Re: Engineers who dismiss AI

#137

> The engineers refusing to try aren’t protecting themselves; quite the opposite, they’re falling behind. The gap is widening between engineers who’ve integrated these tools and engineers who haven’t. For me, however, there is one issue: how can I utilize AI without degenerating my own abilities? I use AI sparingly because, to be honest, every time I use AI, I feel like I'm getting a little dumber. I fear that excess…

Do you save time by using a calculator / spreadsheet or try to do all calculations in your head, because your ability to do quick calculations degrades the more you rely on tools to do it.

I'm not too worried about degrading abilities since my fundamentals are sound and if I get rusty due to lack of practice, I'm only a prompt away from asking my expert assistant to throw down some knowledge to bring me back up to speed.

Whilst my hands on programming has reduced, the variety of Software I create has increased. I used to avoid writing complex automation scripts in bash because I kept getting blocked trying to remember its archaic syntax, so I'd typically use bun/node for complex scripts, but with AI I've switched back to writing most of my scripts in bash (it's surprising at what's capable in bash), and have automated a lot more of my manual workflows since it's so easy to do.

I also avoided Python because the lack of typing and api discovery slowed me down a lot, but with AI autocomplete whenever I need to know how to do something I'll just write a method stub with comments and AI will complete it for me. I', now spending lots of time writing Python, to create AI Tools and Agents, ComfyUI Custom Nodes, Image and Audio Classifiers, PIL/ffmpeg transformations, etc. Things I'd never consider before AI.

I also don't worry about its effects as I view it as inevitable, with the pendulum having swung towards code now being dispensable/cheap to create, what's more important is velocity and being able to execute your ideas quickly, for me that's using AI where I can.

Re: Engineers who dismiss AI

#138

Earlier quoted context omitted.

I don't disagree with that, just that there's anything that can be done about it. Which technology did we successfully roll back? Nukes are the closest I think you can get and those are very hard to make and still exist in abundance, we just somewhat controlled who can have them

> Which technology did we successfully roll back? Quite a few come to mind: chemical and biological weapons, beanie babies, NFTs, garbage pail kids... Some take real effort to eradicate, some die out when people get bored and move on. Today's version of "AI," i.e. large language models for emitting code, is on the level of fast fashion. It's novel and surprising that you can get a shirt for $5, then you realize that…

Chemical weapons still exist and are used[1]

So are beanie babies, NFTs and garbage pail kids -- Things that have fallen out of fashion isn't the same thing as eradicating a technology. I think that's part of the difficulty, how could you roll back knowledge without some Khmer Rouge generational trauma?

I think about the original use of steam engines and the industrial revolution -- Steam engines were so inefficient, their use didn't make sense outside of pulling its own fuel out of the ground -- Many people said haha look how silly and inefficient this robot labor is. We can see how that all turned out.[2]

1: https://www.armscontrol.org/factsheets/timeline-syrian-chemi...

2: https://en.wikipedia.org/wiki/Newcomen_atmospheric_engine

Re: Engineers who dismiss AI

#139
We’ve been “losing skills” to better tools forever, and it’s usually been a net positive. Nobody hand-writes a sorting algorithm in production to “stay sharp”, most of us don’t do long division because calculators exist, and plenty of great engineers today couldn’t write assembly (or even manage memory in C) comfortably. That didn’t make the industry worse; it let us build bigger things by working at higher abstraction.

LLM-assisted coding feels like the next step in that same pattern. The difference is that this abstraction layer can confidently make stuff up: hallucinated APIs, wrong assumptions, edge cases it didn’t consider. So the work doesn’t disappear, it shifts. The valuable skill becomes guiding it: specifying the task clearly, constraining the solution, reviewing diffs, insisting on tests, and catching the “looks right but isn’t” failures. In practice it’s like having a very fast junior dev who never gets tired and also never says “I’m not sure”.

That’s why I don’t buy the extremes on either side. It’s not magic, and it’s not useless. Used carelessly, it absolutely accelerates tech debt and produces bloated code. Used well, it can take a lot of the grunt work off your plate (refactors, migrations, scaffolding tests, boilerplate, docs drafts) and leave you with more time for the parts that actually require engineering judgement.

On the “will it make me dumber” worry: only if you outsource judgement. If you treat it as a typing/lookup/refactor accelerator and keep ownership of architecture, correctness, and debugging, you’re not getting worse—you’re just moving your attention up the stack. And if you really care about maintaining raw coding chops, you can do what we already do in other areas: occasionally turn it off and do reps, the same way people still practice mental math even though Excel exists.

Privacy/ethics are real concerns, but that’s a separate discussion; there are mitigations and alternatives depending on your threat model.

At the end of the day, the job title might stay “software engineer”, but the day-to-day shifts toward “AI guide + reviewer + responsible adult.” And like every other tooling jump, you don’t have to love it, but you probably do have to learn it—because you’ll end up maintaining and reviewing AI-shaped code either way.

Basically, I think the author hit just in the point.

Re: Engineers who dismiss AI

#140
post #122

Earlier quoted context omitted.

by AI you mean LLMs right? I use a neural network to blur my background on Zoom calls, among other non-LLM usage

[flagged]

I just wanted to clarify only some neural networks are bad :) technical precision of language is important to avoid confusion

sorry you’re so angry though. best of luck

Post reply on HN