Quality degrades long before you hit compaction, compaction is the "Next gas station, 100 miles" sign but you're already in the middle of nowhere.
You don't need to go down the rabbit hole of crazy workflows, but to avoid slop:
- Break down the work into tasks
- New context. Create a plan for one task.
- New context. Implement the plan.
- New context. /code-review the implementation
- New context. Fix the review findings.
- Repeat for next task.
I do this with Fable 5, and the quality is consistently quite good. If the context goes over 50%, the quality will become crap and you end up with 4 duplicates of the same thing across the codebase. Letting a current session review its own work is like asking a student to grade their own paper.
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.
Add more humans and LLMs to correct for errors. If humans sometimes go crazy and try to randomly end the world at a rate of 0.1%, requiring two humans to turn two keys synchronously to end the world reduces the error rate to 0.01%.
So, to avoid depressed AIs ending the world randomly, have a stable of multiple AIs with different provenance (one from Anthropic, one from OpenAI, one from Google...) require a majority agreement to reduce the error rate. Adjust thresholds depending on criticality of the task at hand.
All of AWS' big money makers are the meat-and-potatoes services around compute, storage, databases etc. where you could drop their offering and replace it with another in a straightforward way. It will cost you to migrate in terms of time and direct spend (those egress fees...), but it's possible. Companies ultimately stay put because the products work and the price is reasonable, but if they tried to 10X the price overnight everyone would eventually bolt.
Yeah they keep pushing higher-level services, but the uptake of these is extremely limited. If you used something like SageMaker, which has an extremely high lock-in factor, it's probably because you're an old school company that don't know what you're doing and AWS held your developer's hand to get the Hello World-level app working, but at least you got your name printed in their case study materials of the project at the end.
I think OpenAI looks at AWS and thinks they can do better. And for their investors, they must do better. But in the end I think the commoditization of LLMs is already almost complete, and this is just a futile attempt to fight it.
Exactly. You would have to be naive to build a company on top of this kind of API. LLMs are going to be become commodities, and this is OpenAI fighting against that fate as their valuation and continued investment requirements doesn't make any sense otherwise.
If you built on the Assistant API, maybe take the hint and don't just rewrite to the Responses API? Own your product, black box the LLM-of-the-day.
AWS is desperate to climb up the value stack. Compute and networking is a commodity (with fat margins at retail prices to be sure), and the second and third place providers are willing to make deep discounts to land big deals. That's not going to justify those future lofty valuations.
The problem is, for all it's talk over the last few years, AWS remains a complete non-player in the GenAI space, much less so than Azure. In my opinion the problem is exactly the same as for every other high-level service they've tried to launch. QuickSight, Lex, Polly, Cognito, CodeGuru, SageMaker, etc: they're not good. Nobody ever said "I really like QuickSight, I sure wish it had GenAI capabilities". So when the hastily-expanded QuickSight team(s) then goes on to release 42 different Q enabled SKUs, nobody cares. For various reasons, AWS is organizationally incapable of launching a non-infrastructure product that is simply great, as doing so would take attention to detail and deeply caring about things like UX which are anathema to Amazon.
On the positive side, GenAI model access will be commoditized and part of the basic undifferentiated cloud infra, and AWS will do fine there.
> The slow part of using awk is waiting for the disk to spin over the magnetic head.
If we're talking about 6 TB of data:
- You can upgrade to 8 TB of storage on a 16-inch MacBook Pro for $2,200, and the lowest spec has 12 CPU cores. With up to 400 GB/s of memory bandwidth, it's truly a case of "your big data problem easily fits on my laptop".
- Contemporary motherboards have 4 to 5 M.2 slots, so you could today build a 12 TB RAID 5 setup of 4 TB Samsung 990 PRO NVMe drives for ~ 4 x $326 = $1,304. Probably in a year or two there will be 8 TB NVMe's readily available.
The way the Golden Gate is incorporated across all answers seems almost like an obsessive compulsive disorder. If the association was negative, we might call it a phobia. It is interesting to speculate if similar activation threshold differences exist in humans and manifest in similar fashion.
This might be a way to encode personality traits into models, by emphasizing some aspects and damping others.
The equivalent for a human would be an reflexive response to a question, the kind you could immediately answer after being woken up at 3am in the morning. That type of answer has been deeply trained into the human networks and also requires no deep insight.
But if a human is allowed time and internal reasoning iterations, so should the LLM when determining if it has deep insight. Right now we're simply observing input -> output of LLMs, the equivalent of snap answers from a human. But nothing says it couldn't instead be an input -> extensive internal dialogue, maybe even between multiple expert models for seconds, minutes or hours, that are not at all visible to the prompter -> final insightful answer. Maybe future LLMs will say, "let me get back to you on that".
Remember the "Mongo DB is web scale" craze from now over a decade ago? That's the current state of vector DBs, despite vector DBs having been around forever.
Do you have more than a terabyte of embeddings? No? Do yourself a favor and use pg_vector with a HNSW index, it'll do just fine. Operationally, it is very hard to beat Postgres.
The most negative influence on my sleep by far is from using my phone in bed, as I suspect it is for many others. Not only when falling asleep, but also when waking up reaching for the phone is too easy and robs me of any chance of falling asleep again.
The only trick I've found that works quite consistently for me, is removing the phone from the room entirely. This makes my laziness work for me for once, as getting the phone from another room altogether is too much of a hassle.
Similarly, if you want to stop eating after a certain hour, 9pm in my case, brush your teeth at that exact time. After that I can't be bothered to eat since brushing my teeth again would be a hassle.
You don't need to go down the rabbit hole of crazy workflows, but to avoid slop:
- Break down the work into tasks
- New context. Create a plan for one task.
- New context. Implement the plan.
- New context. /code-review the implementation
- New context. Fix the review findings.
- Repeat for next task.
I do this with Fable 5, and the quality is consistently quite good. If the context goes over 50%, the quality will become crap and you end up with 4 duplicates of the same thing across the codebase. Letting a current session review its own work is like asking a student to grade their own paper.