Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If you are good at code review, you will be good at using AI agents

seangoedecke.com

Post reply on HN
Print view View original

91–100 of 203 posts

Re: If you are good at code review, you will be good at using AI agents

#91

Post by [deleted] »

thunky wrote: post #88
HarHarVeryFunny wrote: post #76

Earlier quoted context omitted.

Right, this is the exact opposite of the best practices that Edward Deming helped develop in Japan, then brought to the west. Quality needs to come from the process, not the people. Choosing to use a process known to be flawed, then hoping that people will catch the mistakes, doesn't seem like a great idea if the goal is quality. The trouble is that LLMs can be used in many ways, but only some of those ways play to t…

> Choosing to use a process known to be flawed, then hoping that people will catch the mistakes, doesn't seem like a great idea if the goal is quality. You're also describing the software development process prior to LLMs. Otherwise code reviews wouldn't exist.

[deleted]

Re: If you are good at code review, you will be good at using AI agents

#92

Post by HarHarVeryFunny »

thunky wrote: post #88
HarHarVeryFunny wrote: post #76

Earlier quoted context omitted.

Right, this is the exact opposite of the best practices that Edward Deming helped develop in Japan, then brought to the west. Quality needs to come from the process, not the people. Choosing to use a process known to be flawed, then hoping that people will catch the mistakes, doesn't seem like a great idea if the goal is quality. The trouble is that LLMs can be used in many ways, but only some of those ways play to t…

> Choosing to use a process known to be flawed, then hoping that people will catch the mistakes, doesn't seem like a great idea if the goal is quality. You're also describing the software development process prior to LLMs. Otherwise code reviews wouldn't exist.

Sure - software development is complex, but there seems to be a general attempt over time to improve the process and develop languages, frameworks and practices that remove the sources of human error.

Use of AI seems to be a regression in this regard, at least as currently used - "look ma, no hands! I've just vibe coded an autopiliot". The current focus seems to be on productivity - how many more lines of code or vibe-coded projects can you churn out - maybe because AI is still basically a novelty that people are still learning how to use.

If AI is to be used productively towards achieving business goals then the focus is going to need to mature and change to things like quality, safety, etc.

Re: If you are good at code review, you will be good at using AI agents

#95

Post by crazygringo »

skydhash wrote: post #62
crazygringo wrote: post #60

Earlier quoted context omitted.

> Developers like _writing_ and that gives the most job satisfaction. Not me. I enjoy figuring out the requirements, the high-level design, and the clever approach that will yield high performance, or reuse of existing libraries, or whatever it is that will make it an elegant solution. Once I've figured all that out, the actual process of writing code is a total slog. Tracking variables, remembering syntax, trying to…

> Tracking variables, remembering syntax, That's why you have short functions so you don't have to track that many variable. And use symbol completion (a standard in many editors). > trying to think through every edge case, avoiding off-by-one errors. That is designing, not coding. Sometimes I think of an edge case, but I'm already on a task that I'd like to finish, so I just add a TODO comment. Then at least before…

You always have variables. Not just at the function level, but at the class level, object level, etc. And it's not about symbol completion, it's about remembering all the obscure differences in built-in function names and which does what.

And no, off-by-one errors and edge cases are firmly part of coding, once you're writing code inside of a function. Edge cases are not "todos", they're correctly handling all possible states.

> Sometimes the best design is done by doing.

I mean, sure go ahead and prototype, rewrite, etc. That doesn't change anything. You can have the AI do that for you too, and then you can re-evaluate and re-design. The point is, I want to be doing that evaluation and re-designing. Not typing all the code and keeping track of loop states and variable conditions and index variables and exit conditions. That stuff is boring as hell, and I've written more than enough to last a lifetime already.

Re: If you are good at code review, you will be good at using AI agents

#96

Post by giovannibonetti »

HarHarVeryFunny wrote: post #76
rsynnott wrote: post #23

