10 ms·

If you are a Senior Developer, who is comfortable giving a Junior tips, and then guiding them to fixing them (or just stepping in for a brief moment and writing

If you are a Senior Developer, who is comfortable giving a Junior tips, and then guiding them to fixing them (or just stepping in for a brief moment and writing where they missed something) this is for you. I'm hearing from Senior devs all over thought, that Junior developers are just garbage at it. They product slow, insecure, or just outright awful code with it, and then they PR the code they don't even understand. For me the sweet spot is for boilerplate (give me a blueprint of a class based on a description), translate a JSON for me into a class, or into some other format. Also "what's wrong with this code? How would a Staff Level Engineer white it?" those questions are also useful. I've found bugs before hitting debug by asking what's wrong with the code I just pounded on my keyboard by hand.

channel_t 1y ago
Yes, can confirm that as a senior developer who has needed to spend huge amounts of time reviewing junior code from off-shore contractors with very detailed and explicit instructions, dabbling in agentic LLM coding tools like Claude Code has felt like like a gift from heaven. I also have concerns about said junior developers wielding such tools, because yes, without being able to supply the right kind of context and being able to understand the difference between a good solution and a bad solution, they will produce tons of awful, but technically working code.
- awesome_dude 1y ago
  This. I've got myself in a PILE of trouble when trying to use LLMs with languages/technologies I am unfamiliar with (React, don't judge me). But with something that I am familiar with (say Go, or Python) LLMs have improved my velocity massively, with the caveat that I have had to explicitly tell the LLM when it is producing something that I know that I don't want (me arguing with an LLM was an experience too!)
- willsmith72 1y ago
  Totally agree with the off-shore component of this. I'm already going to have to break a task down into clear detail and resolve any anticipated blocker myself upfront to avoid multi-timezone multi-day back and forth. Now that I'm practiced at that, the off-shored part is no longer valuable
  - sitkack 1y ago
    The unemployment in India is going to be catastrophic. Geopolitical.
    - vaidhy 1y ago
      You know senior developers can also be off-shored, right?
      - benreesman 1y ago
        Blowing away the junior -> senior pipeline would, on average, hit every country the same. Though it raises an interesting point: if a country like India or China did make the investment in hiring, paying, and mentoring junior people but e.g. the US didn't, then you could see a massive shift in the global center of gravity around software expertise in 10 years (plus or minus). Someone is going to be the best at planning for and investing in the future on this, and someone is going to maximally wishful thinking / short-term thinking this, and seductive-but-not-really-there vibe coding is probably going to be a major pivot point there.
        azinman2 1y ago
        This is such an important point. Not sure about India, which is still very market forces driven, but china can just force its employers to do whatever is of strategic importance. That’s long gone in the US. Market forces here will only ever optimize for short term game, shooting ourselves in the chest.
    - FirmwareBurner 1y ago
      Unlikely. Microsoft had layoffs everywhere except India. There they keep hiring more. As song as the can keep upskilling themselves while still being much cheaper than US workers they won't fear unemployment. Just yesterday I saw on X a video of a Miami hotel where the check-in procedure was via a video call to a receptionist in India.
      - 1y ago
- makingstuffs 1y ago
  Ah mate I can’t relate more to the offshore component. I had a very sad experience where I recently had to let go of an offshore team due to them providing devs that essentially ‘junior with copilot’ but labelled as a ‘senior’. Time and time again I would find telltale signs of dumping LLM output into PRs n then claiming it as their own. Not a problem, but the code didn’t do what the detailed ticket asked and introduced other bugs as a result. It ultimately became a choice of ‘go through the hassle of making a detailed brief for it to just be put in copilot verbatim and then go through the hassle of reviewing it and explaining the issues back to the offshore dev’ or ‘brief Claude directly’ I hate to say it but from a business perspective the latter won outright. It tears me up as it goes against my morality.
  - willsmith72 1y ago
    Why does it go against your morality? Sounds like a totally rational business decision, only affecting a sub-par partner
    - makingstuffs 1y ago
      I know what you mean it just feels a bit inhumane to me. Sort of like defining a value for a living being and then determining that they fell beneath said value.
      - aswegs8 1y ago
        Yeah well, at some point some one higher up without scruples about such moral issues will make that decision for you...
  - zed_the_face 1y ago
    Then why did you do it?
