10 ms·

This reads like shilling/advertisement.. Coding AIs are struggling for anything remotely complex, make up crap and present it as research, write tests that are

by 63stack 9mo ago

This reads like shilling/advertisement.. Coding AIs are struggling for anything remotely complex, make up crap and present it as research, write tests that are just "return true", and won't ever question a decision you make. Those twenty engineers must not have produced much.

pfannkuchen 9mo ago
I think part of what is happening here is that different developers on HN have very different jobs and skill levels. If you are just writing a large volume of code over and over again to do the same sort of things, then LLMs probably could take your job. A lot of people have joined the industry over time, and it seems like the intelligence bar moved lower and lower over time, particularly for people churning out large volumes of boilerplate code. If you are doing relatively novel stuff, at least in the sense that your abstractions are novel and the shape of the abstraction set is different from the standard things that exist in tutorials etc online, then the LLM will probably not work well with your style. So some people are panicking and they are probably right, and some other people are rolling their eyes and they are probably right too. I think the real risk is that dumping out loads of boilerplate becomes so cheap and reliable that people who can actually fluently design coherent abstractions are no longer as needed. I am skeptical this will happen though, as there doesn’t seem to be a way around the problem of the giant indigestible hairball (I.e as you have more and more boilerplate it becomes harder to remain coherent).
- deleted 9mo ago
  [deleted]
- IshKebab 9mo ago
  > different developers on HN have very different jobs and skill levels. Definitely this. When I use AIs for web development they do an ok job most of the time. Definitely on par with a junior dev. For anything outside of that they're still pretty bad. Not useless by any stretch, but it's still a fantasy to think you could replace even a good junior dev with AI in most domains. I am slightly worried for my job... but only because AI will keep improving and there is a chance it will be as good as me one day. Today it's not a threat at all.
  - ryandrake 9mo ago
    Yea, LLMs produce results on par with what I would expect out of a solid junior developer. They take direction, their models act as the “do the research” part, and they output lots of code: code that has to be carefully scrutinized and refined. They are like very ambitious interns who never get tired and want to please, but often just produce crap that has to be totally redone or refactored heavily in order to go into production. If you think LLMs are “better programmers than you,” well, I have some disappointing news for you that might take you a while to accept.
    - monsieurbanana 9mo ago
      > LLMs produce results on par with what I would expect out of a solid junior developer This is a common take but it hasn't been my experience. LLMs produce results that vary from expert all the way to slightly better than markov chains. The average result might be equal to a junior developer, and the worst case doesn't happen that often, but the fact that it happens from time to time makes it completely unreliable for a lot of tasks. Junior developers are much more consistent. Sure, you will find the occasional developer that would delete the test file rather than fixing the tests, but either they will learn their lesson after seeing your wth face or you can fire them. Can't do that with llms.
      - jvanderbot 9mo ago
        I think any further discussion about quality just needs to have the following metadata: - Language - Total LOC - Subject matter expertise required - Total dependency chain - Subjective score (audited randomly) And we can start doing some analysis. Otherwise we're pissing into ten kinds of winds. My own subjective experience is earth shattering at webapps in html and css (because I'm terrible and slow at it), and annoyingly good but a bit wrong usually in planning and optimization in rust and horribly lost at systems design or debugging a reasonably large rust system.
        monsieurbanana 9mo ago
        I agree in that these discussions (this whole hn thread tbh) are seriously lacking in concrete examples to be more than holy wars 3.0. Besides one point: junior developers can learn from their egregious mistakes, llms can't no matter how strongly worded you are in their system prompt. In a functional work environment, you will build trust with your coworkers little by little. The pale equivalent in LLMs is improving system prompts and writing more and more ai directives that might or might not be followed.
