One of the hard things about building a product on an LLM is that the model frequently changes underneath you. Since we introduced Claude Code almost a year ago, Claude has gotten more intelligent, it runs for longer periods of time, and it is able to more agentically use more tools. This is one of the magical things about building on models, and also one of the things that makes it very hard. There's always a feeling that the model is outpacing what any given product is able to offer (ie. product overhang). We try very hard to keep up, and to deliver a UX that lets people experience the model in a way that is raw and low level, and maximally useful at the same time.

In particular, as agent trajectories get longer, the average conversation has more and more tool calls. When we released Claude Code, Sonnet 3.5 was able to run unattended for less than 30 seconds at a time before going off the rails; now, Opus 4.6 1-shots much of my code, often running for minutes, hours, and days at a time.

The amount of output this generates can quickly become overwhelming in a terminal, and is something we hear often from users. Terminals give us relatively few pixels to play with; they have a single font size; colors are not uniformly supported; in some terminal emulators, rendering is extremely slow. We want to make sure every user has a good experience, no matter what terminal they are using. This is important to us, because we want Claude Code to work everywhere, on any terminal, any OS, any environment.

Users give the model a prompt, and don't want to drown in a sea of log output in order to pick out what matters: specific tool calls, file edits, and so on, depending on the use case. From a design POV, this is a balance: we want to show you the most relevant information, while giving you a way to see more details when useful (ie. progressive disclosure). Over time, as the model continues to get more capable -- so trajectories become more correct on average -- and as conversations become even longer, we need to manage the amount of information we present in the default view to keep it from feeling overwhelming.

When we started Claude Code, it was just a few of us using it. Now, a large number of engineers rely on Claude Code to get their work done every day. We can no longer design for ourselves, and we rely heavily on community feedback to co-design the right experience. We cannot build the right things without that feedback. Yoshi rightly called out that often this iteration happens in the open. In this case in particular, we approached it intentionally, and dogfooded it internally for over a month to get the UX just right before releasing it; this resulted in an experience that most users preferred.

But we missed the mark for a subset of our users. To improve it, I went back and forth in the issue to understand what issues people were hitting with the new design, and shipped multiple rounds of changes to arrive at a good UX. We've built in the open in this way before, eg. when we iterated on the spinner UX, the todos tool UX, and for many other areas. We always want to hear from users so that we can make the product better.

The specific remaining issue Yoshi called out is reasonable. PR incoming in the next release to improve subagent output (I should have responded to the issue earlier, that's my miss).

Yoshi and others -- please keep the feedback coming. We want to hear it, and we genuinely want to improve the product in a way that gives great defaults for the majority of users, while being extremely hackable and customizable for everyone else.

To try it: /config > verbose, or --verbose.

Please keep the feedback coming. If there is anything else we can do to adjust verbose mode to do what you want, I'd love to hear.

And so the very first thing that the LLM does when planning, namely choosing which files to read, are a key point for manual intervention to ensure that the correct domain or business concept is being analyzed.

Speaking personally: Once I know that Claude is looking in the right place, I'm on to the next task - often an entirely different Claude session. But those critical first few seconds, to verify that it's looking in the right place, are entirely different from any other kind of verbosity.

I don't want verbose mode. I want Claude to tell me what it's reading in the first 3 seconds, so I can switch gears without fear it's going to the wrong part of the codebase. By saying that my use case requires verbose mode, you're saying that I need to see massive levels of babysitting-level output (even if less massive than before) to be able to do this.

(To lean into the babysitting analogy, I want Claude to be the babysitter, but I want to make sure the babysitter knows where I left the note before I head out the door.)

To be clear: we re-purposed verbose mode to do exactly what you are asking for. We kept the name "verbose mode", but the behavior is what you want, without the other verbose output.

Might it have been better to retire and/or rename the feature, if the underlying action was very different?

I work on silly basic stuff compared to Claude Code, but I find that I confuse fewer users if I rename a button instead of just changing the underlying effect.

This causes me to have to create new docs, and hopefully triggers affected users to find those docs, when they ask themselves “what happened to that button?”

All we want is the file paths. That is all. Verbose mode pulls in a lot of other information that might very well be needed in other contexts. People who want that info should use verbose mode. All we want is the regular non-verbose mode, with paths.

I fail to see how it is confusing to users, even new users, to print which paths were accessed. I fail to see the point of printing that some paths were accessed, but not which.

While we're here, another thing that's annoying: the token counter. While claude is working, it read some files, makes an edit, let's say token counter is at 2k tokens, I accept the edit, now it starts counting very fast from 0 to 2k and then shows normal inference speed changes to 2.1k, 2.3k etc. So wanted to confirm: is that just some UI decision and not actually using 2k tokens again? If so, it would be nice to have it off, just continue counting where you left off.

Another thing: is it possible to turn off the words like finagling and similar (I can't remember the spelling of any of them) ?

Big +1 on that. I find the names needlessly distracting. I want to just always say a single thing like “thinking”

    "spinnerVerbs": {
      "mode": "replace",
      "verbs": ["Thinking"]
    }

It's not an easy UI problem to solve in all cases since behavior in CC can be so flexible, compaction, forking, etc. But it would be great if it was simply consistent (ctrl+o shows last N where N is like, 50, or 100), with ctrl+e revealing the rest.

That said, we recently rewrote our renderer to make it much more efficient, so we can bump up the default a bit. Let me see what it feels like to show the last 10-20 messages -- fix incoming.

o7

Heck, simply handle the scrolling yourself a la tmux/screen and only update the output at most every 4ms?

It's so trivial, can't you ask your fancy LLM to do it for you? Or you guys lost the plot at his point and forgot the most basics of writing non pessimized code.

The real problem is their ridiculous "React rendering in the terminal" UI.

I actually miss being able to see all of the thinking, for example, because I could tell more quickly when the model was making a wrong assumption and intervene.

(And yeah, I would love the verbose mode myself, but there could be various levels to it.)

I find this decision weird due to claude _code_, while being used by _some_ non-technical users, is mostly used by technical users and developers.

Not sure why the choice would be to dumb the output down for technical users/developers.

The thinking mode is super-useful to me as I _often_ saw the model "think" differently from the response. Stuff like "I can see that I need to look for x, y, z to full understand the problem" and then proceeds to just not do that.

This is helpful as I can interrupt the process and guide it to actually do this. With the thinking-output hidden, I have lost this avenue for intervention.

I also want to see what files it reads, but not necessarily the output - I know most of the files that'll be relevant, I just want to see it's not totally off base.

Tl;dr: I would _love_ to have verbose mode be split into two modes: Just thinking and Thinking+Full agent/file output.

---

I'm happy to work in verbose mode. I get many people are probably fine with the standard minimal mode. But at least in my code base, on my projects, I still need to perform a decent amount of handholding through guidance, the model is not working for me the way you describe it working for you.

All I need is a few tools to help me intervene earlier to make claude-code work _much_ better for me. Right now I feel I'm fighting the system frequently.

Or have ctrl+o cycle between "Info, Verbose, Trace"?

Or give us full control over what gets logged through config?

Ideally we would get a new tab where we could pick logging levels on:

  - Thoughts
  - Files read / written
  - Bashes
  - Subagents

“Did something 2 times”

That may as well not be shown at all in default mode?

What useful information is imparted by “Read 4 files”?

You have two issues here:

1) making verbose mode better. Sure.

2) logging useless information in default.

