If the agent does everything for you it means it can do everything for the next person. At that point you're replaceable and have no value in your field. Learn things deeply even if you use AI because its the deep knowledge workers that will keep getting hired.
> Learn things deeply even if you use AI because its the deep knowledge workers that will keep getting hired. The problem is that this realistically is only applicable and actionable to a subset of the labor pool, and that subset is decreasing. There are a lot of people who discovered that their "deep knowledge" and "deep skill" wasn't as deep as they thought (read: "deep" enough to make them irreplaceable to their e…
If you are asking for human attention, demonstrate human effort
211–220 of 551 posts
Re: If you are asking for human attention, demonstrate human effort
#212So feel free to use AI to pimp your resume, they will use AI to process it.
Re: If you are asking for human attention, demonstrate human effort
#213A very prolific coworker who fully embraced claude has inflicted the team with a flood of AI-generated PRs. About six months later, it is his frequent bemoaning at the standup that their PR don't get reviewed, languishing in inattention. I don't think anyone - including myself - _intentionally_ avoid his PRs. It's just that he doesn't make it easy for the team to look at. This single headline perfectly captures what…
Even before AI, I've worked with people who would produce a huge wall of code and ask for review, and sometimes that code was completely off base or needed a significant rework. I would always feel bad in those cases, because it's clear they spent a lot of time, and I'm going to have to say "no" and they will feel like they wasted a ton of effort. The thought process around this has started shifting for me in the las…
Re: If you are asking for human attention, demonstrate human effort
#214Earlier quoted context omitted.
In big software teams, the bottleneck is team communication. I've run big and small teams. If I want to speed things up, I remove people from the team. Everything gets easier. This has worked amazingly well every time I've done this over the past decades. Removing people doesn't have to mean firing them necessarily. Splitting teams is a good reflex. But of course the people you remove from a team are typically not th…
> I'd question the added value of manual PR reviews at this point. Yeah, why not reduce the team size to zero while you are at it? These generalizations about software engineering have never been useful, IMO. Context is everything, there is no flow chart for building a perfect software process. Although, I'd say you are absolutely delusional if you think we are universally beyond the point where manual review of pull…
Re: If you are asking for human attention, demonstrate human effort
#215A very prolific coworker who fully embraced claude has inflicted the team with a flood of AI-generated PRs. About six months later, it is his frequent bemoaning at the standup that their PR don't get reviewed, languishing in inattention. I don't think anyone - including myself - _intentionally_ avoid his PRs. It's just that he doesn't make it easy for the team to look at. This single headline perfectly captures what…
Run several rounds of such reviews until the clanker fails to find problems.
Re: If you are asking for human attention, demonstrate human effort
#216A very prolific coworker who fully embraced claude has inflicted the team with a flood of AI-generated PRs. About six months later, it is his frequent bemoaning at the standup that their PR don't get reviewed, languishing in inattention. I don't think anyone - including myself - _intentionally_ avoid his PRs. It's just that he doesn't make it easy for the team to look at. This single headline perfectly captures what…
I like this rule of thumb: Spend more effort producing the work than it takes for someone else to consume it.
Re: If you are asking for human attention, demonstrate human effort
#217Earlier quoted context omitted.
As a last resort, do the code-review with a live pair programming session. If they can't explain their own code then it is by default a bad pull request. At the end of the day, everyone's time is being wasted on tokens and on the increasing cognitive complexity of AI generated code.
So if they say "idk Claude did it", what would you write in the PR review box?
Re: If you are asking for human attention, demonstrate human effort
#218Earlier quoted context omitted.
So if they say "idk Claude did it", what would you write in the PR review box?
"Author of this pull request has not yet reviewed code and does not understand it. This PR was submitted prematurely, probably by accident. Please, check whether you accidentally submitted other unreviewed code - and close such PRs for now and reopen once reviewed."
Re: If you are asking for human attention, demonstrate human effort
#219Earlier quoted context omitted.
why leave comments intended for your human colleague when they will only forward them to the bot? why not speak directly to the bot yourself instead? then you can drop pretenses and get to the point I find this to be a new variant of the old behavior where a colleague comments on a typo in a PR, and the team later moans about laborious back and forth for small nitpicks, instead of simply editing the typo right there…
yeah I have this happen to me. I occasionally get screenshots of claude sent to me!
Re: If you are asking for human attention, demonstrate human effort
#220A very prolific coworker who fully embraced claude has inflicted the team with a flood of AI-generated PRs. About six months later, it is his frequent bemoaning at the standup that their PR don't get reviewed, languishing in inattention. I don't think anyone - including myself - _intentionally_ avoid his PRs. It's just that he doesn't make it easy for the team to look at. This single headline perfectly captures what…
Even before AI, I've worked with people who would produce a huge wall of code and ask for review, and sometimes that code was completely off base or needed a significant rework. I would always feel bad in those cases, because it's clear they spent a lot of time, and I'm going to have to say "no" and they will feel like they wasted a ton of effort. The thought process around this has started shifting for me in the las…
I get this feeling, too. I do however think the onus is on the developer to make something reviewable by their team members if they want a speedy review. Stacked PRs, scoping things down, properly structuring commits so you can review commit-by-commit for example.
I also think that "I spent a bunch of time on this" is not a valid reason for expecting an approval. It should hurt if you've produced a bunch of code that is way off target, even if it ends up implementing the feature. That's how I learned at least.
A proper way to go about large projects, in my opinion, is the same as with software development at large. Fail fast if possible. Draw up a crude boxes and arrows sketch or just discuss how you want the code to integrate with whatever already exists and invite the team to comment. If no one has anything to say, well then they can't complain later when you implement that approach. But if anyone cares then most likely valueable input will come that makes the end result better.