- charcircuit 9mo ago
  >at least in the sense that your abstractions are novel and the shape of the abstraction set is different from the standard things that exist People shouldn't be doing this in the first place. Existing abstractions are sufficient for building any software you want.
  - bryanrasmussen 9mo ago
    I'm supposing that nobody who has a job is producing abstractions that are always novel, but there may be people who find abstractions that are novel for their particular field because it is something most people in that field are not familiar with, or that come up with novel abstractions (infrequently) that improve on existing ones.
  - yetihehe 9mo ago
    > Existing abstractions are sufficient for building any software you want. Software that doesn't need new abstractions is also already existing. Everything you would need already exists and can be bought much more cheaply than you could do it yourself. Accounting software exists, unreal engine exists and many games use it, why would you ever write something new?
    - charcircuit 9mo ago
      >Software that doesn't need new abstractions is also already existing This isn't true due to the exponential growth of how many ways you can compose existing abstractions. The chance that a specific permutation will have existing software is small.
  - bckr 9mo ago
    The new abstraction is “this corporation owns this IP and has engineers who can fix and extend it at will”. You can’t git clone that. But if there is something off the shelf that you can use for the task at hand? Great! The stakeholders want it to do these other 3000 things before next summer.
  - mdemare 9mo ago
    Software development is a bit like chess. 1. e4 is an abstraction available to all projects, 3. Nc3 is available to 20% of projects, while 15. Nxg5 is unique to your own project. Or, abstractions in your project form a dependency tree, and the nodes near the root are universal, e.g. C, Postgres, json, while the leaf nodes are abstractions peculiar to just your own project.
- stackghost 9mo ago
  Absolutely this, and TFA touches on the point about natural language being insufficiently precise: AI can write you an entire CRUD app in minutes, and with some back-and-forth you can have an actually-good CRUD app in a few hours. But AI is not very good (anecdotally, based on my experience) at writing fintech-type code. It's also not very good at writing intricate security stuff like heap overflows. I've never tried, but would certainly never trust it to write cryptography correctly, based on my experience with the latter two topics. All of the above is "coding", but AI is only good at a subset of it.
  - llmslave2 9mo ago
    > and with some back-and-forth you can have an actually-good CRUD app in a few hours Perhaps the debate is on what constitutes "actually-good". Depends where the bar is I suppose.
    - stackghost 9mo ago
      Beauty is in the eye of the beholder. Litigating our personal opinions about "actually-good" is irrelevant and pointless.
  - bonesss 9mo ago
    Generating CRUD is like solving cancer in mice, we already have a dizzying array of effective solutions… Ruby on Rails, Access 97, model first ORMs with GUI mappers. SharePoint lets anyone do all the things easily. The issue is and always has been maintenance and evolution. Early missteps cause limitations, customer volume creates momentum, and suddenly real engineering is needed. I’d be a lot more worried about our jobs if these systems were explaining to people how to solve all their problems with a little Emacs scripting. As is they’re like hyper aggressive tech sales people, happy just to see entanglements, not thinking about the whole business cycle.
    - skydhash 9mo ago
      Go with Laravel and some admin packages and you generate CRUD pages in minutes. And I think with Django, that is builtin. But I don’t think I’ve seen pure CRUD on anything other than prototype. Add an Identity and Access Management subsystem and the complexity of requirements will explode. Then you add integration to external services and legacy systems, and that’s where the bulk of the work is. And there’s the scalability issue that is always looming. Creating CRUD app is barely a level over starting a new project with the IDE wizard.
- 1718627440 9mo ago
  > If you are just writing a large volume of code over and over again But why would you do that? Wouldn't you just have your own library of code eventually that you just sell and sell again with little tweaks? Same money for far less work.
  - embedding-shape 9mo ago
    People, at least novice developers, tend to prefer fast and quick boilerplate that makes them look effective, over spending one hour sitting just thinking and designing, then implementing some simple abstraction. This is true today, and been true for as long as I've been in programming. Besides, not all programming work can be abstracted into a library and reused across projects, not because it's technically infeasible, but because the client doesn't want to, cannot for legal reasons or the developer process at the client's organization simply doesn't support that workflow. Those are just the reasons from the top of my head, that I've encountered before, and I'm sure there is more reasons.
    - deleted 9mo ago
      [deleted]
    - 1718627440 9mo ago
      But people don't stay novices after years/decades. Of course when you write the boilerplate for the 20x time maybe you still accept that, but when you write it for the 2000x time, I bet you do the lazy thing and just copy it. > cannot for legal reasons or ... Sure, you can't copy trade secrets, but that's also not the boilerplate part. Copying e.g. a class hierarchy and renaming all the names and replacing the class contents that represent the domain, won't be a legal problem, because this is not original in the first place.
      - embedding-shape 9mo ago
        > But people don't stay novices after years/decades Some absolutely do. I know programmers who entered web development at the same time as me, and now after decades they're still creating typical CRUD applications for whatever their client today is, using the same frameworks and languages. If it works, makes enough money and you're happy, why change? > Copying e.g. a class hierarchy and renaming all the names and replacing the class contents that represent the domain, won't be a legal problem, because this is not original in the first place. Some code you produce for others definitively fall under their control, but obviously depends on the contracts and the laws of the country you're in. But I've written code for others that I couldn't just "abstract into a FOSS library and use in this project", even if it wasn't trade secrets or what not, just some utility for reducing boilerplate.