This idea that you can get good results from a bad process as long as you have good quality control seems… dubious, to say the least. “Sure, it’ll produce endless broken nonsense, but as long as someone is checking, it’s fine.” This, generally, doesn’t really work. You see people _try_ it in industry a bit; have a process which produces a high rate of failures, catch them in QA, rework (the US car industry used to be…

Right, this is the exact opposite of the best practices that Edward Deming helped develop in Japan, then brought to the west. Quality needs to come from the process, not the people. Choosing to use a process known to be flawed, then hoping that people will catch the mistakes, doesn't seem like a great idea if the goal is quality. The trouble is that LLMs can be used in many ways, but only some of those ways play to t…

> Quality needs to come from the process, not the people.

Not sure which Japanese school of management you're following, but I think Toyota-style goes against that. The process gives more autonomy to workers than, say, Ford-style, where each tiny part of the process is pre-defined.

I got the impression that Toyota-style was considered to bring better quality to the product, even though it gives people more autonomy.

Re: If you are good at code review, you will be good at using AI agents

#97

Post by em-bee »

code review can be almost as much effort as writing the code, especially when the code is not up to the expectations of the reviewer. this is fine, because you want two people (the original author, and the reviewer) on the code.

when reviewing AI code, not only will the effort needed by the reviewer increase, you also lose the second person (the author) looking at the code, because AI can't do that. it can produce code but not reason about or reflect on it like humans can.

Re: If you are good at code review, you will be good at using AI agents

#98

Post by coffeefirst »

fhd2 wrote: post #14
lapcat wrote: post #9

If you are good at code review, you will also be good at not using AI agents.

This. Having had the pleasure to review the work and fix the bugs of agent jockeys (generally capable developers that fell in love with Claude Code et al), I'm rather sceptical. The code often looks as if they were on mushrooms. They cannot reason about it whatsoever, like they weren't even involved, when I know they weren't completely hands off. I really believe there are people out there that produce good code with…

Yeah.

I'm not even anti-LM. Little things—research, "write TS types for this object", search my codebase, go figure out exactly what line in the Django rest framework is causing this weird behavior, —are working great and saving me an hour here and 15m there.

It's really obvious when people lean on it, because they don't act like a beginner (trying things that might not work) or just being sloppy (where there's a logic ot it but there's no attention to detail), but it's like they copy pasted from Stackoverflow search results at random and there are pieces that might belong but the totality is incoherent.

Re: If you are good at code review, you will be good at using AI agents

#99

Post by HarHarVeryFunny »

giovannibonetti wrote: post #96
HarHarVeryFunny wrote: post #76

Earlier quoted context omitted.

Right, this is the exact opposite of the best practices that Edward Deming helped develop in Japan, then brought to the west. Quality needs to come from the process, not the people. Choosing to use a process known to be flawed, then hoping that people will catch the mistakes, doesn't seem like a great idea if the goal is quality. The trouble is that LLMs can be used in many ways, but only some of those ways play to t…

> Quality needs to come from the process, not the people. Not sure which Japanese school of management you're following, but I think Toyota-style goes against that. The process gives more autonomy to workers than, say, Ford-style, where each tiny part of the process is pre-defined. I got the impression that Toyota-style was considered to bring better quality to the product, even though it gives people more autonomy.

In an ideal world all employees would be top notch, on their game every day, never making mistakes, but the real world isn't like that. If you want repeatable quality then it needs to be baked into the process.

It's a bit like Warren Buffet saying he only wants to invest in companies that could be run by an idiot, because one day they will be.

Edward Deming actually worked with both Toyota and Ford, perhaps more foundationally at Toyota, bringing his process-based-quality ideas to both. Toyota's management style is based around continuous process improvement, combined with the employee empowerment that you refer to.

Re: If you are good at code review, you will be good at using AI agents

#100

Post by sougou »

swaptr wrote: post #45

AI-generated code can be useful in the early stages of a project, but it raises concerns in mature ones. Recently, a 280kloc+ Postgres parser was merged into Multigres ( https://github.com/multigres/multigres/pull/109 ) with no public code review. In open source, this is worrying. Many people rely on these projects for learning and reference. Without proper review, AI-generated code weakens their value as teaching to…

I oversaw this work, and I'm open to feedback on how things can be improved. There are some factors that make this particular situation different:

This was an LLM assisted translation of the C parser from Postgres, not something from the ground up.

For work of this magnitude, you cannot review line by line. The only thing we could do was to establish a process to ensure correctness.

We did control the process carefully. It was a daily toil. This is why it took two months.

We've ported most of the tests from Postgres. Enough to be confident that it works correctly.

Also, we are in the early stages for Multigres. We intend to do more bulk copies and bulk translations like this from other projects, especially Vitess. We'll incorporate any possible improvements here.

The author is working on a blog post explaining the entire process and its pitfalls. Please be on the lookout.

I was personally amazed at how much we could achieve using LLM. Of course, this wouldn't have been possible without a certain level of skill. This person exceeds all expectations listed here: https://github.com/multigres/multigres/discussions/78.

Post reply on HN