If you're not imparting any useful information, claude may as well just show a spinner.

Like, I'm open to the idea that I'm the one using your software the wrong way, since obviously you know more about it than I do. What would you recommend I do with the knowledge of how many files Claude has read? Is there a situation where this number can tell me whether the model is on the right track?

If I got messages like "Accessed 6 websites" I'd flip and go spam a couple github issues with as much "I want names" as I could.

Not just because it requires constant attention which will eventually lapse, but because the agent has an unlimited number of ways to exfiltrate the key, for example it can pretend to write and run a "test" which reads your key, sends it to the attacker and you'll have no idea it's happening.

I understand that I’m probably not the target audience if I want to actually step in and correct course, but it’s annoying.

shhh don't say that, they will never fix it if means you use less tokens.

Sighted users lost convenience. I lost the ability to trust the tool. There is no "glancing" at terminal output with a screen reader. There is no "progressive disclosure." The text is either spoken to me or it doesn't exist.

When you collapse file paths into "Read 3 files," I have no way to know what the agent is doing with my codebase without switching to verbose mode, which then dumps subagent transcripts, thinking traces, and full file contents into my audio stream. A sighted user can visually skip past that. I listen to every line sequentially.

You've created a situation where my options are "no information" or "all information." The middle ground that existed before, inline file paths and search patterns, was the accessible one.

This is not a power user preference. This is a basic accessibility regression. The fix is what everyone in this thread has been asking for: a BASIC BLOODY config flag to show file paths and search patterns inline. Not verbose mode surgery. A boolean.

Please just add the option.

And yes, I rewrote this with Claude to tone my anger and frustration down about 15 clicks from how I actually feel.

They are much more responsive on GitHub issues than Anthropic so you could also try reporting your issue there

If people find it too noisy, they can use the flag or toggle that makes everything quieter.

p.s. Serendipitously I just finished my on-site at anthropic today, hi :)

Do you guys have a screen reader user on the dev team?

Is verbose mode the same as the old mode, where only file paths are spoken? Or does it have other text in it? Because I tried to articulate, and may have failed. More text is usually bad for me. It must be consumed linearly. I need specific text.

Quality over quantity

> Yoshi and others -- please keep the feedback coming. We want to hear it, and we genuinely want to improve the product in a way that gives great defaults for the majority of users, while being extremely hackable and customizable for everyone else.

I think an issue with 2550 upvotes, more than 4 times of the second-highest, is very clear feedback about your defaults and/or making it customizable.

Are you actually wondering, or just hoping to hear a confirmation of what you already know? Because the reason behind it is pretty clear, it doubles as both vendor lock-in and advertisement.

> The amount of output this generates can quickly become overwhelming in a terminal

