I don't enjoy the keypresses of building useful features. I like identifying what needs to be changed, and how, in abstract terms. These tools quickly help me verify those changes are right.

If I need to call the VideoService to fetch some data, I don't want to spend time writing that and the tests that come with it. I'd rather outsource that part.

I don't object to abstracting, at all; or reducing labor in general.

But this method of getting there makes me feel like I'm degraded to being the assistant and the machine is pulling my strings; and as a result I become dumber the more I do it, more dependent on crap tech.

I can imagine people making the same argument decades ago about higher-level languages being "crappy and unfulfilling" compared to writing assembly. After all, you're not even writing the instructions yourself, you're just describing what you want and the computer figures out what to do.

The (pretty substantial) difference is now the computer is telling you what to do.

In what way?

In the way that the more you do that, the less you have any clue what you're doing. Because you're not learning, you're following instructions. Being programmed, if you will.

Why do we use hotkeys and snippets?

There is a lot of tedium in software development and these tools help alleviate it.

If all these tools do is wipe out all the tedium in software then we are all laughing. Happy days to come.

There are tools and then there are the people holding the tools. The problem is no-one really knows which one AI is going to be.

At some point in your career you realize every line of code you write is not just an asset—it's also a liability that needs to be maintained, debugged, and understood by others.

The excitement around AI coding tools isn't about chaining yourself to a crappy experience — it's about having support to offload cognitive overhead, reduce boilerplate, and help spot potential missteps early.

Sure, the current gen AI isn't quite there yet, but it can lighten the load, leaving more space to solving interesting problems, architecting elegant solutions and "figuring stuff out".

I really don't understand how replacing writing N lines of code by reading N lines of code reduces mental load. Reading and understanding code is generally harder than writing equivalent code.

You'd still have to review code if you asked another human to write it.

That's why minimizing the generated code is important as well as working on smaller parts at once to avoid what the author refers as "too much up-front work" -- It is also easier mentally when you can iterate on this whole process in seconds rather than days in a pull request review.

Because you'll be replaced by those engineers in N months/years when they can outperform you because they are wizards with the new tools.

It's like failing to adopt compiled code and sticking to punch cards. Or like refusing to use open source libraries and writing everything yourself. Or deciding that using the internet isn't useful.

Yes, developing as a craft is probably more fulfilling. But if you want it to be a career you have to adapt. Do the crafting on your own time. Employers won't pay you for it.

Let them replace me then, it's not a job I feel like doing anyway.

And when they have forgotten all about how to actually write software, the market is mine.

Instead of writing code, you can now figure out the code that your AI wrote and effectively treat everything as a legacy system.

How is correcting someone else's solutions even close to as fulfilling as creating your own? How can you not lose something by choosing that method?

> I like writing code and figuring stuff out, that's why I chose a career in software development in the first place.

That's not why I got into software development. I got into it to make money. I think most people in Silicon Valley these days are the same mentality. How else could you tolerate the level of abuse you experience in the workplace and how little time you get to really dig on that particular aspect of the job?

This is a website that is catered to YC/Silicon Valley. My perspective is going to be common here.

I guess there were always two kinds, Bill Gates doesn't strike me as a person who loves technology. Compared to, say Dennis Ritchie or Wozniak.

I'm firmly in the problem solver/hacker/artist camp.

Which I guess is why we're more concerned about the current direction. Because we value those aspects more than anything; consider them essential to creating great software/technology, to staying human; and that's exactly what GenAI takes away.

I see how not giving a crap about anything but money means you don't see many problems with GenAI.

Because on net it often saves tons and tons of time and effort if you know how to use it.

Luddism is a strange philosophy for a software engineer.

> Luddism is a strange philosophy for a software engineer.

Luddism and critically evaluating the net benefit and cost of a piece of tech, are 2 very different things.

And the latter is not strange for a SWE at all, in fact I'd say it's an essential skill.

I'm referring to this part:

>I like writing code and figuring stuff out

This is an alien mentality to me.

Problem solving, I'm pretty sure it's the driving motivation for many/most coders.

I find pleasure in crafting the solution, sculpting it by hand; putting everything I've got into making it fit the problem like a glove. Coding to me is an artistic way of expressing myself, exploring, always improving; it's part of the fun to me.

And I don't like following instructions in general, don't like being programmed.

So what's in it for you then, if not the problem solving?

Okay...given that a SWE job is literally "take problem description, figure out way to solve problem in software", what part about this is "alien" exactly?

And yes, there already are solutions to many common problems. The task then becomes finding a best-fit, and adapting these solutions to the specific needs of the usecase...which is another instance of the same task.