- mekoka 9mo ago
  Indeed, discussions on LLMs for coding sound like what you would expect if you asked a room full of people to snatch up a 20 kg dumbbell once and then tell you if it's heavy. > I think the real risk is that dumping out loads of boilerplate becomes so cheap and reliable that people who can actually fluently design coherent abstractions are no longer as needed. Cough front-end cough web cough development. Admittedly, original patterns can still be invented, but many (most?) of us don't need that level of creativity in our projects.
- therobots927 9mo ago
  That’s a very good point I hadn’t heard explained that way before. Makes a lot of sense and explains a lot of the circular debates about AI that happen here daily.
photios 9mo ago
Ok, let's say the 20 devs claim is false [1]. What if it's 2? I'd still learn and use the tech. Wouldn't you? [1] I actually think it might be true for certain kinds of jobs.
- BirdieNZ 9mo ago
  Jevon's Paradox: more software will be produced, rather than fewer software engineers being employed.
- bloppe 9mo ago
  It's not 20 and it's not 2. It's not a person. It's a tool. It can make a person 100x more effective at certain specific things. It can make them 50% less effective at other things. I think, for most people and most things, it might be like a 25% performance boost, amortized over all (impactful) projects and time, but nobody can hope to quantify that with any degree of credibility yet.
  - andrekandre 9mo ago
    > but nobody can hope to quantify that with any degree of credibility yet i'd like to think if it was really good, we would see product quality improve over time; iow less reported bugs, less support incidents, increased sign-ups etc, that could easily be quantified no?
sh4rks 9mo ago
Post model
dent9 9mo ago
This is completely wrong. Codex 5.2 and Claude Sonnet 4.5 don't have any of these issues. They will regularly tell you that you're wrong if you bother to ask them and they will explain why and what a better solution is. They don't make up anything. The code they produce is noticeably more efficient in LoC than previous models. And yes they really will do research, they will search the Internet for docs and articles as needed and cite their references inline with their answers. You talk as if you haven't used a LLM since 2024. It's now almost 2026 and things have changed a lot.
- claytongulick 9mo ago
  With apologies, and not GP, but this has been the same feedback I've personally seen on every single model release. Whenever I discuss the problems that my peers and I have using these things, it's always something along the lines of "but model X.Y solves all that!", so I obediently try again, waste a huge amount of time, and come back to the conclusion that these things aren't great at generation, but they are fantastic at summarization and classification. When I use them for those tasks, they have real value. For creation? Not so much. I've stopped getting excited about the "but model X.Y!!" thing. Maybe they are improving? I just personally haven't seen it. But according to the AI hypers, just like with every other tech hype that's died over the past 30 years, "I must just be doing it wrong".
  - dent9 9mo ago
    A lot of people are consistently getting their low expectations disproven when it comes to progress in AI tooling. If you read back in my comment history, six months ago I was posting about how AI is over hyped BS. But I kept using it and eventually new releases of models and tools solved most of the problems I had with them. If it has not happened for you yet then I expect it will eventually. Keep up with using the tools and models and follow their advancements and I think you'll eventually get to the point where your needs are met
- 63stack 9mo ago
  The same response (you are using model X instead of Y) have been perpetuated since 2024, and will still be perpetuated in 2026.
aspenmartin 9mo ago
No it doesn’t read like shilling and advertisement, it’s tiring hearing people continually dismiss coding agents as if they have not massively improved and are driving real value despite limitations and they are only just getting started. I’ve done things with Claude I never thought possible for myself to do, and I’ve done things where Claude made the whole effort take twice as long and 3x more of my time. It’s not like people are ignoring the limitations, it’s that people can see how powerful the already are and how much more headroom there is even with existing paradigms not to mention the compute scaling happening in 26-27 and the idea pipeline from the massive hoarding of talent.
- threethirtytwo 9mo ago
  The paradigm shift hit the world like a wall. I know entire teams where the manager thinks AI is bullshit and the entire team is not allowed to use AI. I love coding. But reality is reality and these fools just aren’t keeping pace with how fast the world is changing.
  - goatlover 9mo ago
    Or we're in another hype cycle and billions of dollars are being pumped in to sustain the current bubble with a lot of promises about how fast the world is changing. Doesn't mean AI can't be a useful tool.
    - aspenmartin 9mo ago
      When people say “hype cycle” that can mean so many different things. That valuations are too high and many industry “promises” are wrong is maybe true but to me it’s irrelevant, this isn’t speculative, I think most posters who are positive on agents in these threads are talking about two things: current, existing tools, and the existing rate of progress. Check out e.g. Epoch.ai for great industry analyses. To compare AI to crypto is disingenuous, they are completely different and crypto is a technology that fundamentally makes no sense in a world where governments want to (and arguably should) control money supply. You may or may not agree on that take but AI is something that governments will push aggressively and see as crucial to national security/control. It means this is not going away