If I use Opus 4.6, arguably the most verbose, over thinking model you've released to date, OpenCode handles it just the same as it does Sonnet 4.0.

OpenCode even allows me to toggle into subagent and task agents with their own output terminals that, if I am curious what is going on, I can very clearly see it.

All Claude-Code has done has turned the output into a black box so that I am forced to wait for it to finish to look at the final git diff. By then it's spent $5-10 working on a task, and threw away a lot of the context it took to get there. It showed "thinking" blocks that weren't particularly actionable, because it was mostly talking to itself that it can't do something because it goes against a rule, but it really wants to.

I'm actually frustrated with Code blazing through to the end without me able to see the transcript of the changes.

But this one isn't? I'd call myself a professional. I use with tons of files across a wide range of projects and types of work.

To me file paths were an important aspect of understanding context of the work and of the context CC was gaining.

Now? It feels like running on a foggy street, never sure when the corner will come and I'll hit a fence or house.

Why not introduce a toggle? I'd happily add that to my alisases.

Edit: I forgot. I don't need better subagent output. Or even less output whrn watching thinking traces. I am happy to have full verbosity. There are cases where it's an important aspect.

More details here: https://news.ycombinator.com/item?id=46982177

Funnily enough, both independently sided with the users, not the authors.

The core problem: --verbose was repurposed instead of adding a new toggle. Users who relied on verbose for debugging (thinking, hooks, subagent output) now have broken workflows - to fix a UX decision that shouldn't have shipped as default in the first place.

What should have been done:

  /config
  Show file paths: [on/off]
  Verbose mode: [on/off]  (unchanged)

Opus 4.6's parting thought: if you're building a developer tool powered by an AI that can reason about software design, maybe run your UX changes past it before shipping.

To be fair, your response explains the design philosophy well - longer trajectories, progressive disclosure, terminal constraints. All valid. But it still doesn't address the core point: why repurpose --verbose instead of adding a separate toggle? You can agree with the goal and still say the execution broke existing workflows.

https://martin.ankerl.com/2007/09/01/comprehensive-linux-ter...

Could the React rendering stack be optimised instead?

If you are serious about this, I think there are so many ways you could clean up, simplify, and calm the Claude Code terminal experience already.

I am not a CC user, but an enthusiastic CC user generously spent an hour or two last week or so showing me how it worked and walking through an non-publicly-implemented Gwern.net frontend feature (some CSS/JS styling of poetry for mobile devices).

It was highly educational and interesting, and Claude got most of the way to something usable.

Yet I was shocked and appalled by the CC UI/UX itself: it felt like the fetal alcohol syndrome lovechild of a Las Vegas slot machine and Tiktok. I did not realize that all those jokes about how using CC was like 'crack' or 'ADHD' or 'gambling' were so on point, I thought they were more, well, metaphorical about the process as a whole. I have not used such a gross and distracting UI in... a long time. Everything was dancing and bouncing around and distracting me while telling me nothing. I wasted time staring at the update monitor trying to understand if "Prognosticating..." was different from "Fleeblegurbigating..." from "Reticulating splines...", while the asterisk bounces up and down, or the colored text fades in and out, all simultaneously, and most of the screen was wasted, and the whole thing took pains to put in as much fancy TUI nonsense as it could. An absolute waste, not whimsy, of pixels. (And I was a little concerned how much time we spent zoned out waiting on the whole shabang. I could feel the productivity leaving my body, minute by minute. How could I possibly focus on anything else while my little friendly bouncing asterisk might finish at any instant...?!) Some description of what files are being accessed seems like you could spare the pixels for them.

So I was impressed enough with the functionality to move it up my list, but also much of it made me think I should look into GPT Codex instead. It sounds like the interfaces there respect my time and attention more, rather than treating me like a Zoomer.

As others have said - 'reading 10 files' is useless information - we want to be able to see at a glance where it is and what it's doing, so that we can re-direct if necessary.

With the release of Cowork, couldn't Claude Code double down on needs of engineers?

I just find that very hard to believe. Does anyone actually do anything with the output now? Or are they just crossing their fingers and hoping for the best?

Please revert this

And stop banning 3rd party harnesses please. Thanks

Anthropic, your actual moat is goodwill. Remember that.

Maybe "AI IDEs" will gain ground in the future, e.g. vibe-kanban

It doesn't compose with any other command line program and the terminal interface is limiting.

I'm surprised nobody has yet made a coding assistant that runs in the browser or as a standalone app. At this point it doesn't really need to integrate with my text editor or IDE.

(That said I do like being able to SSH in and run an agent that way. But there are other remote access modalities.)

https://github.com/anthropics/claude-code/issues/19673

Of course all the logs can’t be streamed to a terminal. Why would they need to be? Every logging system out there allows multiple stream handlers with different configurations.

Do whatever reasonable defaults you think make sense for the TUI (with some basic configuration). But then I should also be able to give Claude-code a file descriptor and a different set of config optios, and you can stream all the logs there. Then I can vibe-code whatever view filter I want on top of that, or heck, have a SLM sub-agent filter it all for me.

I could do this myself with some proxy / packet capture nonsense, but then you’d just move fast and break my things again.