Rapzid 1y ago
Yeah I noticed the issue with more Junior developers right away. Some developers, Junior or not, have yet to be exposed to environments where their PRs are put under HEAVY scrutiny. They are used to loosey-goosey and unfortunately they are not prepared to put LLM changes under the level of scrutiny they require. The worst is getting, even smallish, PRs with a bunch of changes that look extraneous or otherwise off. After asking questions the code changes without the questions being answered and likely with a new set of problems. I swear I've been prompting an LLM through an engineer/PR middleman :(
- 0x696C6961 1y ago
  Our offshore devs keep doing this and it drives me nuts. No answers to my question, completely different code gets pushed.
  - andrekandre 1y ago
    > No answers to my question, completely different code gets pushed. at what point does that cost become higher than benefit?
    - boringg 1y ago
      It does but most execs dont care about long term they want that perf bonus before they leave in 3-4 years
      - nosianu 1y ago
        That is how you get Oracle source code. It broke my illusions after entering real life big company coding after university, many years ago. It also led to this gem of an HN comment: https://news.ycombinator.com/item?id=18442637 https://news.ycombinator.com/item?id=18442637
yubblegum 1y ago
> I'm hearing from Senior devs all over thought, that Junior developers are just garbage at it. They product slow, insecure, or just outright awful code with it, and then they PR the code they don't even understand. If this is the case then we better have full AI generated code within the next 10 years since those "juniors" will remain atrophied juniors forever and the old timers will be checking in with the big clock in the sky. IF we, as a field, believe that this can not possibly happen, then we are making a huge mistake leaning on a tool that requires "deep [orthogonal] experience" to operate properly.
- ako 1y ago
  IT education and computer science (at least part of it) will need a stronger focus on software engineering and software architecture skills to teach developers how to be in control of an AI dev tool.
  - renegade-otter 1y ago
    The fastest way is via struggle. Learn to do it yourself first. Understand WHY it does not work. What's good code? What's bad code? What are conventions? There are no shortcuts - you are not an accountant just because you have a calculator.
    - ako 1y ago
      With that mindset you don't have to go to school, you could learn everything through struggle... Ideally it's a bit of both, you need theory and experience to succeed.
      - globular-toast 1y ago
        And talent.
  - nosianu 1y ago
    Brains are not computers and we don't learn by being given abstract rules. We also don't learn nearly as well from class room teaching as we do from doing things IRL for a real purpose - the brain always knows the difference and that the (real, non-artificially created) stakes are low in a teaching environment. That's also the huge difference between AI and brains: AI does not work on the real world but on our communication (and even that is limited to text, missing all the nuance or face to face communication includes). The brain works based on sensor data from the real world. The communication method, language, is a very limited add-on on top of how the brain really works. We don't think in language, to do even some abstract language based thinking, e.g. when doing formal math, requires a lot of concentration and effort and still uses a lot of "under the hood" intuition. That is why even with years of learning the same curriculum we still need to make a significant effort for every single concrete example to "get everyone on the same page", creating compatible internal models under the hood. Everybody's own internal model of even simple things are slightly different, depending on what brain they brought to learning and what exactly they learned, where even things like social classroom interactions went into how the connections were formed. Only based on a huge amount of effort can we then use language to communicate in the abstract, and even then, when we leave the central corridor of ideas people will start arguing forever about definitions. No matter how the written text is the same, the internal model is different for every person. As someone who took neuroscience, I found this surprisingly well written: "The brain doesn't like to abstract unless you make it" http://howthebrainworks.science/how_the_brain_works_/the_brain_doesnt_like_to_abstract_unless_you_make_it/ http://howthebrainworks.science/how_the_brain_works_/the_bra... > This resource, prepared by members of the University of London Centre for Educational Neuroscience (CEN), gives a brief overview of how the brain works for a general audience. It is based on the most recent research. It aims to give a gist of the brain’s principles of function, covering the brain’s evolutionary origin, how it develops, and how it copes in the modern world. The best way to learn is to do things IRL that matter. School is a compromise and not really all that great. People motivated by actual need often can learn things that take years in school with middling results significantly faster and with better and deeper results.
