Problem isn’t with “tastes better and at half the calories”, no, it is actually for providing filler when the initial sell was using genuine simple ingredients.
The software analog is like a certain Italian company that buys SaaS companies and waters down the initial product, firing then very ingredients that made the product good in the first place in an effort to:
- extract maximum profit
- ride the coattails of trust a brand has garnered.
I won’t speak to the odd coincidence of their name and its relation to ice cream.
Some people aren’t buying icecream to lose weight. That’s not their purpose. It’s to indulge and enjoy artisanal foods where the purpose was high quality not high margins.
Of course I don’t buy that icecream much anymore - I just buy Andies custard by the quart.
“Maintainability” is probably the word you are really looking for. Few devs care whether something adheres to whatever as long as we maintain:
- user experience/expectation (i.e., if feature X worked three years ago, it still works in a consistent way today after a bug fix)
- development cadence (if implementation of feature X took N days, a comparable feature Y should take N days)
- sanity (can we assume that a fix going in Thursday night or Friday morning doesn’t wreck the weekend)
SOLID, DRY, ACID-compliant, linted, formatted, clean, functional, compositional, etc. May be the means (misdirected or otherwise) but they are not the motivator(or at least should not be).
What matters is whether the day two feature requests, bug reports, CVEs, and traffic load that are coming can be met on time.
Not saying it can’t be done without a developer at the helm, Anyone Can Cook™, but I guess it depends on what harness is in use or has created for the org, and whether that consideration is baked into the guidelines for the codebase (which seems to be, at least to some extent, what this service tries to course correct).
And of course, what is done to the process when incident x happens, again and again. Are we only updating code without paying attention to process that enabled it in the first place?
Maybe that’s the story of vibe coded repos: the code devs were removed but we really still need devops personnel. Also maybe new tech will be more readily adopted.
I mean for local dev I like that I can just press one button and have Kubernetes available. Podman Desktop had something approaching that simplicity but I have found Docker Desktop more stable in my limited experience with it.
Uncle Bob is awesome, maybe some of his ideas aren’t iron clad but he embodies a great engineer and person. Every time I’ve listened to (https://youtu.be/UBXXw2JSloo) or (now) read interviews the guy is humble, listening, and it would seem extremely genuine.
Corruption is ever present. No counter to it is what kills countries.
The US has been security by obscurity in so many ways, this latest abuse is just further evidence that counting on it would only ever delay abuse for [checks calendar] about 250 years.
And really is has been in free fall for decades, the fact that so many recent examples are so flagrant (along with this) is what is upsetting (mainly because no one with any power is moving to stop it in any meaningful way).
I’m not sure what the US government is trying to do. At first it seems like they are just trying to stifle some company that said no. Now they are just doing free publicity. It’s like never before have I wanted to try something out as much as this.
They’re in effect saying “nothing else is as powerful as what Anthropic put out”. Even though that might not really be the case it’s what it sounds like.
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.