davnicwil 9mo ago
I would say while LLMs do improve productivity sometimes, I have to say I flatly cannot believe a claim (at least without direct demonstration or evidence) that one person is doing the work of 20 with them in december 2025 at least. I mean from the off, people were claiming 10x probably mostly because it's a nice round number, but those claims quickly fell out of the mainstream as people realised it's just not that big a multiplier in practice in the real world. I don't think we're seeing this in the market, anywhere. Something like 1 engineer doing the job of 20, what you're talking about is basically whole departments at mid sized companies compressing to one person. Think about that, that has implications for all the additional management staff on top of the 20 engineers too. It'd either be a complete restructure and rethink of the way software orgs work, or we'd be seeing just incredible, crazy deltas in output of software companies this year of the type that couldn't be ignored, they'd be impossible to not notice. This is just plainly not happening. Look, if it happens, it happens, 26, 27, 28 or 38. It'll be a cool and interesting new world if it does. But it's just... not happened or happening in 25.
- emseetech 9mo ago
  Could be speed/efficiency was the wrong dimension to optimize for and its leading the industry down a bad path. An LLM helps most with surface area. It expands the breadth of possibilities a developer can operate on.
- EagnaIonat 9mo ago
  > I mean from the off, people were claiming 10x probably mostly because it's a nice round number, Purely anecdotal, but I've seen that level of productivity from the vibe tools we have in my workplace. The main issue is that 1 engineer needs to have the skills of those 20 engineers so they can see where the vibe coding has gone wrong. Without that it falls apart.
- CuriouslyC 9mo ago
  It's entirely dependent on the type of code being written. For verbose, straightforward code with clear cut test scenarios, one agent can easily 24/7 the work of 20 FT engineers. This is a best case scenario. Your productivity boost will depend entirely on a combination of how much you can remove yourself from the loop (basically, the cost of validation per turn) and how amenable the task/your code is to agents (which determines your P(success)). Low P(success) isn't a problem if there's no engineer time cost to validation, the agent can just grind the problem out in the background, and obviously if P(success) is high the cost of validation isn't a big deal. The productivity killer is when P(success) is low and the cost of validation is high, these circumstances can push you into the red with agents very quickly. Thus the key to agents being a force multiplier is to focus on reducing validation costs, increasing P(success) and developing intuition relating to when to back off on pulling the slot machine in favor of more research. This is assuming you're speccing out what you're building so the agent doesn't make poor architectural/algorithmic choices that hamstring you down the line.
