6 ms·

Revenge of the Junior Developer

68 points by ado__dev 2y ago

davydm 2y ago
the only good part was the joke about "vibecoding" (shudder what a stupid term) being like a fart and attracting flies... ok investors still, this "ai code tools will deprecate real programming" bullshit will one day be laughed at just like how most of us laugh at shitcoin maniacs it just takes a lot of people way too long to learn
- skydhash 2y ago
  Maybe there's a different universe out there, where the code you write is not expected to work, so you can poke the LLM for a whole day to see if it barfs something out. I spend much of the day reading and thinking and only a small portion actually writing code, because when I'm typing, I usually have a hypothetical solution that is 99% correct and I'm just bringing it to life. Or I'm refactoring. You can interrupt me at any time and I could give you the complete recipe of what I'm doing. Which is why I don't use LLMs, because it's actually twice the work for me. Typing out the specs, then verifying and editing the given result, while I could type the code in the first place. And they suck at prototyping. Sometimes I may want to leave something in the bare state where only one incantation works, because I'm not sure of the design yet, and have a TODO comment, but they go to generate a more complicated code. Which is a pain to refactor later.
  - wrs 2y ago
    I agree with the spirit of the argument, but I don’t think you’re taking into account the scale of “typing” we’re talking about now. For example, yesterday I needed a parser for a mini-language. I wrote a grammar — actually not even the formal grammar, just some examples — and what I wanted the AST to look like. I said “write the tokenizer”, and it did. I told it to tweak a few things and write tests. It did. I told it to “write a recursive descent parser”, and it did. Add tests and do some tweaks, done. The whole thing works and it took less than an hour. So yeah, I had to know I needed a parser, but at that point I could pretty much hand off the details. (Which I still checked over, so I’m not even in full vibe mode, guess.)
    - LPisGood 2y ago
      This is a cool use case that probably saved you some time, but writing a recursive descent parser is something freshman CS students do for a lab assignment. It isn’t exactly breaking new ground or doing anything you couldn’t find with a quick google search.
      - wrs 2y ago
        You want me to do a Google search for a parser for the language that I just invented? If you have a parser generator tool that can go from zero to parser based on a few examples rather than a grammar, I’d love to hear about it.
        kuschku 2y ago
        > If you have a parser generator tool that can go from zero to parser based on a few examples rather than a grammar, I’d love to hear about it. That's the part where the LLM would be useful. Turn the examples into a grammar, verify the grammar, and use a parser generator for the rest. You know the code does what it should and you get there in minutes.
        wrs 2y ago
        I'm pretty sure it could have done that equally easily, but this grammar is small enough that a parser generator is overkill. (I made that decision before I asked the LLM to write the parser.)
    - skydhash 2y ago
      Isn't that what tools like antlr [0], bison[1] do? [0]: https://www.antlr.org/ https://www.antlr.org/ [1]: https://www.gnu.org/software/bison/ https://www.gnu.org/software/bison/
      - jdlshore 2y ago
        They typically generate generic LALR parsers, not custom recursive descent parsers. I'm no expert, but my understanding is that custom recursive descent parsers have advantages in terms of readability and error message generation.
  - danielbln 2y ago
    I disagree, agentic coding is amazing for prototyping. It removes a ton of friction and inertia and allows me to try a bunch of ideas to see what works (from a delivery and/or UX perspective). Of course, you should have the systems thinking and experience in place to know what it is you're doing with it at any given point , but for demos and prototypes it has been an absolute boon. Generally, you wouldn't type out the spec either, either you provide an existing spec to the model (in form of white board notes, meeting notes, etc.) or you iterate conversationally until you arrive at an initial implementation plan. It's a different way of working for sure, and it has distinct draw backs and requires different mental modes depending if you're doing green field, demo/prototype, existing large app feature development etc. but it's been a massive productivity enhancement, especially when tackling multiple projects in quick succession.
    - hombre_fatal 2y ago
      A good example of this at the extreme is game design. When you're making a game, it's really expensive to try out different ideas, like a few different implementations of a mechanic. It could be hours of work to make a change. You tend to have to do a lot of thinking to tweak a mechanic in a fundamental way just to see what it feels like, knowing that you're probably going to throw it away. LLMs are really good at this. Make a git branch, ask Claude Code to tweak the physics so that it does X, see what it feels like. Rollback the change or continue tweaking. Same with branching the UI to see what a different idea would feel like. Simple changes to explain could result in hours of refactoring UI code (chore work) just to see if you like the result. Or just ask the LLM to do it, see what it feels like, roll it back.
      - bluefirebrand 2y ago
        > LLMs are really good at this. Make a git branch, ask Claude Code to tweak the physics so that it does X, see what it feels like How do you verify that Claude did what you wanted? Maybe more importantly, how do you verify that Claude didn't make a change that you didn't want? Trying to verify the code changes just by testing the running project seems incredibly careless