js2 1y ago
I've also found it good at catching mistakes and helping write commit messages. "Review the top-most commit. Did I make any mistakes? Did I leave anything out of the commit message?" Sometimes I let it write the message for me: "Write a new commit message for the current commit." I've had to tell it how to write commit messages though. It likes to offer subjective opinions, use superlatives and guess at why something was done. I've had to tell it to cut that out: "Summarize what has changes. Be concise but thorough. Avoid adjective and superlatives. Use imperative mood."
- conradfr 1y ago
  How long are you commit messages if you still are ahead after typing all this prompt?
  - skydhash 1y ago
    My commits’description part, if warranted, is about the reason for the changes, not the specificity of the solution. It’s a little memo to the person reading the diff, not a long monograph. And the diff is usually small.
- danielbln 1y ago
  What I can recommend is to tell it that for all documentation, readmes and PR descriptions to keep it "tight, no purple-prose, no emojis". That cuts everything down nicely to to-the-point docs without GPTisms and without the emoji storm that makes it look like yet another frontend framework Readme.
- fireflash38 1y ago
  This is insane to me. Review your own code. Understand why you made the changes. And then clearly describe why you made them. If you can't do that yourself, I think that's a huge gap in your own skills. Making something else do it means you don't internalize the changes that you made.
  - js2 1y ago
    Your comment is not a fair interpretation of what I wrote. For the record, I write better and more detailed commit messages than almost anyone I know across a decades[^0] long career[^1,^2,^3,^4,^5]. But I'm not immune from making mistakes, and everyone can use an editor, or just runs out of mental energy. Unfortunately, I find it hard to get decent PR reviews from my colleagues at work. So yeah, I've started using Claude Code to help review my own commits. That doesn't mean I don't understand my changes or that I don't know why I made them. And CC is good at banging out a first draft of a commit message. It's also good at catching tiny logic errors that slip through tests and human review. Surprisingly good. You should try it. I have plenty of criticisms for CC too. I'm not sure it's actually saving me any time. I've spent the last two weeks working 10 hour days with it. For some things it shines. For other things, I would've been better off writing the code from scratch myself, something I've had to do maybe 40% of the time now. [^0]: https://seclists.org/bugtraq/1998/Jul/172 https://seclists.org/bugtraq/1998/Jul/172 [^1]: https://github.com/git/git/commit/441adf0ccf571a9fe15658fdfcd856d2aabc01cb https://github.com/git/git/commit/441adf0ccf571a9fe15658fdfc... [^2]: https://github.com/git/git/commit/cacfc09ba82bfc6b0e1c047247785d56a6054b2f https://github.com/git/git/commit/cacfc09ba82bfc6b0e1c047247... [^3]: https://github.com/fastlane/fastlane/pull/21644 https://github.com/fastlane/fastlane/pull/21644 [^4]: https://github.com/CocoaPods/Core/pull/741 https://github.com/CocoaPods/Core/pull/741 [^5]: None of the these are my best examples, just the ones I found quickly. Most of my commit messages are obviously locked away by my employer. Somewhere in the git history is a paragraphs long commit message from Jeff King (peff) explaining a one line diff. That's probably my favorite commit message of all time. But I also know that at work I've got a message somewhere explaining a single character diff.
