This reminds me of a Pre-LLM-slop era issue I had with a process that a co-worker had created via a shared script that would automate combining many dependabot PR’s into one consolidated PR.
The script was excellent because it simplified the review process for a single repo (that had many competing dependsbot PR’s) and it also happened to do this across increasingly many many different repo’s simultaneously.
Funny thing is, however, that it also created a team dynamic where who ran the script became almost a race because the effort in creating x pr’s didn’t correspond at all to the effort required to review x pr’s.
The optics were also lopsided since the script would operate on the runner’s local machine and so it would have seemed as if the person who made all these PR’s was highly efficient at producing when in fact it was the reviewer doing the majority of the work.
Also reviewing represented a chunk of a developer’s day so it would affect other actual work the developer was tasked to do anyways.
In an agile workplace points (correctly or not) completed are attributed only to the code creator with no points at all being shared by those who reviewed the work, and rightfully so I’d argue because tangentially reviewers can also tend to just click “approve” (or slap a LGTM) without much effort into critiquing a piece or giving a thoughtful review. Why? It slows down the introduction of the feature (the PM won’t like that, why would you slow down the process eh? You grumpy goose), it messes with team dynamic (you may end up offending those who you review, who also happen to be the one who you need to review your work, who then may be petty or worse, mud slow to review your own PR’s), it takes additional time to provide reviews that seem as if you even read the PR or don’t come off as flippant (did you provide examples or a suggested refactor or detailed reasons), and it takes context because you may be working currently on a totally different project (regardless of your experience/authority in the PR’ed repo), so giving an honest review may sacrifice even more time to first review the purpose of the PR and how that lands in the context of the target repo(s) and then sacrifice the time necessary to reorient yourself to the task you previously had in process. With all this…that “approve” button becomes sooooo tempting.
It’s funny because fast forward some of the ways I battle increasingly prolific AI generated material is through GitHub’s CoPilot bot. I ask it to do the review first and when it gives the review there is none of that dynamic because it wasn’t me who levied the criticism and also it’s not me who is trying to block code integration (so no grumpy goose or team dynamics problems). Having a bot do preliminary checks almost does what git hooks did for team dynamics way back when automation of linting, testing, style, etc was introduced as a common part of the review process. And I say “almost” because a)sometimes the critiques from the bot are wrong and b) the critiques aren’t necessarily deterministic, so just because they are there or not doesn’t mean you are truly relieved of that portion of the review process (for better or worse).
It’s very helpful to know the motivation for the commit and if that motivation was tied to a client contract/feature. Especially in cases where a commit affects multiple files or even just one file so that all commits can be grouped into a feature/contract.
COMPANY-1234 in the title doesn't tell the reader all that much about the the feature or motivation. It does tell the client, but I'm not seeing why that is better than having it in the description as a tag, or some other nice way of extracting it.
Least of all when that ticket is older and so much of the code and the company has changed too. Like sometimes useful historical context sure but worth putting in the first line of a commit? I put it in the body with a link to the ticket or tickets as a footer, if someone wants historical context it's there.
I have a friend who’s doing this for himself. He owns an AC business. He has need for tools but does not like plunking down money for a feature set that moves him in a direction he doesn’t wish to go. Solution? Create a bespoke internal system of one off apps for his OWN business using an LLM.
He’s not a software developer, he has no concept of software maintenance or security.
I’ve been watching and it’s interesting to me because I would not be surprised that he’s not alone as a small family business. Many probably feel liberated from company’s that would enforce a certain cookie cutter shape.
Does this mean AI is shifting towards contractor jobs more? Does it mean a huge security issue brewing? Both? Maybe business owners turned SWVibers like him will swing back to an off the shelf option once pouring more effort into 3am-my-stuff-is-broke scenarios becomes more of a chore than it’s worth.
I feel like there are a million billion green field projects brewing that will soon turn brown for one reason or another.
> Maybe business owners turned SWVibers like him will swing back to an off the shelf option once pouring more effort into 3am-my-stuff-is-broke scenarios becomes more of a chore than it’s worth.
I mean, that's what, as an industry, we're all desperately hoping for, but, well, shit. ChatGPT-5.5 is quite capable, so if the business owner is disciplined and prompts it with thought, I'm not so sure those greenfield projects are going to turn brown. Hell, if I was an AC business owner, would I rather pay a software startup who think they know the AC business, or pay another AC business owner to use the software they wrote?
"Your job isn't going to be taken by AI, it's going to be taken by someone using AI" -Jenson Huang
Problem is, that person using AI is from outside our field. (Not a problem for the AC business owner who has a new product to sell! Good on them, if they choose to go that route.)
Are you ever supposed to inherit from the protocol though(unless you’re defining another protocol)? One of the great things about protocols is that your class doesn’t even have to know about the protocol explicitly. What this code looks closer to doing (style wise) is an abstract base class
"To explicitly declare that a certain class implements a given protocol, it can be used as a regular base class. In this case a class could use default implementations of protocol members. Static analysis tools are expected to automatically detect that a class implements a given protocol. So while it’s possible to subclass a protocol explicitly, it’s not necessary to do so for the sake of type-checking."
I’m not sure if you were expecting the boo’s to totally drown out the speaker. The audio system for orators in those types of venues are made to focus on the orators voice, not that of the audience. The fact that they were audible at all (they WERE) is to say they were substantial. The fact Schmidt recognized hearing them and from time to time had to pause to make a point means he was speaking through the crowds discontent.
It was a good watch - I appreciated hearing the audible boos. I’m not the only one in the room who is concerned about the adoption of AI being overly cavalier without clear evidence it’s even worth it / or that you go to school and are told great now you MUST learn this, your degree choice (your dream) is moot - the message has been “deal with it”. That’s not to say there isn’t already plenty evidence online that supports the thought, but hearing it from a college campus audience makes me think about what my son is going into right now, that my concern is real.
I’m torn really because I am already benefitting from the tools provided. I can see
their utility. And, though, I actually agree with Schmidt’s overall message - it was truthful and felt genuine, it’s an unfortunate reality. Who’s going to cheer that? So good on him for being naive to that fact or willing to endure an obvious boo fest.
AI’s fun but life is more fun. Speed is fun, but so is sitting down for a sec to chat with friends. Maybe the backlash against AI is because we’re still grappling with the onslaught of the internet and smart phones. The unintended negative effects we have yet to solve today (Schmidt even starts his speech referring to them before he brings up AI almost as if to say, “look how well these blunders went, now hold my beer”). Youth and people in general feel robbed, they have become a cog in someone else’s machine and AI doesn’t free you from it - it’s not like businesses are saying “oh excellent! we can get the work done faster, let’s decrease the amount of hours we make people work to get their wage. Let’s let them benefit from this boon of productivity.” No! The opposite, “We will kick you and if you want to stay, be happy you’re here and willing to run in this fever pitch rat race that has just introduced a rapidly increasing devourer that runs behind you.” … “Want weekends!? AI doesn’t, hmm is that the way you ‘demonstrate what it means to be human’?”
My mind keeps on thinking that what I am really being told is it’s time to start my own business because I will only ever be the person to give me a weekend off.
Showdead is quite a disheartening experience - there’s just so much LLM generated crap. The dead internet theory doesn’t feel as fringe as it once did.
The script was excellent because it simplified the review process for a single repo (that had many competing dependsbot PR’s) and it also happened to do this across increasingly many many different repo’s simultaneously.
Funny thing is, however, that it also created a team dynamic where who ran the script became almost a race because the effort in creating x pr’s didn’t correspond at all to the effort required to review x pr’s.
The optics were also lopsided since the script would operate on the runner’s local machine and so it would have seemed as if the person who made all these PR’s was highly efficient at producing when in fact it was the reviewer doing the majority of the work.
Also reviewing represented a chunk of a developer’s day so it would affect other actual work the developer was tasked to do anyways.
In an agile workplace points (correctly or not) completed are attributed only to the code creator with no points at all being shared by those who reviewed the work, and rightfully so I’d argue because tangentially reviewers can also tend to just click “approve” (or slap a LGTM) without much effort into critiquing a piece or giving a thoughtful review. Why? It slows down the introduction of the feature (the PM won’t like that, why would you slow down the process eh? You grumpy goose), it messes with team dynamic (you may end up offending those who you review, who also happen to be the one who you need to review your work, who then may be petty or worse, mud slow to review your own PR’s), it takes additional time to provide reviews that seem as if you even read the PR or don’t come off as flippant (did you provide examples or a suggested refactor or detailed reasons), and it takes context because you may be working currently on a totally different project (regardless of your experience/authority in the PR’ed repo), so giving an honest review may sacrifice even more time to first review the purpose of the PR and how that lands in the context of the target repo(s) and then sacrifice the time necessary to reorient yourself to the task you previously had in process. With all this…that “approve” button becomes sooooo tempting.
It’s funny because fast forward some of the ways I battle increasingly prolific AI generated material is through GitHub’s CoPilot bot. I ask it to do the review first and when it gives the review there is none of that dynamic because it wasn’t me who levied the criticism and also it’s not me who is trying to block code integration (so no grumpy goose or team dynamics problems). Having a bot do preliminary checks almost does what git hooks did for team dynamics way back when automation of linting, testing, style, etc was introduced as a common part of the review process. And I say “almost” because a)sometimes the critiques from the bot are wrong and b) the critiques aren’t necessarily deterministic, so just because they are there or not doesn’t mean you are truly relieved of that portion of the review process (for better or worse).
reply