- null_name 2y ago
  Yeah, call me a cynic or conservative or whatever - I'll believe it when I see it. I give very little weight to predictions about the future from AI shills, especially when they include some variant of "we're 90% there already" or "an exponential shift is imminent, if things keep improving at this rate, which they Will." Opinion discarded, create your thing and come back if/when it works. Everything is shifting so fast right now that it hardly matters anyways. Whatever I spend time learning will be outdated in a few years (when things are predicted to get good). It does matter if you're trying to sell AI products, though. Then you gotta convince people they're missing out, their livelihood is at stake if they don't use your new thing now now now.
Teha189 2y ago
[dead]
djha-skin 2y ago
> I have bad news: Code completions were very popular a year ago, a time that now feels like a distant prequel. But they are now the AI equivalent of “dead man walking.” I disagree. I view this as a "machine guns versus heat sinking missiles from the 70s" dichotomy. Sure, using missiles is faster. However, sometimes you're too close for missiles. Also, machine gun rounds are way cheaper than missiles. However, when they first came out, missiles were viewed as the future. For a while, fighter jets were made without machine guns, but they added them back later because they decided they needed both. Sometimes I find I want to drill down and edit what Claude generated. In that case, copilot is still really nice. With regard to ai assisted coding: the more you know what you're doing, the more you know the code base, the better result you'll get. To me it feels like a rototiller or some other power tool. It plows soil way faster than you can and is self propelled, but it isn't self directed. Using it still requires planning and it's expensive to run. While using the tool, you must micromanage its direction, constantly giving it haptic feedback from the hands, or it goes off course. A rototiller could be compared to a hired hand plowing himself, I guess, but there's way less micromanagement with a hired hand vs a rototiller. Kind of like horses and cars. Horses can get you home if you're drunk. Cars can't. The proper use of AI agentic tools is like operating heavy machinery. Juniors can really hurt themselves with it but seniors can do a lot of good. The analogy goes further: sometimes you need to get out of the backhoe and dig with smaller tools like jackhammers or just shovels. The jackhammer is like copilot -- a mid-grade power tool -- and Claude code is like the backhoe. Clunky, crude, but can get massive amounts done quickly, if that's what's needed.
- skydhash 2y ago
  > Clunky, crude, but can get massive amounts done quickly, if that's what's needed. You know what's quicker in your analogy? A spell. Or in the coding world. Template, snippets, code generators, framework, and metaprogramming. Where you abstract all the boilerplate behind a few commands. You already know the blast radius of your brute modification tools, so you no longer have to micromanage them. And it's reliable
tyleo 2y ago
I love how new technology becomes like religion. It develops both cult followers and critics. In that lens think the AI cult is more right than the Crypto cult. At least I can use it to do something tangible right now while crypto is still pretty useless after many years. In some sense I think these technologies need the cults and the critics though. It’s good to have people push new things forwards even if everyone isn’t along for the ride. It’s also good to have a counter side poke holes. I think the world is better with both optimists charting new paths forwards and pessimists making sure they don’t walk right off a cliff.
- LightHugger 2y ago
  Cryptocurrency allows people who are otherwise limited by draconian payment platform limitations, puritanical moralists who own credit card companies and such to buy and sell things online without being stopped. It's obviously not a good system but it provides a high effort release valve, a fallback mechanism that hopefully will undermine some of these draconian measures. Lots of people have been helped by the existence of cryptocurrency because of this, especially since lately a lot of bad actors control payment platforms and often just shut down businesses on whims. Whether more have been helped or hurt is debatable but it certainly has a tangible, if niche, use case with real value. It certainly has no value as a store of value, though.
  - glitchc 2y ago
    Evidence suggests it's the exact opposite. The only thing crypto has really been good for is a store of value. Sure, it's a volatile commodity, but over any 5 year average window, Bitcoin definitely beats inflation. That makes it a safe store of value.
    - jdlshore 2y ago
      Huh. While I agree that Bitcoin specifically has been a successful speculative investment in the past, "a safe store of value" is a massive stretch. It's a safe store of value in the same way a S&P 500 index fund is, except more volatile. What's that phrase... "Past performance is not indicative of future gains?"
nickysielicki 2y ago
I’m usually one of the people complaining about hype cycles, and it’s usually been correct to be pessimistic about them. But in this particular case I have to think a lot of people just haven’t tried it in its best form. No, not a local model on your MacBook. No, not the web interface on the free plan. Go lay down $300 into API credits, spend a weekend (or maybe two) fully setting up aider, really give it a shot. It’s ultimately a pretty small amount of money when it comes to figuring out whether the people who are telling you there’s an existential risk to your livelihood on the horizon are onto something, don’t you think?
- LoganDark 2y ago
  $300? That much sounds like it would last a year. You don't need to spend anywhere near $300 just to try things out
  - danielbln 2y ago
    We're using Cline, and it's very easy to blow through $20-40 if you get going. The value proposition is absolutely there so we eat the cost, but OP is correct in that agentic coding eats tokens like there's no tomorrow.
  - nickysielicki 2y ago
    RTFA, agents churn through credits. Further enforcing my belief that the vast majority of people have not actually tried it yet.
    - LoganDark 2y ago
      > RTFA, agents churn through credits. I literally use Claude Code as part of my job, so either the "FA" is wrong, or my costs are only low because work just happens to have a codebase that reduces costs (lol)
  - hombre_fatal 2y ago
    I burned through $50 credits in a sitting the first time I used Claude Code to see what I could vibe-code from scratch. You're pushing whole files of tokens through it every time you interact with it.
