6 ms·

You do. Even the latest models still frequently write really weird code. The problem is some developers now just submit code for review that they didn't bother

by oakpond 7mo ago

You do. Even the latest models still frequently write really weird code. The problem is some developers now just submit code for review that they didn't bother to read. You can tell. Code review is more important than ever imho.

MrDarcy 7mo ago
It is remarkably effective to have Claude Code do the code review and assign a quality score, call it a grade, to the contribution derived from your own expectations of quality. Then don’t even bother looking at C work or below.
- NitpickLawyer 7mo ago
  IME it works even better if you use another model for review. We've seen code by cc and review by gpt5.2/3 work very well. Also works with planning before any coding sessions. Gemini + Opus + GPT-xhigh works to get a lot of questions answered before coding starts.
sausagefeet 7mo ago
I agree with you. But I have to say, it is an uphill battle and all the incentives are against you. 1. AI is meant to make us go faster, reviews are slow, the AI is smart, let it go. 2. There are plenty of AI maximizers who only think we should be writing design docs and letting the AI go to town on it. Maybe, this might be a great time to start a company. Maximize the benefits of AI while you can without someone who has never written a line of code telling you that your job is going to disappear in 12 months. All the incentives are against someone who wants to use AI in a reasonable way, right now.
- redhed 7mo ago
  I actually agree with good time to start a company. Lot of available software engineers that can actually understand code, AI at a level that can actually speed up development, and so many startups focusing on AI wrapper slop that you can actually make a useful product and separate yourself from the herd. Or you can be a grifter and make some AI wrapper yourself and cash out with some VC investment. So good time for a new company either way.
  - radlad 7mo ago
    It's gonna be like that HBO Silicon Valley bit again, where everyone and their doctor is telling you about their app.
  - rvz 7mo ago
    The people that are declaring holier-than-thou with self proclaimed 'principles' are the worst grifters and the ones actively scamming with AI with VC investment. Pretending that they can only save the world and at the same time declaring they don't use AI but use it secretly by building an so-called "AI startup" and then going on the media doomsaying that "AGI" is coming. At this point in this cycle in AI, "AGI" is just grifting until IPO.
xienze 7mo ago
> The problem is some developers now just submit code for review that they didn't bother to read. Can you blame them? All the AI companies are saying “this does a better job than you ever could”, every discussion topic on AI includes at least one (totally organic, I’m sure) comment along the lines of “I’ve been developing software for over twenty years and these tools are going to replace me in six months. I’m learning how to be a plumber before I’m permanently unemployed.” So when Claude spits out something that seems to work with a short smoke test, how can you blame developers for thinking “damn the hype is real. LGTM”?
- jf22 7mo ago
  I'm an 99% organic person (I suppose I have tooth fillings) and the new models write code better than I do. I've been using LLMS for 14+ months now and they've exceeded my expectations.
  - xienze 7mo ago
    So are you learning a trade? Or do you somehow think you’ll be one of the developers “good enough” to remain employed?
    - jf22 7mo ago
      I have a physical goods side hustle already and I'm brainstorming ideas about a trade I can do that will benefit from my programming experience. I'm thinking HVAC or painting lines in parking lots. HVAC because I can program smart systems and parking lot lines because I can use google maps and algos to propose more efficient parking lot designs to existing business owners. There is that paradox when if something becomes cheaper there is more demand so we'll see what happens. Finally, I'm a mediocre dev that can only handle 2-3 agents at a time so I probably won't be good enough.
  - HoldOnAMinute 7mo ago
    Not only do they exceed expectations, but any time they fall down, you can improve your instructions to them. It's easy to get into a virtuous cycle.
bradleykingz 7mo ago
But it's so BORING. AI gets to do the fun part (writing code) and I'm stuck with the lame bits. It's like watching someone else solve a puzzle, or watching someone else play a game vs playing it yourself (at least that's half as interesting as playing it through)
- lukan 7mo ago
  For me the most fun part is getting something that works. Design the goal, but not micromanage and get lost in the details. I love AI for that, but it is hard really owning code this way. (At least I manually approve every or most changes, but still, verifying is hard).
  - bitwize 7mo ago
    AI has really sharpened the line between the Master Builders of the world and the Lord Businesses along this question: What, exactly, is the "fun part" of programming? Is it simply having something that works? Or is it the process of going from not having it to having it through your own efforts and the sum total of decisions you made along the way?
  - jurgenburgen 7mo ago
    > For me the most fun part is getting something that works. Design the goal, but not micromanage and get lost in the details. That’s management, which is not necessarily bad by itself. What is bad if you have to be both a manager giving the requirements and the IC responsible for the output. That’s the worst of both worlds. If it was possible to truly vibe code in the same way a product manager asks a team to build something then we wouldn’t need to have this discussion. In reality you can never truly trust the output. Ultimately you’re on the hook if production breaks apart, not the LLM.
