Author here. This isn’t the one true framework, but it is the one I use. The goal of this post was to communicate to the team the way I think. There are many ways to think and there isn’t one that is more correct than others.
The word “feedback” might be overloaded here also — if you haven’t worked in a culture where feedback is an honest, no-blame part of the culture, then I can see how the idea of giving feedback can feel like a disingenuous corp-speak way to make a person fall in line or have their career impacted. There’s also an inherent power dynamic in giving feedback. However, if the work culture celebrates feedback as an honest way to have more direct conversations, and makes coworkers feel psychologically safe talking to one another directly in this way, it is something that makes culture better for everyone and gives better results in the end. I have given feedback to many people, and I have received it in turn many times.
Thanks for sharing and engaging with the comments.
Also, I am an IC, not a manager.
I think this understates the power dynamics involved. At your level, being an IC doesn’t mean you aren’t in a leadership position, and feedback from you can still carry substantial weight.
Psychological safety is a worthy aim, but it cannot be assumed, nor will everyone experience it equally. I’d be wary of relying on it too heavily here.
There are many ways to think and there isn’t one that is more correct than others.
Charlie Munger once said "The right way to think is how Zeckhauser plays bridge. It's just that simple." He managed to boil it down to a single way to think. You disagree?
I can't say I agree with forcing your team to use your own personal "framework" of approaching a problem or else you'll get "feedback".
Sometimes I will give feedback to people when they are missing steps in the framework, or are poorly executing some of the steps. I expect the same feedback in return.
I also don't like that urgency is built in as the standard process either, no wonder everyone is burnt out.
Acting with urgency is a bit at odds with discovering flaws in your plan. If you're sprinting you're less likely to notice smells and things that are inelegant, more likely to paper them over. That said, there is a time for urgency. Just not every single task.
I can't say I agree with forcing your team to use your own personal "framework" of approaching a problem
Is that not prt of what leadership always is? It might be less explicit. People often don't write their process down. Things get more confusing because people don't understand what is being asked of them.
But when is there ever no process that has to be followed? What leader lets people do whatever however and what's the role of that leader?
This seems strongly aligned with the Amazon doc-writing and decision making process. I found it to be unusually effective as a business process, and took it with me when I left to my current role.
Making thoroughly informed decisions and iterating on a decision doc before committing to a direction and plan is better than every alternative I’ve ever observed in my career.
The criticism I’ve read thus far on this thread seems unwarranted. I give the same kind of feedback to my mentees when their work product or process could use improvement.
Making thoroughly informed decisions and iterating on a decision doc before committing to a direction and plan is better than every alternative I’ve ever observed in my career.
My last company did this. It usually devolved into a design-by-committee full of compromises to make various stakeholders happy and often yielded a worse artifact.
It became more effective once people got burnt out on the process and most stakeholders stopped caring and started rubber stamping, allowing the one or two people willing to put in the energy to come up with something coherent.
I worked for AWS for several years, eventually leaving during the big "return" to office push because my geographically distributed team working on a product that didn't exist back before the remote period was told we had a month to either move to one of three cities where our team was allowed to work out of our transfer to a team in our area. My wife had an autoimmune condition that would put her at risk if I commuted, so I asked my manager what processes there were for exemptions, but he literally hadn't been told anything by the higher-ups and that as far as he was aware, there were no processes defined at all and we'd have to just try to talk with HR and upper management to try to figure something out. I didn't think that the company expecting me to rush to figure it out when they were the ones who put an artificially constrained timeline on us to either abandon what we had been working on it uproot our lives, so I ended to just giving my notice a couple of days later instead.
My point here is that companies that love to have extremely formal processes around for to handle technical things are not necessarily less likely to have extremely arbitrary decisions without any process for recourse defined when it comes to how employees get treated. If someone describes a technical process that they say they use for everything that a literal reading seems pretty dubious in regards to things like burnout or micromanagement, I don't think it's that crazy to recognize that the reality is probably at least as bad as the obvious implication. Sure, they're not directly saying "I overwork my employees by imposing short deadlines on everything and I nitpick their processes if they different from my own", but there are enough managers who do act this way that it's kind of hard to think someone who cared about being perceived as saying that wouldn't go out of their way to clarify where the nuance is if it truly exists.
This is what happens when you let things get to your head. You work on a (highly inefficient, often broken) piece of extremely basic software by prompting a slot machine and hoping it works. Calm down and stop forcing your shitty framework on employees, you're the most replaceable cog of all.
Steps 1–5 of his framework are increasingly formal ways of saying “figure out what’s going on before doing something,” followed by step 6: “then do it fast”
Yeah? A very basic process, most people use some variation of this implicitly without talking about it.
This sounds like a slightly narcissistic manager who thinks people are doing it wrong if they don't act like small copies of him. There are multiple ways to reach the same outcome and a lot depends on your information. E.g. I typically have a mental model of a system in my head, meaning when some problem needs fixing very likely I already know where it would need fixing and already think about the various future implications arising from a different fix. A point that is totally absent from that framework.
Being a senior dev myself I have seen enough good software turn bad to know that seemingly innocent technological decisions can come with huge and lasting implications. The fact that this is missing here is speaking volumes about the lack of experience at display here.
Your task as a manager isn't to create small copies of yourself. Your task is to know each persons weaknesses and strengths and compose the work in such chunks that the weaknesses have little effect, while the strengths multiply. For this you will first of all have to trust your people and lead them to discover certain ideas themselves.
E.g. if you feel someone always jumps gun-ho I to the task without doing the research, just tell them to give you the research first. Do that a few times and they might realize how useful that is.
The most annoying thing about this is that the steps are out of order unless the definition of problems and goals are intermixed
1. define a goal
2. understand information and gaps in information
3. define and prioritize the problems to achieve that goal
4. identify potential solutions for top problems and prioritize
5. measure success
and do all of it with urgency (magically managers want everything done with urgency)
Something that people learn quickly when they work with me is that my approach to pretty much every problem is:
> ...
> 6. Act with urgency to achieve the goal
If everything is urgent, then nothing is. This guy sounds miserable to work for and with. Assuming this is accurate and not just hyperbole, he is essentially saying he has no prioritization skills because everything is urgent. I think most people who have been around the block have worked with people like this, and unbeknownst to them, their coworkers develop a default snooze button associated with most of their requests and projects.
Heavens. Is it possible you're reading into it a bit?
Perhaps, which is why I hedged with the possibility that it is mere hyperbole. However, I think what did it for me was his statement that he provides and expects feedback to anyone not following this recipe, which is at utterly without nuance. Incidentally, you can execute with focus and intention without urgency and arguably be more effective over the long haul.
If someone literally publishes on the internet that they require their employees to act like every problem is urgent, it's not clear why you think we shouldn't take them at their word. It's a pretty common thing for bad managers to expect people to work full-tilt 100% of the time rather than understanding that tends to burn poorly out. I'm honestly not sure how someone could spend a decent amount of time in this industry and not be able to recognize that pattern and have thoughts about how to avoid it unless they just don't really care about it much, so while you're entitled to disagree, it's hard not to get the impression that being so affronted by the parent comment pointing out that the blog post doesn't seem to address the very real pattern of phrases like the article uses being euphemisms for pretty horrible work cultures that you just also don't particularly care about it.
Personally, I've seen far too many talented people in tech be worked too hard for too long by management that either is too clueless or too uncaring to the point where it can take years for their health and happiness to recover not to find it extremely alarming when someone says stuff like "everything is urgent". The likelihood that they mean pretty much exactly what they say rather than mean something more nuanced is high enough that the fact that don't seem concerned about the implication says more than enough.
Interesting what I found objectionable was his expectation that everyone around him follow his internal process, regardless of its steps or urgency.
Someone who has an ounce of leadership realizes that a team is a puzzle of different pieces of different shapes. You fit them together in varying ways, by observing how their processes and methods and strengths interlock to be greater than the sum of their parts. You do this fractally as you become more senior, and expect people to follow this meta framework rather than some fixed process or way of perceiving. You see quickly the organization takes on different strengths depending on the puzzle underneath them, composed of nonlinear amalgams of unique individuals. You do create protocols for communicating and decision making that are relatively uniform, but you get your grip off of people’s mojo and let them be people, not one of whom is Boris (unless Boris works for you). But beyond building a Postels law structure for communication and decision making, you expect the meta framework to be the way people evaluate their teams and you evaluate your team in the same way.
You eventually need people to shift around and reorg people to the shape of the system (Conways law) based on their strengths and processes that work for them and their teams. If you need the system to be different you organize the people in that way in and expect the system to change to fit (again Conways law).
None of what I read reflects a thinking like this, and I’d prefer to not work with someone who feels their role is to mint out clones of themselves. Further someone who posts about how they are frequently wrong is the first sign of a narcissist that believes they’re actually never actually wrong, but admits they might be misinformed at times. For me, it’s a red flag to avoid.
Heavens. Is it possible you're reading into it a bit? He's miserable to work with? From this one blog post?
Everything about this blog post makes me think that I don't want to work with him, not just the "act with urgency" claim. The whole idea that he thought this was a blog post he should write and publish makes me not want to work with him.
I think there is a worthwhile idea in this blog post, which is that you should generally not strongly commit to any specific solution to a problem because you will learn new information while working on the solution, and that it is fine to say, "I was wrong; let's take a step back and rethink this."
But if you were to write a useful post about this, you'd focus on how to decide when to change your approach and when to stick to it, because always rethinking your approach can lead to infinite churn without any releases.
This list also makes zero sense. It says to gather missing information after gathering all known information but before defining a problem. How could you even know what information is missing, much less information that is important, without knowing the problem? And if you're to gather missing information, that you somehow know about, doesn't that make it part of gathering known information? The rest of the list is just as dumb. This list is like a middle schooler was asked to come up with a problem solving framework.
This guy is usually all over threads in which he gets to show off his internal knowledge of Claude Code. I'm sure he'll be here after getting clowned.
The entire Bay Area seems like the most insufferable people known to man. These people have zero introspection.
It says to gather missing information after gathering all known information but before defining a problem. How could you even know what information is missing, much less information that is important, without knowing the problem?
The post’s description of these steps is reasonable IMO. I’d write it as “put in order the relevant information you have” and “find the information which you know you need but don’t have at hand”.
By way of bad analogy, one could imagine writing up a document first off the top of your head, then filling in more of the document based on the documentation of the relevant systems, corresponding to these two steps the author describes.
Eh, the list and post is not really worth debating. Even the ideas of problems, solutions, and goals are conflated. This has just not been thought about deeply enough by the author to be thought deeply about by others. It's typical Silicon Valley pablum.
There are multiple ways to read what the author said. I personally read it as urgency relative to other stages in the lifecycle, not other tasks you are balancing it against. So if you have five things you are slowly shaping into an executable state, with four of those in the requirements gathering/solution shaping phase, as soon as the fifth ticks over into a state where the solution is ready to implement, you should focus on implementing the solution over shaping other tasks.
To me this seems like a viable approach, and one that isn't obviously the correct approach (but what if busy stakeholder X only has time to discuss unrelated task Y 30 minutes from now? Do you still sit down to work on the shaped task to completion?). Choosing this approach isn't without its downsides, so choosing it is a deliberate decision with its own tradeoffs.
saying he has no prioritization skills because everything is urgent.
It's not just prioritization. If project is no urgent, it's often gets stuck in "let's think this through", "have we considered X", "let's gather alignment", especially at e.g. Google
So "it's urgent, because X" is sometimes the only way for something to happen
And yet there's none of this uncertainty or caution with his posts that then go on to have massive ripple effects because of his position at Anthropic and the marketting related to claude.
I personally have a lot of anger and frustration with many people in the ai hypesphere that are just mindlessly frolicking around without a care in the world, happy to speak into the megaphone offered by masses that are in a rat-race to avoid some AI dystopian hellscape that keep getting painted by these thought leaders... and then going "oopsies... I am just human guys... y so mad?!"
This guy doesn't think deeply about any problem, possibly because he has never had to and probably because he has never wanted to. He would probably make a good residential plumber.
You must not be a home owner because good residential plumbers are definitely out there solving the “hard problems” that techies love to bloviate about every day.
Literally the author of the comment I responded to? Do you not know how to read?
Let me deconstruct it for you.
His words:
He would probably make a good residential plumber.
would probably make a good residential plumber
probably make a good residential plumber.
make a good residential plumber.
a good residential plumber.
good residential plumber.
I think someone can follow "good practices" with a team and get to a bad place, especially with such a novel product (as AI coding agents).
But taking Claude Code as the product of this style of thinking -- who is Claude Code for? Is it for everyone in the world? Well, if you look at the feature velocity, it seems like the answer is intended to be yes ... Claude Code is trying to solve every problem in software development in the world, all at the same time.
So I question the "user model" here.
Here's another thing that is true about Claude Code: it's among the most inconsistent and buggy pieces of software I've ever encountered.
- You can move the cursor with the mouse in the composer, but not in AskUserQuestion?
- When agents spawn subagents, the model name is inherited from the main agent, and seemingly none of the (4! yes, 4!) subagent tools seem to get this right (except for Explore, which seems to be fixed to a weaker model)
- Sometimes, when my usage limit halts, my agents will pick up when it refreshes (within ~2 hours or something) ... other times, nope -- even within the usage limit?
This is a sampling of my own experiences using this thing frequently. Are these sorts of details not important? Maybe not: I'm not at the level of this team, and may never be.
But I think it's a reflection of agentic engineering ... a somewhat embarrassing one, from my perspective. It paints a picture of a team who can't quite get the details right, even with the assistance of purported extremely powerful AI tools, even internal ones which we don't have access to?
I think when people look back on 2025 -- Boris is going to have his name right there in the books ... Claude Code, coding agents -- Anthropic (& Boris + team) made the first move.
But now it's 2026, and people know how harnesses work, and heavy lies the crown.
Having listened to him give a couple of talks I am always struck by how much he talks and writes like Claude code.
I don’t think he farms out all of his writing and talking to LLMs. I don’t think Claude code was trained to emulate him or anything.
I think his “voice” has been filed LLM smooth by years of agent based interactions. He claims Anthropic engineers use an average of 500+ agents a day. They are human interfaces to token generators more than human to human communication. They are picking up the tendencies of their most frequent communication partner.
Unfortunately, I see Claude being wrong often enough that I view it as a faulty narrator. Often helpful, sometimes totally full of it.
And now I subconsciously apply this filter to anything that sounds like Claude.
Makes me nervous that my voice may be becoming that of a faulty narrators.
What does that mean though? Does it mean there are more than 500 different "agent" systems within Anthropic and employees interact with most of those in a daily basis?
That isn't humanly possible, you will blow out your neurotransmitters and not be able to think. Only being semi serious, but we can't make that many decisions a day.
That isn't typically how abstraction is tallied. The ceo doesn't say they use 15k employees, or the programmer uses 30B transistors. Or the director uses 120 workers. You enumerate what you actually interact with.
There might be some confusion on your part on just how much AI compute has been installed in the past few years in relation to the total amount of CPU compute and the speed at which it was installed.
If the CPUs life was an hour, the GPU AI accelerator would have been around 5 minutes and is around 5x larger in total compute.
It should not be underestimated in any way the scale of what is occurring.
Higher level thinking has fewer constraints on being wrong than lower level subconscious thinking. Low level stuff tends to have some repetitive and evolutionary basis. Higher level thought tends to be more one off, less evidence based, and more exploratory until we get to the point of being an expert around particular concepts.
A huge amount of human thinking is being a parrot and repeating statements without a deeper understanding. For example when I say 1+1=2 I'm not thinking about it. If I say 638483+949948= calculation is necessary.
So in this, your voice has always been one of a somewhat faulty narrator, LLMs just may be further degrading the quality of the narration.
Lets say you have a colleague named Bob. Bob is a pretty good engineer, but he is as confident when he doesn’t know as when he knows.
You can never tell his degree of confidence in his answer. For low-level things he is pretty good but for critical high-level things it is more ambiguous.
You work around this by checking Bob’s work. Having formal verification steps to check what he says.
Now let’s say you meet Bob’s twin brother Bill. Who talks and sounds just like Bob. He makes fairly grand high-level statements that you can neither test nor verify.
Bob also knows how to quickly check things with a little bash scripting and tests. Can quickly switch branches to confirm regressions and consult documentation if something requires more information. His twin can also quickly scan for all the common security vulnerabilities in any code, and will do it without complaining as many times as you want him to.
I’ve come to trust Bob with code more than any human.
"They are human interfaces to token generators more than human to human communication. They are picking up the tendencies of their most frequent communication partner."
I see this happening at work, too. All communication and collaboration between engineers has broken down. Juniors don't have questions anymore. Seniors don't discuss architecture anymore. Everyone is just off in their own world of feature work with the only interaction coming at merge time. Really depressing what has happened to our trade.
I think his “voice” has been filed LLM smooth by years of agent based interactions.
I've wondered this for a long time now: how does one differentiate between your voice getting "filed smooth to match LLMs" or your brain getting "filed smooth to match LLMs"?
After all, if we accept (as the token providers want us to) that evidence of language use as we see in LLMs is evidence of intelligence, then surely the reverse is true - evidence of machine-only language use is evidence of machine-only intelligence.
IOW, it's the LLM talking through you, not you talking through it.
The problem here is that the latest Claude models have gone off the deep end in their communication, and there seems to be neither awareness nor willingness to fix this. "Having your writing and talking turn into Claude is the risk nothing names" or what vapid strange meaningless thing would Opus say.
I still am mind blown at how bad CC is as software. It’s just not that hard of a problem. I get that harnesses aren’t trivial, but they’re not insane either. And the fact that it’s running on a JS runtime (that they bought!) is also crazy. Why not Go/BubbleTea? Why not literally anything native? It makes no sense
I don’t want to be a jackass, but it’s hard to take anything Boris says seriously when he’s headed up such weird software. And it’s not like resourcing or money is an issue for them. If Claude was so damn good, why does CC suck?
I dont't really know stats about such things, but I assume the adoption of CC has been insane compared to almost anything, and is also like two years old? Yeah, not surprised.
But also, if they all use 500 agents daily and latest models can "one shot" everything, one would think 5k issues are fixed in no time...
Havent used CC in some time, worked fine last time I tried.
But also, if they all use 500 agents daily and latest models can "one shot" everything, one would think 5k issues are fixed in no time...
IMO, CC should be the poster child of what LLM coding should "feel" like. If things are so good why are there so many issues? Why can't they get a handle like other well-run projects? As you said, they have unlimited tokens so this project should be close to pristine as much as possible.
Those numbers don't really mean anything. Claude Code has millions of users, and that issue forum is the most obvious place for them to ask questions or request features.
If there were 11,000 open and confirmed bugs then yeah, that would mean the software is bad.
Curl is great, but I think you're vastly underestimating the surface area of CC.
It looks like it has more in: editor integrations, multiple guis and tuis, config variations, external systems (eg, git, mcps, curl-like requests?), statefulness (curl is "only" request response), inner runtimes (eg, sandbox per OS), sensitivity to its environment, possible side effects of its own execution, potential interaction combinations, etc.
Curl has hard system-level code requirements but it's design space feels more bounded and predictable to me.
No one knows how many bugs claude has because Anthropic auto-closes Issues (or at least used to) if there isn't someone constantly pinging the issue every two weeks. I've contributed to several issues that were confirmed by several other people, which were they were auto-closed after people gave up confirming the problem without any response from Anthropic. They seemingly don't care if it isn't on fire or at least smoldering heavily, which seems really bad in my book if you're trying to make even reasonably good software.
I'm surprised you think Claude Code is good software. I find it so hard to use because it is fundamentally constrained as a TUI. It is buggy, clunky and slow. It is sooo slow.
One example of what is particularly bad with it: tool calls and progress. Codex UI does it so much better. The way in which CC waits for a task to complete etc is really poorly done compared to Codex.
Another thing that's missing: no way to continue a side chat in Claude Code - this is easy in Codex with /side and it is super usefu.
Claude Code has /btw which I think is the equivalent of /side in Codex.
I don't think Claude Code is perfect software, but I don't think fact that Codex has a slightly nicer implementation of certain patterns makes Claude Code bad software.
I’ve rolled my own harness in Go. I have a rule to not let the production LoC exceed 50k lines. It is _very_ nice for my use cases. DeepSeek Flash V4.1 often performs at the level of GPT 5.6 Sol for non-orchestration tasks (programming and maths).
I add features and tweak it all the time: You just need to get comfortable with spending 3 hours in a chat session every 3 weeks to think hard about how to simplify whatever slop you didn’t simplify the last time you did this :)
They have a UI which is pretty good! That explains why JS , they can run that in Electron and in TUI. I only use the UI now since it is do damn useful with its management of worktrees and multiple sessions, including ones running remotely via ssh devcontainers.
Heaps of comments here but nobody has pointed out he defined the goal after defining the problem. That's cheating.
Step one is to define the goal. Then you work out how to reach the goal. (Gather information and form a hypothesis) Then you take steps toward the goal. (Test your hypothesis to make sure you stepped in the right direction.)
I literally read this as human loop engineering. The next step would logically be to turn this into an agentic loop, and I imagine he does lots of that too.
It is strange how people who say they are "often wrong", never quite sound like they take that into consideration when delivering opinions or thought pieces - I see it fairly often in tech. Anyways; nothing against Boris, but Anthropic/Claude has certainly been the first company (& product) too annoying for me to use.
1) I start to believe my own hype because I am so consistently correct- which blinds me to other ideas if I don't actively take steps to humble myself.
(after all, I won't be right very often if I stop listening, as that's part of why I am right, because I listen to people and have a huge amount of context)
and
2) I am able to quickly come to a conclusion which makes people uneasy, as they think I haven't considered all the points even though I have- and it's also true that people have a bias to inaction unless it's an urgent issue.. this is how things get stuck in committees and meetings and continually get kicked down the road because it's difficult to get everyone together and there's a million reasons to keep deferring meetings.
What I'm trying to say is, don't sit there thinking that "if only I could make correct decisions"- because even if you are quick, correct and decisive: you will ruffle feathers.
(at the risk of sounding arrogant: i'm not saying I'm right about everything, like the red baron, I pick my battles very carefully).
It seems strange to write a blog post about being proven wrong, without a single example of being wrong. Especially with all the current Claude.md drama.
Everyone loves being wrong in the abstract - this reads more like a self-congratulation than a genuine reflection.
Dario tells me you're quite the science whiz. You know, I'm something of a scientist myself. I like to pee on ants and watch them swim around in it. I sometimes wonder what they think of the mysterious yellow rain. They panic at first, mandibles flailing, running into each other, trying to escape the warm, bitter stream, but eventually they come to accept it, maybe even enjoy it. Really puts things into perspective. So Boris, if you ever find yourself in doubt, just find an anthill, and pee on it. You'll thank me later.
If you do this step well, in my experience, the next steps fall into place quickly.
My version: accurately naming the problem is the essence of problem solving. There are things you usually need to do before you can accurately name the problem, because most problems aren’t presented to you in textbook form.
Once properly defined and framed, it’s obvious how to solve most problems, most of the time.
If you’ve ever worked with someone amazingly good at accurately naming the problem, it’s hard to unsee it. This is one of the hidden talents of the most effective people I’ve met.
I think how important this step is something you realize once you consider the alternative, which is trying to fix a problem, without knowing, what the problem is. It is going to result in weird workarounds instead of addressing the actual issue.
Right and wrong are forms of judgement, subject to debate, and sources of resentment.
Correct and incorrect are at least possibly quantifiable and do not intrinsically involve subjectivity.
In other words, my being incorrect is something others can help me to understand and rectify. My being "wrong" is a position which can yield second order harm.
Haven't seen any Claude Code specific examples of Boris admitting he's wrong and then actually fixing things in the way the community wants.
There are mind blowing bugs in CC that go unaddressed for months.
Something like 15-20% of all Fable messages in CC are invisible to users. You've most likely noticed this when Claude references something it said but it never said it?
It happens frequently when Fable outputs a message above a certain number of tokens just before doing a tool call.
This has been going on for months. If "users can't see messages the agent sends" isn't a critical issue that gets addressed within 24 hours, I don't really care if you admit you're often wrong, we know.
He would, but he keeps hitting his weekly limit. /s Seriously though, you would think they would have the (agentic) resources to do better QA on their flagship product. Not a week goes by without some kind of regression.
Another example of "More AI, worse app" is amazon.com for me lately. Alexa AI Chat keeps showing whenever I scroll up on the amazon.com mobile page. I don't want Alexa to search for products. Worst thing is, I can't close it. The "X" button just isn't doing anything. So the only way out of it is to refresh the page and avoid scrolling up ...
This has been going on for at least 1 1/2 months by now, and I wonder if it'll ever be fixed.
I’m surprised that you haven’t noticed this yourself, this is an incredibly common issue.
I always thought that it was perhaps referencing something that’s in its hidden thinking tokens, but the grandparent’s explanation could also very well be it.
Yeah it's something server side if I recall correctly from the numerous threads, regular messages getting returned as thinking tokens or something strange.
I've got a Claude session going which can check sessions and count how many of these messages I haven't seen due to this bug.
On a similar topic - since you said "I always use" - is it true that nearly everyone at Anthropic is using Fable and that's why Opus 5's style of speech was not really noticed as problematic by Anthropic employees?
To be fair, isn't this the standard response to issues everywhere? Generally, users will find edge cases in odd scenarios that are difficult to reproduce.
(But I do not use CC and have never looked at their issue trackers, so maybe I'm missing something.)
Ridiculous CC bug I encountered, that others have encountered as well: I asked Fable to review a commit. Suddenly my Fable quota for the week was at 100%, while a moment ago it was at 55%. A few days pass (1 day before the weekly reset) the quota resets back to 55%. ?!?!?!?!
There’s bugs, and there’s also just a ton of bizarre choices that no human would ever make.
CC (the desktop version) has a built-in terminal. It’s great idea when working with worktrees!
But the terminal is _in the sidebar_. Not as a panel that pops up from the bottom like in… every IDE ever that has this feature, but in the sidebar.
You can drag it to the bottom using tiny drag targets if you want, but if course this only persists for a duration of a single conversation.
And there’s a built-in keyboard shortcut to toggle it being shown/hidden. Again, great idea!
But using this resets the panel to its original position, again, making it appear in the sidebar.
Bonus points: when I tried to submit this via the GUI version of /feedback, it told me that it was disabled by workspace policy _after_ I filled out the form and hit submit. Brother, just hide the button that makes the form appear in the first place!
Boris's checklist is just a slightly modified version of your classic mathematics or engineering problem solving steps.
1. Write down your problem statement.
2. State your knowns, unknowns, and assumptions.
3. Solve.
(Step 2 is also further enhanced by performing first principles reasoning, collecting data for evidence, and using reasonable estimates where data is absent.)
I think Boris's list is pretty solid, but I personally would unmix the problem solving methodology from the planning/goal setting SMART principles as two separate things. One addresses problem solving, while the other addresses human cognitive shortcomings for getting things done.
A. Why define the goal after identifying the solution? Or does define the goal mean identify a stopping point for step 4, in which case you must first define the solution?
B. Isn't the goal explicit in a clear problem definition?
1) Ambiguous problem definition with no implied goal: We need more money.
2) Clearer problem definition with implied goal: We need $500K by Monday.
Title is click-bait with poor framing (i.e. if you are often wrong, then sometimes, you will be right).
Finishing your goals does not "make you right". Life is not a binary where you are either wrong, or right. Thinking that you ever become "right" or that you ever achieve 100% confidence that you have arrived at a "solution" is arrogance of the highest order.
Life is about getting better. Every person, every product, starts at a beginning. A beginning is not "wrong", it is early. We try, individually and collectively, to improve ourselves and that which we are responsible for. The decision to ship is not whether we have made something "right" but about whether we have made it better. We ship, knowing we will ship another improvement after this one.
2. Gather missing information... 6. Achieve the goal
Sometimes in life, you need to ship first in order to gather missing information later. You cannot do that if everything has to be "right" before you ship it.
I love being wrong
This is not the essay of someone who loves being wrong. This is the essay of someone who loves becoming right. But the deeper truth is that you will always be "wrong" - unfinished, lacking knowledge, under-developed, incomplete. Do not love being wrong - love improvement.
Wow. Is that the whispering earring story playing out in real life? I'd cringe if I'd found platitudes like that in my notes from the teenage days. Let alone flaunt it in front of the whole world.
Can't wait to hear about this brand new approach from my managers and VP.
I think if people are always told that they are geniuses, they stop being able to discern good ideas from bad ones. Then they end up writing things like this, thinking they're incredibly gracious for publicly admitting they can be wrong, and missing how the whole message comes across.
Goal definition is way down at step 5. Why do you even care about doing something even before you know the goal?
Why does step 6 has word "urgency" in it, as if it applies to all goals?
Getting more fundamental, why do you need to go through any of this at all? What happens if you don't do all of this? What's the cost-benefit analysis of doing all this and not doing?
This post has the same vibe as the best/worst of modern tech leadership principals. I feel these things are like a rorschach test for an individuals current position corporate psychopathy scale.
There are times in my life where I'd have read these, been really deeply impacted by them, and picked up a new mantra or 2 for a few weeks. It's like "Get a plan, execute it violently, do it today".
If you're in a time and place where you're motivated to "move fast and break things", I think you'll nod along with Boris' post.
But it's so general and high level, the only meaning you get from it depends entirely on your own personal attitude and examples that you throw at it.
The obvious pro angle is: "yeah, understand stuff well, biased for action, act urgently, yeah!" and competent, motivated, currently-in-the-zone people will spring into action. (But they would have done anyway, because they're already motivated and in the zone).
The obvious against angle is "uuuh, last week you said we needed to be goal oriented, and now you're telling us to go and learn a bunch before we even know why/what we're learning? And I've learnt a bunch of stuff, but you're telling me it's not right because it doesn't fit within this framework you just invented that you're now telling me I absolutely have to follow and you're my manager so I have no choice?"
I'm not totally hating on this, there's a time and a place for it and I've found it very motivating at times where I was already thoroughly motivated, but I think it's also useful to recognise that it comes across as self-serving platitudes for a lot of people who aren't already in that kinda zone.
It’s kind of like catnip. But it’s ok, chances are that a lot of people keep asking you how you achieve success when you get to that point. You don’t really know either, but you have to write down something.
I think it's also useful to recognise that it comes across as self-serving platitudes for a lot of people who aren't already in that kinda zone.
While true, I think trying to complicate or make this lesson “all accompanying” to make it more accurate to the real world would make it lose something in the process.
Many things we do or aspire to be are in some way cope for the world we find ourselves in, and cope is made to be simple and consumable like this. We all know it’s more complicated than what the mantras here entail; it doesn’t make the ideology any less significant for me though. As you are right, there are times when this would’ve ‘vibed with me’ and those are now behind me, like you. But even now, I still see the significance of these platitudes. They beat a lack of them, for me.
But I think you put it well that the problem is making it all accompanying. e.g.
Something that people learn quickly when they work with me is that my approach to pretty much every problem is:
The overall sentiment is good, positive and actionable (think, do informed things intentionally, understand things well) but I feel like the tone tries to make it all accompanying and somewhat unquestionable, which is confusing for an article titled "I am often wrong" that ends with "I am open to changing it".
They beat a lack of them, for me.
I generally agree, but I feel like there's a midground where we acknowledge positive, productive motivation, whilst also acknowledging that it is not how normal humans go around talking about their normal day to day activities. I feel I only see this stuff in environments where people are expected to be pushed to the point of being uncomfortable, and to be okay with it. There's a time and a place for that. I think it's not always sustainable, but that's not always understood/believed by younger engineers/younger me (and younger you?)
I think without that nuance, things like this will always be criticised/torn apart by people not currently in that kinda zone.
It’s often struck me how many “leaders” basically jump to step 6, and come up with an urgent set of superficial actions without even clarifying what they’re trying to do. There’s probably some value in “bias for action” as you might call it. But it’s been one of the difficult adjustments for me, how little people want to think.
sorry, but when you reach certain levels of influence, you need to slow down, be more methodical, and not be so flippant
Nothing more annoying than a manager with a personal know-it-all framework requiring people to follow it or else they get "feedback".
He's often wrong, don't you know.
Just not about your performance review.
Author here. This isn’t the one true framework, but it is the one I use. The goal of this post was to communicate to the team the way I think. There are many ways to think and there isn’t one that is more correct than others.
The word “feedback” might be overloaded here also — if you haven’t worked in a culture where feedback is an honest, no-blame part of the culture, then I can see how the idea of giving feedback can feel like a disingenuous corp-speak way to make a person fall in line or have their career impacted. There’s also an inherent power dynamic in giving feedback. However, if the work culture celebrates feedback as an honest way to have more direct conversations, and makes coworkers feel psychologically safe talking to one another directly in this way, it is something that makes culture better for everyone and gives better results in the end. I have given feedback to many people, and I have received it in turn many times.
Also, I am an IC, not a manager.
Thanks for sharing and engaging with the comments.
I think this understates the power dynamics involved. At your level, being an IC doesn’t mean you aren’t in a leadership position, and feedback from you can still carry substantial weight.
Psychological safety is a worthy aim, but it cannot be assumed, nor will everyone experience it equally. I’d be wary of relying on it too heavily here.
Charlie Munger once said "The right way to think is how Zeckhauser plays bridge. It's just that simple." He managed to boil it down to a single way to think. You disagree?
For that you use internal communication channels.
Though we've known for a while that no one at Anthropic is capable of doing any proper communication.
I can't say I agree with forcing your team to use your own personal "framework" of approaching a problem or else you'll get "feedback".
I also don't like that urgency is built in as the standard process either, no wonder everyone is burnt out.
But if you don't only surround yourself with people who think exactly like you, how will you ever recruit an army of yes men and women?
I'll rent an army of yes agents instead.
It’s basically OODA loop, which is itself just as descriptive of how people act and adjust than it is prescriptive.
How else would you describe iteratively solving problems?
Interestingly enough the problem with most of problem solving is identifying the right problem to solve.
It may sound weird but OODA starts making sense once you’ve identified the right problem to focus on.
In its original definition it was based on dogfights. There, your problem is clearly defined.
and the fun question of how do you find good problems is very hard to systematize!
These steps, but in many other arbitrary orders, some with feedback to previous steps
Acting with urgency is a bit at odds with discovering flaws in your plan. If you're sprinting you're less likely to notice smells and things that are inelegant, more likely to paper them over. That said, there is a time for urgency. Just not every single task.
Is that not prt of what leadership always is? It might be less explicit. People often don't write their process down. Things get more confusing because people don't understand what is being asked of them.
But when is there ever no process that has to be followed? What leader lets people do whatever however and what's the role of that leader?
This seems strongly aligned with the Amazon doc-writing and decision making process. I found it to be unusually effective as a business process, and took it with me when I left to my current role.
Making thoroughly informed decisions and iterating on a decision doc before committing to a direction and plan is better than every alternative I’ve ever observed in my career.
The criticism I’ve read thus far on this thread seems unwarranted. I give the same kind of feedback to my mentees when their work product or process could use improvement.
My last company did this. It usually devolved into a design-by-committee full of compromises to make various stakeholders happy and often yielded a worse artifact.
It became more effective once people got burnt out on the process and most stakeholders stopped caring and started rubber stamping, allowing the one or two people willing to put in the energy to come up with something coherent.
I worked for AWS for several years, eventually leaving during the big "return" to office push because my geographically distributed team working on a product that didn't exist back before the remote period was told we had a month to either move to one of three cities where our team was allowed to work out of our transfer to a team in our area. My wife had an autoimmune condition that would put her at risk if I commuted, so I asked my manager what processes there were for exemptions, but he literally hadn't been told anything by the higher-ups and that as far as he was aware, there were no processes defined at all and we'd have to just try to talk with HR and upper management to try to figure something out. I didn't think that the company expecting me to rush to figure it out when they were the ones who put an artificially constrained timeline on us to either abandon what we had been working on it uproot our lives, so I ended to just giving my notice a couple of days later instead.
My point here is that companies that love to have extremely formal processes around for to handle technical things are not necessarily less likely to have extremely arbitrary decisions without any process for recourse defined when it comes to how employees get treated. If someone describes a technical process that they say they use for everything that a literal reading seems pretty dubious in regards to things like burnout or micromanagement, I don't think it's that crazy to recognize that the reality is probably at least as bad as the obvious implication. Sure, they're not directly saying "I overwork my employees by imposing short deadlines on everything and I nitpick their processes if they different from my own", but there are enough managers who do act this way that it's kind of hard to think someone who cared about being perceived as saying that wouldn't go out of their way to clarify where the nuance is if it truly exists.
i am pretty sure it would just be "wrong," not "meta-wrong," and given the title, i am giving myself the point.
I am not even wrong.
7. Reflect on that goal?
I, I, I, I, I, I, I, Me me me me me me
This is what happens when you let things get to your head. You work on a (highly inefficient, often broken) piece of extremely basic software by prompting a slot machine and hoping it works. Calm down and stop forcing your shitty framework on employees, you're the most replaceable cog of all.
Unlike me, 56 and yet to be wrong once.
It is a burden all of its own.
Steps 1–5 of his framework are increasingly formal ways of saying “figure out what’s going on before doing something,” followed by step 6: “then do it fast”
“let Claude figure out what’s going on before doing something”
“then ask Claude to do it fast with no mistakes”
(edited for accuracy)
That's what it took to finally support Agents.md I guess. Boris had to blog about having made a mistake.
How about you stop taking things so personal instead and let others steer more.
Author here. These are unrelated, just happened to both be the same week.
I prefer being right, but to each their own.
I like being right so much that, when I'm wrong, I change my mind, despite how embarrassing that is.
a foolish consistency is the hobgoblin of little minds
Yeah? A very basic process, most people use some variation of this implicitly without talking about it.
This sounds like a slightly narcissistic manager who thinks people are doing it wrong if they don't act like small copies of him. There are multiple ways to reach the same outcome and a lot depends on your information. E.g. I typically have a mental model of a system in my head, meaning when some problem needs fixing very likely I already know where it would need fixing and already think about the various future implications arising from a different fix. A point that is totally absent from that framework.
Being a senior dev myself I have seen enough good software turn bad to know that seemingly innocent technological decisions can come with huge and lasting implications. The fact that this is missing here is speaking volumes about the lack of experience at display here.
Your task as a manager isn't to create small copies of yourself. Your task is to know each persons weaknesses and strengths and compose the work in such chunks that the weaknesses have little effect, while the strengths multiply. For this you will first of all have to trust your people and lead them to discover certain ideas themselves.
E.g. if you feel someone always jumps gun-ho I to the task without doing the research, just tell them to give you the research first. Do that a few times and they might realize how useful that is.
The most annoying thing about this is that the steps are out of order unless the definition of problems and goals are intermixed 1. define a goal 2. understand information and gaps in information 3. define and prioritize the problems to achieve that goal 4. identify potential solutions for top problems and prioritize 5. measure success
and do all of it with urgency (magically managers want everything done with urgency)
there is a missing step: "believe in yourself"
“I am often wrong” is directly from how to make friends and influence people.
Just retire at this point, you don't even have to work.
If everything is urgent, then nothing is. This guy sounds miserable to work for and with. Assuming this is accurate and not just hyperbole, he is essentially saying he has no prioritization skills because everything is urgent. I think most people who have been around the block have worked with people like this, and unbeknownst to them, their coworkers develop a default snooze button associated with most of their requests and projects.
Heavens. Is it possible you're reading into it a bit? He's miserable to work with? From this one blog post?
A more generous read, or, at least the reading I took: "once we (think we) know what we're doing, we violently execute."
So, "boo" on you. This guy sounds awesome.
I was literally writing almost this exact post but decided to reload the page first.
Developers get triggered about managers breathing down their neck when they read things like this that’s why you get such strong reactions.
I disagree, on the principle of "slow is smooth, smooth is fast"
This principle is basically a movie quote, though.
No it's not, though?
and similarly, the need for slack in software teams
How often do people that make this kind of assertion end up themselves being the ones that are miserable to be around I wonder
Perhaps, which is why I hedged with the possibility that it is mere hyperbole. However, I think what did it for me was his statement that he provides and expects feedback to anyone not following this recipe, which is at utterly without nuance. Incidentally, you can execute with focus and intention without urgency and arguably be more effective over the long haul.
If someone literally publishes on the internet that they require their employees to act like every problem is urgent, it's not clear why you think we shouldn't take them at their word. It's a pretty common thing for bad managers to expect people to work full-tilt 100% of the time rather than understanding that tends to burn poorly out. I'm honestly not sure how someone could spend a decent amount of time in this industry and not be able to recognize that pattern and have thoughts about how to avoid it unless they just don't really care about it much, so while you're entitled to disagree, it's hard not to get the impression that being so affronted by the parent comment pointing out that the blog post doesn't seem to address the very real pattern of phrases like the article uses being euphemisms for pretty horrible work cultures that you just also don't particularly care about it.
Personally, I've seen far too many talented people in tech be worked too hard for too long by management that either is too clueless or too uncaring to the point where it can take years for their health and happiness to recover not to find it extremely alarming when someone says stuff like "everything is urgent". The likelihood that they mean pretty much exactly what they say rather than mean something more nuanced is high enough that the fact that don't seem concerned about the implication says more than enough.
It's not saying treat every problem as urgent, it's saying go through 5 steps that are defing the problem correctly then treat it urgently.
Interesting what I found objectionable was his expectation that everyone around him follow his internal process, regardless of its steps or urgency.
Someone who has an ounce of leadership realizes that a team is a puzzle of different pieces of different shapes. You fit them together in varying ways, by observing how their processes and methods and strengths interlock to be greater than the sum of their parts. You do this fractally as you become more senior, and expect people to follow this meta framework rather than some fixed process or way of perceiving. You see quickly the organization takes on different strengths depending on the puzzle underneath them, composed of nonlinear amalgams of unique individuals. You do create protocols for communicating and decision making that are relatively uniform, but you get your grip off of people’s mojo and let them be people, not one of whom is Boris (unless Boris works for you). But beyond building a Postels law structure for communication and decision making, you expect the meta framework to be the way people evaluate their teams and you evaluate your team in the same way.
You eventually need people to shift around and reorg people to the shape of the system (Conways law) based on their strengths and processes that work for them and their teams. If you need the system to be different you organize the people in that way in and expect the system to change to fit (again Conways law).
None of what I read reflects a thinking like this, and I’d prefer to not work with someone who feels their role is to mint out clones of themselves. Further someone who posts about how they are frequently wrong is the first sign of a narcissist that believes they’re actually never actually wrong, but admits they might be misinformed at times. For me, it’s a red flag to avoid.
Everything about this blog post makes me think that I don't want to work with him, not just the "act with urgency" claim. The whole idea that he thought this was a blog post he should write and publish makes me not want to work with him.
I think there is a worthwhile idea in this blog post, which is that you should generally not strongly commit to any specific solution to a problem because you will learn new information while working on the solution, and that it is fine to say, "I was wrong; let's take a step back and rethink this."
But if you were to write a useful post about this, you'd focus on how to decide when to change your approach and when to stick to it, because always rethinking your approach can lead to infinite churn without any releases.
This list also makes zero sense. It says to gather missing information after gathering all known information but before defining a problem. How could you even know what information is missing, much less information that is important, without knowing the problem? And if you're to gather missing information, that you somehow know about, doesn't that make it part of gathering known information? The rest of the list is just as dumb. This list is like a middle schooler was asked to come up with a problem solving framework.
This guy is usually all over threads in which he gets to show off his internal knowledge of Claude Code. I'm sure he'll be here after getting clowned.
The entire Bay Area seems like the most insufferable people known to man. These people have zero introspection.
The post’s description of these steps is reasonable IMO. I’d write it as “put in order the relevant information you have” and “find the information which you know you need but don’t have at hand”.
By way of bad analogy, one could imagine writing up a document first off the top of your head, then filling in more of the document based on the documentation of the relevant systems, corresponding to these two steps the author describes.
Eh, the list and post is not really worth debating. Even the ideas of problems, solutions, and goals are conflated. This has just not been thought about deeply enough by the author to be thought deeply about by others. It's typical Silicon Valley pablum.
I'm still thinking about your first para. But in the second para, did you actually mean he'll be cloned?
I assume "clowned" as in "getting clowned on"
There are multiple ways to read what the author said. I personally read it as urgency relative to other stages in the lifecycle, not other tasks you are balancing it against. So if you have five things you are slowly shaping into an executable state, with four of those in the requirements gathering/solution shaping phase, as soon as the fifth ticks over into a state where the solution is ready to implement, you should focus on implementing the solution over shaping other tasks.
To me this seems like a viable approach, and one that isn't obviously the correct approach (but what if busy stakeholder X only has time to discuss unrelated task Y 30 minutes from now? Do you still sit down to work on the shaped task to completion?). Choosing this approach isn't without its downsides, so choosing it is a deliberate decision with its own tradeoffs.
It's not just prioritization. If project is no urgent, it's often gets stuck in "let's think this through", "have we considered X", "let's gather alignment", especially at e.g. Google
So "it's urgent, because X" is sometimes the only way for something to happen
I think you're wrong. I think it's embarrassing. Though I might be wrong.
And yet there's none of this uncertainty or caution with his posts that then go on to have massive ripple effects because of his position at Anthropic and the marketting related to claude.
I personally have a lot of anger and frustration with many people in the ai hypesphere that are just mindlessly frolicking around without a care in the world, happy to speak into the megaphone offered by masses that are in a rat-race to avoid some AI dystopian hellscape that keep getting painted by these thought leaders... and then going "oopsies... I am just human guys... y so mad?!"
This guy doesn't think deeply about any problem, possibly because he has never had to and probably because he has never wanted to. He would probably make a good residential plumber.
You must not be a home owner because good residential plumbers are definitely out there solving the “hard problems” that techies love to bloviate about every day.
Who said anything about “good” residential plumbers?
Literally the author of the comment I responded to? Do you not know how to read?
Let me deconstruct it for you.
His words: He would probably make a good residential plumber. would probably make a good residential plumber probably make a good residential plumber. make a good residential plumber. a good residential plumber. good residential plumber.
Concept of sarcasm will blow your mind.
And since you’re so intent on deconstructing:
Him making a good residential plumber≠average residential plumber is good.
I think someone can follow "good practices" with a team and get to a bad place, especially with such a novel product (as AI coding agents).
But taking Claude Code as the product of this style of thinking -- who is Claude Code for? Is it for everyone in the world? Well, if you look at the feature velocity, it seems like the answer is intended to be yes ... Claude Code is trying to solve every problem in software development in the world, all at the same time.
So I question the "user model" here.
Here's another thing that is true about Claude Code: it's among the most inconsistent and buggy pieces of software I've ever encountered.
- You can move the cursor with the mouse in the composer, but not in AskUserQuestion?
- When agents spawn subagents, the model name is inherited from the main agent, and seemingly none of the (4! yes, 4!) subagent tools seem to get this right (except for Explore, which seems to be fixed to a weaker model)
- Sometimes, when my usage limit halts, my agents will pick up when it refreshes (within ~2 hours or something) ... other times, nope -- even within the usage limit?
This is a sampling of my own experiences using this thing frequently. Are these sorts of details not important? Maybe not: I'm not at the level of this team, and may never be.
But I think it's a reflection of agentic engineering ... a somewhat embarrassing one, from my perspective. It paints a picture of a team who can't quite get the details right, even with the assistance of purported extremely powerful AI tools, even internal ones which we don't have access to?
I think when people look back on 2025 -- Boris is going to have his name right there in the books ... Claude Code, coding agents -- Anthropic (& Boris + team) made the first move.
But now it's 2026, and people know how harnesses work, and heavy lies the crown.
Having listened to him give a couple of talks I am always struck by how much he talks and writes like Claude code.
I don’t think he farms out all of his writing and talking to LLMs. I don’t think Claude code was trained to emulate him or anything.
I think his “voice” has been filed LLM smooth by years of agent based interactions. He claims Anthropic engineers use an average of 500+ agents a day. They are human interfaces to token generators more than human to human communication. They are picking up the tendencies of their most frequent communication partner.
Unfortunately, I see Claude being wrong often enough that I view it as a faulty narrator. Often helpful, sometimes totally full of it.
And now I subconsciously apply this filter to anything that sounds like Claude.
Makes me nervous that my voice may be becoming that of a faulty narrators.
What are they doing all day with that, I wonder?
Does that mean 500 separate agents or 500 agent sessions I wonder.
the former
What does that mean though? Does it mean there are more than 500 different "agent" systems within Anthropic and employees interact with most of those in a daily basis?
That isn't humanly possible, you will blow out your neurotransmitters and not be able to think. Only being semi serious, but we can't make that many decisions a day.
Right, but you can imagine eg a hierarchy, in which case you might only talk with -say- 10 reports directly.
That isn't typically how abstraction is tallied. The ceo doesn't say they use 15k employees, or the programmer uses 30B transistors. Or the director uses 120 workers. You enumerate what you actually interact with.
Well, trying to make RSI for one so humans don't have to do that work.
LLMs are still a very new technology in relation to human timeliness. There is a whole lot of exploration to be done.
I mean, in relation to human timelines, so are computers in general. It's not close why you think that this is unique to LLMs.
There might be some confusion on your part on just how much AI compute has been installed in the past few years in relation to the total amount of CPU compute and the speed at which it was installed.
If the CPUs life was an hour, the GPU AI accelerator would have been around 5 minutes and is around 5x larger in total compute.
It should not be underestimated in any way the scale of what is occurring.
To err is human.
Higher level thinking has fewer constraints on being wrong than lower level subconscious thinking. Low level stuff tends to have some repetitive and evolutionary basis. Higher level thought tends to be more one off, less evidence based, and more exploratory until we get to the point of being an expert around particular concepts.
A huge amount of human thinking is being a parrot and repeating statements without a deeper understanding. For example when I say 1+1=2 I'm not thinking about it. If I say 638483+949948= calculation is necessary.
So in this, your voice has always been one of a somewhat faulty narrator, LLMs just may be further degrading the quality of the narration.
Left, right, higher, lower, male, female. People love to explain the brain by dividing it in half, or into poles.
Nothing more human than to label, simplify and categorize, even in the absence of higher quality information.
Lets say you have a colleague named Bob. Bob is a pretty good engineer, but he is as confident when he doesn’t know as when he knows.
You can never tell his degree of confidence in his answer. For low-level things he is pretty good but for critical high-level things it is more ambiguous.
You work around this by checking Bob’s work. Having formal verification steps to check what he says.
Now let’s say you meet Bob’s twin brother Bill. Who talks and sounds just like Bob. He makes fairly grand high-level statements that you can neither test nor verify.
How much do you intuitively distrust him?
Bob also knows how to quickly check things with a little bash scripting and tests. Can quickly switch branches to confirm regressions and consult documentation if something requires more information. His twin can also quickly scan for all the common security vulnerabilities in any code, and will do it without complaining as many times as you want him to. I’ve come to trust Bob with code more than any human.
I see this happening at work, too. All communication and collaboration between engineers has broken down. Juniors don't have questions anymore. Seniors don't discuss architecture anymore. Everyone is just off in their own world of feature work with the only interaction coming at merge time. Really depressing what has happened to our trade.
I'm reminded of <insert-someone-in-your-life-that-generates-friction-here>
"Often wrong, never in doubt"
I've wondered this for a long time now: how does one differentiate between your voice getting "filed smooth to match LLMs" or your brain getting "filed smooth to match LLMs"?
After all, if we accept (as the token providers want us to) that evidence of language use as we see in LLMs is evidence of intelligence, then surely the reverse is true - evidence of machine-only language use is evidence of machine-only intelligence.
IOW, it's the LLM talking through you, not you talking through it.
The problem here is that the latest Claude models have gone off the deep end in their communication, and there seems to be neither awareness nor willingness to fix this. "Having your writing and talking turn into Claude is the risk nothing names" or what vapid strange meaningless thing would Opus say.
I still am mind blown at how bad CC is as software. It’s just not that hard of a problem. I get that harnesses aren’t trivial, but they’re not insane either. And the fact that it’s running on a JS runtime (that they bought!) is also crazy. Why not Go/BubbleTea? Why not literally anything native? It makes no sense
I don’t want to be a jackass, but it’s hard to take anything Boris says seriously when he’s headed up such weird software. And it’s not like resourcing or money is an issue for them. If Claude was so damn good, why does CC suck?
Turns out he just used what he knew, TypeScript, and not what best solves the problem. He must have not had his "framework" then.
Claude Code is also offered as an SDK, you can build custom (customized) harness on top of what essentially is Claude Code. https://code.claude.com/docs/en/agent-sdk/overview
I'll be honest, I don't actually understand what people mean when they say Claude Code is bad software.
Seems pretty good to me. Presumably this is about the TUI version?
Do you really think that having this many issues is justifiable/ok?
https://github.com/anthropics/claude-code/issues
I dont't really know stats about such things, but I assume the adoption of CC has been insane compared to almost anything, and is also like two years old? Yeah, not surprised.
But also, if they all use 500 agents daily and latest models can "one shot" everything, one would think 5k issues are fixed in no time...
Havent used CC in some time, worked fine last time I tried.
IMO, CC should be the poster child of what LLM coding should "feel" like. If things are so good why are there so many issues? Why can't they get a handle like other well-run projects? As you said, they have unlimited tokens so this project should be close to pristine as much as possible.
Those numbers don't really mean anything. Claude Code has millions of users, and that issue forum is the most obvious place for them to ask questions or request features.
If there were 11,000 open and confirmed bugs then yeah, that would mean the software is bad.
IMO this is very dismissive. One example of probably many more, where software is used by millions and yet doesn't have this much being reported.
https://github.com/curl/curl/issues
curl isn't end-user software, and has a very small, well defined surface area.
curl is certainly a much more difficult problem to solve well, and does so without 30 million issues or whatever the CC codebase has
Curl is great, but I think you're vastly underestimating the surface area of CC.
It looks like it has more in: editor integrations, multiple guis and tuis, config variations, external systems (eg, git, mcps, curl-like requests?), statefulness (curl is "only" request response), inner runtimes (eg, sandbox per OS), sensitivity to its environment, possible side effects of its own execution, potential interaction combinations, etc.
Curl has hard system-level code requirements but it's design space feels more bounded and predictable to me.
This of course isn't an excuse for all bugs.
No one knows how many bugs claude has because Anthropic auto-closes Issues (or at least used to) if there isn't someone constantly pinging the issue every two weeks. I've contributed to several issues that were confirmed by several other people, which were they were auto-closed after people gave up confirming the problem without any response from Anthropic. They seemingly don't care if it isn't on fire or at least smoldering heavily, which seems really bad in my book if you're trying to make even reasonably good software.
I'm surprised you think Claude Code is good software. I find it so hard to use because it is fundamentally constrained as a TUI. It is buggy, clunky and slow. It is sooo slow.
One example of what is particularly bad with it: tool calls and progress. Codex UI does it so much better. The way in which CC waits for a task to complete etc is really poorly done compared to Codex.
Another thing that's missing: no way to continue a side chat in Claude Code - this is easy in Codex with /side and it is super usefu.
Claude Code has /btw which I think is the equivalent of /side in Codex.
I don't think Claude Code is perfect software, but I don't think fact that Codex has a slightly nicer implementation of certain patterns makes Claude Code bad software.
it tries but /btw can't be invoked at any time. it is blocked until the reasoning is done. you also can't continue the chat with it
you also can't have tool calls inside it
I’ve rolled my own harness in Go. I have a rule to not let the production LoC exceed 50k lines. It is _very_ nice for my use cases. DeepSeek Flash V4.1 often performs at the level of GPT 5.6 Sol for non-orchestration tasks (programming and maths).
I add features and tweak it all the time: You just need to get comfortable with spending 3 hours in a chat session every 3 weeks to think hard about how to simplify whatever slop you didn’t simplify the last time you did this :)
Is it open? I'd love to take a look and perhaps steal some ideas :)
They're a small bootstrapped startup, give them some grace.
Small indie company, as the kids like to say.
They have a UI which is pretty good! That explains why JS , they can run that in Electron and in TUI. I only use the UI now since it is do damn useful with its management of worktrees and multiple sessions, including ones running remotely via ssh devcontainers.
Heaps of comments here but nobody has pointed out he defined the goal after defining the problem. That's cheating.
Step one is to define the goal. Then you work out how to reach the goal. (Gather information and form a hypothesis) Then you take steps toward the goal. (Test your hypothesis to make sure you stepped in the right direction.)
“Claude, fix my framework (I am often wrong)”
quick - someone turn this into agentic harness :)
I literally read this as human loop engineering. The next step would logically be to turn this into an agentic loop, and I imagine he does lots of that too.
It is strange how people who say they are "often wrong", never quite sound like they take that into consideration when delivering opinions or thought pieces - I see it fairly often in tech. Anyways; nothing against Boris, but Anthropic/Claude has certainly been the first company (& product) too annoying for me to use.
It's because it's some weird form of virtue signalling/humble brag. Nothing genuine about it.
Heh, I have the opposite... uh "problem".
I am often right.
This has two negative effects;
1) I start to believe my own hype because I am so consistently correct- which blinds me to other ideas if I don't actively take steps to humble myself.
(after all, I won't be right very often if I stop listening, as that's part of why I am right, because I listen to people and have a huge amount of context)
and
2) I am able to quickly come to a conclusion which makes people uneasy, as they think I haven't considered all the points even though I have- and it's also true that people have a bias to inaction unless it's an urgent issue.. this is how things get stuck in committees and meetings and continually get kicked down the road because it's difficult to get everyone together and there's a million reasons to keep deferring meetings.
What I'm trying to say is, don't sit there thinking that "if only I could make correct decisions"- because even if you are quick, correct and decisive: you will ruffle feathers.
(at the risk of sounding arrogant: i'm not saying I'm right about everything, like the red baron, I pick my battles very carefully).
We all have a short time on this planet. This desire to always have urgency, speed, more money is insane.
Humans are in trouble
It seems strange to write a blog post about being proven wrong, without a single example of being wrong. Especially with all the current Claude.md drama.
Everyone loves being wrong in the abstract - this reads more like a self-congratulation than a genuine reflection.
Boris is a scientist, that's all that has to be said here. Keep up the great work.
Dario tells me you're quite the science whiz. You know, I'm something of a scientist myself. I like to pee on ants and watch them swim around in it. I sometimes wonder what they think of the mysterious yellow rain. They panic at first, mandibles flailing, running into each other, trying to escape the warm, bitter stream, but eventually they come to accept it, maybe even enjoy it. Really puts things into perspective. So Boris, if you ever find yourself in doubt, just find an anthill, and pee on it. You'll thank me later.
Aha, another iterative improvement variant. (see also eg OODA and PDCA)
I'd argue that Boris Cherny is in fact nearly always wrong;
except when he's right, which is in the final pass just before the work is done. ;)
If you do this step well, in my experience, the next steps fall into place quickly.
My version: accurately naming the problem is the essence of problem solving. There are things you usually need to do before you can accurately name the problem, because most problems aren’t presented to you in textbook form.
Once properly defined and framed, it’s obvious how to solve most problems, most of the time.
If you’ve ever worked with someone amazingly good at accurately naming the problem, it’s hard to unsee it. This is one of the hidden talents of the most effective people I’ve met.
I think how important this step is something you realize once you consider the alternative, which is trying to fix a problem, without knowing, what the problem is. It is going to result in weird workarounds instead of addressing the actual issue.
Translation: "I'm so wise guys, that I'm using epistemic humility principles to hide it"
Right and wrong are forms of judgement, subject to debate, and sources of resentment.
Correct and incorrect are at least possibly quantifiable and do not intrinsically involve subjectivity.
In other words, my being incorrect is something others can help me to understand and rectify. My being "wrong" is a position which can yield second order harm.
why does boris have this urge to become an influencer
It makes him feel important and smart and powerful.
Haven't seen any Claude Code specific examples of Boris admitting he's wrong and then actually fixing things in the way the community wants.
There are mind blowing bugs in CC that go unaddressed for months.
Something like 15-20% of all Fable messages in CC are invisible to users. You've most likely noticed this when Claude references something it said but it never said it?
It happens frequently when Fable outputs a message above a certain number of tokens just before doing a tool call.
This has been going on for months. If "users can't see messages the agent sends" isn't a critical issue that gets addressed within 24 hours, I don't really care if you admit you're often wrong, we know.
He would, but he keeps hitting his weekly limit. /s Seriously though, you would think they would have the (agentic) resources to do better QA on their flagship product. Not a week goes by without some kind of regression.
Huh, it's almost like using agents exclusively to write software doesn't lead to quality code or a quality product. Interesting.
Preaching the choir.
Another example of "More AI, worse app" is amazon.com for me lately. Alexa AI Chat keeps showing whenever I scroll up on the amazon.com mobile page. I don't want Alexa to search for products. Worst thing is, I can't close it. The "X" button just isn't doing anything. So the only way out of it is to refresh the page and avoid scrolling up ...
This has been going on for at least 1 1/2 months by now, and I wonder if it'll ever be fixed.
Anthropic never listens to their customers or community. It's basically their culture at this point.
We'd gladly fix the bugs in Claude Code in our own forks but they're too ashamed of their AGI level code to make it open source.
Sorry I meant it's too dangerous to be released.
That is the culture of any self-respecting startup.
You can be informed by the community, but the decisions are your own.
Only gross incompetence can even lead to the point of users telling them what obvious things to fix.
So what are they respecting themselves for, what do they take pride in? Anything I would care about?
Author here. How can I repro what you’re seeing? Double check you don’t have /focus mode enabled.
I’m surprised that you haven’t noticed this yourself, this is an incredibly common issue.
I always thought that it was perhaps referencing something that’s in its hidden thinking tokens, but the grandparent’s explanation could also very well be it.
Yeah it's something server side if I recall correctly from the numerous threads, regular messages getting returned as thinking tokens or something strange.
I've got a Claude session going which can check sessions and count how many of these messages I haven't seen due to this bug.
I always use /focus mode, Tag, or Projects, so didn’t notice it personally. Either way, digging in.
No. No you're not diggin in. You're spinning out a Claude instance that will or will not find the cause and will or will not make a proper fix.
This comment is needlessly hostile and adds no value to the conversation.
On a similar topic - since you said "I always use" - is it true that nearly everyone at Anthropic is using Fable and that's why Opus 5's style of speech was not really noticed as problematic by Anthropic employees?
Which one of multiple GitHub issues on this topic should I link to?
#67071 is one of them
Or #83281 which you closed as a duplicate of #67051 which was closed as not planned.
There's a bunch more. Just ask Claude to search repo issues for messages not being shown.
Looking
Are there days when you forget to apply your framework or you feel lazy and cheat/shortcut parts/all of the framework?
Fairly often, yeah. Sometimes it is too easy to get excited about a solution without taking the time to specify a clear problem/goal.
Yeah, I feel you here :+1:
The typical Anthropic/bcherny reaponse. "I've never noticed this, can you tell me more".
See literally every isssue, even those widely reported.
To be fair, isn't this the standard response to issues everywhere? Generally, users will find edge cases in odd scenarios that are difficult to reproduce.
(But I do not use CC and have never looked at their issue trackers, so maybe I'm missing something.)
Step 1 "Understand the available information" is apparently a hard step.
(I too have been incredulous that this remains an open issue; if this gets it fixed, bring on the boris blog posts!)
Ridiculous CC bug I encountered, that others have encountered as well: I asked Fable to review a commit. Suddenly my Fable quota for the week was at 100%, while a moment ago it was at 55%. A few days pass (1 day before the weekly reset) the quota resets back to 55%. ?!?!?!?!
There’s bugs, and there’s also just a ton of bizarre choices that no human would ever make.
CC (the desktop version) has a built-in terminal. It’s great idea when working with worktrees!
But the terminal is _in the sidebar_. Not as a panel that pops up from the bottom like in… every IDE ever that has this feature, but in the sidebar.
You can drag it to the bottom using tiny drag targets if you want, but if course this only persists for a duration of a single conversation.
And there’s a built-in keyboard shortcut to toggle it being shown/hidden. Again, great idea!
But using this resets the panel to its original position, again, making it appear in the sidebar.
Bonus points: when I tried to submit this via the GUI version of /feedback, it told me that it was disabled by workspace policy _after_ I filled out the form and hit submit. Brother, just hide the button that makes the form appear in the first place!
Users of Claude aren't customers, they are the product (a living training set data generators). The customers are governments and megacorpos.
Well maybe stop posting then and leave it to people who are not often wrong.
This is about as insightful as the "draw the rest of the owl" meme, with a bit of Lex Fridman style forced humility in the title.
Well, sounds like problems and products are largely solved.
60% of the time, the framework works, every time.
Boris's checklist is just a slightly modified version of your classic mathematics or engineering problem solving steps.
1. Write down your problem statement.
2. State your knowns, unknowns, and assumptions.
3. Solve.
(Step 2 is also further enhanced by performing first principles reasoning, collecting data for evidence, and using reasonable estimates where data is absent.)
I think Boris's list is pretty solid, but I personally would unmix the problem solving methodology from the planning/goal setting SMART principles as two separate things. One addresses problem solving, while the other addresses human cognitive shortcomings for getting things done.
What LinkedIn post did this blow in from?
I am confused by step 5.
A. Why define the goal after identifying the solution? Or does define the goal mean identify a stopping point for step 4, in which case you must first define the solution?
B. Isn't the goal explicit in a clear problem definition?
1) Ambiguous problem definition with no implied goal: We need more money.
2) Clearer problem definition with implied goal: We need $500K by Monday.
Just another instance of him being wrong, i guess. (Which he absolutely, most definitively loves!)
Bayes spotted in the wild.
Title is click-bait with poor framing (i.e. if you are often wrong, then sometimes, you will be right).
Finishing your goals does not "make you right". Life is not a binary where you are either wrong, or right. Thinking that you ever become "right" or that you ever achieve 100% confidence that you have arrived at a "solution" is arrogance of the highest order.
Life is about getting better. Every person, every product, starts at a beginning. A beginning is not "wrong", it is early. We try, individually and collectively, to improve ourselves and that which we are responsible for. The decision to ship is not whether we have made something "right" but about whether we have made it better. We ship, knowing we will ship another improvement after this one.
Sometimes in life, you need to ship first in order to gather missing information later. You cannot do that if everything has to be "right" before you ship it.
This is not the essay of someone who loves being wrong. This is the essay of someone who loves becoming right. But the deeper truth is that you will always be "wrong" - unfinished, lacking knowledge, under-developed, incomplete. Do not love being wrong - love improvement.
Is there anyone else like me who can't help but noticed the url has a comma in it?
Removing that comma, you got a 404 error.
My pet peeve.
yuck
Aka. business-as-usual being human.
Imagine it were so simple that we had not figured out 1-6 before in all of our research and management principles over the centuries?
Like as though it needs to be stated?
I mean ...
There's a very weird thing they like to do in Silicon Valley where they re-invent everything 'in other words' - this time, no fancy words.
Also, I would say he missed the 'iteration and experimentation part'.
If $400K/yer people need this level of guidance, something is wrong.
This whole things feels kind of wrong.
Imagine it were just some random Engineer, what would we think?
Imagine if a non-tech person wrote this.
Boy, Boris, you're getting ripped on this.
Tbh your article is pretty poor. Your "framework" is what everyone on this planet does every day.
I guess the lesson for you is to realize that your wisdom nugget may annoy the shit out of your team.
Wow. Is that the whispering earring story playing out in real life? I'd cringe if I'd found platitudes like that in my notes from the teenage days. Let alone flaunt it in front of the whole world.
Can't wait to hear about this brand new approach from my managers and VP.
I think if people are always told that they are geniuses, they stop being able to discern good ideas from bad ones. Then they end up writing things like this, thinking they're incredibly gracious for publicly admitting they can be wrong, and missing how the whole message comes across.
https://web.archive.org/web/20121008025245/http://squid314.l...
https://tiliosophrang.com/
All 6 steps are wrong.
Goal definition is way down at step 5. Why do you even care about doing something even before you know the goal?
Why does step 6 has word "urgency" in it, as if it applies to all goals?
Getting more fundamental, why do you need to go through any of this at all? What happens if you don't do all of this? What's the cost-benefit analysis of doing all this and not doing?
Replace "goal" with "solution" and it makes sense. Otherwise (trite) you might solve the wrong problem.
Somehow the most relevant comment on the thread is the most downvoted.
I guess lots of people are often wrong.
I absolutely love it, and this correlates perfectly with Polya's math problem solving [1] combined with Fail Fast [2] .
[1] https://en.wikipedia.org/wiki/How_to_Solve_It
[2] https://en.wikipedia.org/wiki/Fail_fast_(business)
This post has the same vibe as the best/worst of modern tech leadership principals. I feel these things are like a rorschach test for an individuals current position corporate psychopathy scale.
There are times in my life where I'd have read these, been really deeply impacted by them, and picked up a new mantra or 2 for a few weeks. It's like "Get a plan, execute it violently, do it today".
If you're in a time and place where you're motivated to "move fast and break things", I think you'll nod along with Boris' post.
But it's so general and high level, the only meaning you get from it depends entirely on your own personal attitude and examples that you throw at it.
The obvious pro angle is: "yeah, understand stuff well, biased for action, act urgently, yeah!" and competent, motivated, currently-in-the-zone people will spring into action. (But they would have done anyway, because they're already motivated and in the zone).
The obvious against angle is "uuuh, last week you said we needed to be goal oriented, and now you're telling us to go and learn a bunch before we even know why/what we're learning? And I've learnt a bunch of stuff, but you're telling me it's not right because it doesn't fit within this framework you just invented that you're now telling me I absolutely have to follow and you're my manager so I have no choice?"
I'm not totally hating on this, there's a time and a place for it and I've found it very motivating at times where I was already thoroughly motivated, but I think it's also useful to recognise that it comes across as self-serving platitudes for a lot of people who aren't already in that kinda zone.
It’s kind of like catnip. But it’s ok, chances are that a lot of people keep asking you how you achieve success when you get to that point. You don’t really know either, but you have to write down something.
1. Do things well
2. Reflect on doing things well
3. Humbleness about the process (or other meta)
While true, I think trying to complicate or make this lesson “all accompanying” to make it more accurate to the real world would make it lose something in the process.
Many things we do or aspire to be are in some way cope for the world we find ourselves in, and cope is made to be simple and consumable like this. We all know it’s more complicated than what the mantras here entail; it doesn’t make the ideology any less significant for me though. As you are right, there are times when this would’ve ‘vibed with me’ and those are now behind me, like you. But even now, I still see the significance of these platitudes. They beat a lack of them, for me.
I agree. There's definitely value in it.
But I think you put it well that the problem is making it all accompanying. e.g.
The overall sentiment is good, positive and actionable (think, do informed things intentionally, understand things well) but I feel like the tone tries to make it all accompanying and somewhat unquestionable, which is confusing for an article titled "I am often wrong" that ends with "I am open to changing it".
I generally agree, but I feel like there's a midground where we acknowledge positive, productive motivation, whilst also acknowledging that it is not how normal humans go around talking about their normal day to day activities. I feel I only see this stuff in environments where people are expected to be pushed to the point of being uncomfortable, and to be okay with it. There's a time and a place for that. I think it's not always sustainable, but that's not always understood/believed by younger engineers/younger me (and younger you?)
I think without that nuance, things like this will always be criticised/torn apart by people not currently in that kinda zone.
nice
so is coding solved or no?
I expected something like "I was wrong coding is not solved" alas
It’s often struck me how many “leaders” basically jump to step 6, and come up with an urgent set of superficial actions without even clarifying what they’re trying to do. There’s probably some value in “bias for action” as you might call it. But it’s been one of the difficult adjustments for me, how little people want to think.