I've had really good success lately with having Claude Code resolve conflicts, to the point that I don't see myself doing manual resolutions going forward.
Set git.conflictStyle to zdiff3 and ask Claude to resolve the conflict, or even better, complete the entire rebase for you. A quick diff sanity check against the merge base of the result takes just a few seconds.
Looks like agent orchestrators provided by the foundation model providers will become a big theme in 2026. By wrapping it in terms that are already used in software development today like team leads, team members, etc. rather than inventing a completely new taxonomy of Polecats and Badgers, will help make it more successful and understandable.
80% of the value of TypeScript is that it will tell you when when you changed or added a parameter and forgot to update it everywhere, you doofus. The other 20% is that it keeps coding agents from going too far off the rails. Trying to use the type system as a metaprogramming language is only valuable as a fun exercise, but of negative value in real world projects.
I use Cursor in anger every day. The core idea behind Cursor is genuinely smart. But the execution is like the classic "unfinished horse" meme [0].
Microsoft provides the editor base, foundation models provide the smarts, and Cursor provides some, in my experience, extremely buggy context management features. There is no moat.
VSCode must have over 100 times the user base of Windsurf and Cursor combined. All Microsoft needs to do is implement a halfway decent version of the context management features these forks added. That alone would be enough to halt user migration.
For users who've already switched to the forks, the cost of switching back is essentially zero, especially if Microsoft begins introducing changes that break fork compatibility. In that case, the migration direction would reverse almost overnight.
Windsurf and Cursor feel like temporary stopgaps, products of a narrow window in time before the landscape shifts again.
Microsoft has clearly taken notice. They're already starting to lock down the upstream VSCode codebase, as seen with recent changes to the C/C++ extension [0]. It's not hard to imagine that future features like TypeScript 7.0 might be limited or even withheld from forks entirely. At the same time, Microsoft will likely replicate Windsurf and Cursor's features within a year. And deliver them with far greater stability and polish.
Both Windsurf and Cursor are riddled with bugs that don't exist upstream, _especially_ in their AI assistant features beyond the VSCode core. Context management which is supposed to be the core featured added is itself incredibly poorly implemented [1].
Ultimately, the future isn't about a smarter editor, it's about a smarter teammate. Tools like GitHub Copilot or future agents will handle entire engineering tickets: generating PRs with tests, taking feedback, and iterating like a real collaborator.
Marketing and Sales budgets are bigger than R&D at most tech companies. So, you can work with the people who's job is literally to spend that allocated pot of money every single month. Or you can try to change how businesses operate.
If your ultimate goal is to work on OSS and to get companies to chip in, I'm quite convinced the former will yield better results and be less frustrating for everyone involved.
I think there would be significant benefits to all parties if GitHub just put the proper automated scaffolding for large scale sponsoring in place instead of relying on such ad-hoc conventions:
1) Individual developers and the companies that want to sponsor projects will otherwise just continue to talk past each other. The developers ask "Why aren't companies donating?" while the very use of the word donation is already a complete showstopper for a company that otherwise doesn't flinch at dropping $50K on a one-day booth at a developer conference that draws maybe 15K visitors at best (a website like Material UI or Webpack probably does 10x that in a month, a perfect fit!). If GitHub doesn't set the system in place, large players like Webpack will continue to "get it" (they offer invoices for sponsors!) while Bob with his 5K stars project will be left out.
2) If the attribution is on a case-per-case basis, companies will continue to select just a few big showcase projects. If the handling is uniform it would be much easier for companies to do things like spreading their spend out all over some segments like "top-100 Go projects" or "libraries built on top of D3" or whatever audience they'd like to target.
3) If there is actually significant uptake in a project, meaning more than a handful of sponsors, it quickly becomes a serious timesink for developers just to track who is active which month at which tier, which sponsors churned etc. and then to actually attribute everything correctly. How about, sponsor picks the project, developer does nothing except gets paid, and all campaign links, logos etc. automatically taken care of. Hmm, I guess what I'm describing is sort of like an AdWords for GitHub now that I think of it :)
This is a nice start for allowing sending "coffee money" between persons. If however you want to drive Serious Money into actually funding OSS projects please remember this: While virtually no company has a donations budget, almost every company has a $$$ marketing budget.
Please let me give you some of that money that would otherwise be spent on blue pens with logos and endless display ads to GitHub projects. I'd be happy to drive $xxK/mo to open source projects my company depends on or that are simply being used by an audience that aligns with our own. To sell that internally, I need (as in, I would be laughed out of the room to propose it without):
- My sponsoring company logo on the GitHub project page
- UTM links and all that jazz to attribute traffic and campaigns to the specific projects that we sponsor
See https://webpack.js.org/ for a good example of a successful sponsorship program. Literally the biggest hurdle remaining for BigCorp to sponsor something like Webpack today is selling your boss on "Patreon" and "OpenCollective". But if you just increase our GitHub budget by a few K/month, AND the marketers get attributable traffic to boot that we can point to, well that's an easy sell!
It's exactly the opposite. You want to make your props as specific to the component as possible to minimize re-renders and pass-through of props causes unnecessary work.
<List items={items} /> will re-render (or at least completely unnecessarily re-evaluate shouldComponentUpdate) the List itself whenever any item has changed.
<Item item={i} /> with a shouldComponentUpdate or better yet React.PureComponent will only re-render the single changed item.
Also, when you do use Redux, as in your nesting example don't pass props through components that don't have any need for them except they propagate the prop to someone else. It's absolutely fine to connect() a component deeper in the hierarchy. Passing everything down is an anti-pattern with Redux, separation of concerns still applies and the props of a component defines the API, don't clutter that API with unrelated things.
Components only receiving props that they themselves need has kept things clean in our massive codebase, and allows you to effortlessly move things about and easily re-use components wherever it makes sense.
Set git.conflictStyle to zdiff3 and ask Claude to resolve the conflict, or even better, complete the entire rebase for you. A quick diff sanity check against the merge base of the result takes just a few seconds.