ChuckMcM 1y ago
An observation. If we stipulate that this is true that a 'senior developer' benefits from Claude Code but a junior developer do not. Then I'm wondering if that creates this gap where you have a bunch of newly minted '10x' engineers who are doing the work that a bunch of junior devs helped with, and now you're not training any new junior devs because they are unemployable. Is that correct?
- pmg101 1y ago
  It already was the case wasn't it, that you could either get one senior dev to build your thing in a week, or give them a team of juniors and it would take the whole team 4 weeks and be worse. Yet somehow companies continued to opt for the second approach. Something to do with status from headcount?
  - oumua_don17 1y ago
    >> Something to do with status from headcount? And usually projected as ensuring bus factor > 1
  - itsalotoffun 1y ago
    n=1 but my experience is the ratio of what'd I'd class "senior" devs (per the example given) to everyone else is comfortably 10:1.
    - pmg101 1y ago
      Do you mean that for every 11 devs, 10 of them are "senior" as per the example? Or that only 1 is?
      - itsalotoffun 1y ago
        1 senior to 10 everyone else. Sorry that wasn't super clear.
  - wrs 1y ago
    “Wasting” effort on juniors is where seniors come from. So that first approach is only valid at a sole proprietorship, at an early stage startup, or in an emergency.
brundolf 1y ago
I find the "killer app" right now is anything where you need to integrate information you don't already have in your brain. A new language or framework, a third-party API, etc. Something straightforward but foreign, and well-documented. You'll save so much time because Claude has already read the docs
collingreen 1y ago
I'm getting my moneys worth having claude write tools. We've reached the dream where I can vibe out some one off software and it's great; today I made two different (shitty but usable!) gui programs in seconds that let me visually describe some test data. The alternative was probably half an hour of putting something together if my first idea was good. Then I deleted them and moved on. It still writes insane things all the time but I find it really helpful to spit out single use stuff and to brainstorm with. I try to get it to perform tasks I don't know how to accomplish (eg. computer vision experiments) and it never really works out in the end but I often learn something and I'm still very happy with my subscription.
siva7 1y ago
Can also confirm. Almost any output from claude code needs my careful input for corrections, which you could only spot and provide if you have experience. There is no way a junior is able to command these tools because the main competency to use them correctly is your ability to guide and teach others in software development, which by definition is only possible if you have senior experience in this field. The sycophancy provided by these models will outright damage the skill progression for juniors, but on the other hand there is no way to not use them. So we are in a state where the future seems really uncertain for most of us.
michaelrpeskin 1y ago
Yes, this! A couple of week ago, I had a little down time and thought about a new algorithm I wanted to implement. In my head it seemed simple enough that 1) I thought the solution was already known, and 2) it would be fairly easy to write. So I asked Claude to "write me a python function that does Foo". I spent a whole morning going back and forth getting crap and nothing at all like what I wanted. I don't know what inspired me, but I just started to pretend that I was talking to one one of my junior engineers. I first asked for a much simpler function that was on the way to what I wanted (well, technically, it was the mathematical inverse of what I wanted), then I asked it to modify it to add one different transform, and then another, and then another. And then finally, once the function was doing what I wanted, I asked it to write me the inverse function. And it got it right. What was cool about it, is that it turned out to be more complex linear algebra and edge cases than I originally thought, and it would have been weeks for me to figure all of that out. But using it as a research tool and junior engineer in one was the key. I think if we go down the "vibe coding" route, we will end up with hoards of juniors who don't understand anything and the stuff they produce with AI will be garbage and brittle. But using AI as a tool is starting to feel more compelling to me.
- rusk 1y ago
  “ we will end up with hoards of juniors who don't understand anything and the stuff they produce” I’ve spent a lot of my career cleaning up this kind of nonsense so the future looks bright
- ifwinterco 1y ago
  The LLM will never admit it doesn't have a clue what's going on, but over time you develop a sense of when it's onto something and when it's trapped in a loop of plausible sounding nonsense Edit: Also, it's funny how often you can get it to improve its output by just saying "this looks kind of bad for x reason, there must be a way to make it better"
  - bredren 1y ago
    I have experimented with instructing CC to doubt itself greatly and presume it is not validating anything properly. It caused it to throw out good ideas for validation and working code. I want to believe there is some sweet spot. The constant “Aha!” type responses followed by self validating prose that the answer is at hand or within reach can be intoxicating and can not be trusted. The product is also seemingly in constant flux of tuning, where some sessions result in great progress, others the AI seems as if it is deliberately trying to steer you into traffic. Anthropic is alluded toward this being the result of load. They mentioned in their memo about new limits for Max users that abuse of the subscription levels resulted in ~subpar product experiences. It’s possible they meant response times and the overloaded 500 responses or lower than normal TPS, but there are many anecdotal accounts of CC suddenly having a bad day from “longtime” users, including myself. I don’t understand how load would impact the actual model’s performance. It seems like only load based impacts on individual session context would result in degraded outputs. But I know nothing of serving LLM at scale. Can anyone explain how high load might result in an unchanged product performing objectively worse?