disambiguation 2y ago
Everyone: telling me how great AI is. No one: making anything great with AI. Sourcegraph: an AI company, routinely promoting their LLM-optimism blogposts to HN, perpetuating the hype cycle their business model depends on.
- null_name 2y ago
  This sapling is twice as large as it was a week ago, which was twice again as large as it was the week before. Why, at this rate, it'll be bigger than the whole world in but a month.
  - bayindirh 2y ago
    I remembered the dialogue from the movie Snatch: T: What's happening with this sausages, Charlie? C: 2 minutes, Turkish. -- 5 Minutes later --- T: How long for the sausages? C: 5 minutes, Turkish. T: It was 2 minutes, 5 minutes ago. I don't know why I remembered it. Is it AI, or self driving cars, or both. Huh.
    - jcgrillo 2y ago
      Don't forget the electric air taxis!
      - edoceo 2y ago
        Drone-bot delivering my new dishwasher-top-rack-rails today; waiting 4 days for a human; SMH
        DonHopkins 2y ago
        Where's my TacoCopter??! https://tacocopter.com/ https://tacocopter.com/
    - fragmede 2y ago
      self driving cars are here, just unevenly distributed. Waymo operates in several cities already, providing millions of rides to people. Just because you haven't seen them doesn't mean they don't exist.
xyzzy9563 2y ago
I think a lot of people are going to be surprised at how fast "vibe coding" with agents replaces a lot of traditional software engineering. Especially for non-critical software, but eventually where safety matters too since AI can generate tons of test cases.
- LPisGood 2y ago
  There is so much hype around agents but I am still thoroughly unimpressed. They’re fine at basic tasks, but nothing more.
- kolektiv 2y ago
  And without any traditional software engineers, who's going to check that those test cases actually do anything useful and verify the important properties of the system? It doesn't matter how many unit tests your Therac-25 has if none of them test the thing that matters.
  - xyzzy9563 2y ago
    Well theoretically you can also do E2E testing where an AI agent also clicks around a user-interface and takes screenshots, which are then fed back into it.
    - saint_yossarian 2y ago
      That's just another type of test, the question was who's going to check that the tests are actually testing the correct things. Maybe look up the Therac-25 that was mentioned.
jsdalton 2y ago
Much of this post was spot on — but the blind spots are highly problematic. In this agentic AI utopia of six months from now: * Why would developers — especially junior developers — be assigned oversight of the AI clusters? This sounds more like an engineering management role that’s very hands on. This makes sense because the skill set required for the desired outcomes is no longer “how do I write code that makes these computers work correcty” and rather “what’s the best solution for our customers and/or business in this problem space.” Higher order thinking, expertise in the domain, and dare I say wisdom are more valuable than knowing the intricacies of React hooks. * Economically speaking what are all these companies doing with all this code? Code is still a liability, not an asset. Mere humans writing code faster than they comprehend the problem space is already a problem and the brave new world described here makes this problem worse not better. In particular here, there’s no longer an economic “moat” to build a business off of if everything can be “solved” in a day with a swarm of AI agents. * I wonder about the ongoing term scaling of these approaches. The trade off seems to be extremely fast productivity at the start which falls off a cliff as the product matures and grows. It’s like a building that can be constructed in a day up to a few floors but quickly hits an upper limit as your ability to build _on top of_ the foundational layer of poorly understood garbage. * Heaven help the ops / infrastructure folks who have to run this garbage and deal with issues at scale. Btw I don’t reject everything in this post — these tools are indeed powerful and compelling and the trendlines are undeniable.
haburka 2y ago
One of the funniest things I’ve read in a while. Also full of some truths. I think learning how to use AI will become a core part of being a dev but I seriously doubt they’ll have anywhere near the competency of solving a problem that a junior engineer has. They can certainly write code like one though. I really recommend this to anyone reading - if you haven’t tried using cursor or copilot, check them out. It makes writing code less tedious.
mwkaufma 2y ago
Nothing smells like bullshit quite like a data-less "graph"
monsieurbanana 2y ago
Even if I would agree with everything the article says, I have no idea how the author gets to the conclusion that junior developers will prevail because they are faster at adopting LLMs. Didn't he just made a point about how fast the situation is evolving? I had some FOMO about ai last year, not anymore. I don't care that I don't have time to fully explore the current LLM state of the art, because in a month it will be obsolete. I'm happy waiting until it settles down. And if their scenario ends up happening, and you can basically multiply a dev's productivity by N by paying N x K dollarinos, why would you chose a junior dev? It's cheaper, but sometimes a junior dev doesn't take longer to arrive at a solution, it never does (same for senior devs, don't get me wrong, but it happens less often).
- bryanlarsen 2y ago
  It's a counterpoint to Yegge's original post https://sourcegraph.com/blog/the-death-of-the-junior-developer https://sourcegraph.com/blog/the-death-of-the-junior-develop... And it's not saying his original post is wrong, they should be taken together. He's saying those who adapt to the new paradigm will "win", whether senior or junior.
