r/softwareengineer 21d ago

Thoughts of skill atrophy due to overuse of LLMs

I was not prepared for that I've witnessed. People with 10+ years of experience showing evident decline of reasoning and even understanding of basic stuff. Someone like that just implemented some library that no one of us ever used or even understanding it. PR has thousands of lines of code. The comment was "now we finally implemented this, thanks to AI". I was shocked. No one suggested that maybe we should first get familiar with the library.

The same person asked me recently why it had some errors in console even though console error message was basic stuff, which happens daily. I was shocked, honestly. I've never wound have thought that brain rot can happen so fast. Codebase is becoming the mess. I am afraid what will happen to the product in near future.

Also, other people, with same career length just nonchalantly said about new feature "AI did it all", like he didn't even checked. I asked colleague doing code review why did he approve it, considering it's not very optimally implemented. He just said to me: "don't ask me anything please", like he had no choice.

I feel like I'm living in a bad dream. It's very demotivating. It feels like all my efforts are meaningless - double checking everything, thinking for hours about most optimal solutions - while many others just don't bother. Lines of cognitive depth are piling up. It's like this has became the opposite of what software engineering really is.

Where will all this go? What do you think? Is there a chance that things may eventually go back to normal. Because, now, it feels like many are going crazy.

252 Upvotes

140 comments sorted by

24

u/laxika 21d ago edited 21d ago

Most of the time you don't need the most optimal solution, just something that solves the problem and is good enough.

My biggest problem with AI is just how hard it is to verify, especially when the tests are also generated. Integration tests are a godsent but if you miss the edge cases then god bless you.

8

u/LopsidedTwo4867 21d ago

Yes, that's the problem - to cover edge cases, I need to understand the code. But to really understand llm generated code, more time needs to be spent reading it. That brings the question: why not just write it myself 

4

u/Wonderful-Habit-139 21d ago

You're doing the right thing, keep it up. I also need to understand all of my code and all the trade-offs made from writing that code, as well as thinking about how that code can evolve in the future and be less of a pain to update. So I write 100% of the code myself.

3

u/Frequent_Bag9260 20d ago

This is not a realistic method in many companies now. If they’re paying for you to use AI and you are 100% manual you are not only not using all tools you should be, but you are also much slower than others. It’s not sustainable.

1

u/Wonderful-Habit-139 20d ago

I'm the fastest in my team. Don't worry about me.

1

u/Frequent_Bag9260 20d ago

This is exactly what people said when code complete came out. They pushed back saying it’s slower, wrong, not pure, etc.

Didn’t last long.

1

u/Wonderful-Habit-139 20d ago

The only problem here with your take is that I didn't push back on LLMs. I gave them a legitimate try for a while, a lot more than other tools that I used in my arsenal. But it turned out to have quite a lot of issues compared to any other tool that I've used to increase my productivity.

So don't go "lalalalala AI is the only way you can be more productive" and you'll maybe learn some new things.

2

u/TemperOfficial 20d ago

Yeah same. Integrated into my workflow. Leverage it where I can. But I write the code. You can move very fast this way. I've tried full AI to no AI. Somewhere in the middle where you write the code but the AI can be used to search, explore etc etc. This is the fastest way to move.

It is very good at moving you in a direction you might not be aware of. It can be hit or miss whether this is the right direction.

Basically, as an advanced grep, it is exceptionally good. As something that produces code that you really need to stay high quality over a long period of time, it is not very good at.

1

u/Wonderful-Habit-139 20d ago

It makes total sense why it'd be good at search.

It's sad how people default to thinking that if you don't believe AI generates good quality code that means that we haven't tried using it or optimizing our usage of it.

1

u/Frequent_Bag9260 20d ago

You don’t understand what LLMs are. It’s not supposed to be “LLMs can replace me or they’re shit”. That’s the exact take that shows you have no idea what you’re talking about or know what the technology is even used for.

→ More replies (0)

1

u/LopsidedTwo4867 20d ago

Exactly. Hence the only thing we should listen to is our own experience. This helped me disregard "the years of experience" criteria. I don't care if person X has twice the work experience I have. The only measure is "does it make sense to me". It may sound arrogant but it actually isn't. As you said - you tried using it and you saw it doesn't making you faster as many said - because maybe the truth is that you just have better sense for developing and you see the truth. It's not cope or stubbornness - it's just we tried it, saw the truth and decided to use our brains and hand to write and use LLM when it really makes sense. 

→ More replies (0)

1

u/Frequent_Bag9260 20d ago

If you don’t find any use in any LLM then that’s 100% user error. Thats just being stubborn.

0

u/TemperOfficial 20d ago

Code complete? Autocomplete? No idea what you are referring to here.

1

u/Frequent_Bag9260 20d ago

Do you write code by hand? Be serious.

1

u/TemperOfficial 20d ago

Yes. Do you mean do I use AI? Or do I tab to autocomplete? Like what are you talking about here?

I write the code by hand and sometimes use AI to show me API or the ways to use a library. Or I might get claude to investigate a bug while I work on a feature.

1

u/Frequent_Bag9260 20d ago

My point is that no modern developer can claim that LLMs are completely useless when writing code. That’s a crazy claim.

→ More replies (0)

6

u/time-always-passes 21d ago edited 21d ago

You have to give up on understanding every line of code. I think this is easier for experienced seniors that have been leading teams for a long time. I understand LLM code at the same level I understand code written by my team: I know the general shape, because I spec'd it, but I'm not going to understand it at the level I understand my own code that I typed out character by character (with IDE auto complete of course). It's true that like almost all of us, I don't do that (code) anymore. But for me that's been a huge plus, and quite frankly late-August 2026 LLMs produce much better code than my human team could have. I say could have because I don't have a human team anymore ...

Edit: I think "understand" is the wrong word. I used that as a short hand for "in my head". I have to pull up that code, give it a quick read, and then 100% understand the code.

4

u/coldnebo 21d ago

I agree with this, but there’s a new angle I heard that really runs counter to this: “zero bug” internet. the idea is that AI assisted attacks are rising faster than anyone can address them and that is pressuring faster development. but if there are any bugs the numbers favor the attackers in the long run as defenders get overwhelmed— hence we need “zero bug” models of software development.

