>It’s already doing 100% of the coding. Way to go killing credibility straight out the gate. I could buy a high percentage for certain types of apps, but not 100%
Dev jobs are about to get a hard reset and nobody's ready
41–50 of 93 posts
Re: Dev jobs are about to get a hard reset and nobody's ready
#42Earlier quoted context omitted.
Agreed. Where's the code?
Where's the 10x, 20x, or whatever increases in profit from all the AI "productivity"? Typing is not the challenging aspect of writing code. Writing boilerplate faster isn't the super power that a lot of non-technical people seem to think it is.
(Or at the extreme end, this is what something like C++ templates were for).
Re: Dev jobs are about to get a hard reset and nobody's ready
#43Good luck trying to debug the code you've generated without knowing anything about what it does.
Is this really any different from debugging code that has been built by hundreds of people over 10s of years and you're just the latest schmuck working on it?
Re: Dev jobs are about to get a hard reset and nobody's ready
#44Earlier quoted context omitted.
I've seen a different kind of usage pattern recently, which is to find a problem that the LLM is good at, something which is very local in reasoning, and do it at big scale across the whole codebase.
Could you give an example? I like almost know what you mean, but not quite
Re: Dev jobs are about to get a hard reset and nobody's ready
#45Earlier quoted context omitted.
This is true. I've been using LLMs for code generation, and it does stuff I don't understand well. Also it makes mistakes, bugs. What I do find helpful is use it to ask for suggestions for how to achieve some result, then learn from the code it gives me. But even then, going back to this code later is difficult because I didn't go through that period of the failure research success learning loop.
Maybe at the high end of the talent but most of us are already there. I wouldn't admit this to my manager but a lot of the time if you made me explain what actually happens at the machine level, I have no idea.
Re: Dev jobs are about to get a hard reset and nobody's ready
#46It’s only a feeling, but I’d swear I’ve seen variations on this post across a half a dozen software-adjacent subreddits every day for the last month. The common denominator has always been “Paying $200 for Claude Max is a steal” with absolutely no evidence of what the author did with it. I honestly think we’re being played.
Supposing this is true, who is playing us and why?
Re: Dev jobs are about to get a hard reset and nobody's ready
#47Re: Dev jobs are about to get a hard reset and nobody's ready
#48Earlier quoted context omitted.
I've seen a different kind of usage pattern recently, which is to find a problem that the LLM is good at, something which is very local in reasoning, and do it at big scale across the whole codebase.
Could you give an example? I like almost know what you mean, but not quite
IME so far that's what it's best at. As long as there exists tests in the codebase that provide enough of the basic skeleton (i.e. if they already test part of a controller or code that interacts with a DB) to guess what's needed then it can do a decent job. It's still not perfect though and when it comes to inventing bespoke tests that are uniquely different from other tests it needs much more of a helping hand.
Re: Dev jobs are about to get a hard reset and nobody's ready
#49Yeah maybe. Talk is cheap, show me the code. > Last week, I did something I’ve put off for 10 years. Built a full production-grade desktop app in 1 week. Fully reviewed. Clean code. Launched builds on Launchpad. UI/UX and performance? Better than most market leaders. ONE. WEEK. I really wonder why people who write these things never actually show these apps they vibe coded in a week that are “better than most market…
Re: Dev jobs are about to get a hard reset and nobody's ready
#50Earlier quoted context omitted.
refactoring
LLMs are terrible at that in my experience. In what world is refactoring "very local in reasoning"? Switching libraries/frameworks or switching piecemeal to a new language for a codebase that's already well structured seems like it would be noticeably less costly though.