shove 2y ago
I read the whole thing, top to bottom, and by the 80% mark, I still wasn’t sure whether the piece was written in earnest or the sharpest piece of satire I’ve seen in a decade.
- felideon 2y ago
  On a corporate blog, though, for a product that is competing in this space?
  - shove 2y ago
    That was the only thing that conclusively gave it away!
DanHulton 2y ago
As always, citation needed. (Also, grain of salt required, because this is a blatant marketing post.) Look, I've been hearing "the models will get better and make these core problems go away" since it become common to talk about "the models" at all. Maybe they will some day! But also, and critically, maybe they won't. You also have to consider the future where some companies spend an additional $50-100k per developer and they DON'T see any of this supposed increase in performance, if these "trust me, it'll happen this time" promises don't come true. This is the kind of bet that can CRATER companies, so it's not surprising to see some hesitation here, a desire to see if the football will be again yanked away. Plus, and I believe most damningly, this article appears to be engaging in the classic technocratic failure mode: mistaking social problems for technical ones. Obviously, yes, developers engage in solving technical problems, but that is not all they do, and at the higher level, that becomes the least of what they do. More and more, a good developer ensures that they are solving the RIGHT problem in the RIGHT WAY. They're consulting with managers, (ideally) users, other teams, a whole host of people to ensure the right thing is built at the right time with the right features and that the right sacrifices are being made. LLMs are classically bad at this. The author dismissively calls this "getting stuck", and handwaves the importance of it away, saying that the engineer will be able to unstuck the model at first (which, if we're putting armies of "vibe coding" junior engineers in charge of the LLMS, who've not had time enough in their career to develop this skill, HOW?), and then makes the classic claim "but the models will get better", and predicts the models will eventually be able to do it (which, if this is an intractable problem with LLMS -- and so far evidence has been leaning this way -- again, HOW?). Forgive that apalling grammar. I am het up. But note well what I'm doing: I'm asking "should we even be doing this?" Which is something these models a) will have to do well to accomplish what the author insinuates they will, and b) have been persistently terrible at. I'm going to remain skeptical for now, since it seems that's my one remaining superpower versus these LLMs, and I guess I'm going to need to keep that skill sharp if I want to avoid the breadline in this author's future. =)
sfjailbird 2y ago
LOL, pretty good, he had me going a few times. I'm sure a surprising amount of people will actually take this seriously, showing how ludicrous the situation is right now.
lcnPylGDnU4H9OF 2y ago
> We think the flat hiring right now is just companies signalling that they don’t know what to do yet. The whole article seems to be written disingenuously for the junior developer audience but this one kinda irked me: the flat hiring is because interest rates are high and has nothing to do with companies figuring out what to do with vibe coding. On topic, nothing in this article suggests anything fundamentally useful about vibe coding other than it being an easier way to start for juniors and entry-levels. If you are a junior, go ahead and keep vibe coding but also do your best to understand the code you’re given. I strongly suspect that will (continue to) be something that makes people stand out.
mdaniel 2y ago
I still have to get used to the fact that a (sourcegraph.com) /item may contain (steve-yegge.blogspot.com) content
DonHopkins 2y ago
Is it just me, or has anyone else noticed that: 1) Cursor has been crashing several times an hour for me recently. 2) Cursor seems to ignore .cursorrules files. I'm using the json format that's supposed to let you filter on file name patterns (although how that works for cross-cutting agent stuff I don't know). 3) Cursor is obsessed with making sketchy iffy defensive code checking for the most recent symptom and trying to guess and shart its way out of it instead of addressing the real problem? And it's extremely hard to talk it out of doing that, I have to keep reminding it and admonishing it to cut it the fuck out, fail instead of mitigate, address the root cause not the symptoms, and stop trying to close the barn door after all the horses have escaped. It's as of it was only trained on Stack Overflow and PHP manual page discussions.
6510 2y ago
I had this rather comical picture where developers finally get to experience what it is like to have someone write software for you. You get sort of what you asked for but it is obviously wrong to even the most novice user. You then change the requirements and get something entirely different but equally wrong or worse... and a new invoice. hahaha It gets more funny the more I think about it.
pluto_modadic 2y ago
I'm going to guess this is satire unless sourcegraph only has "junior" developers, on "junior" pay. The article tells me something unfortunate about the appropriateness about ever buying software from this person; based on how they write.
donotjoinsour 2y ago
[dead]

68 points by ado__dev 2y ago

the only good part was the joke about "vibecoding" (shudder what a stupid term) being like a fart and attracting flies... ok investors still, this "ai code tools will deprecate real programming" bullshit will one day be laughed at just like how most of us laugh at shitcoin maniacs it just takes a lot of people way too long to learn

skydhash 2y ago
Maybe there's a different universe out there, where the code you write is not expected to work, so you can poke the LLM for a whole day to see if it barfs something out. I spend much of the day reading and thinking and only a small portion actually writing code, because when I'm typing, I usually have a hypothetical solution that is 99% correct and I'm just bringing it to life. Or I'm refactoring. You can interrupt me at any time and I could give you the complete recipe of what I'm doing. Which is why I don't use LLMs, because it's actually twice the work for me. Typing out the specs, then verifying and editing the given result, while I could type the code in the first place. And they suck at prototyping. Sometimes I may want to leave something in the bare state where only one incantation works, because I'm not sure of the design yet, and have a TODO comment, but they go to generate a more complicated code. Which is a pain to refactor later.
- wrs 2y ago
  I agree with the spirit of the argument, but I don’t think you’re taking into account the scale of “typing” we’re talking about now. For example, yesterday I needed a parser for a mini-language. I wrote a grammar — actually not even the formal grammar, just some examples — and what I wanted the AST to look like. I said “write the tokenizer”, and it did. I told it to tweak a few things and write tests. It did. I told it to “write a recursive descent parser”, and it did. Add tests and do some tweaks, done. The whole thing works and it took less than an hour. So yeah, I had to know I needed a parser, but at that point I could pretty much hand off the details. (Which I still checked over, so I’m not even in full vibe mode, guess.)
  - LPisGood 2y ago
    This is a cool use case that probably saved you some time, but writing a recursive descent parser is something freshman CS students do for a lab assignment. It isn’t exactly breaking new ground or doing anything you couldn’t find with a quick google search.
    - wrs 2y ago
      You want me to do a Google search for a parser for the language that I just invented? If you have a parser generator tool that can go from zero to parser based on a few examples rather than a grammar, I’d love to hear about it.
      - kuschku 2y ago
        > If you have a parser generator tool that can go from zero to parser based on a few examples rather than a grammar, I’d love to hear about it. That's the part where the LLM would be useful. Turn the examples into a grammar, verify the grammar, and use a parser generator for the rest. You know the code does what it should and you get there in minutes.
        wrs 2y ago
        I'm pretty sure it could have done that equally easily, but this grammar is small enough that a parser generator is overkill. (I made that decision before I asked the LLM to write the parser.)
  - skydhash 2y ago
    Isn't that what tools like antlr [0], bison[1] do? [0]: https://www.antlr.org/ https://www.antlr.org/ [1]: https://www.gnu.org/software/bison/ https://www.gnu.org/software/bison/
    - jdlshore 2y ago
      They typically generate generic LALR parsers, not custom recursive descent parsers. I'm no expert, but my understanding is that custom recursive descent parsers have advantages in terms of readability and error message generation.
- danielbln 2y ago
  I disagree, agentic coding is amazing for prototyping. It removes a ton of friction and inertia and allows me to try a bunch of ideas to see what works (from a delivery and/or UX perspective). Of course, you should have the systems thinking and experience in place to know what it is you're doing with it at any given point , but for demos and prototypes it has been an absolute boon. Generally, you wouldn't type out the spec either, either you provide an existing spec to the model (in form of white board notes, meeting notes, etc.) or you iterate conversationally until you arrive at an initial implementation plan. It's a different way of working for sure, and it has distinct draw backs and requires different mental modes depending if you're doing green field, demo/prototype, existing large app feature development etc. but it's been a massive productivity enhancement, especially when tackling multiple projects in quick succession.
  - hombre_fatal 2y ago
    A good example of this at the extreme is game design. When you're making a game, it's really expensive to try out different ideas, like a few different implementations of a mechanic. It could be hours of work to make a change. You tend to have to do a lot of thinking to tweak a mechanic in a fundamental way just to see what it feels like, knowing that you're probably going to throw it away. LLMs are really good at this. Make a git branch, ask Claude Code to tweak the physics so that it does X, see what it feels like. Rollback the change or continue tweaking. Same with branching the UI to see what a different idea would feel like. Simple changes to explain could result in hours of refactoring UI code (chore work) just to see if you like the result. Or just ask the LLM to do it, see what it feels like, roll it back.
    - bluefirebrand 2y ago
      > LLMs are really good at this. Make a git branch, ask Claude Code to tweak the physics so that it does X, see what it feels like How do you verify that Claude did what you wanted? Maybe more importantly, how do you verify that Claude didn't make a change that you didn't want? Trying to verify the code changes just by testing the running project seems incredibly careless
null_name 2y ago
Yeah, call me a cynic or conservative or whatever - I'll believe it when I see it. I give very little weight to predictions about the future from AI shills, especially when they include some variant of "we're 90% there already" or "an exponential shift is imminent, if things keep improving at this rate, which they Will." Opinion discarded, create your thing and come back if/when it works. Everything is shifting so fast right now that it hardly matters anyways. Whatever I spend time learning will be outdated in a few years (when things are predicted to get good). It does matter if you're trying to sell AI products, though. Then you gotta convince people they're missing out, their livelihood is at stake if they don't use your new thing now now now.

Teha189 2y ago

[dead]

djha-skin 2y ago

> I have bad news: Code completions were very popular a year ago, a time that now feels like a distant prequel. But they are now the AI equivalent of “dead man walking.” I disagree. I view this as a "machine guns versus heat sinking missiles from the 70s" dichotomy. Sure, using missiles is faster. However, sometimes you're too close for missiles. Also, machine gun rounds are way cheaper than missiles. However, when they first came out, missiles were viewed as the future. For a while, fighter jets were made without machine guns, but they added them back later because they decided they needed both. Sometimes I find I want to drill down and edit what Claude generated. In that case, copilot is still really nice. With regard to ai assisted coding: the more you know what you're doing, the more you know the code base, the better result you'll get. To me it feels like a rototiller or some other power tool. It plows soil way faster than you can and is self propelled, but it isn't self directed. Using it still requires planning and it's expensive to run. While using the tool, you must micromanage its direction, constantly giving it haptic feedback from the hands, or it goes off course. A rototiller could be compared to a hired hand plowing himself, I guess, but there's way less micromanagement with a hired hand vs a rototiller. Kind of like horses and cars. Horses can get you home if you're drunk. Cars can't. The proper use of AI agentic tools is like operating heavy machinery. Juniors can really hurt themselves with it but seniors can do a lot of good. The analogy goes further: sometimes you need to get out of the backhoe and dig with smaller tools like jackhammers or just shovels. The jackhammer is like copilot -- a mid-grade power tool -- and Claude code is like the backhoe. Clunky, crude, but can get massive amounts done quickly, if that's what's needed.

skydhash 2y ago
> Clunky, crude, but can get massive amounts done quickly, if that's what's needed. You know what's quicker in your analogy? A spell. Or in the coding world. Template, snippets, code generators, framework, and metaprogramming. Where you abstract all the boilerplate behind a few commands. You already know the blast radius of your brute modification tools, so you no longer have to micromanage them. And it's reliable

tyleo 2y ago

I love how new technology becomes like religion. It develops both cult followers and critics. In that lens think the AI cult is more right than the Crypto cult. At least I can use it to do something tangible right now while crypto is still pretty useless after many years. In some sense I think these technologies need the cults and the critics though. It’s good to have people push new things forwards even if everyone isn’t along for the ride. It’s also good to have a counter side poke holes. I think the world is better with both optimists charting new paths forwards and pessimists making sure they don’t walk right off a cliff.

LightHugger 2y ago
Cryptocurrency allows people who are otherwise limited by draconian payment platform limitations, puritanical moralists who own credit card companies and such to buy and sell things online without being stopped. It's obviously not a good system but it provides a high effort release valve, a fallback mechanism that hopefully will undermine some of these draconian measures. Lots of people have been helped by the existence of cryptocurrency because of this, especially since lately a lot of bad actors control payment platforms and often just shut down businesses on whims. Whether more have been helped or hurt is debatable but it certainly has a tangible, if niche, use case with real value. It certainly has no value as a store of value, though.
- glitchc 2y ago
  Evidence suggests it's the exact opposite. The only thing crypto has really been good for is a store of value. Sure, it's a volatile commodity, but over any 5 year average window, Bitcoin definitely beats inflation. That makes it a safe store of value.
  - jdlshore 2y ago
    Huh. While I agree that Bitcoin specifically has been a successful speculative investment in the past, "a safe store of value" is a massive stretch. It's a safe store of value in the same way a S&P 500 index fund is, except more volatile. What's that phrase... "Past performance is not indicative of future gains?"

nickysielicki 2y ago

I’m usually one of the people complaining about hype cycles, and it’s usually been correct to be pessimistic about them. But in this particular case I have to think a lot of people just haven’t tried it in its best form. No, not a local model on your MacBook. No, not the web interface on the free plan. Go lay down $300 into API credits, spend a weekend (or maybe two) fully setting up aider, really give it a shot. It’s ultimately a pretty small amount of money when it comes to figuring out whether the people who are telling you there’s an existential risk to your livelihood on the horizon are onto something, don’t you think?

LoganDark 2y ago
$300? That much sounds like it would last a year. You don't need to spend anywhere near $300 just to try things out
- danielbln 2y ago
  We're using Cline, and it's very easy to blow through $20-40 if you get going. The value proposition is absolutely there so we eat the cost, but OP is correct in that agentic coding eats tokens like there's no tomorrow.
- nickysielicki 2y ago
  RTFA, agents churn through credits. Further enforcing my belief that the vast majority of people have not actually tried it yet.
  - LoganDark 2y ago
    > RTFA, agents churn through credits. I literally use Claude Code as part of my job, so either the "FA" is wrong, or my costs are only low because work just happens to have a codebase that reduces costs (lol)
- hombre_fatal 2y ago
  I burned through $50 credits in a sitting the first time I used Claude Code to see what I could vibe-code from scratch. You're pushing whole files of tokens through it every time you interact with it.

disambiguation 2y ago

Everyone: telling me how great AI is. No one: making anything great with AI. Sourcegraph: an AI company, routinely promoting their LLM-optimism blogposts to HN, perpetuating the hype cycle their business model depends on.

null_name 2y ago
This sapling is twice as large as it was a week ago, which was twice again as large as it was the week before. Why, at this rate, it'll be bigger than the whole world in but a month.
- bayindirh 2y ago
  I remembered the dialogue from the movie Snatch: T: What's happening with this sausages, Charlie? C: 2 minutes, Turkish. -- 5 Minutes later --- T: How long for the sausages? C: 5 minutes, Turkish. T: It was 2 minutes, 5 minutes ago. I don't know why I remembered it. Is it AI, or self driving cars, or both. Huh.
  - jcgrillo 2y ago
    Don't forget the electric air taxis!
    - edoceo 2y ago
      Drone-bot delivering my new dishwasher-top-rack-rails today; waiting 4 days for a human; SMH
      - DonHopkins 2y ago
        Where's my TacoCopter??! https://tacocopter.com/ https://tacocopter.com/
  - fragmede 2y ago
    self driving cars are here, just unevenly distributed. Waymo operates in several cities already, providing millions of rides to people. Just because you haven't seen them doesn't mean they don't exist.

xyzzy9563 2y ago

I think a lot of people are going to be surprised at how fast "vibe coding" with agents replaces a lot of traditional software engineering. Especially for non-critical software, but eventually where safety matters too since AI can generate tons of test cases.

LPisGood 2y ago
There is so much hype around agents but I am still thoroughly unimpressed. They’re fine at basic tasks, but nothing more.
kolektiv 2y ago
And without any traditional software engineers, who's going to check that those test cases actually do anything useful and verify the important properties of the system? It doesn't matter how many unit tests your Therac-25 has if none of them test the thing that matters.
- xyzzy9563 2y ago
  Well theoretically you can also do E2E testing where an AI agent also clicks around a user-interface and takes screenshots, which are then fed back into it.
  - saint_yossarian 2y ago
    That's just another type of test, the question was who's going to check that the tests are actually testing the correct things. Maybe look up the Therac-25 that was mentioned.

jsdalton 2y ago

Much of this post was spot on — but the blind spots are highly problematic. In this agentic AI utopia of six months from now: * Why would developers — especially junior developers — be assigned oversight of the AI clusters? This sounds more like an engineering management role that’s very hands on. This makes sense because the skill set required for the desired outcomes is no longer “how do I write code that makes these computers work correcty” and rather “what’s the best solution for our customers and/or business in this problem space.” Higher order thinking, expertise in the domain, and dare I say wisdom are more valuable than knowing the intricacies of React hooks. * Economically speaking what are all these companies doing with all this code? Code is still a liability, not an asset. Mere humans writing code faster than they comprehend the problem space is already a problem and the brave new world described here makes this problem worse not better. In particular here, there’s no longer an economic “moat” to build a business off of if everything can be “solved” in a day with a swarm of AI agents. * I wonder about the ongoing term scaling of these approaches. The trade off seems to be extremely fast productivity at the start which falls off a cliff as the product matures and grows. It’s like a building that can be constructed in a day up to a few floors but quickly hits an upper limit as your ability to build _on top of_ the foundational layer of poorly understood garbage. * Heaven help the ops / infrastructure folks who have to run this garbage and deal with issues at scale. Btw I don’t reject everything in this post — these tools are indeed powerful and compelling and the trendlines are undeniable.

haburka 2y ago

One of the funniest things I’ve read in a while. Also full of some truths. I think learning how to use AI will become a core part of being a dev but I seriously doubt they’ll have anywhere near the competency of solving a problem that a junior engineer has. They can certainly write code like one though. I really recommend this to anyone reading - if you haven’t tried using cursor or copilot, check them out. It makes writing code less tedious.

mwkaufma 2y ago

Nothing smells like bullshit quite like a data-less "graph"

monsieurbanana 2y ago

Even if I would agree with everything the article says, I have no idea how the author gets to the conclusion that junior developers will prevail because they are faster at adopting LLMs. Didn't he just made a point about how fast the situation is evolving? I had some FOMO about ai last year, not anymore. I don't care that I don't have time to fully explore the current LLM state of the art, because in a month it will be obsolete. I'm happy waiting until it settles down. And if their scenario ends up happening, and you can basically multiply a dev's productivity by N by paying N x K dollarinos, why would you chose a junior dev? It's cheaper, but sometimes a junior dev doesn't take longer to arrive at a solution, it never does (same for senior devs, don't get me wrong, but it happens less often).