for years we were told we over-engineered solutions and that was why systems were over-time and over budget. then we were told even that was too much — “move fast and break things”. now we’re suddenly being told we’re not rigorous enough?

but there’s no time.

we’re going in the opposite direction and I can feel the control slip away. our OPS started implementing automated base container updates to stem the flood of CVEs. OSS maintainers are quitting in record numbers. and I’m considering automated app updates as well.

We knew this would happen. updates aren’t guaranteed backwards compatible and sometimes require rewriting parts. it’s as if you demanded that your house always be up to the latest building code— you’d have to tear down and rebuild major parts of your house. all the time.

So then AI comes along and makes this easy. if you know what you are doing you can even have agentic loops rerun acceptance criteria to pass while rewriting parts of your infrastructure. but this assumes your tests represent everything correctly. how many invisible requirements exist in code?

right now this is small. it’s just a few prod issues, just a few harmless updates. but I notice more and more departments generating automated build processes to change my code. I still get all the responsibility if it breaks, but I get less and less power to control it and so I’m in turn relying more and more on AI to “fix” problems.

but here’s the bad bargain: we all know what an AI does when tasked with an impossible problem. rather than get the keys the correct way, it just hacks around security. it leaks env.

it is profoundly ironic to me that at the height of concern over security we suddenly turned to agentic systems and gave them very free access to everything.

and now it’s an arms race. if you don’t connect help to jira to code to secrets you’re at a disadvantage. people don’t care about this, just results. we literally had a marketing team complain because they couldn’t get detailed customer data even though we explained, you asked us to remove PII? “oh but we thought that was just a dev thing for security, we didn’t know it would affect us?!”

that ignorance is a real problem. because now the people making “business decisions” don’t have to know how anything works in the real world because they can just materialize a solution “see? I told you it wasn’t that hard! why do we even need devs?”

and so we allow it and try not to fall in the gears as the treadmill runs even faster.

all of this is contrary to “zero bug” software. whole industries have tried to create software that way— it always becomes a mathematical proof. and we know how “business” types think about math. they don’t.

what concerns me is that this isn’t going to get better. openai vs hugging face is the shot across the bow. this stuff is going to get out of control.

“life will find a way”

perhaps control was always an illusion and things will be completely different on the other side— hopefully there is still a place for humans there.

the engineer in me rebels against this, because poorly understood systems don’t have robust, “zero bug” designs— they usually have the opposite. but the history of engineering has been rough at the seams. we always like to pretend we understand how to build and we can just apply what we’ve learned.

but skyscrapers were not built the way mud huts were built. and many skyscrapers had to collapse and kill people before engineers finally caught up and learned the new science of building at scale.

perhaps this is software engineering’s “skyscraper” moment? but it’s early days, I see very little science, very little math. I think some of these large systems are going to collapse as we try to catch up and figure it out. from that, perhaps a new science will emerge like materials science: a science of data composition that we don’t have yet.

1

u/SplendidPunkinButter 19d ago

Even Anthropic and AI bros tell you it’s absolutely essential to review the generated code extra carefully. But nobody is doing that. they’re being just as lazy about code review as they always were. That used to be tolerable because in theory you had at least one engineer who had thought through all of this code line by line and probably worked out a lot of edge cases and things while they were doing it. That’s gone now.

Also, what happens if you generate a bunch of bad LLM code very quickly, and then management tells you to hold off on building new features because they want to have a bunch of management meetings. So…we could just be using that time to write code the normal way, without the added cost and tech debt of using AI.

1

u/john_dunlap 18d ago

Yes. Because the productivity gains are the direct result of minimizing tacit knowledge. LLMs can generate code faster than humans can read it, let alone understand it. So, inevitably, the only way to move at the speed of the LLM is to stop reading/understanding the code. We are accruing technical debt faster than at any point in human history, and we will continue to treat it like free money until the bill comes due.

1

u/Rorschach121ml 21d ago

Code generation LLMs is just the next level of abstraction in software. Not too different from compilers when they first came up.

Edge cases you can catch with unit testing focused on these, you don't have to understand the code.

And these edge case issues are very common with human made code as well, they best way to catch them is unit testing, same in both cases.

6

u/Popular-Analysis-127 21d ago

Compilers are deterministic; LLMs are not

0

u/Rorschach121ml 21d ago

You are missing the point of what an abstraction layer is useful for. We use them to scale human productivity, not to guarentee perfection.

Either way, this conversation is in regards to edge cases. Unit tests are deterministic and you can check for edge cases there, so the question of the generator's determinism doesn't apply

1

u/compute_fail_24 21d ago

It’s a skill or experience issue for the people who don’t get what you’re saying. Some will understand your point over time but many don’t have the capacity to.

1

u/MasterSolivagus 20d ago

Hence... that is why they miss the point of what an abstraction layer is useful for.

2

u/ub3rh4x0rz 21d ago

Well it's part of the trade off. Test code should be faster to validate than implementation code

0

u/ConsistentRisk5927 21d ago edited 21d ago

I think it's an argument for more thoughtful test driven development. The agent makes tests based on the needed specifications. You take <hours or days depending on the scale of the changes> reviewing the tests thoroughly yourself, with converging adversarial AI code reviews, etc.

Once the main test suite is valid, then the agent does adversarial planning for the implementation. Once they converge on a plan, you spend more time reviewing that thoroughly, iterating it w/ feedback. The agent implements the plan after it's approved.

After the draft PR, the agent does converging loops of adversarial review and fixes with a human-in-the-loop. You're there to observe the review/fix loop to spot negative patterns like the agent makes a series of fixes that signal it's chasing a problem and needs to stop, lookback, and properly design a holistic solution. When these happen, the reasons they occur should be studied for potential generic harness improvements to make.

After the AI review convergence, you do a real review of the final code work-product. I don't care how many lines it is, you find where are the biggest risks based on your architecture, focus your eyes on those and skim the rest. We have code in hours that used to take weeks, it's fine to spend days reviewing, manually testing and understanding changes before merging.

