If the government is going to gate access to frontier models from here on out, even if new releases are a step function change… which they’re not… then it may be even more comparable to what’s available with a subscription.
As one that does, it’s a difficult discussion to have with the executives. My peers look like their teams are producing more than my teams are and any argument along the lines of “but their code sucks” isn’t going to hold water. The executives care but until there’s actual impact or poor quality, it won’t matter, and it’s a lagging metric. Many still don’t care about technical debt and that’s been well understood in industry for a while.
It’ll take production incidents, impacted customers, and brand damage to make the executives start to prioritize quality over quantity again.
I wonder if there are different use cases. You sound like you’re using an LLM in a similar way to me. I think about the problem and solution, describe what I need implemented, provide references in the context (“the endpoint should be structured like this one…”) and then evaluate the output.
It sounds like other folks are more throwing an LLM at the problem to see what it comes up with. More akin to how I delegate a problem to one of my human engineers/architects. I understand, conceptually, why they might be doing that but I know that I stopped trying that because it didn’t produce quality. I wonder if the newer models are better at handling that ambiguity better.
I agree with you, but my gut tells me that a lot of people don’t know what a good outcome should/could look like and are accepting whatever it delivers.
I just sync down everything from my wife/kids’ Google Drive/Dropbox/whatever nightly to my NAS. Usability of a cloud solution, but with on-prem backup.
> What is sure is that a lot of capacity is been built and that capacity won't disappear.
They really are subsidizing what will be an incredibly healthy used server equipment market in a year or two. Can’t wait. My homelab is going to be due for an upgrade.
I honestly think that the windows phone development experience is where Microsoft majorly shit the bed. The sheer volume of breaking changes (and the severity of those breaks) meant rewriting a non-trivial amount of your app from version to version. I know multiple developers that just dropped support for windows phone as a result.
It’s almost like people that use the tools to the best of their ability will produce higher quality outputs. This is a new tool like we’ve never seen before with a low skill floor to use it. We don’t know what the skill ceiling is yet.
Maybe you’re the person I’ve been looking for but I’ve yet to find someone that actually maintains a zettelkasten that isn’t a researcher/author and doesn’t come to the conclusion that it’s a huge waste of time and energy.
My reading of it also violates the Boy Scout Rule. That is to say: if improving some portion of the codebase would make it better, but inconsistent, you should avoid the improvement; which is something that I would disagree with.
I think adherence to “consistency is more important than ‘good design’” naturally leads to boiling the ocean refactoring and/or rewrites, which are far riskier endeavors with lower success rates than iterative refactoring of a working system over time.