bryanlarsen 2y ago
It's a counterpoint to Yegge's original post https://sourcegraph.com/blog/the-death-of-the-junior-developer https://sourcegraph.com/blog/the-death-of-the-junior-develop... And it's not saying his original post is wrong, they should be taken together. He's saying those who adapt to the new paradigm will "win", whether senior or junior.

shove 2y ago

I read the whole thing, top to bottom, and by the 80% mark, I still wasn’t sure whether the piece was written in earnest or the sharpest piece of satire I’ve seen in a decade.

felideon 2y ago
On a corporate blog, though, for a product that is competing in this space?
- shove 2y ago
  That was the only thing that conclusively gave it away!

DanHulton 2y ago

As always, citation needed. (Also, grain of salt required, because this is a blatant marketing post.) Look, I've been hearing "the models will get better and make these core problems go away" since it become common to talk about "the models" at all. Maybe they will some day! But also, and critically, maybe they won't. You also have to consider the future where some companies spend an additional $50-100k per developer and they DON'T see any of this supposed increase in performance, if these "trust me, it'll happen this time" promises don't come true. This is the kind of bet that can CRATER companies, so it's not surprising to see some hesitation here, a desire to see if the football will be again yanked away. Plus, and I believe most damningly, this article appears to be engaging in the classic technocratic failure mode: mistaking social problems for technical ones. Obviously, yes, developers engage in solving technical problems, but that is not all they do, and at the higher level, that becomes the least of what they do. More and more, a good developer ensures that they are solving the RIGHT problem in the RIGHT WAY. They're consulting with managers, (ideally) users, other teams, a whole host of people to ensure the right thing is built at the right time with the right features and that the right sacrifices are being made. LLMs are classically bad at this. The author dismissively calls this "getting stuck", and handwaves the importance of it away, saying that the engineer will be able to unstuck the model at first (which, if we're putting armies of "vibe coding" junior engineers in charge of the LLMS, who've not had time enough in their career to develop this skill, HOW?), and then makes the classic claim "but the models will get better", and predicts the models will eventually be able to do it (which, if this is an intractable problem with LLMS -- and so far evidence has been leaning this way -- again, HOW?). Forgive that apalling grammar. I am het up. But note well what I'm doing: I'm asking "should we even be doing this?" Which is something these models a) will have to do well to accomplish what the author insinuates they will, and b) have been persistently terrible at. I'm going to remain skeptical for now, since it seems that's my one remaining superpower versus these LLMs, and I guess I'm going to need to keep that skill sharp if I want to avoid the breadline in this author's future. =)