- HoldOnAMinute 7mo ago
  I am really enjoying making requirements docs in an iterative process. I have a continuous improvement loop where I use the implementation to test out the docs. If I find a problem with the docs, I throw away the implementation, improve the docs, then re-implement. The kind of docs I'm getting are of amazing quality.
throwaw12 7mo ago
> You do I really want to say: "You are absolutely right" But here is a problem I am facing personally (numbers are hypothetical). I get a review request 10-15/day by 4 teammates, who are generating code by prompting, and I am doing same, so you can guess we might have ~20 PRs/day to review. now each PR is roughly updating 5-6 files and 10-15 lines in each. So you can estimate that, I am looking at around 50-60 files, but I can't keep the context of the whole file because change I am looking is somewhere in the middle, 3 lines here, 5 lines there and another 4 lines at the end. How am I supposed to review all these?
- radlad 7mo ago
  I don't quite follow - are you describing an issue with the way your team has structured PRs? IMO, a PR should contain just enough code to clearly and completely solve "a thing" without solving too much at once. But what this means in practice depends on the team, product, velocity, etc. It sounds like your PRs might be broken up into too small of chunks if you can't understand why the code is being added.
  - throwaw12 7mo ago
    I am saying PRs I get are around 60-70 lines of change, which is small enough to be considered as single unit (add to this unit tests which must pass with new change, so we are talking about 30 line change + 30 line unit test) But when looking at the PR changes, you don't always see whole picture because review subjects (code lines) are scattered across files and methods, and GitHub also shows methods and files partially making it even more difficult to quickly spot the context around those updated lines. Its difficult problem, because even if GitHub shows whole body of the updated method or a file, you still don't see grand picture. For example: A (calls) -> B -> C -> D And you made changes in D, how do you know the side effect on B, what if it broke A?
    - cesarb 7mo ago
      > Its difficult problem, because even if GitHub shows whole body of the updated method or a file, you still don't see grand picture. > For example: A (calls) -> B -> C -> D > And you made changes in D, how do you know the side effect on B, what if it broke A? That's poor encapsulation. If the changes in D respect its contract, and C respects D's contract, your changes in D shouldn't affect C, much less B or A.
deleted 7mo ago

by oakpond 7mo ago

MrDarcy 7mo ago

It is remarkably effective to have Claude Code do the code review and assign a quality score, call it a grade, to the contribution derived from your own expectations of quality. Then don’t even bother looking at C work or below.

NitpickLawyer 7mo ago
IME it works even better if you use another model for review. We've seen code by cc and review by gpt5.2/3 work very well. Also works with planning before any coding sessions. Gemini + Opus + GPT-xhigh works to get a lot of questions answered before coding starts.

sausagefeet 7mo ago

I agree with you. But I have to say, it is an uphill battle and all the incentives are against you. 1. AI is meant to make us go faster, reviews are slow, the AI is smart, let it go. 2. There are plenty of AI maximizers who only think we should be writing design docs and letting the AI go to town on it. Maybe, this might be a great time to start a company. Maximize the benefits of AI while you can without someone who has never written a line of code telling you that your job is going to disappear in 12 months. All the incentives are against someone who wants to use AI in a reasonable way, right now.

redhed 7mo ago
I actually agree with good time to start a company. Lot of available software engineers that can actually understand code, AI at a level that can actually speed up development, and so many startups focusing on AI wrapper slop that you can actually make a useful product and separate yourself from the herd. Or you can be a grifter and make some AI wrapper yourself and cash out with some VC investment. So good time for a new company either way.
- radlad 7mo ago
  It's gonna be like that HBO Silicon Valley bit again, where everyone and their doctor is telling you about their app.
- rvz 7mo ago
  The people that are declaring holier-than-thou with self proclaimed 'principles' are the worst grifters and the ones actively scamming with AI with VC investment. Pretending that they can only save the world and at the same time declaring they don't use AI but use it secretly by building an so-called "AI startup" and then going on the media doomsaying that "AGI" is coming. At this point in this cycle in AI, "AGI" is just grifting until IPO.

xienze 7mo ago

> The problem is some developers now just submit code for review that they didn't bother to read. Can you blame them? All the AI companies are saying “this does a better job than you ever could”, every discussion topic on AI includes at least one (totally organic, I’m sure) comment along the lines of “I’ve been developing software for over twenty years and these tools are going to replace me in six months. I’m learning how to be a plumber before I’m permanently unemployed.” So when Claude spits out something that seems to work with a short smoke test, how can you blame developers for thinking “damn the hype is real. LGTM”?