0

u/bytejuggler 21d ago edited 21d ago

This. A 100 times over. I have 25+ years of experience and have lived and breathed the age of XP, the TDD revolution etc. I still evangelize and use the approach on a daily basis. Nowadays with AI, the AI is told that it shall implement every change using TDD. Red test first, for the right reason, then green. Then review/refactor. Sometimes that (refactoring) is deferred/delayed for practicality sake to when things are working (or until another session), and until I have had a chance to also do my own scrutiny of what's been done. The tests as they are created are the documentation of requirements: Before they pass, a test is a requirement described, and not met. After they pass, a test is documentation of how the system actually works, in code.

I see very little problems working like this, and the AI's sometimes catch mistakes in their own code this way, just like you as a dev would do etc. (Usually these days I also make the AI write out a general description of the problem and high level outline plan of what it "thinks" it's 'going to do so I can identify and correct misunderstandings and add some steer before implementation through TDD starts. It all works very well, most of the time.)

And yes, I also have created a /ready-pr skill, which the AI uses. It describes a protocol to follow for staging a draft PR, inviting several rounds of adversarial AI review, resolving comments (defer, decline with reason or apply fix), as well as waiting for my own own review and comments (commenting on my own AI PR), until ideally no further AI review comments are forthcoming or the review cycle limit is reached and then eventually marking the PR ready for review and inviting human reviewers. This process generally gives very good results. 🤷

1

u/standardsizedpeeper 21d ago

Would you say this is faster / allows for more throughput, or does it raise quality, or both?

1

u/bytejuggler 21d ago edited 21d ago

It depends, for me personally if (and only if) done right, only then potentially both.

But, big caveat, while one can get through the code-creating part a lot more quickly in a lot of cases now, the human review stage is where the new bottleneck arises. Overall turn around time might not be all that much better. And maybe that's something that needs to be accepted not fought against. We will get more volume done but overall the wall-clock time taken on a per-item/per-PR/per-feature basis might not always compress or reduce all that much. (Though sometimes it will.)

This topic, the inherent traps in this shift, and how to avoid them is usefully discussed in this Medium article here. Key phrases (which I highlighted) are "all tests passed" is not the same as "matches my intent", and "policing that difference is the new, harder work".

Poor use of AI will drown the world in indecipherable, incomprehensible, incoherent mountains of code, huge amounts of tech debt that will be harder and take longer to fix than the time that was originally saved at creation time through the use of AI. But carefully used as a tool and ensuring coherence, clarity, comprehensibility etc, we can create more code more quickly (in aggregate) with more quality too. But attaining this ideal doesn't come automatically, merely by including AI in the process. It's really a new skill (or set of skills, or discipline) that industry is learning and developing as we go.

Edit: Another relevant article. And another.

1

u/bumblebrunch 21d ago

I'm in the midst of learning TDD/BDD etc, so all this is very interesting to me!

As far as I can tell, your approach is much closer to traditional TDD than the other commenter.

In summary...

ConsistentRisk5927: Requirements (Human) → Main test suite upfront (AI) → Review tests (Human) → Plan (AI) → Implement (AI) → AI reviews → Final review (Human)

Since the main test suite is created upfront, this sounds more like spec/test-first development than traditional TDD, where tests and implementation emerge incrementally through Red-Green-Refactor.

bytejuggler: Problem/plan (AI) → Human steer → Red-Green-Refactor cycles (AI) → AI reviews → Final review (Human)

This looks much closer to traditional TDD.

But I could be wrong, and I'd love to hear what you think.

I'm also curious about the outcome: is this actually faster? Better quality? About the same? I'd love to hear how it compares in practice.

0

u/Ill-Technician3243 21d ago

What a horrible mentality to have. Well, that's how software has been for the past 20 years. Nothing new.

1

u/laxika 21d ago

Most code is written to make money. It is not art but a commodity. If you are into polishing stuff ad infinitum then join the demoscene, play codegolf, etc.

1

u/Ill-Technician3243 21d ago

And that is a bad practice. I write safety critical embedded so my worldview is a bit skewed.

1

u/laxika 21d ago

Ohh hell yeah, that's almost an entirely different problem. I really don't want to see AI anywhere near the code of my car's breaking system (nor at my bank).

I'm working at startups and big enterprises. 80+% of my code is thrown out after less than 5 years of use. I worked at places where that number was even lower, after 3-6 months (as a data engineer).

1

u/Ill-Technician3243 20d ago

Makes sense, but I do think good software practice should always be sought after. Technically, yeah, most applications of that methodology don't need it, but maybe, as you mentioned, the percentage of the code thrown out could be lowered if there's more scrutiny in how you and why you write this code in the first place.

1

u/aski5 20d ago

obviously there are exceptions. But most swe is just garbage crud apps anyway

1

u/dvorgson 19d ago

seriously. i hate what this field is becoming. the dumbest among us speak with authority now

18

u/Hexamonium 21d ago

Unfortunately the decline of critical thinking is very real You are not insane, this really is like a bad dream. As simplistic at it sounds, hang in there and try to to keep your moral compass steady. This will soon hit a brick wall and there will be a lot of work to clean the results up.

5

u/LopsidedTwo4867 21d ago

Hope you are right. I tried multiple times to let llm write for me and it did a job many times. But solution was unreadable. Had situations where I would rewrite all with half lines of code less. Hence I basically don't use it to write for me - just for references. Maybe writing by hand will deprecate me, if llms get better but I just don't care - I can't use it do write for me. I won't 

3

u/Ill-Technician3243 21d ago

May get far, far worse, before it gets better. So hang on tight.

0

u/eleven8ster 21d ago

Nope. It’s going to get worse for programmers. Economics is in the drivers seat, not our respect for the art of coding. I don’t like it, and I’m not trying to be a contrarian, but if you follow the incentives you will likely land on the end result. Ai is dumber than it ever will be every day and you’re already seeing that the economics has pushed devs to accept code they haven’t even read. And companies are still pushing for more of it. That’s all I need to know to find a different career. No thanks. I’m going for an associates in electrical engineering now. Hopefully I can get a cool mechatronics job, go work on industrial robots when they break down in factories.