channel_t 1y ago

Yes, can confirm that as a senior developer who has needed to spend huge amounts of time reviewing junior code from off-shore contractors with very detailed and explicit instructions, dabbling in agentic LLM coding tools like Claude Code has felt like like a gift from heaven. I also have concerns about said junior developers wielding such tools, because yes, without being able to supply the right kind of context and being able to understand the difference between a good solution and a bad solution, they will produce tons of awful, but technically working code.

awesome_dude 1y ago
This. I've got myself in a PILE of trouble when trying to use LLMs with languages/technologies I am unfamiliar with (React, don't judge me). But with something that I am familiar with (say Go, or Python) LLMs have improved my velocity massively, with the caveat that I have had to explicitly tell the LLM when it is producing something that I know that I don't want (me arguing with an LLM was an experience too!)
willsmith72 1y ago
Totally agree with the off-shore component of this. I'm already going to have to break a task down into clear detail and resolve any anticipated blocker myself upfront to avoid multi-timezone multi-day back and forth. Now that I'm practiced at that, the off-shored part is no longer valuable
- sitkack 1y ago
  The unemployment in India is going to be catastrophic. Geopolitical.
  - vaidhy 1y ago
    You know senior developers can also be off-shored, right?
    - benreesman 1y ago
      Blowing away the junior -> senior pipeline would, on average, hit every country the same. Though it raises an interesting point: if a country like India or China did make the investment in hiring, paying, and mentoring junior people but e.g. the US didn't, then you could see a massive shift in the global center of gravity around software expertise in 10 years (plus or minus). Someone is going to be the best at planning for and investing in the future on this, and someone is going to maximally wishful thinking / short-term thinking this, and seductive-but-not-really-there vibe coding is probably going to be a major pivot point there.
      - azinman2 1y ago
        This is such an important point. Not sure about India, which is still very market forces driven, but china can just force its employers to do whatever is of strategic importance. That’s long gone in the US. Market forces here will only ever optimize for short term game, shooting ourselves in the chest.
  - FirmwareBurner 1y ago
    Unlikely. Microsoft had layoffs everywhere except India. There they keep hiring more. As song as the can keep upskilling themselves while still being much cheaper than US workers they won't fear unemployment. Just yesterday I saw on X a video of a Miami hotel where the check-in procedure was via a video call to a receptionist in India.
    - 1y ago
makingstuffs 1y ago
Ah mate I can’t relate more to the offshore component. I had a very sad experience where I recently had to let go of an offshore team due to them providing devs that essentially ‘junior with copilot’ but labelled as a ‘senior’. Time and time again I would find telltale signs of dumping LLM output into PRs n then claiming it as their own. Not a problem, but the code didn’t do what the detailed ticket asked and introduced other bugs as a result. It ultimately became a choice of ‘go through the hassle of making a detailed brief for it to just be put in copilot verbatim and then go through the hassle of reviewing it and explaining the issues back to the offshore dev’ or ‘brief Claude directly’ I hate to say it but from a business perspective the latter won outright. It tears me up as it goes against my morality.
- willsmith72 1y ago
  Why does it go against your morality? Sounds like a totally rational business decision, only affecting a sub-par partner
  - makingstuffs 1y ago
    I know what you mean it just feels a bit inhumane to me. Sort of like defining a value for a living being and then determining that they fell beneath said value.
    - aswegs8 1y ago
      Yeah well, at some point some one higher up without scruples about such moral issues will make that decision for you...
- zed_the_face 1y ago
  Then why did you do it?

Rapzid 1y ago

