| ▲ | sollewitt 4 hours ago |
| This only solves part of the problem, the other half is: ok so you have 3 chats going, at some point you realize you have 3 >10k line CLs to review, on top of code your colleagues are asking you to review. Every review I’ve ever done I’ve found overfitting and brittle solutions and things tacked on instead of integrated so I refuse to give up on code reviews, but those are my real bottleneck, and having three is so much worse than one because my context and understanding is diluted and a bit muddled. I want to time how long it takes me to land code and I suspect going serial on one thing will be faster than going parallel on multiple things. Parallel feels faster but the code review takes longer. |
|
| ▲ | acheron9383 3 hours ago | parent | next [-] |
| I end up in similar situations, the codebase I work on demands a level of professionalism opus5.5 can't muster on the first pass. Code review remains the bottleneck. Usually I approach it like a code review, reading through and as I find things I markup the code, then afterwords I have the agent collate all the feedback and we discuss and it re-implements. Usually I can simplify and improve a lot in like 3 passes. One thing that speeds up the reviews and improves my ability to find issues and provide guidance is having the agent work on better review guides (think an html page rendered locally, with object diagrams, decisions/assumptions, animations of data flow if it makes sense, whatever). Those in hand I can read the codebase faster and talk against that document too. I think the end result is better code than I could previously write by hand, in probably 5x the speed. Usually I can't do more than two projects in parallel though. |
| |
| ▲ | sollewitt 2 hours ago | parent [-] | | Yeah, that makes a ton of sense, I'm going to try this - I particularly like the idea of making animations of data flow. | | |
|
|
| ▲ | SamerIA 4 hours ago | parent | prev [-] |
| What models are you using? At this point I'd only use Opus 5.5 for any serious work where I care about the code, so I'm interested if you're still seeing brittle solutions with it |
| |
| ▲ | ncruces 3 hours ago | parent | next [-] | | CL (change list) is Google speak for a PR [1]. So, likely: Gemini Flash, Argon, Carbon [2]; and Claude Opus [3]. Maybe more. https://google.github.io/eng-practices/review/developer/cl-d... https://blog.google/innovation-and-ai/models-and-research/ge... https://www.businessinsider.com/google-finally-lets-all-engi... The models are great, but the experience resonates. It really depends on what you're doing, and ultimately, how much you care. A 10k LoC PR that feels “tacked on” should help you guess the size of the code base. So do you care about getting 10k LoC to review, in a 1M LoC code base? How about 3 such PRs? How about reviewing another half a dozen, from colleagues? And doing that 2 or 3 times a week? | |
| ▲ | user43928 3 hours ago | parent | prev | next [-] | | It depends on how you define brittle. Functional code that is perhaps overly defensive or specific in ways that will require updating it in the future? All the time. What many do not yet understand is that the maintenance burden is a fraction of the effort that it takes you to review the code, much less iterate on it. I see people on here talk about a supposed eventual collapse of maintainability if they do not review or understand the code. In reality this never happens. The latest models can salvage and refactor even the biggest mess; all you need to do is ask. They could probably do it even if source code isn't available and you only have a binary to work with. | | |
| ▲ | zarldev 43 minutes ago | parent [-] | | Brittle by building ever more increasing numbers of abstractions rather that take a coherent view of some things. So over time you have these "seams" that the code base ends up looking like a punk motor cycle jacket. |
| |
| ▲ | 01100011 4 hours ago | parent | prev [-] | | I don't know how you can expect a useful answer to that question without you and OP syncing up on what you're working on. The experiences of, say, a python network programmer vs a C/C++ GPU engineer are going to be worlds apart. I think a lot of pointless arguments on HN stem from a failure to realize that "software" is too big of a field to generalize much of anything. |
|