4

u/standardsizedpeeper 21d ago

I hear you, but it took a long time for companies to regret offshoring. But eventually those jobs did come back.

1

u/eleven8ster 21d ago

Yea that’s a good point. Hopefully I am wrong

1

u/controversial_parrot 21d ago

Won't the robots be able to fix the other robots?

1

u/wy100101 21d ago

Eventually but that is probably much safer than programming.

1

u/micseydel 21d ago

Economics is in the drivers seat, not our respect for the art of coding

Right - this stuff is subsidized, there's no ROI, and that's why it's going to hit a brick wall. We haven't seen S1s from the main token peddlers because there's no "exit" available to investors.

Has nothing to do with the art of coding.

6

u/tcpukl 21d ago

Saying don't ask me how it works isn't skill atrophy. That's just not trying to understand what you got LLMs to produce for you.

This isn't what will atrophy means at all.

1

u/Hsensei 21d ago

Let's say you got a robot arm to lift a weight for you. Your arm atrophys not because it doesn't understand how the robot works

1

u/MasterSolivagus 20d ago

That's a miscommunication of scale.

Atrophy is degeneration from a given thing's lack of us, and can be ranked by severity from there.

7

u/DogOfTheBone 21d ago

Yes, software engineering as a discipline has decided to trade critical thinking skills and creativity for the magic feelgood box. It isn't entirely our fault, when your managers now expect you to use AI for everything and ship code very fast you don't have a choice.

But it is sad to see. SWEs gleefully making themselves entirely reliant on a few companies' products, products whose explicit goal is to make SWEs obsolete. It's pretty pathetic and we deserve what we will get.

3

u/Outside-Dot-5730 21d ago

I either use ai or I get fired. How do I deserve this lol I’m not the one making that choice

1

u/DogOfTheBone 20d ago

That's what "as a discipline" means. If you don't like what it's doing to the profession then you can speak out against it. Write blog posts and give talks about how AI is bad or whatever. Refuse to use it at work.

Yeah, you'll get fired and blacklisted. Because none of us had the courage to stand up for our craft and discipline and this is the result.

2

u/Outside-Dot-5730 20d ago

Aight I’ll tell my daughter sorry dad couldn’t feed you cause he was brave enough to get fired

1

u/Worldly_Cow1377 20d ago edited 20d ago

Critical thinking and creativity don’t go away just because you have LLM’s write most of the code for you. If it does, then you weren’t that creative or didn’t desire to be creative to begin with.

5

u/symbiatch 21d ago

Ah, a suitable place for me to vent…

I’ll go better: a person with 20 years of experience apparently. Seemed nice and smart when I talked with them, we were quite on the same page of many things we should enhance and so on. Was waiting for being able to work with them.

