Specs weren’t the problem with waterfall. The difficulty in changing them to match reality was.
The waterfall process I experienced went like this:
- Product folks created requirements
- architects produced detailed specs
- project managers created tickets based on specs
- lengthy estimation ensued.
- Then finally developers proceeded with implementation.
- QA tested it.
Each step above involved lengthy review with like 5-10people. If the devs found an issue with the spec or god forbid the requirement it triggered a massive cascade of work for everyone above. Things needed to be reviewed again, customers may need to get contacted, …etc.
I think we can learn from that and optimize for change. Specs as living documents close to the code should be less cumbersome. But, just like anything else large corporations will probably fumble this like they did with “agile” (SAFe I am looking at you).
This is a long way to say specs aren’t bad. Specs that are difficult to change are though.
Changing the default behavior for all of your users with no notification is pretty unforgivable. Even if this feature worked correctly, it obviously doesn’t, this should at minimum be a prompt after upgrade to let the user confirm that this is what they want. But honestly should be opt in for those that want it.
To have it silently just start adding marketing copy to git commit messages is pretty bad. To have that added text not be visible to the user in the UI so they can remove it before commit is just much worse.
This kind of thing being released speaks to a greater disfunction over there. Not a good look at all and I am not a Microsoft or AI hater. But my commit messages are not where you move fast and break things
> Changing the default behavior for all of your users with no notification is pretty unforgivable.
I noticed that as soon as you make a bug report/feature request on VSCode's repo, you instantly get someone's OpenClaw agent with an automated pull request that sometimes wants to change defaults in the main codebase
Looks like AI is really trigger-happy with that, with zero understanding or care that there's thousands of users affected and it's not just one individual's settings.json
Also, the hallucinated PR does not necessarily address the original issue whatsoever, just like this PR. It should have functionality to detect AI-authored code, but whoever made the PR skipped actually doing the hard work and just changed a default to always on, exactly the kind of misunderstanding you see with OpenClaw shotgun PRs
And then they apparently posted an alibi "I'm sorry" here. Or maybe it is genuine, but the choice is between incompetence and fake "I'm sorry". Where is QA?
> To have it silently just start adding marketing copy to git commit messages is pretty bad. To have that added text not be visible to the user in the UI so they can remove it before commit is just much worse.
This is one of the problems, but it is not only one. To be better, should be:
1. It should be visible in the UI for entering the commit message, to make it clear what it is doing.
2. It should not add such a thing if the Copilot is disabled. (It is mentioned by dmitriv and would hopefully be fixed soon enough)
I do not use Copilot nor any other LLMs nor VS Code, but if the problems are corrected then I think the feature would probably be reasonable.
No, it's fine. I really hope that more people will switch to something else, like Neovim, Emacs, or any other open-source editor where such unacceptable situations are practically impossible. I hope more people will start to value their privacy and right to choose, and find the courage to say gtfo and switch to something else. Because this is unforgivable.
It just means that when changing a global default with such impact the user should be prompted with an option to opt out of the new behavior. Something like “AI assisted changes will now have ‘coauthored by Copilot’ added to the commit message”. If the user clicks “no thanks” it changes their local setting to “off” to opt them out of this new global default.
Not sure of what current prices look like but an old desktop sitting on the floor of your office might work well for you. You would need decent internet but running a single node kubernetes cluster as a GitHub action runner has worked well for others I know.
A buddy of mine runs his whole CICD setup off an old gaming desktop. They use tailscale to connect to their hosted infrastructure and set it up as a GitHub action runner.
I stay 1 major version behind with MacOS. If you do that you should have a pretty stable experience. You still get all the security patches but skip most bugs/regressions.
Also the article doesn’t attempt to explore the business and resourcing constraints they were operating under at the time.
I have been in situations where I was told “don’t worry about cost just get it done”. Then a few years later the business constraints shift and now we need to “worry about the cost”. It ignores that decisions made under a different set of constraints were correct, or at least reasonable, at the time but things change.
One of my pet peeves is when people say “do it right the first time” but the definition of “right” often changes over time. If the only major flaw of this design was that it was expensive; then I am much more skeptical that it was wrong given the original set of conditions that they were operating under.
Yeah, this is exactly what I thought when I read this post. It seemed like the author either hasn't worked in big tech, or hasn't worked in the industry very long. It's extremely likely that the engineer who designed this was standing on his desk shouting "it's going to cost THIS MUCH MONEY. I want to make sure that EVERYONE IS OK WITH THIS." and was met with shrugs.
Here's how a big tech reporting chain sees this situation when everything is smooth sailing: "We're growing 3x year-over-year? After 2 years, the cost will be an order of magnitude higher no matter what solution we pick. The constant factor doesn't matter that much. But we have such an incredible roadmap that we will book more than an order of magnitude of revenue, backed by this new ledger project. The cost will always be a nonissue because of growth."
And then 2 years go by, and this incredible product growth adds a bunch of ledger entries that weren't there 2 years ago, someone nudges your reporting chain with the question, "this is pretty expensive.. what gives?" and then someone with a good combination of social and technical skills points out that a migration to your existing storage solution would be a cost effective way to continue growing.
At every step of the way, everyone is generally happy with what's going on.
Also totally possible that it was just an unpublished partnership of sorts between AWS and Uber. AWS wants the logo and a big case study implementation to give the product some credibility or a boost. Uber may not have been charged at all, may have even been paid to use AWS. The Uber developer may not have even known, just was given an edict to build it on dynamodb.
I think it's important for leadership to clearly define what right is in these cases, too, otherwise, you get as many ddefinitions of "right" as you have people, times, and places.
Easy to say, but it's a real human cost to relying on people to figure out what you mean rather than explaining what you mean. Not enough time is spent on cultivating effective communication and training. Everyone wants everything done yesterday and don't feel like investing in their own people.
Amen, right now I’m rewriting some code and parts of an application after running for years. So I have all the advantages of knowing the bugs and history.
There is zero chance anyone who wrote this the first time would do what I’m doing.
Some things I’m simplifying because it never becomes a spot that the previous devs thought would be a big pivot point for customization and heavy use….
If this requirement was in place they would be a bit more careful about terminating accounts because the cost equation would incentivize it. Maybe they would be more careful in their automation or require more than one level of human review before cutting off access.
These companies are gatekeepers for their platform. It isn’t crazy to require them to act more responsibly.
Apple is in the process of fixing Tahoe which was a regression from Sequoia the previous release. Tahoe is decent with 26.4 though from what I am hearing. Either OS version is far far better than regular Windows 11 though.
Apple’s real differentiator is their silicon. M series chips are just incredibly good and you get a full workday out of them on battery.
The M1 Pro I still have at work is easily the best laptop I have ever used. For side projects I use an M4 air with maxed out RAM and it has no issues with anything I have thrown at it.
I'm also still on my M1 and I just don't see a need to upgrade. I've never owned a laptop this long without even considering getting a new one. It's still so fast, so cool, great screen, biometric unlocking... it's just incredible.
I have seen this mostly on teams which refuse to formalize preferences into a style guide.
I have fixed this by forcing the issue and we get together as a team, set a standard and document it. If we can use tools to enforce it automatically we do that. If not you get a comment with a link to the style guide and told to fix it.
Style is subjective but consistency is not. Having a formal style guide which is automatically enforced helps with onboarding and code review as well.
Hard agree here. I think the best predictor of whether someone will be good, eventually, at something is “do they love it”. If they do then chances are they will spend lots of focused time practicing and actively seeking out ways to get better.
Maybe that love, or at least liking something, comes from inherent talent to some degree but all the talent in the world won’t help you if you don’t put in the time.
https://newsroom.cisco.com/c/r/newsroom/en/us/a/y2026/m05/ci...
reply