sfjailbird 2y ago

LOL, pretty good, he had me going a few times. I'm sure a surprising amount of people will actually take this seriously, showing how ludicrous the situation is right now.

lcnPylGDnU4H9OF 2y ago

> We think the flat hiring right now is just companies signalling that they don’t know what to do yet. The whole article seems to be written disingenuously for the junior developer audience but this one kinda irked me: the flat hiring is because interest rates are high and has nothing to do with companies figuring out what to do with vibe coding. On topic, nothing in this article suggests anything fundamentally useful about vibe coding other than it being an easier way to start for juniors and entry-levels. If you are a junior, go ahead and keep vibe coding but also do your best to understand the code you’re given. I strongly suspect that will (continue to) be something that makes people stand out.

mdaniel 2y ago

I still have to get used to the fact that a (sourcegraph.com) /item may contain (steve-yegge.blogspot.com) content

DonHopkins 2y ago

Is it just me, or has anyone else noticed that: 1) Cursor has been crashing several times an hour for me recently. 2) Cursor seems to ignore .cursorrules files. I'm using the json format that's supposed to let you filter on file name patterns (although how that works for cross-cutting agent stuff I don't know). 3) Cursor is obsessed with making sketchy iffy defensive code checking for the most recent symptom and trying to guess and shart its way out of it instead of addressing the real problem? And it's extremely hard to talk it out of doing that, I have to keep reminding it and admonishing it to cut it the fuck out, fail instead of mitigate, address the root cause not the symptoms, and stop trying to close the barn door after all the horses have escaped. It's as of it was only trained on Stack Overflow and PHP manual page discussions.

6510 2y ago

I had this rather comical picture where developers finally get to experience what it is like to have someone write software for you. You get sort of what you asked for but it is obviously wrong to even the most novice user. You then change the requirements and get something entirely different but equally wrong or worse... and a new invoice. hahaha It gets more funny the more I think about it.

pluto_modadic 2y ago

I'm going to guess this is satire unless sourcegraph only has "junior" developers, on "junior" pay. The article tells me something unfortunate about the appropriateness about ever buying software from this person; based on how they write.

donotjoinsour 2y ago

[dead]