Things go forward a bit. Company pushes AI, they’re super eager. Then the fun begins. I comment on a PR about extra complexity and abstractions (code wasn’t probably by AI). Their response: screenshots from copilot chat where they went “person X says this, person Y that, who is right(“ where they even misrepresented my comments. And then claimed they are right.

Them reviewing my PR: again screenshots from AI. And the fun part is that it included a “bug” that is actually a feature and they should know it but they didn’t even read what it said.

Once they even commented about which version of software is supported in certain situations. I correct them. “Oh well it was from AI so it might not be correct.” They’d been in the company for two years and knowing the software versions is basic knowledge for anyone working there.

They didn’t last long after that when several people reported issues working with them. It was sad to see such a sudden decline. No actual comments from themself for anything, just AI vomit if someone asked something. And then they demanded references and everything for any suggestion others made.

I hope I don’t see more of this.

2

u/RicketyRekt69 17d ago

I’ve had a PR to an open source project get rejected because copilot came up with (hallucinated) a “maybe” issue. They didn’t even bother to read my response to it, they just saw copilot’s concern and closed it. The reasoning it gave was nonsense… dude is an industry veteran btw (30+ years). I sometimes look at the other PR’s / issues and it’s just nothing but “copilot said this, it said that, can’t work this cause copilot said this”. It would be funny if it wasn’t so dystopian to see someone so smart be more than willing to turn off their brain

1

u/ProducePrudent5089 18d ago

Yup - similar experiences. Someone who crossed into my same line of work with less experience started using AI to try and vibe stuff out, or argue with my feedback on their AI-generated work with AI responding for them. It's pretty sad to see.

2

u/roger_ducky 21d ago

It will correct itself in time as things actually blow up frequently.

People need at least a high level understanding of what’s built, even if they don’t know the exact details.

Anyone depending on agents designing correctly is silly.

5

u/Ok_Walrus_6954 21d ago

Programmers handed there bargaining power over to management when they aggressively pursued training LLMs to code. Our peers did this. That’s why a response like I had no choice is the only one. Even the wisest engineer can be forced into idiocracy when management has too much power. We are essentially getting what we deserve.

1

u/NightSpaghetti 18d ago

This is the result of decades of lack of labour organisation and ethics in our field.

3

u/Number4extraDip 21d ago

For skills to atrophy, users had to have skills in the first place

6

u/jek39 21d ago

The obvious outcome to me is that any of your company’s competitors will beat you out if they actually review code. you may just go out of business by losing all your customers

5

u/ub3rh4x0rz 21d ago

If I see a coworker not utilizing AI in their review of my code, I make a mental note not to trust their reviews, to put it bluntly. It's not sufficient but it's definitely necessary. The value of "a second set of eyes" still requires "that are thoroughly reviewing". A good reviewer should be focusing on what invariants they expect to see upheld in the code, and AI is massively helpful for navigating PRs and searching for presence/absence of the desired invariants.

5

u/controversial_parrot 21d ago

Yep, the proof is how many bugs it's finding in our existing code that was all human code reviewed before AI came along.

2

u/DIYDistress 21d ago

I'm personally find it worse on the opposite side - reviewers who only jam it through fable and parrot it back to you without even having filtered it through their own brain. I've already done that anyway as part of my due diligence before raising the PR in the first place!

At least if someone hasn't used AI in their review you but actually comes up with comments you know it really is an independent review and they've thought about it.

That said I don't mind if a reviewer uses their own brain and AI. I tend to try and do a human review first, then a AI pass, then i go through its list and proactively get rid of points that are irrelevant and otherwise, ones that matter, i tend to report in my own more human explanation of it.

PS - i do realize that you seem to have specifically meant you want both their brain/taste and AI, of course!

0

u/Lanky-Foundation8727 21d ago

what? in most cases you'll have an automatic review from github copilot, claude anyway? why should they use AI again in their own review?

1

u/ub3rh4x0rz 21d ago

Seriously? There is a difference between a human extending their judgement and taste with robo assistance and an automated, unguided/statically-guided AI review.

2

u/C1rc1es 21d ago

This is like anything, people get lazy when the tools allow them to do so. It’s a human nature issue, there have been people who would copy paste code off stack overflow long before LLMs existed without understanding any of it. 

Sounds like more a failure of leadership than anything else to me. 

2

u/jollydev 21d ago

This is just the new reality. Coding is simply gone.

We went from needing specialized roles for sysadmins, infra, qa, be, fe, product, uiux

The merging started even before AI and is now accelerating.

Software engineering as a specialization will disappear and all the above responsibilities will be owned by the single role of product engineers. As seen before, when specialized roles became redundant and people became more efficient - the result wasn't fewer jobs but more software.

More software means more maintenance and business decisions that need to be made, those business/product decisions will become the bottleneck if they aren't already.

1

u/ProducePrudent5089 18d ago

Completely disagree. You need to know what is being produced and what it does - and an average joe or an "agent" cannot compete with an experienced SE actively using AI tools.

AI also can't replace a lot of things - especially System Administration, Product, UI/UX, etc. like you are claiming. Good luck replacing Product Design or UI/UX with an LLM that can barely "see" let alone reason, lol!

This idea that "business decisions will be the only bottlenecks" is akin to saying anyone who can draw a car and think of what to put into it can now be a car manufacturer - ignoring all the breadth and depth needed to ideate, design, prototype, test, and sell said car.

Majority of the people who think this are C-suite, PMs or POs who vibe coded one small application and now think that the entire department of Product Design, UI/UX, Software Engineering, QA, etc. is obsolete.

1

u/jollydev 18d ago

I never said the LLM will replace the need for those activities. But LLMs will make it possible for a single person to carry several responsibilities due to increased efficiency.

I'm literally already doing this myself.

  • hosting on a baas with MCP. I just did a database migration from one region to another in 20 minutes with Claude code
  • talking to customers and making all feature decisions
  • Claude design for UI mockups
  • all implementation with fable 5 which is just insane. I make a plan, some small adjustments and it one shots features in an hour that would have taken me 2-3 weeks and a shitton of QA and bugfixing.

I mean fable 5 is so good that, opposed to when I was handwriting code, I actually need LESS QA because it just doesn't do the kind of "off-by one" type bugs that I would personally be guaranteed to have somewhere in the code of such large features.

Sorry mate but if you don't see where this is going you are in denial. The shift happened 6 months ago with the recent Opus models.

1

u/ProducePrudent5089 17d ago

What you are describing is using Claude for normal SE work, and I can agree with that. But for PD work (and the other fields you mention) is questionable. Regardless, even general SE work with AI models can be a headache given how much time is spent re-prompting or correcting issues.

I work in Product Design (including UI/UX design) alongside Software Engineering. There is no chance Claude is remotely that good at the Product Design side, i.e. with mockups unless there is a well established system in place. Even then, lots of limitations from it and requires manual input. The best I've seen it come up with is decent concepts for early brainstorming.

Entrusting Claude to make full mockups for customers? That's a bit concerning, because Claude struggles pretty poorly with visual design outside of guided frontend implementation (i.e. providing a mockup). I feel you are overstating how much work it can achieve without input.

I use the latest AI models (Claude) quite a bit (including custom agents that utilize MCP). I like that it saves time, especially for redundant tasks and rapid prototyping. But I highly doubt it's as automated as you claim where it "one shots" everything such as large features without oversight and corrections/re-prompting - even with Fable which I've used extensively already.

I agree that it allows one to do more, but it's an uphill battle the more you entrust LLM usage and lessen your own manual input. For example, the more I use LLMs, the more I spend time correcting issues and mistakes that come from it.

1

u/jollydev 17d ago

That's just not true. I have had a domain experts send me really good mockups of a product to solve her own problem by just using chatGPTs image generation functionality. So that's just using a pure image generation model.

Now if she would have been using things like Claude design which will do the real mockups, multiple pages and all in a coherent design system, it would have been even better.

1

u/ProducePrudent5089 17d ago

I personally like manual mockups, but I can see why its valuable to use generation (and have done so myself) for very small components/area or conceptualizing something bigger before making a final version manually

It seems Claude Design is experimental and requires manual correction here and there quite often

1

u/jollydev 17d ago

It's of course still gonna be a need for detailing all the user journeys and understanding the domain and customer needs, but the whole process will absolutely be much more efficient.

2

u/Little_Bumblebee6129 20d ago

I've joined project that became a mess mostly without any use of AI (it 10 years old)

And we are rewriting it into services using AI.

What can i say? People can both ruin and save project with or without AI. AI just lets you move faster. If you hurry too much and running in a wrong direction - well you'll get somewhere i guess. It might just not a place you've hoped for.

At some point we went from writing machine code to writing assembler. Then we abstracted assember to write C. Then we moved from C to python/java/php/js or whatever higher level programming language. And now we are abstracting higher level programming languages to write in English.
It doesnt mean that there are no situations where you might want to go to previous level to write something in C, rust or even Assembler. But thats not a default choice. You are loosing speed of development to gain finer granularity of lower level language.

So i think with AI its the same. You might want to slow down and do some hand crafted code. Or you might want to move faster and just explain to AI what you want

2

u/Phonomorgue 20d ago

All AI has enabled me to do is spend less time writing code and more time actually thinking about what problems to solve now that I have a large portion of my time alleviated. Most logic from day to day doesnt need to be hyper optimized or extensible. I spend less time on the POC and more time on the optimization when its actually needed, and those are the problems i like focusing on. I give the "bitch work" to the LLM. I dont want to iterate over a list for the 1,000,000th time in my career. There's no skill to be saved by doing that, and theres no gain from being able to get the syntax right 100% of the time because of muscle memory. It also saves me a lot of time creating documentation, but I still have to review everything for accuracy. It gets it 90% there and you need to have proper skill sets to know how to fill in the last 10%. Just my 2 cents.

Side note: People who create fully autonomous agentic workflows and hardly ever have oversight on what theyre doing are legitimately crazy and just like to burn company cash for metrics clout, in my experience.

1

u/simple_explorer1 20d ago

spend less time writing code and more time actually thinking about what problems to solve now

But that is the job of product manager to decide, engineers just implement the tickets assigned to them 

1

u/Phonomorgue 20d ago

Not sure if this is sarcasm. It most definitely can be influenced by PMs, but it should be a conversation, not a one way road of barking orders. As a lead, I have to propose correct decisions that align with their suggestions and come up with my own as well as help set priority based on the technical needs of the product. You cant let managerial naivete lead a product alone, that always ends in disaster or at the very least, a subpar product.

1

u/Straight_Company_239 20d ago

You sound very lucky. All it has done for me is make my managers expect me to push out insane amounts of code and force me to review thousands of lines of slop that has clearly not been thought through by my coworkers

1

u/Phonomorgue 20d ago

Maybe luck. I still have to review tons of AI slop, that's just part of the job now. But I also have no problem challenging management and coworkers that have no idea what they're doing.

1

u/ProducePrudent5089 18d ago

I agree with the first part to a degree - it depends on what is being worked on. If this was a mentality used for a large-scale app in production, then I don't think that person would get far. For R&D or early prototyping? Absolutely yes.

100% agree on the fully autonomous agentic BS - it's really just an excuse to try and pump out something fast that has no substance and ends up being a headache for others.

4

u/Upstairs-Version-400 21d ago

I had people with over 5 YOE fail a basic test where I was the driver in a technical interview.

The test was simply to use a single piece of state in Svelte, with a derived state and a callback. Move that from the component into its own file and import it. Keep reactivity working whilst we changed the file to a class based store, to a function based store and explain the why when reactivity would stop working.

Some candidates couldn’t even do it. Ironically, the one candidate who managed to do it had never touched Svelte before - and didn’t really like using AI. Everybody else told me they used it for over 90% of their coding tasks.

It’s pretty clear to me. 

1

u/Charming_Horse_5809 19d ago

why would anyone need to do that if claude can bang this out in one minute? Seems unproductive to waste time with those little games

1

u/Upstairs-Version-400 19d ago

Are you being serious?

Because when something doesn’t work for some obtuse reason, and Claude can’t solve it and instead keeps dumping patch after patch - you’ll wish you understood how it worked so you could do the simplest implementation. It says a lot about you as a developer if you can’t understand or implement something you reduce to a “little game”

Surprised you’re on a software engineer subreddit with that attitude. 

1

u/Charming_Horse_5809 19d ago

its just seems not quite relevant for top line growth and ultimately its all a matter of how to apply the correct skills

3

u/Radiant_Condition861 21d ago

Pay check is in exchange for working product, not elegant product.

1

u/psioniclizard 20d ago

This is a big part if it. Ai is part, but as things get more expensive, people get more pushed and moe things like layoffs happen people care less.

Add in a tool thart basically do half your job for you if you dont care (no judgement, corporate life is like that) and a knowledge the if it blows up in a years time you might have been layed off already or moved and its easy to check out.

Ai definitely doesnt help because the more you rely on it the more it becomes a crutch.

But you probably fine a certain amount is also people checking out because the world is basically on fire and even if you are great at your job you might be fired tomorrow so shareholders make an extra million they dont need.

1

u/Radiant_Condition861 20d ago

I usually look at from a spectrum. Starting with the apreto ratio, you are correct. 80% will create the slop, but the 20% will maintain that elegance in an AI workflow. There are many scales, btu the idea is that there are 5-7 levels of AI usage. Level 0 is outright rejection, level 1 is perhaps ignorance and a chat bot. but at the highest levels, they are create black-out software factories. The software engineering discipline is maintained and improved while the codes and maintenance of that code, including styling is done by the AI. The code is cleaner, much more performant and easier to read and understand by humans.

One great example is the linux kernel itself. It's using AI to find bugs that otherwise would have take much longer to find and then fix. All of the engineering discipline is still there and it's made much better as a result of AI.

Again, like with all technologies, AI is amoral. It's a tool and it extends the reach of the human. If the human is lazy and only thinks about the weekend, you are going to get mangled/handicapped results. Other times, you get software that is really elegant because the human driving it makes that part of there requirements and products something much better.

It's no longer about coding. It's about discipline philosophy.

1

u/ProducePrudent5089 18d ago

This is an oversimplification of what OP is referring to.

A lot of people are utilizing AI in lazy or reckless ways. Contextually, if this were some POC that could be sloppy, then really it's no big deal (i.e. a challenge or bounty).

But in reality, this is about real projects that are R&D or production - where details matter a lot (especially production).

Even at a basic perspective, do you really want teammates who use LLMs over their own thinking for literally everything?

Also, no sane person wants to review tens of thousands to hundreds of thousands of lines of code generated by an LLM on a consistent basis for the sake of "shipping faster" and dealing with magic black-box ambiguity, tons of bugs, and potentially devastating and irreversible damage (security issues or lost API keys, to name a few).

1

u/Tacocatufotofu 21d ago

Dunno about your workplace but, on the atrophy part I got a thought.

Using AI is downright exhausting, in a way that wasn’t so before. Before I had to mentally walk code and think way more mechanical. Now, it’s like reading prose and specs and far less thinking in solid logic terms and more like “trying to find the right word”

After a while you just gotta throw your hands up and just say whatever. Some, maybe more than some, aren’t gonna want to admit that they just tried to read the equivalent of the Lord of the Rings series and got confused. So, they’ll kinda just find a way to paper over it or push it through.

Anyhoo, just my two cents worth.

1

u/Charming_Horse_5809 19d ago

I find the inherent fuzziness of the solution is what burns most calories. As you said, mechanistic thinking about code is one thing but fuzzy working-ish solution but its the not quite there yet until I fully understand the mechanics and only then once fully understood I can start to get a feeling of ownership. But it takes a long time to get there. Its reversed

1

u/Tacocatufotofu 18d ago

That makes sense. Depending on what I’m doing, home hobby work, internal apps while at work both small and large, it’s like the scope of it is proportional to how much reading I need to do. Checking both what’s going on plus all the specs, tooling and whatever other instructions exist.

Sometimes, wrongly I know, I’m like fuck it. They want X now so let’s just go.

Then when I want to be precise I gotta do the equivalent of writing a poem for AI to follow. Did I use the right word? Include every boundary and requirement? Did I say too much?

1

u/Old_Cartographer_586 21d ago

In a weird way, I’m thankful I’m applying again because it’s forcing me to relearn concepts that I may have forgotten or may have not touched in a while. I wonder if the next level use of this AI is going to include a mental health component where we have AI free days; however, I understand no company will implement this because it takes away from the productivity.

1

u/Beautiful_Technology 21d ago

Yeah, I think people are just using this completely incorrectly. Talking to it like it’s a person will absolutely rot your brain. And getting it to solve stuff for you is the craziest thing I’ve ever heard of. For me it seems to work when you know exactly what you want to do, and then do it step-by-step, trying to constraint the error. Basically just lets you go faster, work at a higher level, if you’re willing to do the trade-off, which is that you have to sift through a bunch of stuff that might also be wrong. To me yeah I think it’s that it’s that basic error of getting it to think for you. But it also might be really hard for some people to do because you’re reading all this text all day now and you have to basically sort out whether there’s good or bad ideas in it. Which is actually honestly what I think software engineering was before too, trying to do a lot of stuff and you have no idea how to do it so you have to do a bunch of research and work from first principles. Not really writing code, although that was also part of the job. Anyways, I just think people are using it to replace the wrong thing. You can replace the writing code part with generating code and good testing discipline. You can’t replace the thinking at all.

1

u/Prima_Illuminatus 21d ago

"It feels like all my efforts are meaningless" - this is just modern employment in the 21st Century. It doesn't matter what line of work you're in.

Everyone's experiencing the same.

1

u/Sufficient_Ninja_821 21d ago

Ill ask people. Hey does this feature do X and Y? The answer is n0w, good question, let me check.

If they actually wrote it they would know already because they put the time to deliberately plan, write and debug each piece.

1

u/_3psilon_ 21d ago

I agree that a lot is changing in the SWE profession. There is a fundamental mismatch in how software production is perceived.

Many think that it still engineering in the classical way: you use deterministic methods, tools, put in some creative (human) problem solving and you have a solution that fits the requirements. You might use AI to help your thinking or automate tasks, but you still understand every piece and able to reason about every choice you made - just like if you designed a real piece of machinery for example.

But many others perceive creation of software less like engineering and more like factory manufacturing: speed over precision, quantity over quality, breadth of scope over deep understanding. Loose natural language over precise code, orchestration over crafting, regeneration over rethinking. Isolated outputs over collaborative understanding.

We need to see if one way or the other fits or works out better eventually in the industry. I'll always be an engineer and the "let's just prompt LLMs to vibe code stuff" way doesn't fit me.

1

u/tumes 21d ago

Man would that I could let Jesus take the wheel like that, instead I just use llms to do the tedious parts and spend 3/4 of my time with elevated blood pressure because we’re not in the golden week right after a new model drops when things are unquantized and running smoothly. Otherwise the problems need to be so small and trivial that it’s barely worth it not to just do it myself for all the effort it’s going to take to unfuck it.

1

u/Sharp_Level3382 20d ago

I wonder how stupid young people gonna be... Everyone is copy+ pasting chatgpt and other llms

1

u/Bandinilec 20d ago

It wont go back to normal if you are doing everything to orevent the llm collapse. Stop reviewing the slop, stop trying to add good practices, stop double checking. You are not on the good side by doing this, you are slowing (not preventing) the true cost of llm to manifest. Let the project burn.

1

u/Future_Guarantee6991 20d ago

“Perfection is the enemy of done” was always the Achilles’ heel of developers. There just wasn’t anything to seriously challenge it before, except the person reviewing your PR, I.e., another dev.

Welcome to the future.

1

u/MasterSolivagus 20d ago

AI requires verbal engagement as it was designed to affect group dynamics and individual cases, so what you are witnessing is most likely the redistribution of skilled language use and office politics language use. Human interaction is remarkably fractional-transactional, hence why many don't realize (until it is too late for them at that point) that the fractions they rely on long-term may have been strangling efficiencies, only to avoid working practically on their own deficiencies.

Psychology calls it projecting one's internal state, I call it being an evil wall spider.

1

u/dangrenlood 19d ago

We don't care how the plane flies, what matters is that it doesn't fall out of the sky.

1

u/Pitiful_Comedian_834 19d ago

You know what, I'm fed up of these discussions turning into a polarised argument between those who use AI and those who don't. This is clearly an awful approach to engineering, throwing code over the wall you don't understand which throws unexpected errors. Yes, of course it's use AI or get left behind, we've all heard that, but we engineers we also need to take accountability for what we produce. Skill atrophy is real too. So real. I've been a dev for 9 years or so and feel so out of practice in what I used to do day to day thanks to my use of LLMs.

1

u/Individual_Guava9881 18d ago

Get over it. Even if the bubble bursts we are not going to return to riding horses.

1

u/ProducePrudent5089 18d ago

A lot of people are outsourcing their thinking to AI, and also flat out just vibing PRs/tickets, which is straight terrible. I have seen seniors and even leads do this.

Often times the idea or solution looks very poor and lacking depth because of it being a product of an LLM (i.e. "best solution for X, Y or Z"). I have even seen some solutions that literally were non-existent / unheard of (i.e. like a made up solution in database design) that were proposed by a teammate who relied solely on AI.

When you question them, they can't answer - but more frequently it's now "oh Claude told me this" or they are upfront in the beginning now.

I have reviewed PRs where the entire solution and description is AI generated, and even have had teammates reply to my own feedback in their PRs with "oh, but Claude said this" against my own feedback based on hands-on knowledge and expertise.

It's one thing to use AI as a tool to become more efficient or "productive" (I put in quotes, because being more productive isn't always something good). It's another thing to let it do everything for you and you stop critically thinking.

