Posted by WXLCKNO 4 hours ago
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.)
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.
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.
I actually miss being able to see all of the thinking, for example. That was useful, because I could tell more quickly when the model was making a wrong assumption.
“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.
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.
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
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.
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?
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.
Edit: I can't post anymore today apparently because of dang. If you post a comment about a bad terminal at least tell us about the rendering issues.
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.
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.
> 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.
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 agree it's a mistake, but I don't believe that it's viewed that way by anyone making the decision to do it.
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.
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.
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.
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.
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".
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...
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.
It's not 10x by any means but it doesn't need to be at most dev salaries to pay for itself. 1.5x alone is probably enough of an improvement for most >jr developers for a company to justify $1000/month.
I suppose if your area of responsibility wasn't very broad the value would decrease pretty quickly so maybe less value for people at very large companies?
Using Claude Code for one year is worth the same as a used sedan (I.E., ~$12,000) to you?
You could be investing that money!
edit: Fuck I'm getting trolled
I think personal subs are subsidized while corporate ones definitely not. I have CC for my personal projects running 16h a day with multiple instances, but work CC still racks way higher bills with less usage. If I had to guess my work CC is using 4x as little for 5x the cost so at least 20x difference.
I am not going to say it has 10xed or whatever with my productivity, but I would have never ever in that timeframe built all those things that I have now.
Similarly, STFU about the stuff that can give LLMs ideas for how to harm us (you know what I'm talking about, it's reptilian based)
The whole comment thread is likely to have been read by some folks at Anthropic. Already a disaster. Just keep on with the "we hate it unless it gets cheaper" discourse please!!!
Meanwhile, I am observing precisely how VS+Copilot works in my OAI logs with zero friction. Plug in your own API key and you can MITM everything via the provider's logging features.
To other actors who want to train a distilled version of Claude, more likely.
GitHub Codespaces has a critical bug that makes the copilot terminal integration unusable after 1 prompt, but the company has no idea, because there is no clear way to report it from the product, no customer support funnel, etc. There's 10 upvotes on a poorly-written sorta-related GH issue and no company response. People are paying for this feature and it's just broken.
1: https://blog.devgenius.io/you-might-be-breaking-claudes-tos-...
It's amazing how much other agentic tools suck in comparison to Claude Code. I'd love to have a proper alternative. But they all suck. I keep trying them every few months and keep running back to Claude Code.
Just yesterday I installed Cursor and Codex, and removed both after a few hours.
Cursor disrespected my setting to ask before editing files. Codex renamed my tabs after I had named them. It also went ahead and edited a bunch of my files after a fresh install without asking me. The heck, the default behavior should have been to seek permission at least the first time.
OpenCode does not allow me to scrollback and edit a prior prompt for reuse. It also keeps throwing up all kinds of weird errors, especially when I'm trying to use free or lower cost models.
Gemini CLI reads strange Python files when I'm working on a Node.js project, what the heck. It also never fixed the diff display issues in the terminal; It's always so difficult for me to actually see what edits it is actually trying to make before it makes it. It also frequently throws random internal errors.
At this point, I'm not sure we'll be seeing a proper competitor to Claude Code anytime soon.
And then this. They want to own your dev workflow and for some reason believe Claude code is special enough to be closed source. The react TUI is kinda a nightmare to deal with I bet.
I will say, very happy with the improvements made to Codex 5.3. I’ve been spending A LOT more time with codex and the entire agent toolchain is OSS.
Not sure what anthropic’s plan is, but I haven’t been a fan of their moves in the past month and a half.
for example Amp "feels" much better. Also like in Amp how I can just send the message whenever and it doesn't get queued
* I know, lots of "feels" in there..
Sam wants money. Dario wants to be your dad.
I'm going with Sam.
https://www.nytimes.com/2025/01/08/technology/sam-altman-sis...
DEVELOPERS, DEVELOPERS, DEVELOPERS, DEVELOPERS
I write mainly out of the hope that some Anthropic employees read this: you need an internal crusade to fight these impulses. Take the high road in the short-term and you may avoid being disrupted in the long-term. It's a culture issue.
Probably your strongest tool is specifically educating people about the history. Microsoft in the late 90s and early 00s was completely dominant, but from today's perspective it's very clear: they made some fundamental choices that didn't age well. As a result, DX on Windows is still not great, even if Visual Studio has the best features, and people with taste by and large prefer Linux.
Apple made an extremely strategic choice: rebuild the OS around BSD, which set them up to align with Linux (the language of servers). The question is: why? Go find out.
The difference is a matter of sensibility, and a matter of allowing that sensibility to exist and flourish in the business.
Anthropic is the market leader for advanced AI coding with no serious competitor currently very close and they are preparing to IPO this year. This year is a transition year. The period where every decision would default toward delighting users and increasing perceived value is ending. By next year they'll be fully on the quarterly Wall Street grind of min/maxing every decision to extract the highest possible profit from customers at the lowest possible cost.
This path is inevitable and unavoidable, even with the most well-intentioned management and employees.
Some greatest hits:
- CoreAudio, Mac OS memory management, kernel in general, and many other decisions
- Google's internal dev tooling, Go, and Chrome (at least, in its day)
- C#, .NET, and Typescript (even Microsoft does good work)
One of the hallmarks of heroic engineering work is that everyone takes it for granted afterward. Open source browsers that work, audio that just works, successors to C/C++ with actual support and adoption, operating systems that respond gracefully under load, etc. ... none of these things were guaranteed, or directly aligned with short-term financial incentives. Now, we just assume they're a requirement.
Part of the "sensibility" I'm talking about is seeking to build things that are so boring and reliable that nobody notices them anymore.
I understand the article writers frustration. He liked a thing about a product he uses and they changed the product. He is feeling angry and he is expressing that anger and others are sharing in that.
And I'm part of another group of people. I would notice the files being searched without too much interest. Since I pay a monthly rate, I don't care about optimizing tokens. I only care about the quality of the final output.
I think the larger issue is that programmers are feeling like we are losing control. At first we're like, I'll let it auto-complete but no more. Then it was, I'll let it scaffold a project but not more. Each step we are ceding ground. It is strange to watch someone finally break on "They removed the names of the files the agent was operating on". Of all of the lost points of control this one seems so trivial. But every camels back has a breaking point and we can't judge the straw that does it.
I'm guessing you're not aware of how their newest game, Starfield, was received. In the long term, that direction did not work out for them at all.
Those are fightin’ words as someone who has dumped more hours than I can count into Skyrim but…
I had never heard of this game, but it has a lot going for it (source engine) and I watched a little of the gameplay you linked and I’m intrigued. I’m probably gonna pick this up for the steam deck.
A friend recommended the Might and Magic games to me a long time ago and I bought them off GoG, but wasn’t a fan of the gameplay and just couldn’t get hooked. This looks very different from what I remember (probably because this is a very different game from the earlier ones).
Thank you for mentioning this game!
Maybe Claude Code web or desktop could be targeted to these new vibe coders instead? These folks often don't know how simple bash commands work so the terminal is the wrong UX anyway. Bash as a tool is just very powerful for any agentic experience.
On the other end are the hardcore user orchestrating a bunch of agents, not sitting there watching one run, so they don’t care about these logs at all
In the middle are the engineers sitting there watching the agent go
Or, it could serve as a textbook example how to make your real future long term customers (=fluent coders) angry… what a strategy :)
Yes, it was easier. But it dumbed down a generation of developers.
It took them two decades to try to come up with Powershell, but it was too late.
Not a chance.
If anything, the reverse, in that it devalues engineering. For most, LLMs are a path to an end-product without the bother or effort of understanding. No different than paid engineers were, but even better because you don't have to talk to engineers or pay them.
The sparks of genuine curiosity here are a rounding error.
There is a reason why nowadays games start to help massively if the player gets stuck.
You mean those "free" games, that are hard and grindy by design and the offered help comes in the shape of payed perks to solve the challenges?
Meanwhile all evidence is that the true value of these tools is in their ability to augment & super-charge competent software engineers, not replace them.
Meanwhile the quality of Claude Code the tool itself is a bit of a damning indictment of their philosophy.
Give me a team of experienced sharp diligent engineers with these coding tools and we can make absolutely amazing things. But newbie product manager with no software engineering fundamentals issuing prompts will make a mess.
I can see it even in my own work -- when I venture into doing frontend eng using these tools the results look good but often have reliability issues. Because my background/specialization is in systems, embedded & backend work -- I'm not good at reviewing the React etc code it makes.
The whole company also has this meme about AI safety and some sort of fear-mongering about the models every few months. It's basically a smokescreen for normies and other midwits to make it look more mysterious and advanced than it really is. OOOOH IT'S GOING TO BREAK OUT! IT KNOWS IT'S BEING EVALUATED!
I bet there are some true believers in Anthropic too, people who think themselves too smart to believe in God so they replaced it with AI instead but all the same hopes are there, eg. Amodei preaching about AI doubling the human lifespan. In religion we usually talk about heaven.
I just want useful tools.
just 6 months more and like $200B in capex and we’ll be there, trust the process
It still does what I need so I'm okay with it, but I'm also on the $20 plan so it's not that big of a worry for me.
I did sense that the big wave of companies is hitting Anthropic's wallet. If you hadn't realized, a LOT of companies switched to Claude. No idea why, and this is coming from someone who loves Claude Code.
Anyway, getting some transparency on this would be nice.
It is entirely due to Opus 4.5 being an inflection point codingwise over previous LLMs. Most of the buzz there has been organic word of mouth due to how strong it is.
Opus 4.5 is expensive to put it mildly, which makes Claude Code more compelling. But even now, token providers like Openrouter have Opus 4.5 as one of its most popular models despite the price.
The real annoying thing about Opus 4.5 is that it's impossible to publicly say "Opus 4.5 is an order of magnitude better than coding LLMs released just months before it" without sounding like a AI hype booster clickbaiting, but it's the counterintuitive truth, to my personal frustration.
I have been trying to break this damn model since its November release by giving it complex and seemingly impossible coding tasks but this asshole keeps doing them correctly. GPT-5.3-Codex has been the same relative to GPT-5.2-Codex, which just makes me even more frustrated.
CC confidently iterated until it discovered the issue. CC confidently communicated exactly what the bug was, a detailed step-by-step deep dive into all the sections of the code that contributed to it. CC confidently suggested a fix that it then implemented. CC declared victory after 10 minutes!
The bug was still there.
I’m willing to admit I might be “holding it wrong”. I’ve had some successes and failures.
It’s all very impressive, but I still have yet to see how people are consistently getting CC to work for hours on end to produce good work. That still feels far fetched to me.
But I have to give it to Amodei and his goons in the media, their marketing is top notch. Fear-mongering targeted to normies about the model knowing it is being evaluated and other sort of preaching to the developers.
Why would you even watch a YouTube video with ads?
There are ad blockers, sponsor segment blockers, etc. If you use them, it will block almost every kind of YouTube ad.
One day I visited DistroWatch.com. The site deliberately tweaked its images so ad blockers would block some "good" images. It took me awhile to figure out what was going on. The site freely admitted what it was doing. The site's point was: you're looking at my site, which I provide for free, yet you block the thing that lets me pay for the site?
I stopped using ad blockers after that. If a site has content worth paying for, I pay. If it is a horrible ad-infested hole, I don't visit it at all. Otherwise, I load ads.
Which overall means I pay for more things and visit less crap things and just visit less things period. Which is good.
not even joking
An ad-blocker /is/ security software. You don’t have to take it from me, you can read from the Cybersecurity and Infrastructure Security Agency
> AT-A-GLANCE RECOMMENDATIONS
> Standardize and Secure Web Browsers
> Deploy Advertisement Blocking Software
> Isolate Web Browsers from Operating Systems
> Implement Protective Domain Name System Technologies
Literally their second recommendation on this pamphlet about securing web browsers: https://www.cisa.gov/sites/default/files/publications/Capaci...
Moreover you don’t even need a 0-day to fall for phishing. All you need is to be a little tired or somehow not paying attention (inb4 “it will never happen to ME, I am too smart for that”)
Use the pi coding agent. Bare-bones context, easy to hack.
Yesterday "I don't know about you, but I benefit so much from using Claude at work that I would gladly pay $1,500-$2,000 per month to keep using it."
Thanks for that, and it's worth nothing FYI.
LLMs are probably the most impressive machine made in recorded human existence. Will there be a better machine? I'm 100% confident there will be, but this is without a doubt extremely valuable for a wide array of fields, including software development. Anyone claiming otherwise is just pretending at this point, maybe out of fear and/or hope, but it's a distorted view of reality.
By this do you mean there isn't much more room for future improvement, or that you feel it is not useful in its current form for software development? I think the latter is hard position to defend, speaking as a user of it. I am definitely more productive with it now, although I'm not sure I enjoy software development as much anymore (but that is a different topic)
I don't expect that LLM technology will improve in a way that makes it significantly better . I think the training pool is poisoned, and I suspect that the large AI labs have been cooking the benchmark data for years to suspect that their models are improving more quickly than they are in reality.
That being said, I'm sure some company will figure out new strategies for deploying LLMs that will cause a significant improvement.
But I don't expect that improvements are going to come from increased training.
> [Do] you feel it is not useful in its current form for software development?
IME using LLMs for software development corrodes my intuitive understanding of an enterprise codebase.
Since the advent of LLMs, I've been asked to review many sloppy 500+/1000+ line spam PRs written by arrogant Kool-Aid drinking coworkers. If someone is convinced that Claude Code is AGI, they won't hesitate to drop a slop bomb on you.
Basically I feel that coding using LLMs degrades my understanding of what I'm working on and enables coworkers to dominate my day with spam code review requests.
I feel you there, I definitely notice that. I find I can output high quality software with it (if I control the design and planning, and iterate), but I lack that intuitive feel I get about how it all works in practice. Especially noticeable when debugging; I have fewer "Oh! I bet I know what is going on!" eureka moments.
It seems so gross.
But I guess with all of the trillions of investor dollars being dumped into the businesses, it would be irresponsible to not run guerrilla PR campaigns
I think this takes away from the main thrust of your argument which is the marketing campaign and to me makes you seem conspiratorial minded. LLMs can be both useful and also mass astroturfing can be happening.
Personally I have witnessed non coders (people who can code a little but have not done any professional software building) like my spouse do some pretty amazing things. So I don’t think it’s useless.
It can be all of:
1. It’s useful for coding
2. There’s mass social media astroturfing happening
3. There’s a massive social overhype train that should be viewed skeptically
4. Theres some genuine word of mouth and developer demand to try the latest models out of curiosity, with some driven by the hype train and irrational exuberance and some by fear for their livelihoods.
IN MY GENUINELY HELD OPINION, LLMs generate shit code and the people who disagree don't know what good code looks like.
Yes they are. This is true.
> which is a time consuming and tedious part of programming.
In my experience, this is a tedious part of programming which I do not spend very much time on.
In my experience LLM generated API boilerplate is acceptable, yet still sloppier than anything I would write by hand.
In my experience LLMs are quite bad at generating essentially every other type of code, especially if you are not generating JS/TS or HTML/CSS.
Regarding the thoughts: it also allows me to detect problematic paths it takes, like when it can't find a file.
For example today I was working on a project that depends on another project, managed by another agent. While refactoring my code it noticed that it needs to see what this command is which it is invoking, so it even went so far as to search through vs code's user data to find the recent files history if it can find out more about that command... I stopped it and told it that if it has problems, it should tell me. It explained it can't find that file, i gave it the paths and tokens were saved. Note that in that session I was manually approving all commands, but then rejected the one in the data dir.
Why dumb it down?
There are no vibes in “I am looking at files and searching for things” so I have zero weight to assign to your decision quality up until the point where it tells me the evals passed at 100%.
Your agent is not good enough. I trust it like I trust a toddler not to fall into a swimming pool. It’s not trying to, but enough time around the pool and it is going to happen, so I am watching the whole time, and I might even let it fall in if I think it can get itself out.