I’m also constantly frustrated by the fancier models making wrong assumptions in brownfield projects and creating a big mess instead of asking me follow-up questions. Opus is like the world’s shittiest intern… I think a lot of that is upstream of you, but certainly not all of it. There could be a config option to vary the system prompt to encourage more elicitation.

I love the product you’ve built, so all due respect there, but I also know the stench of enshittification when I smell it. You’re programmers, you know how logging is supposed to work. You know MCP has provided a lot of these basic primitives and they’re deliberately absent from claude code. We’ve all seen a product get ratfucked internally by a product manager who copied the playbook of how Prabhakar Raghavan ruined google search.

The open source community is behind at the moment, but they’ll catch up fast. Open always beats closed in the long run. Just look at OpenAI’s fall into disgrace.

If that's the case, it's important to asses wether it'll be consistent when operating on a higher level, less dependent on the software layer that governs the agent. Otherwise it'll risk Claude also becoming more erratic.

Honestly, man, this is just weird new tech. We're asking a probabilistic model to generate English and JSON and Bash at the same time in an inherently mutable environment and then Anthropic also release one or two updates most workdays that contain tweaks to the system prompt and new feature flags that are being flipped every which way. I don't think you have to believe in a conspiracy theory to understand why it's a little wobbly sometimes.

If Anthropic do something you don't like, you just set a few environment variables and suddenly you're using the Claude Code harness with a local model, or one of thousands available through OpenRouter. And then there is also OpenCode. I haven't tried this, but I'm not worried.

^ https://github.com/ruvnet/claude-flow/wiki/Using-Claude-Code...

As someone who finds formal language a natural and better interface for controlling a computer, can you explain how and why you actually hate it? I mean not stuff like lack of discoverability, because you use a shell that lacks completion and documentation, that have been common for decades, I get those downsides, but why do you detest it in principle?

Most tools are still designed with programmers as the default user. Everyone else is treated as an edge case.

But the real growth is outside that bubble. AI won’t become mainstream by hiding everything. And it won’t get there by exposing everything either.

It gets there by translating action into intent. By showing progress in human terms. By making people feel they’re still in control.

The teams that figure this out won’t just win an argument on GitHub. They’ll reach the much larger audience that’s still waiting on the sidelines.

My detail here: https://open.substack.com/pub/insanedesigner/p/building-ai-f...

I subscribe to max rn. Tons of money. Anthropic’s Super Bowl ads were shit, not letting us use open code was shit, and this is more shit. Might only be a single straw left before I go to codex (no one’s complaining about it. And the openclaw creator prefers it)

This dev is clearly writing his reply with Claude and sounding way too corpo. This feels like how school teachers would talk to you. Your response in its length was genuinely insulting. Everyone knows how to generate text with AI now and you’re doing a terrible job at it. You can even see the emdash attempt (markdown renders two normal dashes as an emdash).

This was his prompt “read this blog post, familiarize yourself with the mentioned GitHub issue and make a response on behalf of Anthropic.” He then added a little bit at the end when he realized the response didn’t answer the question and got so to fix the grammar and spelling on that.

Your response is appropriate for the masses. But we’re not. We’re the so called hackers and read right through the bs. It’s not even about the feature being gone anymore.

There is a principle we uphold as “hackers” that doesn’t align with this that pisses people off a lot more than you think. I can’t really put my finger on it maybe someone can help me out.

PS About the Super Bowl ads. Anyone that knows the story knows they’re exaggerated. (In the general public outside of Silicon Valley it’s like a 50/50 split or something about people liking or disliking AI as a whole rn. OpenAI is doing way more to help the case (not saying ads are a good thing). ) Open ai used to feel like the bad guy now it’s kinda shifting to anthropic. This, the ads and open code are all examples of it. (I especially recommend people watch the anthropic and open ai Super Bowl ads back to back)

> You can even see the emdash attempt (markdown renders two normal dashes as an emdash)