to11mtm 9mo ago
I'd be willing to give you access to the experiment I mentioned in a separate reply (have a github repo), as far as the output that you can get for a complex app buildout. Will admit It's not great (probably not even good) but it definitely has throughput despite my absolute lack of caring that much [0]. Once I get past a certain stage I am thinking of doing an A-B test where I take an earlier commit and try again while paying more attention... (But I at least want to get where there is a full suite of UOW cases before I do that, for comparison's sake.) > Those twenty engineers must not have produced much. I've been considered a 'very fast' engineer at most shops (e.x. at multiple shops, stories assigned to me would have a <1 multiplier for points[1]) 20 is a bit bloated, unless we are talking about WITCH tier. I definitely can get done in 2-3 hours what could take me a day. I say it that way because at best it's 1-2 hours but other times it's longer, some folks remember the 'best' rather than median. [0] - It started as 'prompt only', although after a certain point I did start being more aggressive with personal edits. [1] - IDK why they did it that way instead of capacity, OTOH that saved me when it came to being assigned Manual Testing stories...
- imron 9mo ago
  > Will admit It's not great (probably not even good) but it definitely has throughput Throughput without being good will just lead to more work down the line to correct the badness. It's like losing money on every sale but making up for it with volume.
- notpachet 9mo ago
  > Will admit It's not great (probably not even good) You lost me here. Come back when you're proud of it.
coderenegade 9mo ago
My experience is that you get out what you put in. If you have a well-defined foundation, AI can populate the stubs and get it 95% correct. Getting to that point can take a bit of thought, and AI can help with that, too, but if you lean on it too much, you'll get a mess. And of course, getting to the point where you can write a good foundation has always been the bulk of the work. I don't see that changing anytime soon.

by 63stack 9mo ago

pfannkuchen 9mo ago

I think part of what is happening here is that different developers on HN have very different jobs and skill levels. If you are just writing a large volume of code over and over again to do the same sort of things, then LLMs probably could take your job. A lot of people have joined the industry over time, and it seems like the intelligence bar moved lower and lower over time, particularly for people churning out large volumes of boilerplate code. If you are doing relatively novel stuff, at least in the sense that your abstractions are novel and the shape of the abstraction set is different from the standard things that exist in tutorials etc online, then the LLM will probably not work well with your style. So some people are panicking and they are probably right, and some other people are rolling their eyes and they are probably right too. I think the real risk is that dumping out loads of boilerplate becomes so cheap and reliable that people who can actually fluently design coherent abstractions are no longer as needed. I am skeptical this will happen though, as there doesn’t seem to be a way around the problem of the giant indigestible hairball (I.e as you have more and more boilerplate it becomes harder to remain coherent).

deleted 9mo ago
[deleted]
IshKebab 9mo ago
> different developers on HN have very different jobs and skill levels. Definitely this. When I use AIs for web development they do an ok job most of the time. Definitely on par with a junior dev. For anything outside of that they're still pretty bad. Not useless by any stretch, but it's still a fantasy to think you could replace even a good junior dev with AI in most domains. I am slightly worried for my job... but only because AI will keep improving and there is a chance it will be as good as me one day. Today it's not a threat at all.
- ryandrake 9mo ago
  Yea, LLMs produce results on par with what I would expect out of a solid junior developer. They take direction, their models act as the “do the research” part, and they output lots of code: code that has to be carefully scrutinized and refined. They are like very ambitious interns who never get tired and want to please, but often just produce crap that has to be totally redone or refactored heavily in order to go into production. If you think LLMs are “better programmers than you,” well, I have some disappointing news for you that might take you a while to accept.
  - monsieurbanana 9mo ago
    > LLMs produce results on par with what I would expect out of a solid junior developer This is a common take but it hasn't been my experience. LLMs produce results that vary from expert all the way to slightly better than markov chains. The average result might be equal to a junior developer, and the worst case doesn't happen that often, but the fact that it happens from time to time makes it completely unreliable for a lot of tasks. Junior developers are much more consistent. Sure, you will find the occasional developer that would delete the test file rather than fixing the tests, but either they will learn their lesson after seeing your wth face or you can fire them. Can't do that with llms.
    - jvanderbot 9mo ago
      I think any further discussion about quality just needs to have the following metadata: - Language - Total LOC - Subject matter expertise required - Total dependency chain - Subjective score (audited randomly) And we can start doing some analysis. Otherwise we're pissing into ten kinds of winds. My own subjective experience is earth shattering at webapps in html and css (because I'm terrible and slow at it), and annoyingly good but a bit wrong usually in planning and optimization in rust and horribly lost at systems design or debugging a reasonably large rust system.
      - monsieurbanana 9mo ago
        I agree in that these discussions (this whole hn thread tbh) are seriously lacking in concrete examples to be more than holy wars 3.0. Besides one point: junior developers can learn from their egregious mistakes, llms can't no matter how strongly worded you are in their system prompt. In a functional work environment, you will build trust with your coworkers little by little. The pale equivalent in LLMs is improving system prompts and writing more and more ai directives that might or might not be followed.
charcircuit 9mo ago
>at least in the sense that your abstractions are novel and the shape of the abstraction set is different from the standard things that exist People shouldn't be doing this in the first place. Existing abstractions are sufficient for building any software you want.
- bryanrasmussen 9mo ago
  I'm supposing that nobody who has a job is producing abstractions that are always novel, but there may be people who find abstractions that are novel for their particular field because it is something most people in that field are not familiar with, or that come up with novel abstractions (infrequently) that improve on existing ones.
- yetihehe 9mo ago
  > Existing abstractions are sufficient for building any software you want. Software that doesn't need new abstractions is also already existing. Everything you would need already exists and can be bought much more cheaply than you could do it yourself. Accounting software exists, unreal engine exists and many games use it, why would you ever write something new?
  - charcircuit 9mo ago
    >Software that doesn't need new abstractions is also already existing This isn't true due to the exponential growth of how many ways you can compose existing abstractions. The chance that a specific permutation will have existing software is small.
