[Hippocrates]

It makes me feel very secure in my job that so many engineers ITT are downplaying the ability and productivity of AI coding tools. You can pry cursor out of my cold dead hands. If you aren't seeing a 10x boost, then you must not have tried it lately, or haven't got the experience to prompt well.

What it excels at: - Boilerplate code that's been written 1000x, which can saps your time and enthusiasm for the meaty problems beyond that.

- Complex DSA work. It has been demonstrated millions of times in training material.

- Simple and tedious tasks like making dummy data for tests and struct literals.

- Tightly scoped refactors.

Where does it falter?

- Mapping your product/business to the code or abstractions needed. I think this is where junior devs struggle to leverage it.

- Doing large scale multi-file refactors without proper specifics, guidance, and context. It also can't write a huge project from scratch. Humans are still need to fit the pieces all together or provide guidance. I think this gap closes soon.

Code quality simply isn't a problem IME. If it didn't one-shot your dream abstraction, you probably weren't specific enough in the prompt. Most human-written code is also junk, so pointing out a minor gaffes isn't really a dunk on AI. It's still a massive productivity booster if wielded by even a half-competent engineer.

[thunky]

The things you mentioned it does well on are things that help you avoid tedium, but I don't think that's what's most important to businesses. The things you mentioned it does poorly at are the things that matter most.

To pile on: if a large part of our job is purely mechanical, then there is a bigger problem with our engineering processes and AI can't fix that.

[Hippocrates]

> if a large part of our job is purely mechanical, then there is a bigger problem with our engineering processes and AI can't fix that.

It is! And AI is fixing precisely that. What businesses actually care about (well, 99% of them where code is written) is shipping fast and solving the immediate problem, NOT code quality and craft. It goes against what I want to believe as an engineer. Most problems are not new, they are not hard, they are not sensitive. You will need to start with a good understanding of the business need. It's not that the AI can't code to this. I will often stub out an abstraction, explain inputs/outputs in detail, provide sample data etc. That's all. There are frighteningly few showstopper problems with AI coding at this point, and it's moving so quickly.

We're not at the point where non-engineers are capable engineers with AI, but if you are an engineer not using AI extensively, you are being lapped.

[thunky]

> And AI is fixing precisely that.

I don't think AI is really fixing business problems, though. I think it's only fixing developer problems. And unfortunately nobody really cares about that except for developers.

I just find it sad that instead of focusing on improving how we build things and reducing the need for so much mindless, tedious, repetious, mechanical work, we're content to just build bad things faster with AI and call it a win.

[TeMPOraL]

> I just find it sad that instead of focusing on improving how we build things and reducing the need for so much mindless, tedious, repetious, mechanical work, we're content to just build bad things faster with AI and call it a win.

The AI is doing precisely that: reducing the mindless, tedious, repetitious, mechanical work. And what "vibe coding" wants you to embrace is treating high-level code as if it were compiled assembly: an implementation detail you never want to look at or care about if you can help it.

Yes, in some sense AI isn't fixing anything, because all that "mindless, tedious, repetitious, mechanical" code still exists, it's just autogenerated. I too wish we could've first eliminated the need for that entirely. But we didn't, because most programmers and the industry at large still don't understand where the problem is in the first place. They can't see we've long reached Pareto frontier in our programming languages, that we're being limited by the default paradigm of working directly on plaintext codebase that's a single source of truth.

So yeah, in this sense, LLMs aren't fixing anything - they're just an abstraction layer on top of our exhausted coding paradigm.

[owebmaster]

> shipping fast and solving the immediate problem, NOT code quality and craft

This is also what puts many companies out of business and create huge security issues. If AI is not fixing this but making it worse, then that's not improving software engineering.

[TeMPOraL]

> This is also what puts many companies out of business

Those companies you mention just overdid it. Like with everything else on the market, there's a limit to how much value/quality you can optimize away before the end result stops being fit for purpose. However, existence of this limit doesn't stop companies from racing to the very edge of it.

> and create huge security issues.

Security is mostly a solved problem.

Yes, it truly is - at least from the business point of view.

Nobody except attackers and infosec people cares about the mathematical and technical details, or whether your stack or coding practice is secure enough. Not the customers, as they neither understand any of this, nor could do anything about it even if they did. Not the companies, since they manage it at a higher level of abstraction. Whatever holes and vulnerabilities the AI coding introduces, the industry will account for it. Some headlines will be made, some stocks will move, and nothing will change.

FWIW, I don't like either of these things. I'm an engineer in my heart, so it pains me to be constantly reminded that our work is merely means to an end, and matters only to the extent it can't be substituted by some alternative.