He says he wrote it all manually.[0] Obviously I can't know if that's true, but I do think your internal AI detector is at least overconfident. For example, some of us have been regularly using the double hyphen since long before the LLM era. (In Word, it auto-corrects to an en dash, or to an em dash if it's not surrounded by spaces. In plain text, it's the best looking easily-typable alternative to a dash. AFAICT, it's not actually used for dashes in CommonMark Markdown.)

The rest is more subjective, but there are some things Claude would be unlikely to write (like the parenthetical "(ie. progressive disclosure)" -- it would write "i.e." with both dots, and it would probably follow it with a comma). Of course those could all be intentional obfuscations or minimal human edits, but IMO you are conflating the corporate communications vibe with the LLM vibe.

[0] https://news.ycombinator.com/item?id=46982418

This "emdash" and "double dash" discussion and mention is the first time I have heard of it or seen discussion of it. I've never encountered it in the wild, nor seen it used in any meaningful way in all my time on the internet these last 27 years.

And yes - I've seen that special dash character in word for many years. Not once has anyone said "oh hey I type double dashes and word uses that". No it's always been "word has this weird dash and if you copy-paste it it's weird", and no one knows how it pops up in word, etc.

And yes, I've seen the AI spit out the special dash many times. It's a telltale sign of using LLM generated text.

And now, magically, in this single thread, you can see half-dozen different users all using this "--" as if it's normal. It's like upside down world. Either everyone is now using this brand new form of speaking, or they're covering for this Claude code developer.

So yeah, maybe I've been sticking my head in the sand for years now, or maybe I just blindly ignored double-dashes when reading text till now. But it sure seems fishy.

Here are my pre-2020 HN comments, with 3 double hyphens in 8 comments: https://hn.algolia.com/?dateEnd=1576108800&dateRange=custom&...

As I was in the process of typing the search term to get my comments (and had just typed 'author'), this happened to come up as the top search result for Comments by Date for Feb 1st 2000 > Dec 12th 2019: https://news.ycombinator.com/item?id=21768030

Note that I wasn't searching directly for the double hyphen, which doesn't seem to work -- the first result just happened to contain one. If I'm covering for the Anthropic guy, I could be lying about the process by which I found that comment, but I think you should at least see this as sufficient reason to question your assumptions and do some searches of your own.

Ooo... ooo! I know what this is a reference to!

https://www.youtube.com/watch?v=hxM8QmyZXtg

That's why I use your excellent VS Code extension. I have lots of screen space and it's trivial to scroll back there, if needed.

I would really like even more love given to this. When working with long-lived code bases it's important to understand what is happening. Lots of promising UX opportunities here. I see hints of this, but it seems like 80% is TBD.

Ideally you would open source the extension to really use the creativity of your developer user base. ;)

Can we please move the "Extended Thinking" icon back to the left side of claude desktop, near the research and web search icons? What used to be one click is now three.

And it shouldn’t need to be said, but the words that appear on the screen are from an actual person with, you know, feelings.

Arrogant and clueless, not exactly who I want to give my money to when I know what enshitification is.

They have horrible instincts and are completely clueless. You need to move them away from a public-facing role. It honestly looks so bad, it looks so bad that it suggests nepotism and internal dysfunction to have such a poor response.

This is not the kind of mistake someone makes innocently, it's a window into a worldview that's made me switch to gemini and reactivate cursor as a backup because it's only going to get worse from here.

The problem is not the initial change (which you would rapidly realize was a big deal to a huge number of your users) but how high-handed and incompetent the initial response was. Nobody's saying they should be fired, but they've failed in public in a huge way and should step back for a long time.

Product manager here. Cynically, this is classic product management: simplify and remove useful information under the guise of 'improving the user experience' or perhaps minimalism if you're more overt about your influences.

It's something that as an industry we should be over by now.

It requires deep understanding of customer usage in order not to make this mistake. It is _really easy_ to think you are making improvements by hiding information if you do not understand why that information is perceived as valuable. Many people have been taught that streamlining and removal is positive. It's even easier if you have non-expert users getting attention. All of us here at HN will have seen UIs where this has occurred.

It should be a fad gone by at this point, but people never learn. Here's what to do instead: Find your most socially competent engineer, and have them talk to users a couple times a month. Just saved you thousands or millions in salaries, and you have a better chance of making things that your users actually want.

The problem is, it's hard to measure how good a PM is, even harder than for engineers. The instinct is to use product KPI's to do so, but especially at BigTech company, distribution advantages and traction of previous products will be the dominant factor here, and the best way of raising many product KPI's are actually user-hostile. Someone who has been a successful FAANG engineer who goes to a startup might lean towards over-engineering, but at least they should be sharp on the fundamentals. Someone who has been a successful FAANG PM might actually have no idea how to get PMF.

> Here's what to do instead: Find your most socially competent engineer, and have them talk to users a couple times a month

This is actually a great idea, but what will happen is this socially competent engineer will soon have a new full-time job gathering those insights, coalescing them into actionable product changes, persuading the rest of the org to adopt those changes, and making sure the original user insights make it into the product. Voila: you've re-invented product management.

But I actually think it's good to source PM's from people who've been engineers for a few years. PM's used to come from a technical background; Google famously gave entry-level coding tests to PM's well into the '10s. I dunno when it became more fashionable to hire MBA's and consultants into this role, but it may have been a mistake.

This is a names vs. structure thing. For a moment, taboo the term product manager.

What I'm suggesting is a low risk way to see if an engineer has an aptitude for aligning the roadmap with what the users want. If they aren't great at it, they can go back to engineering. We also know for sure that they are technically competent since they are currently working as an engineer, no risk there.

The conventional wisdom (bad meme) is going to the labor market with a search term for people who claim to know what the users want, any user, any problem, doesn't matter. These people are usually incompetent and have never written software. Then hiring 1 and potentially more of the people that respond to the shibboleth.

If you want the first case, then you can't say "product manager" because people will automatically do the second case.

It doesn't have to be the most socially competent engineer to gather feedback. Having the engineering team sit with the target users gives so much insight into how the product is being used.