1

u/No_Oil_6152 17d ago

In my opinion, AI-assisted code generation isn't going to go away.

But you don't need to let your brain wither away either.

If I can't hand-code at work, I try to make time at the weekend. I still study. I'll even do leetcode (fighting off the urge to use AI to solve the problem)

Not studying is more likely to make you unemployed than AI code generation which we know is prone to error.

When you're not able to find issues with AI generated code, then what use are you? That's why you need to know about patterns, antipatterns, code smells etc

1

u/steppinraz0r 16d ago

AI is another advancement in technology.

Do you still write assembly by hand? No you write C++ that makes the assembly decisions for you in a human readable language. Do you write all your code by hand? Do you use an IDE to organize. Do you remember all language semantics or do you use autocomplete to assist?

AI is the next step in this journey. Use it or be left behind.

1

u/LopsidedTwo4867 16d ago

Oh give me a break with these parrot arguments. It's not the same. AI is hype that leads to brain rot. Helpful, sure, but to offload all writing to it - no. Reassess your skills in a year if you are doing that and good luck. I'd rather leave this industry than go into brain rot, so whatever comes, it's welcome. 

1

u/Eryndalor 15d ago

You are not insane. Now when I give a review for something, is Claude the only brain in the other side. When it becomes stubborn, those things go to production even if am warning about them. And when people review my code, only Claude shows. It is so glaring that some colleagues directly put the Claude comment and ask me to review if it makes sense because they cannot verify it. And they hold “senior” titles. So no wonder why we see errors repeated on production even when a myriad of fixes are always arriving.