Yeah I noticed the issue with more Junior developers right away. Some developers, Junior or not, have yet to be exposed to environments where their PRs are put under HEAVY scrutiny. They are used to loosey-goosey and unfortunately they are not prepared to put LLM changes under the level of scrutiny they require. The worst is getting, even smallish, PRs with a bunch of changes that look extraneous or otherwise off. After asking questions the code changes without the questions being answered and likely with a new set of problems. I swear I've been prompting an LLM through an engineer/PR middleman :(

0x696C6961 1y ago
Our offshore devs keep doing this and it drives me nuts. No answers to my question, completely different code gets pushed.
- andrekandre 1y ago
  > No answers to my question, completely different code gets pushed. at what point does that cost become higher than benefit?
  - boringg 1y ago
    It does but most execs dont care about long term they want that perf bonus before they leave in 3-4 years
    - nosianu 1y ago
      That is how you get Oracle source code. It broke my illusions after entering real life big company coding after university, many years ago. It also led to this gem of an HN comment: https://news.ycombinator.com/item?id=18442637 https://news.ycombinator.com/item?id=18442637

yubblegum 1y ago

> I'm hearing from Senior devs all over thought, that Junior developers are just garbage at it. They product slow, insecure, or just outright awful code with it, and then they PR the code they don't even understand. If this is the case then we better have full AI generated code within the next 10 years since those "juniors" will remain atrophied juniors forever and the old timers will be checking in with the big clock in the sky. IF we, as a field, believe that this can not possibly happen, then we are making a huge mistake leaning on a tool that requires "deep [orthogonal] experience" to operate properly.

ako 1y ago
IT education and computer science (at least part of it) will need a stronger focus on software engineering and software architecture skills to teach developers how to be in control of an AI dev tool.
- renegade-otter 1y ago
  The fastest way is via struggle. Learn to do it yourself first. Understand WHY it does not work. What's good code? What's bad code? What are conventions? There are no shortcuts - you are not an accountant just because you have a calculator.
  - ako 1y ago
    With that mindset you don't have to go to school, you could learn everything through struggle... Ideally it's a bit of both, you need theory and experience to succeed.
    - globular-toast 1y ago
      And talent.
- nosianu 1y ago
  Brains are not computers and we don't learn by being given abstract rules. We also don't learn nearly as well from class room teaching as we do from doing things IRL for a real purpose - the brain always knows the difference and that the (real, non-artificially created) stakes are low in a teaching environment. That's also the huge difference between AI and brains: AI does not work on the real world but on our communication (and even that is limited to text, missing all the nuance or face to face communication includes). The brain works based on sensor data from the real world. The communication method, language, is a very limited add-on on top of how the brain really works. We don't think in language, to do even some abstract language based thinking, e.g. when doing formal math, requires a lot of concentration and effort and still uses a lot of "under the hood" intuition. That is why even with years of learning the same curriculum we still need to make a significant effort for every single concrete example to "get everyone on the same page", creating compatible internal models under the hood. Everybody's own internal model of even simple things are slightly different, depending on what brain they brought to learning and what exactly they learned, where even things like social classroom interactions went into how the connections were formed. Only based on a huge amount of effort can we then use language to communicate in the abstract, and even then, when we leave the central corridor of ideas people will start arguing forever about definitions. No matter how the written text is the same, the internal model is different for every person. As someone who took neuroscience, I found this surprisingly well written: "The brain doesn't like to abstract unless you make it" http://howthebrainworks.science/how_the_brain_works_/the_brain_doesnt_like_to_abstract_unless_you_make_it/ http://howthebrainworks.science/how_the_brain_works_/the_bra... > This resource, prepared by members of the University of London Centre for Educational Neuroscience (CEN), gives a brief overview of how the brain works for a general audience. It is based on the most recent research. It aims to give a gist of the brain’s principles of function, covering the brain’s evolutionary origin, how it develops, and how it copes in the modern world. The best way to learn is to do things IRL that matter. School is a compromise and not really all that great. People motivated by actual need often can learn things that take years in school with middling results significantly faster and with better and deeper results.

js2 1y ago