jf22 7mo ago
I'm an 99% organic person (I suppose I have tooth fillings) and the new models write code better than I do. I've been using LLMS for 14+ months now and they've exceeded my expectations.
- xienze 7mo ago
  So are you learning a trade? Or do you somehow think you’ll be one of the developers “good enough” to remain employed?
  - jf22 7mo ago
    I have a physical goods side hustle already and I'm brainstorming ideas about a trade I can do that will benefit from my programming experience. I'm thinking HVAC or painting lines in parking lots. HVAC because I can program smart systems and parking lot lines because I can use google maps and algos to propose more efficient parking lot designs to existing business owners. There is that paradox when if something becomes cheaper there is more demand so we'll see what happens. Finally, I'm a mediocre dev that can only handle 2-3 agents at a time so I probably won't be good enough.
- HoldOnAMinute 7mo ago
  Not only do they exceed expectations, but any time they fall down, you can improve your instructions to them. It's easy to get into a virtuous cycle.

bradleykingz 7mo ago

But it's so BORING. AI gets to do the fun part (writing code) and I'm stuck with the lame bits. It's like watching someone else solve a puzzle, or watching someone else play a game vs playing it yourself (at least that's half as interesting as playing it through)

lukan 7mo ago
For me the most fun part is getting something that works. Design the goal, but not micromanage and get lost in the details. I love AI for that, but it is hard really owning code this way. (At least I manually approve every or most changes, but still, verifying is hard).
- bitwize 7mo ago
  AI has really sharpened the line between the Master Builders of the world and the Lord Businesses along this question: What, exactly, is the "fun part" of programming? Is it simply having something that works? Or is it the process of going from not having it to having it through your own efforts and the sum total of decisions you made along the way?
- jurgenburgen 7mo ago
  > For me the most fun part is getting something that works. Design the goal, but not micromanage and get lost in the details. That’s management, which is not necessarily bad by itself. What is bad if you have to be both a manager giving the requirements and the IC responsible for the output. That’s the worst of both worlds. If it was possible to truly vibe code in the same way a product manager asks a team to build something then we wouldn’t need to have this discussion. In reality you can never truly trust the output. Ultimately you’re on the hook if production breaks apart, not the LLM.
HoldOnAMinute 7mo ago
I am really enjoying making requirements docs in an iterative process. I have a continuous improvement loop where I use the implementation to test out the docs. If I find a problem with the docs, I throw away the implementation, improve the docs, then re-implement. The kind of docs I'm getting are of amazing quality.

throwaw12 7mo ago

> You do I really want to say: "You are absolutely right" But here is a problem I am facing personally (numbers are hypothetical). I get a review request 10-15/day by 4 teammates, who are generating code by prompting, and I am doing same, so you can guess we might have ~20 PRs/day to review. now each PR is roughly updating 5-6 files and 10-15 lines in each. So you can estimate that, I am looking at around 50-60 files, but I can't keep the context of the whole file because change I am looking is somewhere in the middle, 3 lines here, 5 lines there and another 4 lines at the end. How am I supposed to review all these?

radlad 7mo ago
I don't quite follow - are you describing an issue with the way your team has structured PRs? IMO, a PR should contain just enough code to clearly and completely solve "a thing" without solving too much at once. But what this means in practice depends on the team, product, velocity, etc. It sounds like your PRs might be broken up into too small of chunks if you can't understand why the code is being added.
- throwaw12 7mo ago
  I am saying PRs I get are around 60-70 lines of change, which is small enough to be considered as single unit (add to this unit tests which must pass with new change, so we are talking about 30 line change + 30 line unit test) But when looking at the PR changes, you don't always see whole picture because review subjects (code lines) are scattered across files and methods, and GitHub also shows methods and files partially making it even more difficult to quickly spot the context around those updated lines. Its difficult problem, because even if GitHub shows whole body of the updated method or a file, you still don't see grand picture. For example: A (calls) -> B -> C -> D And you made changes in D, how do you know the side effect on B, what if it broke A?
  - cesarb 7mo ago
    > Its difficult problem, because even if GitHub shows whole body of the updated method or a file, you still don't see grand picture. > For example: A (calls) -> B -> C -> D > And you made changes in D, how do you know the side effect on B, what if it broke A? That's poor encapsulation. If the changes in D respect its contract, and C respects D's contract, your changes in D shouldn't affect C, much less B or A.

deleted 7mo ago