It's clear they consider code review a personal activity than team activity, in the sense that they think "code review is a gate before my code can be merged" rather than "code review is a process where the team discusses, understands and improves the code".
And that's not rare in teams. Lots of teams and developers do code review wrong.
I even hear other people complain that I "block" their code review. I mean, if there are issues in your code, of course I am going to flag them, what do you think the purpose of code review is?
> Lots of teams and developers do code review wrong
In this sense, I'm not sure I've ever seen a team that does codereview "right".
In the before times, most PR feedback was stylistic, with the occasional bug identified. Now that we have ubiquitous auto-formatters/linters/CI, most PR review falls into either "you misunderstood the spec", or "I disagree with your architectural choices" - and my personal feeling is that your process ought to catch both of those well before the PR stage
Yeah, that's fair. I have spent most of my career on high-pressure teams within FAANG, where we aggressively managed-out anyone who wasn't making the grade. And now in the startup world, we apply a very aggressive hiring bar.
I'm not sure how much I'd enjoy working on teams who were routinely producing PRs that were in bad shape.
This is such a weird take. From my 5 years at Amazon, the only people I saw "managed out" were engineers who were good, it even great, at the code part of their job, but trash at working with the team. Our hiring bar was notoriously high, and it wasn't uncommon for engineers who were leads at their startup to get hired at L5.
When I was Bar Raising for promotions, I didn't review their PRs, I reviewed their Reviews. I reviewed the PRs that mentioned those reviews to see what slipped by. I looked at non-crunch time to verify they were reviewing at least as much code as their teammates.
If I saw someone 4x-ing the amount of code, they had better be 4x-ing the reviews too... if all they were leaving was stylistic formatting comments, they'd never make it to L6, unless the only thing they were reviewing was L6 code.
On your original claim, I have seen engineers put up 5x more PRs simply because they paid less attention to the quality or put less thought on each one of them.
I have seen people put up 5x more quality PRs too. But as long as they follow the good practice of doing a code review for every PR they put up (or 2 if you require 2 per PR), they got their stuff through quickly as well.
> your process ought to catch both of those well before the PR stage
We have multiple points where mistakes of any sort can be caught, and code review is one of them.
Yes, most architectural issues should be caught earlier, but some will only become evident in code: some by the dev themselves, others by reviewers.
This is only a problem if you mostly catch architecture issues at code review phase.
For a model, yeah absolutely. You'll spend virtually 0 tokens on memory safety, which means your token budget gets allocated elsewhere. If you wrote a C codebase you'd need to allocate some portion of your budget towards memory safety.
Let's expand the actual quote we're responding to:
> the borrow checker woes can be offloaded to the model, you focus on all the other programming logic
Then the person you responded to asked if "you" really do "focus on all the other programming logic", given that "the model" deals with the borrow checker. In other words, they're asking about the work the actual human is doing at that point. You then replied talking about the model again and token budgets. In effect, you brushed the question under the rug and imply that _everything_ is offloaded to the model, no focus by the human required.
I think we are talking about ROI in terms of solving real world problems and making real impact, not the fact that a tool has been ported from language X to language Y.
It'd seem weird to plan to use this until the readme stops saying
> it has been nearly entirely written by agents and has not been used for realsies. It's probably currently unusably slow or completely broken in ways that are not exercised in the test suite.
Right now it's someone else's experiment that is still in the "might or might not pan out" stage.
There are a bunch of projects using the similar (not vibe coded, less fully featured) gitoxide project - there is demand for git-as-a-library.
I would not use this except to help us test it if interested. I'm announcing it because it's interesting and a milestone in the breadth of test coverage it can pass. It almost certainly cheated on a bunch of those tests and is not feature complete yet.
The author of gitoxide is also working on GitButler (who worked on this project) and we're pushing both projects forward and actively using and developing Gitoxide as well. This is simply a different and hopefully complimentary approach to the same problem.
> because it's interesting and a milestone in the breadth of test coverage it can pass.
Sorry, no. Let me be candid and point out that this has achieved exactly nothing except lighting $8k on fire.
Put it this way: if I suggest to my boss, "I want to spend $8k of company money to port git to Rust to just see how many tests can pass in that project, even though I don't plan to develop new features with the project, and I don't care about adoption", he is going to shot down the idea in half a second and seriously question my competence.
I was immediately excited about this wrapped in Python because the current Python git bindings are kind of obtuse, but they do work so I guess I can't complain.
Wordpress is/was successful because it's braindead and has a solid userbase. I am not to flame WP, but it's a quality to target a specific group of consumers.
It's an organic success, hard to replicate. If at all, CF can only make people migrate with massive effort. Marketing effort, selling lots of snake oil in the process. WP wont just hop on the hot new thing, WP is the definition of the opposite. It works for them. Why change.
Git is the same on the other side. It requires maintenance and improvements, surgical and correct. No git maintainer has time to learn a gigantic new codebase and they will stick with what works for them. For git users there are no advantages. So similarly it would require a long time effort to push the project, building trust that it is somehow better, probably requiring Linus to say "it's great".
Enterprise GTM for these behemoths relies on offering everything a customer needs so they don’t shop around. It’s Microsoft’s playbook and AWS copies it for the same market. That’s why they each offer a “good enough” (but objectively garbage) solution for everything under the sun.
(Their opinion section is of course a different matter.)
reply