LLMs will not replace proper software developers

  • 🔧 Site instability resolved. You can report double-posts and broken attachments. For bigger issues, use the Technical Grievances thread.
    🇵🇦 Nuestro primer dominio localizado está en español en kiwifarms.pa. Our first localized domain is on Spanish on kiwifarms.pa.
  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account

How much code does an LLM create for you?

  • 0% I don't allow it

    Votos: 19 24.1%
  • 0-5% very low

    Votos: 11 13.9%
  • 5-10%

    Votos: 6 7.6%
  • 10-20%

    Votos: 6 7.6%
  • 20-30%

    Votos: 5 6.3%
  • 30-40%

    Votos: 3 3.8%
  • 40-50%

    Votos: 0 0.0%
  • 50-60%

    Votos: 0 0.0%
  • 70-90%

    Votos: 4 5.1%
  • 90-100%

    Votos: 7 8.9%
  • I am not a programmer.

    Votos: 18 22.8%

  • Total de votantes
    79
I think fully replacing software developers with AI is not possible, at all. AIs are like an obtuse genie, if you don't formulate your prompt/wish with exhaustive detail, it will not give you what you want, no matter how perfected it is. So there always has to be someone with some knowledge of how the programming language works in the room communicating to the AI exactly what they need the software to do, because the output won't be able to interact with other pieces of software at all otherwise.
 
Artificial intelligence is advancing at a pace that suggests software developers, as a profession, may eventually be replaced or dramatically diminished. What once required years of education and experience—writing functional code, debugging systems, optimizing performance—can now be done in seconds by AI systems trained on vast repositories of software knowledge. As these systems improve, the economic and practical incentives to replace human developers become increasingly compelling.

At its core, software development is a process of translating human intent into machine-readable instructions. This translation is precisely what large language models and code-generating AI systems excel at. Already, AI can generate entire applications from plain-language prompts, refactor legacy code, detect vulnerabilities, and write test suites automatically. As models gain better reasoning abilities and deeper contextual awareness, the gap between “assistance” and “autonomy” will continue to close.
If you think LLMs can debug on a whim or effortlessly refactor I've got some prime Florida swampland to sell. Debugging production code for one often requires a knowledge of the underlying business logic and the various quirks implemented because of it; no amount of code reading or prompting is going to give the LLM that context without it breaking, especially when the devs themselves may be unfamiliar with the domain, the codebase is large without one adhered format/standard, and documentation fell by the wayside years prior. LLMs can help you narrow down where the problem is and what to investigate, but beyond that it's a total crap shoot for the average commercial service.
 
If you think LLMs can debug on a whim or effortlessly refactor I've got some prime Florida swampland to sell. Debugging production code for one often requires a knowledge of the underlying business logic and the various quirks implemented because of it; no amount of code reading or prompting is going to give the LLM that context without it breaking, especially when the devs themselves may be unfamiliar with the domain, the codebase is large without one adhered format/standard, and documentation fell by the wayside years prior. LLMs can help you narrow down where the problem is and what to investigate, but beyond that it's a total crap shoot for the average commercial service.

LLMs can debug and refactor code more efficiently than human programmers in many practical contexts because they combine speed, breadth of knowledge, and consistency at a scale no individual can match. An LLM can analyze thousands of lines of code in seconds, identifying syntax errors, logical flaws, and edge cases that might take a human hours to trace. Unlike humans, LLMs do not suffer from fatigue, tunnel vision, or context-switching costs, allowing them to maintain a uniform level of attention across an entire codebase.

LLMs also draw on patterns learned from vast amounts of source code written in many languages and paradigms. This enables them to recognize common bug signatures and anti-patterns almost instantly, even in unfamiliar projects. When refactoring, an LLM can systematically apply best practices—such as improving modularity, reducing duplication, or clarifying naming conventions—while preserving functionality. Humans often refactor incrementally and subjectively, whereas LLMs can propose comprehensive, consistent changes in a single pass.

Additionally, LLMs excel at explaining their reasoning. They can annotate fixes, justify design choices, and generate tests to validate changes, accelerating review and verification. While human judgment remains valuable for high-level architectural decisions, LLMs outperform individual programmers at the mechanical, pattern-heavy tasks of debugging and refactoring, making them a more efficient tool for these aspects of software development.
 
