I think this was the most sensible way to deploy this model.
Considering how much of a step up it has been from Opus.
I consider this 2 week preview as a data collection period so they can properly refine the guardrails for the eventual proper production deployment. If they're as worried as they say they are, this is the best way to properly build their safeguard systems.
It's annoying af, but I'd rather be cautious here.
Because it forced them to focus on efficiency, instead of throwing more compute at the problem.
Just like in software, some of the most beautiful solutions come from constraints. Think, the optimisations that game developers implemented because of the frame budget.
Actually there’s a change to dotnet 9 with how it handles the heap and GC which caused major issues for us.
I’ll confess the reason it hit us so hard is because the code quality was so low and wasteful on allocations that it didn’t hide the problem as well as previous versions.
My monolith is large enough to work on multiple systems in parallel without overlapping. One prompt with Opus might take 30-40 minutes once past the planning phase.
So I plan the next work, while the current is still running and if that's a task that can't have parallel work, I have a bunch of time to keep planning the next steps for other systems.
And then there's time for reading through the changes and applying corrective changes to the code or the meta-skills.
I use CMUX and setup workspaces for each topic I'm working on, each workspace has number of tabs. That helps keeping track of everything I'm working on, but also means no topic gets left behind until I close the workspace. So they accumulate
This, the vm bundle which reappears after you delete it. They say it's For Cowork and Claude Code, but if you don't use Cowork or CC sandboxing, it has no value. Considering I'm always finding things to delete on apples anaemic 512gb because I run out of space.
I thought about it a little deeper and I think software development has always had the addictive tendency. That hunt for the solution to the problem, has a rush when you complete it.
It’s just that the rush is more frequent, addiction intensity scales with dose and frequency.
The addiction part, the ADHD part and the pending test part.
The fear of becoming addicted to AI is real and I don't think I'll be capable to stop it, considering we're asking people who struggle with avoiding quick dopamine to use it professionally in their daily work life.
My Pro went to Max(5) to Max(20) pretty quickly and I was burning through that weekly limit still, without large agentic workflows that burn tokens. Just me and 4-5 terminals. Sometimes I was happy to hit the limit because I was forced back to normal life.
I've gone back to Pro to stop what was happening.
Now I'm self-aware enough to notice the trend and put up safe guards, but that's because I've always had to adapt my environment to control my behaviour because I know direct behaviour control is abnormally challenging. I fear for those who won't see it coming, until they're in deep.
Pure agentic loops with markdown documents as a program 'agentic workflow' is incredible for experimentation, developing and testing your workflow idea.
The second it works, bake the workflow into the harness.
Yesterday I was doing just that, and the whole agent loop disappeared because the process could've been condensed into a one-shot request (+1 MorphLLM fast apply) from careful context construction. (It was an Autoresearcher)
It’s that I try and then can’t. When stuck in bed I can feel this momentum building in my head to push for movement and the a surge of will and then nothing. I didn’t reach the threshold of exerting my will and now I’m waiting for the next wave.
There's no harm in a string, only in the execution.
I create Tools as Actors, which you preconfigured for the LLM context (in-house agent loop). The tools being preconfigured means you setup their environment before they can be executed. If it calls a bash tool for instance, the Tool Actor gets called and then it runs that command against an attached remote VM.
Or filesystem operations, are just read/writes inside a .zip file, which is overlayed onto the target project at build time.
This article is spot on, and I probably say that because it's self reinforcing.