- bckr 9mo ago
  The new abstraction is “this corporation owns this IP and has engineers who can fix and extend it at will”. You can’t git clone that. But if there is something off the shelf that you can use for the task at hand? Great! The stakeholders want it to do these other 3000 things before next summer.
- mdemare 9mo ago
  Software development is a bit like chess. 1. e4 is an abstraction available to all projects, 3. Nc3 is available to 20% of projects, while 15. Nxg5 is unique to your own project. Or, abstractions in your project form a dependency tree, and the nodes near the root are universal, e.g. C, Postgres, json, while the leaf nodes are abstractions peculiar to just your own project.
stackghost 9mo ago
Absolutely this, and TFA touches on the point about natural language being insufficiently precise: AI can write you an entire CRUD app in minutes, and with some back-and-forth you can have an actually-good CRUD app in a few hours. But AI is not very good (anecdotally, based on my experience) at writing fintech-type code. It's also not very good at writing intricate security stuff like heap overflows. I've never tried, but would certainly never trust it to write cryptography correctly, based on my experience with the latter two topics. All of the above is "coding", but AI is only good at a subset of it.
- llmslave2 9mo ago
  > and with some back-and-forth you can have an actually-good CRUD app in a few hours Perhaps the debate is on what constitutes "actually-good". Depends where the bar is I suppose.
  - stackghost 9mo ago
    Beauty is in the eye of the beholder. Litigating our personal opinions about "actually-good" is irrelevant and pointless.
- bonesss 9mo ago
  Generating CRUD is like solving cancer in mice, we already have a dizzying array of effective solutions… Ruby on Rails, Access 97, model first ORMs with GUI mappers. SharePoint lets anyone do all the things easily. The issue is and always has been maintenance and evolution. Early missteps cause limitations, customer volume creates momentum, and suddenly real engineering is needed. I’d be a lot more worried about our jobs if these systems were explaining to people how to solve all their problems with a little Emacs scripting. As is they’re like hyper aggressive tech sales people, happy just to see entanglements, not thinking about the whole business cycle.
  - skydhash 9mo ago
    Go with Laravel and some admin packages and you generate CRUD pages in minutes. And I think with Django, that is builtin. But I don’t think I’ve seen pure CRUD on anything other than prototype. Add an Identity and Access Management subsystem and the complexity of requirements will explode. Then you add integration to external services and legacy systems, and that’s where the bulk of the work is. And there’s the scalability issue that is always looming. Creating CRUD app is barely a level over starting a new project with the IDE wizard.
1718627440 9mo ago
> If you are just writing a large volume of code over and over again But why would you do that? Wouldn't you just have your own library of code eventually that you just sell and sell again with little tweaks? Same money for far less work.
- embedding-shape 9mo ago
  People, at least novice developers, tend to prefer fast and quick boilerplate that makes them look effective, over spending one hour sitting just thinking and designing, then implementing some simple abstraction. This is true today, and been true for as long as I've been in programming. Besides, not all programming work can be abstracted into a library and reused across projects, not because it's technically infeasible, but because the client doesn't want to, cannot for legal reasons or the developer process at the client's organization simply doesn't support that workflow. Those are just the reasons from the top of my head, that I've encountered before, and I'm sure there is more reasons.
  - deleted 9mo ago
    [deleted]
  - 1718627440 9mo ago
    But people don't stay novices after years/decades. Of course when you write the boilerplate for the 20x time maybe you still accept that, but when you write it for the 2000x time, I bet you do the lazy thing and just copy it. > cannot for legal reasons or ... Sure, you can't copy trade secrets, but that's also not the boilerplate part. Copying e.g. a class hierarchy and renaming all the names and replacing the class contents that represent the domain, won't be a legal problem, because this is not original in the first place.
    - embedding-shape 9mo ago
      > But people don't stay novices after years/decades Some absolutely do. I know programmers who entered web development at the same time as me, and now after decades they're still creating typical CRUD applications for whatever their client today is, using the same frameworks and languages. If it works, makes enough money and you're happy, why change? > Copying e.g. a class hierarchy and renaming all the names and replacing the class contents that represent the domain, won't be a legal problem, because this is not original in the first place. Some code you produce for others definitively fall under their control, but obviously depends on the contracts and the laws of the country you're in. But I've written code for others that I couldn't just "abstract into a FOSS library and use in this project", even if it wasn't trade secrets or what not, just some utility for reducing boilerplate.