I've also found it good at catching mistakes and helping write commit messages. "Review the top-most commit. Did I make any mistakes? Did I leave anything out of the commit message?" Sometimes I let it write the message for me: "Write a new commit message for the current commit." I've had to tell it how to write commit messages though. It likes to offer subjective opinions, use superlatives and guess at why something was done. I've had to tell it to cut that out: "Summarize what has changes. Be concise but thorough. Avoid adjective and superlatives. Use imperative mood."

conradfr 1y ago
How long are you commit messages if you still are ahead after typing all this prompt?
- skydhash 1y ago
  My commits’description part, if warranted, is about the reason for the changes, not the specificity of the solution. It’s a little memo to the person reading the diff, not a long monograph. And the diff is usually small.
danielbln 1y ago
What I can recommend is to tell it that for all documentation, readmes and PR descriptions to keep it "tight, no purple-prose, no emojis". That cuts everything down nicely to to-the-point docs without GPTisms and without the emoji storm that makes it look like yet another frontend framework Readme.
fireflash38 1y ago
This is insane to me. Review your own code. Understand why you made the changes. And then clearly describe why you made them. If you can't do that yourself, I think that's a huge gap in your own skills. Making something else do it means you don't internalize the changes that you made.
- js2 1y ago
  Your comment is not a fair interpretation of what I wrote. For the record, I write better and more detailed commit messages than almost anyone I know across a decades[^0] long career[^1,^2,^3,^4,^5]. But I'm not immune from making mistakes, and everyone can use an editor, or just runs out of mental energy. Unfortunately, I find it hard to get decent PR reviews from my colleagues at work. So yeah, I've started using Claude Code to help review my own commits. That doesn't mean I don't understand my changes or that I don't know why I made them. And CC is good at banging out a first draft of a commit message. It's also good at catching tiny logic errors that slip through tests and human review. Surprisingly good. You should try it. I have plenty of criticisms for CC too. I'm not sure it's actually saving me any time. I've spent the last two weeks working 10 hour days with it. For some things it shines. For other things, I would've been better off writing the code from scratch myself, something I've had to do maybe 40% of the time now. [^0]: https://seclists.org/bugtraq/1998/Jul/172 https://seclists.org/bugtraq/1998/Jul/172 [^1]: https://github.com/git/git/commit/441adf0ccf571a9fe15658fdfcd856d2aabc01cb https://github.com/git/git/commit/441adf0ccf571a9fe15658fdfc... [^2]: https://github.com/git/git/commit/cacfc09ba82bfc6b0e1c047247785d56a6054b2f https://github.com/git/git/commit/cacfc09ba82bfc6b0e1c047247... [^3]: https://github.com/fastlane/fastlane/pull/21644 https://github.com/fastlane/fastlane/pull/21644 [^4]: https://github.com/CocoaPods/Core/pull/741 https://github.com/CocoaPods/Core/pull/741 [^5]: None of the these are my best examples, just the ones I found quickly. Most of my commit messages are obviously locked away by my employer. Somewhere in the git history is a paragraphs long commit message from Jeff King (peff) explaining a one line diff. That's probably my favorite commit message of all time. But I also know that at work I've got a message somewhere explaining a single character diff.

ChuckMcM 1y ago

An observation. If we stipulate that this is true that a 'senior developer' benefits from Claude Code but a junior developer do not. Then I'm wondering if that creates this gap where you have a bunch of newly minted '10x' engineers who are doing the work that a bunch of junior devs helped with, and now you're not training any new junior devs because they are unemployable. Is that correct?

pmg101 1y ago
It already was the case wasn't it, that you could either get one senior dev to build your thing in a week, or give them a team of juniors and it would take the whole team 4 weeks and be worse. Yet somehow companies continued to opt for the second approach. Something to do with status from headcount?
- oumua_don17 1y ago
  >> Something to do with status from headcount? And usually projected as ensuring bus factor > 1
- itsalotoffun 1y ago
  n=1 but my experience is the ratio of what'd I'd class "senior" devs (per the example given) to everyone else is comfortably 10:1.
  - pmg101 1y ago
    Do you mean that for every 11 devs, 10 of them are "senior" as per the example? Or that only 1 is?
    - itsalotoffun 1y ago
      1 senior to 10 everyone else. Sorry that wasn't super clear.