I once worked on an administrative tool at a financial institution. There were lots of pain points, as it started as a dev tool that turned into a monstrosity for the support staff. We asked to have a meeting with some reps who were literally 2 floors below us. Having the reps talk as they worked with the tool in real time over 1 hour was worth more than a year's worth of feedback that trickled in. It's one thing to solicit feedback. It's another to see how idiosyncrasies shape how products get used.

I agree your assessment about the value of good PMs. The issue, in my experience, is that only about 20% (at most) are actually good. 60% are fine and can be successful with the right Design and Engingeering partners. And 20% should just be replaced by AI now so we can put the proper guardrails around their opinions and not be misled by their charisma or whatever other human traits enabled them to get hired into a job they are utterly unqualified for.

But not lately. Lately it’s been people who have very little relevant domain expertise, zero interest in putting in the time to develop said expertise beyond just cataloguing and regurgitating feedback from the customers they like most on a personal level, and seem to mostly have only been selected for the position because they are really good at office politics.

But I think it’s not entirely their fault. What I’ve also noticed is that, when I was on teams with really elective product managers, we also had a full time project manager. That possibly freed up a lot of the product manager’s time. One person to be good at the tactical so the other can be good at the strategic.

Since project managers have become passé, though, I think the product managers are just stretched too thin. Which sets up bad incentive structures: it’s impossible to actually do the job well anymore, so of course the only ones who survive are the office politicians who are really good at gladhanding the right people and shifting blame when things don’t go well.

That good taste doesn't translate between domains very often. Good taste for developer tools doesn't mean good taste for a video game inventory screen. And that's the crux of the problem. There is a segment of the labor market calling themselves "product manager" who act like good taste is domain independent, and spread lies about their importance to the success of every business. What's worse is that otherwise smart people (founders, executives) fall for it because they think hiring them is what they are supposed to do.

Over time, as more and more people realized that PM is a side door into big companies with lots of money, "Product Manager" became an imposter role like "Scrum Master". Now product orgs are pretty much synonymous with incompetence.

Taste on the other hand is about creating an overall feeling from a product. It's holistic and about coherence, where intuition is more bottom-up problem solving. Tasteful decisions are those that use restraint, that strike a particular tone, that say 'no' when others might say 'yes'. It's a lot more magical, and a lot rarer.

Both taste and intuition are ultimately about judgment, which is why they're often confused for one another. The difference is they approach problems from the opposite side; taste from above, intuition from below.

I agree with your assessment otherwise, PM can be a real smoke screen especially across domain and company stage.

That’s definitely one of the biggest problems with product management. The delusion that you can be an expert at generic “product”.

We used to have subject matter experts who worked with engineers. That made sense to me.

The counter to that is "the proportion of 'really good engineers' to product engineering teams has got to be in the single digits," and I would agree with that, as well.

The problem is what is incentivized to be built - most teams are working on "number go up?" revenue or engagement as a proxy to revenue "problems." Not "is this a good product that people actively enjoy using?" problems.

Just your typical late-stage capitalism shit.

In most of my engineering jobs, the Product Managers were much closer to our users than the engineers.

Good product managers are very valuable. There are a lot of bad ones carrying the product manager title because it was viewed as the easy way to get a job in tech without having to know how to program, but smart companies are getting better at filtering them out.

> Find your most socially competent engineer, and have them talk to users a couple times a month

Every single time I've seen this tried, it turns into a situation where one or two highly vocal customers capture the engineering team's direction and steer the product toward their personal needs. It's the same thing that happens when the sales people start feeding requests from their customers into the roadmap.

For example, I had one product manager who made themselves irrelevant because they wouldn't work with sales. The company needed to sell the product to pay us, and sales talked with potential buyers about what might swing their purchase decision and what they would pay extra for. Since the PM only talked to users and ignored sales when doing product design and product roadmaps, the way sales input got integrated into product development is that we frequently got top-down directives from management to prioritize one-off requests from sales over the roadmap. Needless to say, this didn't lead to a cohesive and easy-to-understand product.

Before I saw that PM failing, I hadn't thought about the relationship between product and sales.

> Find your most socially competent engineer,

These usually get promoted to product management anyway, so this isn't a new thought.

It's not.

Engineers are having more and more minutia and busy work taken off their plate, now done by AI. That allows them to be heads up more often, more of their cognitive capacity is directed towards strategy, design, quality.

Meanwhile, users are building more and more of their own tools in house. Why pay someone when you can vibe code a working solution in a few minutes?

So product managers are getting squeezed out by smarter people below them moving into their cognitive space and being better at solving the problems they were supposed to be solving. And users moving into their space by taking low hanging fruit away from them. No more month long discussions about where to put the chart and what color it should be. The user made their own dashboard and it calls into the API. What API? The one the PM doesn't understand and a single engineer maintains with the help of several LLMs.

If it's simple and easy: the user took it over, if it's complex: it's going to the smartest person in the room. That has never been the PM.

Yet the PM always has the last say on what goes in the product, NOT the engineer. Funny how that works...

None of your conclusions are consistent with experience (interviewed 900+ SaaS management teams)

This also depends on your definition on "smartest".

I agree completely that these are the important qualifications to be setting direction for a product.

> Find your most socially competent engineer, and have them talk to users a couple times a month.