mekoka 9mo ago
Indeed, discussions on LLMs for coding sound like what you would expect if you asked a room full of people to snatch up a 20 kg dumbbell once and then tell you if it's heavy. > I think the real risk is that dumping out loads of boilerplate becomes so cheap and reliable that people who can actually fluently design coherent abstractions are no longer as needed. Cough front-end cough web cough development. Admittedly, original patterns can still be invented, but many (most?) of us don't need that level of creativity in our projects.
therobots927 9mo ago
That’s a very good point I hadn’t heard explained that way before. Makes a lot of sense and explains a lot of the circular debates about AI that happen here daily.

photios 9mo ago

Ok, let's say the 20 devs claim is false [1]. What if it's 2? I'd still learn and use the tech. Wouldn't you? [1] I actually think it might be true for certain kinds of jobs.

BirdieNZ 9mo ago
Jevon's Paradox: more software will be produced, rather than fewer software engineers being employed.
bloppe 9mo ago
It's not 20 and it's not 2. It's not a person. It's a tool. It can make a person 100x more effective at certain specific things. It can make them 50% less effective at other things. I think, for most people and most things, it might be like a 25% performance boost, amortized over all (impactful) projects and time, but nobody can hope to quantify that with any degree of credibility yet.
- andrekandre 9mo ago
  > but nobody can hope to quantify that with any degree of credibility yet i'd like to think if it was really good, we would see product quality improve over time; iow less reported bugs, less support incidents, increased sign-ups etc, that could easily be quantified no?

sh4rks 9mo ago

Post model

dent9 9mo ago

This is completely wrong. Codex 5.2 and Claude Sonnet 4.5 don't have any of these issues. They will regularly tell you that you're wrong if you bother to ask them and they will explain why and what a better solution is. They don't make up anything. The code they produce is noticeably more efficient in LoC than previous models. And yes they really will do research, they will search the Internet for docs and articles as needed and cite their references inline with their answers. You talk as if you haven't used a LLM since 2024. It's now almost 2026 and things have changed a lot.

claytongulick 9mo ago
With apologies, and not GP, but this has been the same feedback I've personally seen on every single model release. Whenever I discuss the problems that my peers and I have using these things, it's always something along the lines of "but model X.Y solves all that!", so I obediently try again, waste a huge amount of time, and come back to the conclusion that these things aren't great at generation, but they are fantastic at summarization and classification. When I use them for those tasks, they have real value. For creation? Not so much. I've stopped getting excited about the "but model X.Y!!" thing. Maybe they are improving? I just personally haven't seen it. But according to the AI hypers, just like with every other tech hype that's died over the past 30 years, "I must just be doing it wrong".
- dent9 9mo ago
  A lot of people are consistently getting their low expectations disproven when it comes to progress in AI tooling. If you read back in my comment history, six months ago I was posting about how AI is over hyped BS. But I kept using it and eventually new releases of models and tools solved most of the problems I had with them. If it has not happened for you yet then I expect it will eventually. Keep up with using the tools and models and follow their advancements and I think you'll eventually get to the point where your needs are met
63stack 9mo ago
The same response (you are using model X instead of Y) have been perpetuated since 2024, and will still be perpetuated in 2026.

aspenmartin 9mo ago

No it doesn’t read like shilling and advertisement, it’s tiring hearing people continually dismiss coding agents as if they have not massively improved and are driving real value despite limitations and they are only just getting started. I’ve done things with Claude I never thought possible for myself to do, and I’ve done things where Claude made the whole effort take twice as long and 3x more of my time. It’s not like people are ignoring the limitations, it’s that people can see how powerful the already are and how much more headroom there is even with existing paradigms not to mention the compute scaling happening in 26-27 and the idea pipeline from the massive hoarding of talent.

threethirtytwo 9mo ago
The paradigm shift hit the world like a wall. I know entire teams where the manager thinks AI is bullshit and the entire team is not allowed to use AI. I love coding. But reality is reality and these fools just aren’t keeping pace with how fast the world is changing.
- goatlover 9mo ago
  Or we're in another hype cycle and billions of dollars are being pumped in to sustain the current bubble with a lot of promises about how fast the world is changing. Doesn't mean AI can't be a useful tool.
  - aspenmartin 9mo ago
    When people say “hype cycle” that can mean so many different things. That valuations are too high and many industry “promises” are wrong is maybe true but to me it’s irrelevant, this isn’t speculative, I think most posters who are positive on agents in these threads are talking about two things: current, existing tools, and the existing rate of progress. Check out e.g. Epoch.ai for great industry analyses. To compare AI to crypto is disingenuous, they are completely different and crypto is a technology that fundamentally makes no sense in a world where governments want to (and arguably should) control money supply. You may or may not agree on that take but AI is something that governments will push aggressively and see as crucial to national security/control. It means this is not going away