- wrs 1y ago
  “Wasting” effort on juniors is where seniors come from. So that first approach is only valid at a sole proprietorship, at an early stage startup, or in an emergency.

brundolf 1y ago

I find the "killer app" right now is anything where you need to integrate information you don't already have in your brain. A new language or framework, a third-party API, etc. Something straightforward but foreign, and well-documented. You'll save so much time because Claude has already read the docs

collingreen 1y ago

I'm getting my moneys worth having claude write tools. We've reached the dream where I can vibe out some one off software and it's great; today I made two different (shitty but usable!) gui programs in seconds that let me visually describe some test data. The alternative was probably half an hour of putting something together if my first idea was good. Then I deleted them and moved on. It still writes insane things all the time but I find it really helpful to spit out single use stuff and to brainstorm with. I try to get it to perform tasks I don't know how to accomplish (eg. computer vision experiments) and it never really works out in the end but I often learn something and I'm still very happy with my subscription.

siva7 1y ago

Can also confirm. Almost any output from claude code needs my careful input for corrections, which you could only spot and provide if you have experience. There is no way a junior is able to command these tools because the main competency to use them correctly is your ability to guide and teach others in software development, which by definition is only possible if you have senior experience in this field. The sycophancy provided by these models will outright damage the skill progression for juniors, but on the other hand there is no way to not use them. So we are in a state where the future seems really uncertain for most of us.

michaelrpeskin 1y ago

Yes, this! A couple of week ago, I had a little down time and thought about a new algorithm I wanted to implement. In my head it seemed simple enough that 1) I thought the solution was already known, and 2) it would be fairly easy to write. So I asked Claude to "write me a python function that does Foo". I spent a whole morning going back and forth getting crap and nothing at all like what I wanted. I don't know what inspired me, but I just started to pretend that I was talking to one one of my junior engineers. I first asked for a much simpler function that was on the way to what I wanted (well, technically, it was the mathematical inverse of what I wanted), then I asked it to modify it to add one different transform, and then another, and then another. And then finally, once the function was doing what I wanted, I asked it to write me the inverse function. And it got it right. What was cool about it, is that it turned out to be more complex linear algebra and edge cases than I originally thought, and it would have been weeks for me to figure all of that out. But using it as a research tool and junior engineer in one was the key. I think if we go down the "vibe coding" route, we will end up with hoards of juniors who don't understand anything and the stuff they produce with AI will be garbage and brittle. But using AI as a tool is starting to feel more compelling to me.

rusk 1y ago
“ we will end up with hoards of juniors who don't understand anything and the stuff they produce” I’ve spent a lot of my career cleaning up this kind of nonsense so the future looks bright
ifwinterco 1y ago
The LLM will never admit it doesn't have a clue what's going on, but over time you develop a sense of when it's onto something and when it's trapped in a loop of plausible sounding nonsense Edit: Also, it's funny how often you can get it to improve its output by just saying "this looks kind of bad for x reason, there must be a way to make it better"
- bredren 1y ago
  I have experimented with instructing CC to doubt itself greatly and presume it is not validating anything properly. It caused it to throw out good ideas for validation and working code. I want to believe there is some sweet spot. The constant “Aha!” type responses followed by self validating prose that the answer is at hand or within reach can be intoxicating and can not be trusted. The product is also seemingly in constant flux of tuning, where some sessions result in great progress, others the AI seems as if it is deliberately trying to steer you into traffic. Anthropic is alluded toward this being the result of load. They mentioned in their memo about new limits for Max users that abuse of the subscription levels resulted in ~subpar product experiences. It’s possible they meant response times and the overloaded 500 responses or lower than normal TPS, but there are many anecdotal accounts of CC suddenly having a bad day from “longtime” users, including myself. I don’t understand how load would impact the actual model’s performance. It seems like only load based impacts on individual session context would result in degraded outputs. But I know nothing of serving LLM at scale. Can anyone explain how high load might result in an unchanged product performing objectively worse?