This doesn't necessarily follow from the above, but in Anthropic's case specifically, where the users are software engineers, it probably would have worked better than whatever they have going on now.

In general, it's probably better to have domain experts doing product management, as opposed to someone who is trained in product management.

Unfortunately, he’s already two of our SEs and the CTO and we’re starting to run low on coders.

What are we going to do when we need a customer success manager or a profserv team?

Make the application configurable. Developers like to tinker with their tools.

I think we can be more charitable. Don't you see, even here on HN, people constantly asking for software that is less bloated, that does fewer things but does them better, that code is cost, and every piece of complexity is something that needs to be maintained?

As features keep getting added, it is necessary to revisit where the UX is "too much" and so things need to be hidden, e.g. menu commands need to be grouped in a submenu, what was toolbar functionality now belongs in a dialog, reporting needs to be limited to a verbose mode, etc.

Obviously product teams get it wrong sometimes, users complain, and if enough users complain, then it's brought back, or a toggle to enable it.

There's nothing to be cynical about, and it's not something we "should be over by now." It's just humans doing their best to strike the balance between a UX that provides enough information to be useful without so much information that it overwhelms and distracts. Obviously any single instance isn't usually enough to overwhelm and distract, but in aggregate they do, so PM's and designers try to be vigilant to simplify wherever possible. But they're only human, sometimes they'll get it wrong (like maybe here), and then they fix it.

I agree it's a mistake, but I don't believe that it's viewed that way by anyone making the decision to do it.

Over the past ten years or so the increasing de-featuring of software under the guise of 'simplification' has become a critical issue for power users. For any GUI apps which have a mixed base of consumer and power users, I mostly don't update them anymore because they're as likely to get net worse vs better.

It's weird that companies like MSFT seem puzzled why so many users refuse to update Windows or Office to major new feature versions.

We have by now taught them about good information density.

Like, the permission pages, if you look at them just once, kinda look like bad 90s UIs. They throw a crapton of information at you.

But they contain a lot of smart things you only realize when actually using it from an admin perspective. Easy comparison of group permissions by keeping sorting orders and colors stable, so you can toggle between groups and just visually match what's different, because colors change. Highlights of edge cases here and there. SSO information around there as well. Loads of frontloaded necessary info with optional information behind various places.

You can move seriously fast in that interface once you understand it.

Parts of the company hate it for not being user friendly. I just got a mail that a customer admin was able to setup SSO in 15 minutes and debug 2 mapping issues in another 10 and now they are production ready.

Not at all cynically, this is classic product management - simplify by removing information that is useful to some users but not others.

We shouldn't be over it by now. It's good to think carefully about how you're using space in your UI and what you're presenting to the user.

You're saying it's bad because they removed useful information, but then why isn't Anthropic's suggestion of using verbose mode a good solution? Presumably the answer is because in addition to containing useful information, it also clutters the UI with a bunch of information the user doesn't want.

Same thing's true here - there are people who want to see the level of detail that the author wants and others for whom it's not useful and just takes up space.

> It requires deep understanding of customer usage in order not to make this mistake.

It requires deep understanding of customer usage to know whether it's a mistake at all, though. Anthropic has a lot deeper understanding of the usage of Claude Code than you or I or the author. I can't say for sure that they're using that information well, but since you're a PM I have to imagine that there's been some time when you made a decision that some subset of users didn't like but was right for the product, because you had a better understanding of the full scope of usage by your entire userbase than they did. Why not at least entertain the idea that the same thing is true here?

The notifications act as an overall progress bar and give you a general sense of what Claude Code is doing: is it looking in the relevant part of your codebase, or has it gotten distracted by some unused, vendored-in code?

"Read 2 files" is fine as a progress indicator but is too vague for anything else. "Read foo.cpp and bar.h" takes almost the same amount of visual space, but fulfills both purposes. You might want to fold long lists of files (5? 15?) but that seems like the perfect place for a user-settable option.

Now this is a good, thoughtful response! Totally agree that if you can convey more information using basically the same amount of space, that's likely a better solution regardless of who's using the product.

Software developers like customizable tools.

That's why IDEs still have "vim keybindings" and many other options.

Your user is highly skilled - let him decide what he wants to see.

The user is highly skilled; let them filter out what is important

This should be better than adding an indeterminate number of toggles and settings, no?

verbose i think puts it on the TUI and i cant particularly grep or sed on the TUI

PM1> Looks like a PM who is out of touch with what the developers want. Easy mistake to make.

PM2> Anthropic knows better than this developer. The developer is probably wrong.

I don't know for sure what the best decision is here, I've barely used CC. Neither does PM1 nor PM2, but PM2 is being awfully dismissive of the opinion of a user in the target audience. PM1 is probably putting a bit too much weight on Developer's opinion, but I fully agree with "All of us... have seen UIs where this has occurred." Yes, we have. I personally greatly appreciate a PM who listens and responds quickly to negative feedback on changes like this, especially "streamlining" and "reducing clutter" type changes since they're so easy to get wrong (as PM1 says).

> It's good to think carefully about how you're using space in your UI and what you're presenting to the user.

