Delivery is becoming a sequence of checks, not a ritual
The same thing happens when it is time to deliver.
First, I invoke my /definition-of-done skill. It checks whether the implementation covers what was stated in the PR and in the plan. It checks tests and the other validations I care about. It tells me when something looks unusual, broken, or missing. When everything looks good, I invoke another skill, /pr-check-release. That checks the remote PR, updates labels, removes [WIP], adds [RFC], updates the description, and prepares the change for review. If one day passes and nobody on the team reviews the PR, we merge it. The agent also tracks that condition for me, so I can run /pr-merge-dev, and it takes care of the process: merge the PR, delete the remote branch, delete the local branch, and pull dev back into a fresh state. None of these steps is particularly difficult. That is exactly the point.
But then:
I still care about all of those things. Probably more than most people.
Obviously the author has irreversibly became AI-pilled and the day API costs balloon or APIs are down, what work will the author do?
I love using AI but please read the diffs and process them with your human brains and eyes. Spin up your containers manually, test the app, MANUALLY.
Talk to real users face to face.
Outsourcing the grunt work is fine, but there's a fine line between that and becoming a button-presser.
I only wish Opus 4.6 from earlier this year at a faster inference speed.
Since Opus 4.6 things have been so much messier and the overall push for more agency isn’t really panning out for agent assisted development as much as they would like
Thanks for saying this! I completely agree with everything you said!
There’s far, far too many people who confuse code quality for speed of development and start treating code quality as the product for customer base in the hundreds and active customers in the dozens and for most features to be basically unused.
The reality is that tech debt as a concept these days is hardly real: to be in debt means previous decisions or a previous implementation makes current work extremely hard or impossible, but, the truth is that the human factors such as knowing what to build, team collaboration and even speaking to customers matter far more and can get you “in debt” so so much faster than code alone. At least in your typical SaaS company.
If you ship code in a way that you let tech debt pile up to the point that customers notice it, you have an organisational problem, not code issues per se.
The fact that a lot of people don’t get this is really baffling to me.
I’ve been plugging away at my running coach style app, powered by the original idea of training for a trail race while living in a flat area with no easy access to natural climbing that has evolved into a fully functional plan generator: https://runcoach.fly.dev
It works well for me so far and I’m pretty happy with it!
Side question: I've always been a recreational runner, running 3/4x a week, completed a few half marathons, and recently decided to _also_ go to the gym to do strength training as it has a lot of benefits for runners too. Should I consider/take creatine, is it useful?
What if you then use AI to try and maintain only one, a single product into which you’ll put your care and craft to try to make something that’s better than “some dopamine hits”?
Any reason why they indexed on Kimi K2.5 model? I have tried many open-source ones in Opencode, and, in my experience (standard backend development, Java, Python, Spring, etc) Qwen3.6 is SO MUCH BETTER that's shocking. Kimi can't even get most tool calling arguments right.
I still haven’t seen any other models be as complete as Claude inside Claude Code. I bet Anthropic knows this and they turn the knobs and see people’s reactions… I have been planning with Qwen3.6 Max inside opencode, absolutely game changer.
Opus can then follow the plan quite detailed and like this I can make progress on my toy apps on Pro plan at 20/mo.
For work, unlimited usage via Bedrock.
Yes I’d like to get more usage out of my personal sub, but at 20/mo no complains
I’ve been using Opus 4.6 extensively inside Claude Code via AWS Bedrock with max effort for a few months now (since release).
I’ve found a good “personal harness” and way of working with it in such a way that I can easily complete self contained tasks in my Java codebase with ease.
Now idk if it’s just me or anything else changed, but, in the last 4/5 days, the quality of the output of Opus 4.6 with max effort has been ON ANOTHER LEVEL.
ABSOLUTELY AMAZING! It seems to reason deeper, verifies the work with tests more often, and I even think that it compacted the conversations more effectively and often. Somehow even the quality of the English “text” in the output felt definitely superior. More crisp, using diagrams and analogies to explain things in a way that it completely blew me away. I can’t explain it but this was absolutely real for me.
I’d say that I can measure it quite accurately because I’ve kept my harness and scope of tasks and way of prompting exactly the same, so something TRULY shifted.
I wish I could get some empirical evidence of this from others or a confirmation from Boris…. But ISTG these last few days felt absolutely incredible.
In the end, Anthropic is a company and needs to make money, my best bet is that even those of us who pay 100/mo to use Claude Code are costing Anthropic money, besides all the rest they’re burning on inference.
Again, I agree with you and the service should be at least reliable but to be completely fair, if I had to bet, the amount of usage people get for 100/mo is probably only balanced out by the corporate/entreprise customers paying their bill to Anthropic via API usage.
If we look at it through this lens, this limits are not surprising at all, except maybe on how generous they are/were. It’s pretty obvious that they want to force people to pay as they go….
Ah yes this is sad to see and a lame move for sure… It’s indeed dependent on usage hours but it’s a bad move even if I’m personally not affected since I use it outside of those hours but I agree it’s lame….
I think in this case, we probably have different experiences that shape how we see some things differently: I see many (very smart) people doing certain things that are not optimal (eg: copy-paste entire files instead of referencing them or tell claude at every message to "read CLAUDE.md and follow its instructions precisely") which can lead to a lot of token waste. If certain system prompts were tweaked internally or some models now read more files than before, keeping these "inneficient prompts" will make limits exhaust faster. Sub-agents or this new agent teams feature didn't exist until a few months ago: that alone eats A LOT of tokens, not intended for this pre-paid API usage, etc.
The ecosystem is evolving super quickly so, our own experiences and workflows must keep adapting with it to experiment, find limitations and arrive at the "tightest possible scope" that still allows you to get things done, because it is possible.
Another example: pre-paid monthly subscription aggregates usage towards web and Claude Code, for eg. So if you're checking for holiday itineraries over your lunch break, then decide to sit down and ask a team of agents to refactor a giant codebase with hundreds or thousands of files, context will be exhuasted quickly, etc, etc.
I see this "context economy" as a new way of managing your "mental models": every token counts, and every token must bear its weight for the task at hand, otherwise, I'm "wasting budget". I am also still learning how to operate in this new way of doing things, and, while there have been genuine issues with Claude Code, not every single issue that people encounter is an upstream problem.
It's the nature of SaaS software, right? It doesn't need to be an enforced "hard change", but, let's say that they trained Opus 4.6 to be more "verbose" or to explore more files to gain more context for it's own tasks.
If your limits stay "the same", but you then use Opus 4.6, your quota will be exhausted much faster, it's just how it works.
Note that some features are simply NOT made for these Pro, Max, Max 5x or whatever pre-paid plans. I'm pretty sure this is by design and not an accident or a bug: If you have 6/7 MCP servers configured or if you want to use this new feature of "Agent Teams", you will exhaust your entire quota before ANY work is even done. This is not a bug. Each agent has its own context window and tools and they all count separately.
MCP servers, when active, add A LOT of context to your sessions before you even use them, etc, etc.
It feels to me that people want to have their cake and eat it too, but, that would NOT be a sustainable business model. You can not complain about the tools if you can't understand them in-depth.
I want to state that I don't think Anthropic are fully aware of the ramifications that ANY small change in ANY of their models might have, because their entire ecosystem is a bit messy atm, but, I'm certain they're aware that if people dont like it, they will cancel the subscription and flock to a competitor very quickly, since there's no real moat anymore. So, it's in their own interest to keep things minimally usable even on the "cheaper plans".
I have seen people with 5-10 "active MCP servers" that they "wanted to try out" then they forget about it and wonder why their context is always full... Cmon... that's almost bad faith.
I don't fully defend Anthropic as they've had several issues with degraded model quality after releasing "the latest model", and CLI usability that cost me real money and real tokens, so, there's a lot of room for improvement, but, to claim that quota gets exhausted after 1h it points out to either some forgotten MCP servers, skills or giant files being accidentally read in, or some sort of mis-use which these limits were put in place to prevent exactly.
There's a very thin line between: quota is exhuasted on a regular, normal session after 1h and I think there's a bug versus I had 3-4 MCP servers active that I am not using at all but forgot to disable and my CLAUDE.md file is 1000 lines...
Replying once again for future reference to make my position clear: I firmly believe that one MUST experience programming on its own first. No LLMs, no crutches. One MUST feel the abstractions melting away and things clicking in the brain first.
The design becoming obvious. Being able to remove that extra if statement after clarifying requirements with a customer face to face.
A design pattern fitting a scenario like a glove, etc, etc.
You need REAL experience that only comes with time and effort. Years or decades, different businesses, different companies, etc.
But once you have crossed that chasm and that rite of passage, using LLMs becomes a true multiplier and my experience quite fun.
Using them blindly or without experience is a very different thing I can imagine.
Delivery is becoming a sequence of checks, not a ritual The same thing happens when it is time to deliver.
First, I invoke my /definition-of-done skill. It checks whether the implementation covers what was stated in the PR and in the plan. It checks tests and the other validations I care about. It tells me when something looks unusual, broken, or missing. When everything looks good, I invoke another skill, /pr-check-release. That checks the remote PR, updates labels, removes [WIP], adds [RFC], updates the description, and prepares the change for review. If one day passes and nobody on the team reviews the PR, we merge it. The agent also tracks that condition for me, so I can run /pr-merge-dev, and it takes care of the process: merge the PR, delete the remote branch, delete the local branch, and pull dev back into a fresh state. None of these steps is particularly difficult. That is exactly the point.
But then:
I still care about all of those things. Probably more than most people.
Obviously the author has irreversibly became AI-pilled and the day API costs balloon or APIs are down, what work will the author do?
I love using AI but please read the diffs and process them with your human brains and eyes. Spin up your containers manually, test the app, MANUALLY. Talk to real users face to face.
Outsourcing the grunt work is fine, but there's a fine line between that and becoming a button-presser.