- Have a vague understanding of the problem
- Architect an overcomplicated solution thinking of all possible contingencies
- Pitching the overcomplicated solution to someone else
- Ask them to come up with a simple solution. Ask questions to "birth" to the solution.
- Not providing any feedback as that would mean need you to be accountable for the work
- Trying to convince them they should work out the solution because they are the expert and much smarter then you
- Taking credit for solving the problem1. Define the problem.
2. Gather information about the problem.
This seems reasonable. "We need to know what we're trying to solve, not boil the ocean."
But it is really common that the information tells us that the problem definition is slightly or really wrong. Hence the importance of gather information, then define the problem... and iterate.
"First define the problem" also feels reasonable because picking the right problem requires a lot of context and experience. Some would add "taste." So in group discussions, people often suggest bad problem definitions. Others then want to get focus and traction. That impatience often results in committing too early to the problem definition.
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.
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.
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.
“then ask Claude to do it fast with no mistakes”
(edited for accuracy)
How about you stop taking things so personal instead and let others steer more.
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.
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.
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.
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.
Everyone loves being wrong in the abstract - this reads more like a self-congratulation than a genuine reflection.
> 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.
> 6. Act with urgency to achieve the goal
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.
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.
I think Boris is a really smart, competent guy. He doesn't deserve the hate. That being said, he was just the person in the right place at the right time to have been empowered to vibe-code Claude Code into existence, with the momentum of unlimited tokens for the strongest agentic coding model behind him. Nothing about CC was revolutionary or insightful really, everyone was building harnesses at that time, and TBH Anthropic was a bit behind the curve in that regard. He's not some kind of "wizard" in the way that public figures in programming of the past were, and I think people are putting that on him, leading to a bit of ego inflation here.
I think you're wrong. I think it's embarrassing. Though I might be wrong.
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.)
Organizations usually suck at this part. Being time & resource constrained, the focus on anything but actual problem solving is just staggering to me. I haven't worked at every place, so your mileage may vary.
As others here have noted, it’s very easy to get lost gathering information that isn’t actually helpful in assessing whether the problem is well formed or whether potential solutions are applicable.
The more you force yourself to specify the problem clearly, but treat your initial problem definition as somewhat suspect - potentially missing key dimensions - the more you will be comfortable finding the information to validate / challenge it (or it's implied solutions) and re-shaping both the problem and it's solutions efficiently.
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.
I experienced maybe a minute of being "whelmed" or +1 out of 10 over baseline because I liked reading someone else that uses this approach. For someone who thinks nothing like me, I would imagine it feeling very similar to "draw the rest of the owl."
I don't think everyone needs to think the same way. And if we did want everyone to think a certain way, well, the author's style would not convince many.
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.
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.
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?!"
I prefer being right, but to each their own.
Humans are in trouble
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.
[deleted]
The worst part is that the product, the actual output, often feels underwhelming and at odds with the narrative around it. Action matters more than the narrative. Show these principles in your work and in how you engage with the community, rather than through shallow thought-leadership mumbo jumbo.
Another thing I find skin-crawling is bragging disguised as humility and sincerity. Come on!! Expecting people to buy into that performance is, in itself, a kind of insult to their intelligence.
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?
Can't wait to hear about this brand new approach from my managers and VP.
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.
60% of the time, the framework works, every time.
You can say it in any context and people will think you're the smartest person in the world while simultaneously dismissing their concerns with no chance for rebuttal.
"Parenting is largely solved"
"Democracy is largely solved"
"Hunger is largely solved"
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?
[deleted]
rest of us get fired if we ever admit at work that we were 'often' wrong.
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.
and do all of it with urgency (magically managers want everything done with urgency)
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. ;)
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.
/management,/product/2026/09/19/I-am-often-wrong.html
My pet peeve.
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
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).
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.
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.
[dead]
[dead]
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!
Sorry I meant it's too dangerous to be released.
You can be informed by the community, but the decisions are your own.
So what are they respecting themselves for, what do they take pride in? Anything I would care about?
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 too have been incredulous that this remains an open issue; if this gets it fixed, bring on the boris blog posts!)
#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.
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.
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.
See literally every isssue, even those widely reported.
(But I do not use CC and have never looked at their issue trackers, so maybe I'm missing something.)
[dead]
While Claude Code is a bunch of bugs held together by below-cost prices, and many have strong opinions on the seniority level of the lead dev(s), I think this is unnecessarily rude.
You're not talking to a bot here, you're talking to a person. Would you communicate your argument in this way to someone standing in front of you?
Whatever happened to attacking the idea, not the person?
[deleted]
First thread when searching for “Boris Cherny” : https://www.reddit.com/r/cscareerquestions/comments/1r161uq/...
Just read through their messages, they live with a bizarre, crooked worldview. Seeing something basic, like “you can pee and poo at the same time”, blows their mind.
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.
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.
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.
[dead]
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.
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
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.
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.
How else would you describe iteratively solving problems?
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.
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?
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.
[dead]
[deleted]
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.
And since you’re so intent on deconstructing:
> He would probably make a good residential plumber.
Him making a good residential plumber≠average residential plumber is good.
[deleted]
The draw the rest of the owl meme is not meant to be insightful at all. This makes it sound like you're trying to tear the author down.
You are comparing them on the basis of doing all the work in the last step, which is a valid way of looking at it but the author already assumed that he has the necessary skills to complete the task and he should slow down before doing the work.
Your post as is kind of misses the point of both the post and the meme without further context.
Looking at this thread, it mostly just lead me to think about how things can be super insightful for one person, and totally meaningless to the next.
Or because the author has enough authority that they are granted a presumption of insightfulness by default, even (or perhaps especially) when the concrete insight that's allegedly being communicated remains unclear.
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.
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.
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?
Nothing more human than to label, simplify and categorize, even in the absence of higher quality information.
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.
I'm reminded of <insert-someone-in-your-life-that-generates-friction-here>
"Often wrong, never in doubt"
What are they doing all day with that, I wonder?
LLMs are still a very new technology in relation to human timeliness. There is a whole lot of exploration to be done.
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.
Seems pretty good to me. Presumably this is about the TUI version?
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.
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
CC might be the best one I've used if I give each major UX aspect a rating 1-5 and then average them. For example, it has a decent subagent viewer.
Meanwhile, Codex doesn't even have one, and its subagent tool call is so buggy that the parent agent sometimes doesn't even know why the child died.
Being a TUI is very limiting, yes, though that limitation isn't the harness' fault.
If there were 11,000 open and confirmed bugs then yeah, that would mean the software is bad.
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 :)
https://web.archive.org/web/20121008025245/http://squid314.l...
I guess lots of people are often wrong.
I've worked in this culture. I was an IC, tech lead, lower and upper management in medium to large AAA tech companies, household names, that had the same sort of feedback focus.
I think the all-in feedback culture is overall a net negative because it invites this kind of micro-criticism, rules-driven feedback sharing.
Given that, all I can say is that while you're appear to be well intentioned, I would at most share your framework once or twice and stop pushing it, assuming you're doing that (it sounded like it). I can see most people being annoyed but this kind of framework and that's why my reply was so upvoted.
> 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.
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?
Harder feedback: the writeup feels like a quickly hacked together memo, which claims it is “self healingly” good. Because it has this throwaway quality I’m not sure what is the goal? Shall I engage with it seriously, when the lead dev didn’t seem to put in the effort? But if I don’t engage with it seriously it means that I have to follow this patchy fremwork?
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.
Just not about your performance review.
[dead]
No, not really. Anthropic is notorius for ignoring issues, pretending they don't exist, gaslighting and blaming users, then spending weeks fixing things that end up being obvious even to juniors.
At the same time they proudly tell everyone how they don't look at code anymore and only run a gazillion Claude sessions.
[deleted]
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.
Yeah, it would lose any credibility it had as you realize that there’s nothing new there.
[deleted]
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.
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.
[deleted]
> I’m surprised that you haven’t noticed this yourself
How much money have you lost to crypto scams.
That is the modus operandi of Anthropic and all of its employees (at least those active on social media).
More here: https://news.ycombinator.com/item?id=49785996
This behaviour is regardless of whether the issue is an edge case or it affects most of their users who are shouting from the rooftops
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.
That is one of the reasons CC code is so low quality. The amount of extra unnecessary code just to implement it using React is by far the worst technical slop decision I've seen made by so called "software engineers" in a long time.