I agree. It's also good to have the humility to know that your subjective opinion as someone not in the target audience even if you're designing the product is less informed in many ways than that of your users.

----

Personally, I get creeped out by how many things CC is doing and tokens it's burning in the background. It has a strong "trust me bro" vibe that I dislike. That's probably common to all agent systems; I haven't used enough to know.

Nope! Not what I said. I specifically said that I don't know if Anthropic is using the information they have well. Please at least have the courtesy not to misrepresent what I'm saying. There's plenty of room to criticize without doing that.

> It's also good to have the humility to know that your subjective opinion as someone not in the target audience even if you're designing the product is less informed in many ways than that of your users.

Ah, but you don't know I'm not the target audience. Claude Code is increasingly seeing non-developer users, and perhaps Anthropic has made a strategic decision to make the product friendlier to them, because they see that as a larger userbase to target?

I agree that it's important to have humility. Here's mine: I don't know why Anthropic made this decision. I know they have much more information than me about the product usage, its roadmap and their overall business strategy.

I understand that you may not like what they're doing here and that the lack of information creeps you out. That's totally valid. My point isn't that you're wrong to have that opinion, it's that folks here are wrong to assume that Anthropic made this decision because they don't understand what they're doing.

100% this.

It might be convenient to hide information from non-technical users; but software engineers need to know what is happening. If it is not visible by default, it should be configurable via dotfiles.

I personally love that the model tells me what file it has read because I know whether or not it's headed in the generally right direction that I intended. Anthropic has no way of knowing I feel this way.

I'll just reiterate my initial point that the author of the post and the people commenting here have no idea what information Anthropic is working with. I'm not saying they've made the right decision, but I am saying that people ought to give them the slightest bit of credit here instead of treating them like idiots.

Because reading through hundreds of lines verbose output is not a solution to the problem of "I used to be able to see _at a glance_ what files were being touched and what search patterns were being used but now I can't".

Cynically, it's a vibe coded mess and the "programmers" at Anthropic can't figure out how to put it back.

More cynically, Anthropic management is trying to hide anything that people could map to token count (aka money) so that they can start jiggling the usage numbers to extract more money from us.

I was recently involved with a company that wanted us to develop a product that would be disruptive enough to enter an established market, make waves and shock it.

We did just that. We ran a deep survey of all competing products, bought a bunch of them, studied absolutely everything about them, how they were used and their users. Armed with that information, we produced a set of specifications and user experience requirements that far exceeded anything in the market.

We got green-lit to deliver a set of prototypes to present at a trade show. We did that.

The prototypes were presented and they truly blew everyone away. Blogs, vlogs, users, everyone absolutely loved what we created and the sense was that this was a winning product.

And then came reality. Neither the product manager nor the CTO (and we could add the CEO and CFO to the list) had enough understanding and experience in the domain to take the prototypes to market. It would easily have required a year or two of learning before they could function in that domain.

What did they do? They dumbed down the product specification to force it into what they understood and what engineering building blocks they already had. Square peg solidly and violently pounded into a round hole.

The outcome? Oh, they built a product alright. They sure did. And it flopped, horribly flopped, as soon as it was introduced and made available. Nobody wanted it. It was not competitive. It offered nothing disruptive. It was a bad clone of everything already occupying space in that ecosystem. Game over.

The point is: Technology companies are not immune to human failings, ego, protectionism/turf guarding, bad decisions, bad management, etc.

When someone says something like "I am not sure that's a good idea for a startup. There's competition." My first though is: Never assume that competitors know what they are doing, are capable and always make the right decisions without making mistakes. You don't always need a better product, you need better execution.

> The point is: Technology companies are not immune to human failings, ego, protectionism/turf guarding, bad decisions, bad management, etc.

They only accidentally succeed in spite of those things. They have those things more than existing businesses precisely because having too much money masks the pressures that would force solid execution and results. When you have 80% profit margins, you can show up drunk.

People who toggle debug will get "full" access and those who dont care, probably won't notice if their LLM us is degraded.

It seems a pure market segmenting prior to a "shrinkflation" approach to cost management.

https://github.com/anthropics/claude-code/issues/15263

https://github.com/anthropics/claude-code/issues/9099

https://github.com/anthropics/claude-code/issues/8371

It's very clear that Anthropic doesn't really want to expose the secret sauce to end users. I have to patch Claude every release to bring this functionality back.

If Claude Code can replace an engineer, it should cost just a bit less than an engineer, not half as much.

Anthropic's Opus 4.6 is a bit bigger, but they'd have to be insanely incompetent to not make a profit on inference.

[1] https://github.com/deepseek-ai/open-infra-index/blob/main/20...

Are you aware of how many years Amazon didn’t turn a profit?

Not agreeing with the tactic - just…are you aware of it?

Having said that, I do think that there is an investment bubble in AI, but am just arguing that you're not looking at the right signal.

That means the pricing is going to be competitive. You may still get your wish though, but instead of the price of an engineer remaining the same, it will cut itself down by 95%.

Autocorrect hall of famer, there.

https://eggcorns.lascribe.net/english/242/escape-goat/