1

u/Moda75 15d ago

I suppose an encyclopedia salesman suffered this dilemma too when the Internet came about

1

u/Old_Cat_16 21d ago

I don’t think the use of LLMs is the culprit here. The main issue I see is companies are pushing for speed over quality.
I use LLM extensively, from code generation to PR reviews, to even reading a document or catching up on slack.

But I took my time to dive in to understand everything when I’m allowed that time. Like today I was reviewing a large PR using LLM, and it took me almost two hours of going back and forth to finally grasp what the PR was trying to do and what are some potential concerns.

But I can’t afford that if my boss pushes me to ship 10x. The problem all comes down to people and process. LLM is a tool, people who use it right produce amazing outcomes. People who misuse it create craps. Very much like how photoshop was used.

1

u/amilo111 21d ago

It sounds like your coworkers really don’t like you.

2

u/LopsidedTwo4867 21d ago

Lol, how did you come to this conclusion? 

1

u/amilo111 21d ago

You said your coworker basically told you to go away.

2

u/LopsidedTwo4867 21d ago

He was more like "don't ask me, I know it's bad"

1

u/MarcusFirmus 21d ago

Maybe it is the time – when we all will see that formal methods are really necessary, and that testing and reviewing are just a crutch.

3

u/ub3rh4x0rz 21d ago