Humans will eventually be obsolete for actual program writing, just like humans are obsolete for making carvings onto steel plate. But software engineers won't be obsolete for the short term because context window sizes are too small for AIs to actually generate or fix a large complicated program without human design, hand-holding and validation. And in the long term, software engineers won't be obsolete for the same reason that civil engineers, doctors and lawyers won't be obsolete: the reason people pay big money no whammies for these roles is because there needs to be someone who can be held legally responsible for the quality of work.
 
LLMs also draw on patterns learned from vast amounts of source code written in many languages and paradigms. This enables them to recognize common bug signatures and anti-patterns almost instantly, even in unfamiliar projects. When refactoring, an LLM can systematically apply best practices—such as improving modularity, reducing duplication, or clarifying naming conventions—while preserving functionality. Humans often refactor incrementally and subjectively, whereas LLMs can propose comprehensive, consistent changes in a single pass.
Now I know you're trolling. Any dev with a few months experience already knows many bugs - and the most consequential bugs - aren't simple stuff like type mismatches, dangling pointers, null exceptions, or flawed string manipulation. The true bugs often span across domains or different codebases, involve weird intricacies and interactions between languages and frameworks, and can see causes which even official documentation and StackOverflow threads have nothing on.

One recent example my team had highlighting the limitations is a Vuex state variable not being initialized even though correctly declared and used. The reason? The store itself was incorrectly instantiated for that variable's declaration (compared to other state variables in the store) and the issue being masked by an in-house frontend framework we use which itself was silently broken for such instantiation until the latest update was stealth applied to our project. Claude and ChatGPT were very useful in identifying an instantiation problem (duh), but never once did they identify the root cause because, lo and behold, the lacked the context which primarily came through word of mouth and dev experience.

I will not deny LLMs are a great tool for assisting a dev (and I quite like Claude for how quickly it takes care of unit test busywork), but the time taken to train a model via prompts and supplying contextual information into figuring out the above example would've taken far longer than us manually walking through the flow - and all before dealing with inevitable hallucinations from missing information, poor wording, and limited ability to cognitively scale beyond a single code repository. Tack on the need to also consider product/design information (itself likely as chaotic and descriptively incomplete as a large codebase's documentation) and you're shooting yourself in the foot taking what it spits out at face value.
 
does the fancy predictive autocomplete that's built into my jetbrains IDE count as LLM code?
if yes then ~10%
if no then 0% cause i'd rather switch careers than ever say a word to claude or cursor
 
does the fancy predictive autocomplete that's built into my jetbrains IDE count as LLM code?
if yes then ~10%
if no then 0% cause i'd rather switch careers than ever say a word to claude or cursor

Jetbrains auto complete is garbage. It's way under the threshold to be useful. Personally, all auto complete is not worth the cognitive load to always be checking it's suggestion, but I've had colleagues disagree.


So my last project made heavy use of cursor. It was the perfect type of project to use cursor. Built in a popular framework, greenfield, and not too technically complicated.
My opinion is that the second order tech that builds on llm, ie cursor makes it worth using. I've tried getting into copilot a few times, but I've always quit because it was more trouble that it was worth.
Cursor makes the ai usable. It could solve some easier bugs, implement simple features, and generate some boilerplate to work off of.
However it drastically increased the amount of code to review for the team. Not only did you have to review everything it generated, you have to review other teammates code that they generated. We very quickly hit a point where reviews were the bottleneck. There are other things it could do. For example, researching the codebase and making writing prs.

I'd say it increased our speed a bit, but not anything amazing. I also think it would be much worse in other situations.
 
If you’re spending time writing code, that means you’re not debugging, testing, and revising, all of which is more critical. Using LLMs to eliminate code writing in order to work on the big three is how to be productive in current day. Otherwise you’re wasting company time and deserve to be eliminated.

If you’re just a hobbyist, do whatever you want, but don’t be surprised when some 18 year old Gen Alpha pops up out of nowhere with something better than whatever you spent ten years working on.
 
I hope it puts every developer out of a job. I've never met one that wasn't an insufferable dolt. Bonus points to all you web devs that don't have a clue about networks and demand access to the domain registrar.
 
If you’re spending time writing code, that means you’re not debugging, testing, and revising, all of which is more critical. Using LLMs to eliminate code writing in order to work on the big three is how to be productive in current day. Otherwise you’re wasting company time and deserve to be eliminated.

If you’re just a hobbyist, do whatever you want, but don’t be surprised when some 18 year old Gen Alpha pops up out of nowhere with something better than whatever you spent ten years working on.
pre LLM, 3 hours writing code 5 minutes debugging.
Post LLM, 5 minutes writing code, 3 hours debugging.
 
Atrás
Top Abajo