davnicwil 9mo ago

I would say while LLMs do improve productivity sometimes, I have to say I flatly cannot believe a claim (at least without direct demonstration or evidence) that one person is doing the work of 20 with them in december 2025 at least. I mean from the off, people were claiming 10x probably mostly because it's a nice round number, but those claims quickly fell out of the mainstream as people realised it's just not that big a multiplier in practice in the real world. I don't think we're seeing this in the market, anywhere. Something like 1 engineer doing the job of 20, what you're talking about is basically whole departments at mid sized companies compressing to one person. Think about that, that has implications for all the additional management staff on top of the 20 engineers too. It'd either be a complete restructure and rethink of the way software orgs work, or we'd be seeing just incredible, crazy deltas in output of software companies this year of the type that couldn't be ignored, they'd be impossible to not notice. This is just plainly not happening. Look, if it happens, it happens, 26, 27, 28 or 38. It'll be a cool and interesting new world if it does. But it's just... not happened or happening in 25.

emseetech 9mo ago
Could be speed/efficiency was the wrong dimension to optimize for and its leading the industry down a bad path. An LLM helps most with surface area. It expands the breadth of possibilities a developer can operate on.
EagnaIonat 9mo ago
> I mean from the off, people were claiming 10x probably mostly because it's a nice round number, Purely anecdotal, but I've seen that level of productivity from the vibe tools we have in my workplace. The main issue is that 1 engineer needs to have the skills of those 20 engineers so they can see where the vibe coding has gone wrong. Without that it falls apart.
CuriouslyC 9mo ago
It's entirely dependent on the type of code being written. For verbose, straightforward code with clear cut test scenarios, one agent can easily 24/7 the work of 20 FT engineers. This is a best case scenario. Your productivity boost will depend entirely on a combination of how much you can remove yourself from the loop (basically, the cost of validation per turn) and how amenable the task/your code is to agents (which determines your P(success)). Low P(success) isn't a problem if there's no engineer time cost to validation, the agent can just grind the problem out in the background, and obviously if P(success) is high the cost of validation isn't a big deal. The productivity killer is when P(success) is low and the cost of validation is high, these circumstances can push you into the red with agents very quickly. Thus the key to agents being a force multiplier is to focus on reducing validation costs, increasing P(success) and developing intuition relating to when to back off on pulling the slot machine in favor of more research. This is assuming you're speccing out what you're building so the agent doesn't make poor architectural/algorithmic choices that hamstring you down the line.

to11mtm 9mo ago

I'd be willing to give you access to the experiment I mentioned in a separate reply (have a github repo), as far as the output that you can get for a complex app buildout. Will admit It's not great (probably not even good) but it definitely has throughput despite my absolute lack of caring that much [0]. Once I get past a certain stage I am thinking of doing an A-B test where I take an earlier commit and try again while paying more attention... (But I at least want to get where there is a full suite of UOW cases before I do that, for comparison's sake.) > Those twenty engineers must not have produced much. I've been considered a 'very fast' engineer at most shops (e.x. at multiple shops, stories assigned to me would have a <1 multiplier for points[1]) 20 is a bit bloated, unless we are talking about WITCH tier. I definitely can get done in 2-3 hours what could take me a day. I say it that way because at best it's 1-2 hours but other times it's longer, some folks remember the 'best' rather than median. [0] - It started as 'prompt only', although after a certain point I did start being more aggressive with personal edits. [1] - IDK why they did it that way instead of capacity, OTOH that saved me when it came to being assigned Manual Testing stories...

imron 9mo ago
> Will admit It's not great (probably not even good) but it definitely has throughput Throughput without being good will just lead to more work down the line to correct the badness. It's like losing money on every sale but making up for it with volume.
notpachet 9mo ago
> Will admit It's not great (probably not even good) You lost me here. Come back when you're proud of it.

coderenegade 9mo ago

My experience is that you get out what you put in. If you have a well-defined foundation, AI can populate the stubs and get it 95% correct. Getting to that point can take a bit of thought, and AI can help with that, too, but if you lean on it too much, you'll get a mess. And of course, getting to the point where you can write a good foundation has always been the bulk of the work. I don't see that changing anytime soon.