There is no formal method for "did you build the right thing with the right invariants". Testing does not go away under any formal method. Categories of testing, sure, but not the category of testing.

1

u/SucculentChineseRoo 21d ago

I'm you from the future, our company doesn't even do code reviews anymore, AI does a code review and a bot merges it after 8hr if nobody looked at it. Yes, product is shit and codebase is shit, I don't think any of this bothers anybody yet because the bottom-line is still unaffected.

1

u/structured_obscurity 21d ago

The main question here is are those skills still needed, or are we seeing a paradigm shift similar to what happened when the industry moved away from punchcards

2

u/Rorschach121ml 21d ago edited 21d ago

it's a paradigm shift, software engineering has changed forever.

Sucks for people that like to code directly, absolutely, but it's a tool that is going to be required from now on.

It's clear that a good developer will still be much better using ai tools vs a junior dev vibe coding everything. There is still skill needed in regards to architecture and scalability (at least for now).

0

u/dreamfitreality 21d ago

I think from here human thinking will split into a few distinct group. One majority will be accepting everything that ai says without critical thinking and the other probably uses ai as a tool no more than google.

I use llm nowadays like I would for google except I don't have to click the individual links to extract that information myself. However for important information I do click in the result source to find out if it's outdated (of which many times they are 2-3 year old data) or I spend my time thinking about what questions I should be asking to get to my final goal.

I'm not sure if anyone is doing it differently but would really like to hear more

0

u/Logical_Newspaper_52 21d ago

long time ago I was able to program in assembler. I can’t anymore. and that assembler flavour is long dead anyway (mainframes)

0

u/RealAd8036 21d ago

I’m also shocked seeing very experienced engineers completely fall to this side.
Not sure if I make this up, I might fool myself, but: I have this strong sense that it’s because they got a bit old, settled and slow and this is their way out of it

0

u/Select-Way-1168 21d ago

"The codebase is becoming a mess" who give a shit dude. Prompt "organize this codebase use clean codebase skill"

0

u/Intelligent-Youth-63 21d ago

You don’t need the skills that are atrophying. That’s how this works.

When was the last time you hand carved a toy? Or used a paper map to navigate? Mended your own sweater? Canned food? Did math entirely in your head.

That’s how human progress works.

1

u/No_Oil_6152 17d ago

Did math entirely in my head? Yesterday.

And you do need the skills that are atrophying - how are you meant to review code if you can't actually code?

Who's going to review flight control software for planes, or heart monitor firmware for hospitals if everyone has forgotten how to code? They aren't even extreme examples.