(I work at Anthropic) I agree. I use an LLM to write my code, but I do all of my writing by hand, since it helps me think.
It reminds me of the transition over the last year from AI-assisted coding to AI doing all the coding. At first the code output wasn't good enough, and humans read and iterated on the code all day, so the details of the source code mattered. Now, the code is largely high quality and it meets a large set of guardrails we've set up over the years (linters, typecheckers, security checks, LLM-assisted code quality checkers), and it's just Claude working on the code, so the details matter less and engineers think a level or two up (machine code < assembly/bytecode < source code < conversation with agent < artifact with high level design).
I wonder if long form writing will go the way of code. You and the AI agree on an outline or other high level representation, then the LLM expands it into a document. But writing and coding are different enough in a number of ways that this is far from inevitable.
> wonder if long form writing will go the way of code. You and the AI agree on an outline or other high level representation, then the LLM expands it into a document.
What use is that? I'm not being facetious, I'd really rather like to know.
Who or what is the audience for that sort of long form writing? If it's a human, why would they read it? They'd just give it to an LLM and get the salient points back. If the audience is another LLM, why expand it?
The only use case is an audience of humans who still read and understand, and those people aren't going to be interested in a message when it is not apparent that the sender actually understands the message themselves.
A lot of corporate documentation exists solely to measure if people are working or not.
That's why there's so many meetings in white collar companies. Because people can't understand what is going on at those documents so they just need to "align".
LLMs are amazing at generating this useless documentation that goes absolutely nowhere.
1. I have a bunch of data or research that I've gathered with a unique hypothesis
2. Having gotten my arms around that pile of information, I believe I have a compelling thesis to put forth
3. I design the narrative arc and of the thesis. The important parts, the necessary but not sufficient scaffolding.
4. An AI helps fill in the story from there. Fact checks each claim, connects the dots, makes it comprehensible.
Who is this for? Well, quite possibly the human who asked for it. It's pretty informative to read back a research brief in full that you helped do the scaffolding.
Also of very clear use is other AI's who did not have the same unique hypothesis and did not gather the supporting evidence. It's an interesting angle for others to build on.
And of course, other humans! Most human written content gets almost zero readers today as it is. And I suppose LLM content probably pulls the asymptote closer to zero, but some pieces of content may be genuinely interesting or useful.
> An AI helps fill in the story from there. Fact checks each claim, connects the dots, makes it comprehensible.
I think this certainly has some value but this claim in and of itself is stated like your hand-wavy step 3. How do they fact check claims and connect the dots?
Maybe LLMs get there but currently they write in an extremely verbose manner, and things that have gotten into the context window that are no longer relevant continue to stick around (just try having it write some code, then work some of it back to simplify the problem - it will insist on writing comments about code that no longer exists).
Right now using an LLM to write documents is like taking a superhighway to travel 100 meters. Yeah you're doing a lot but is all that really necessary?
I won't deny that LLMs will never have a place in writing. But I personally don't think the current form is "the one that actually lands" (!).
Then the reader can use an LLM to compress it back, and you can then interrogate it for details.
I used to say this was the future of advertising (cr sales person prompts “we have some new EV SUVs on the lot”; GPT generates an ad email with a synthetic video, blinking text etc; then the recipient’s spam processor tells them “that dealer has some new SUVs”. I suppose the same could happen with so-called “long form”.
> What use is that? I'm not being facetious, I'd really rather like to know.
People are terrible at writing. Near universally bad. Even good writers have drafts and editors.
There is a constant refrain here that somehow short messages are more valuable than longer ones. But that assumes it's understandable. Lots of short content is, frankly, awful because the writer cannot put themselves in the position of the reader and explain all the things around the point they're making that the reader really should be told.
You can view writing as translation. From your language to a language your audience speaks. At that level is it so odd if the word count differs from one side to the other?
But this is the same with coding. The reason that AI can write code from a description that is shorter than the output is in large part because it makes decisions about the behavior that were unspecified in your prompt. We accept this for coding apparently, I guess because those decisions are often unimportant. We might accept it for writing too. I hope not.
Not necessarily. Poorly worded, ambiguous, confusingly ordered writing can be massively improved without changing the core content. Better setups and explanations can be longer without changing the message or meaning.
Look at it the other way, could you take a good longer message you’ve written and make it shorter and less readable for your audience while still making sense to you and containing the key points?
wasn't it thoreau who said "Not that the story need be long, but it will take a long while to make it short"
personally, I think there's a time and place for short versus long, just like there's a time and place for a 45mins TV episode versus a 2 hour marathon movie.
You claim writing is thinking, but imply writing code isn't thinking.
My opinion of LLM design review isn't that high - it seems to miss design tweaks that could vastly simplify corner cases. But if your code isn't written for human consumption maybe it doesn't matter. I'm still directly responsible for what I commit, so I can't just offload it to Claude.
That's something I struggle with, I try to get LLMs to output code I don't care much about and focus on the parts I do and it kind of works but the problem is that reading code written by the LLM is even worth than reading LLM generating text. It's nauseating and you still have to read what the LLM did if you want to really work on the parts that matter.
People have been "writing code" like this for decades. That a programmer happens to do it doesn't turn it into writing code, no one would have made that claim 25 years ago, and people who aren't programmers wouldn't make that claim today.
It's like watching somebody about to be hit by a bus. You yell, you wave your arms, but they either don't hear you, or they don't believe you. The last thing that goes through their head is a Greyhound's hood ornament.
There is no subtext to bigstrat2003's argument, other than "I'm wrong, and I don't care." If you give persistent, repeatable instructions to a computer, you are programming it. If you disagree, you are gatekeeping. It's that simple.
The most popular programming languages in 2030 will, in fact, be English and Mandarin. Deal with it and get over it.
----------------
Edit, to bcrosby95: Look up the etymology of the word 'computer'. It didn't originally have anything to do with hardware. The first computers were people, who were told what to do ("programmed") without necessarily knowing what they were working on in a big-picture sense.
There is subtext to my argument, namely that you're the one standing in front of the bus, and trying to pull the rest of us in front of the bus, while shouting at the people standing safely out of the road. I'll continue to reject the replacement of humanity. (That doesn't mean remaining ignorant of AI as a technology. It means rejecting the idea that we should be thrilled to be replaced by AI.)
I'm game. Say $1000, donated to a charity of the winner's choice? How do you want to set the bet up, and how do you think it should be decided?
To be precise: I will bet that high-level programming languages won't be any less popular as a whole, but the vast majority of code will be written by AI rather than humans, working from specs written in natural language or something very close to it.
What we call "source code" today will be thought of as "object code" by 2030. Something that occasionally needs to be inspected by humans, but rarely authored directly. Anyone not writing code this way had better be doing it as a hobby, because almost no one will pay for it.
> You and the other poster just need to find some agreeable benchmark so you can decide who won.
That is the hard part. I'm not sure the usage numbers we'd need to decide the outcome are public now, and I can't predict ~4yr out whether any currently available metric will continue to be available. Stack Overflow's popular language thing has been going for a while, that will probably still exist (if SO does) but do we have any reliable metrics to tell us what fraction of code is AI generated?
I think the outcome will be very obvious when the the time comes to settle the bet, but I agree that it's not easy to write those terms today.
But speaking of Stack Overflow, that's a good point to examine more closely. Simply looking at Stack Overflow's usage trend [1] should have been a strong clue that a seismic shift was under way. A couple of things could be responsible for it, though:
1) Stack Overflow's movers and shakers have finally assholed themselves into irrelevance. That's possible, and it could potentially explain the secular decline that began around 2015. But it doesn't explain the rate of descent since 2023, given that the core rules haven't changed for years. It also doesn't explain the meteoric rise between 2008-2014. What they were doing clearly worked, right up until it didn't.
2) AI is now answering questions that would previously have been posted to SO. That's the conventional argument. Hard to dispute it. And it leads to...
3) Stack Overflow has not failed its mission, but fulfilled it: most of the code that will ever need to be written already has been. That's an argument I've never seen anyone else propose, likely because it's a really stupid argument that's been made many times before. I think it's true this time, though, at least until genuinely-new hardware paradigms come along. I think it's a big reason why AI will be doing our jobs for us going forward. Programming is a robot's job now.
3a) As a corollary not related to the SO question, I think the math community is starting to wake up to a similar realization: we have all the math we need. Or, rather, we have all the math we can comprehend. The low-hanging fruit is all gone. Mochizuki's work, which requires a large part of multiple peoples' careers to prove or refute, is an example of that phenomenon. Leading mathematicians are coming to recognize that their best shot at contributing to progress in math is to work on AI.
The groundwork has been laid, and now we need to find better ways to reuse and recycle what we have. That's how AI will help us reach the next level. It's just crazy to think that our industry will be recognizable in 3-5 more years.
Other person probably doesn’t like the idea that LLMs will replace hard earned skills. On the flip side, I bet you’ve seen your skills atrophy at an alarming rate and are trying to justify it.
Both sides come from fear. Just relax and take things as they come. Whatever happens happens.
Maybe. I'll have to think about that one. It doesn't feel like fear to me, but that could be some kind of coping mechanism. From where I sit, I don't believe I fear this AI stuff because I don't really see what all the fuss is about. I don't think I'll be replaced by Claude anytime soon, because fundamentally language models cannot do the things necessary to compete with me. They can generate large amounts of relatively mediocre code quickly, but that's not really what anyone expects of me in the workplace.
Instead, what I do is I think deeply and understand things. And I refine my understanding of those things. And eventually, I have some insight that proves extremely valuable to my employer. Or sometimes not! But on balance it tends to work out swimmingly in their favor. This may sometimes involve writing lots of code, sometimes it involves writing very tiny amounts of code. Sometimes it involves simply deleting code. But the code part of that job is really minimal. It's all the other things--developing understanding, having insights, thinking really hard, making connections, communicating--that are valuable. Banging out code was never a big deal. I'm good at writing clear, correct code and I believe I can do it better than an LLM, if not faster. But that never mattered very much, what actually matters is learning and adapting. I'll be scared when someone makes an "AI" that can do that competitively, but I'm not worried this will happen anytime soon.
So the premises of this "LLM crisis" seem deluded to me. The people saying "everyone will be using an LLM all day every day for their job" seem to have no idea what jobs are like or what LLMs are (in)capable of. The people talking about AI paperclip apocalypses seem like they're having a really bad drug trip. The stock market bros and VCs throwing money as hard as they can after whimsical sci-fi fantasies seem like they've gone completely batshit insane. Meanwhile managers are forcing workers to use LLMs for everything, for no clear reason, and push them into products where it does nothing good. So therefore every little spineless corporate toady is clambering on top of the other little spineless corporate toadies to show big mr manager what a good AI boy they are. It seems like y'all have lost your entire minds because the computer does words now.
It's not fear. It's disgust. I'm disgusted by all of this.
because fundamentally language models cannot do the things necessary to compete with me.
One imagines Lee Sedol telling himself the same thing. True one day and false the next.
It's all the other things--developing understanding, having insights, thinking really hard, making connections, communicating--that are valuable
Spend some time working with frontier models like Fable and Astra. It's clear you haven't. Or if you have, you haven't paid attention to anything but acceptance of the final work product.
"Thinking really hard," LOL. You won't beat an LLM at that. No one ever will again. Insights are still our domain as humans -- if only because the motivations behind them are still entirely ours -- but now we can put those insights into practice at a rate never possible before. And your reaction is disgust?
Meanwhile managers are forcing workers to use LLMs for everything, for no clear reason
I'm with you there. Don't worry, those managers will be the next to go.
Why is it always "you clearly haven't used the latest model, let me tell you this time it'll blow your socks off!"
How many times have we heard this? If it wasn't true all the other times why must I believe it now?
Here's a challenge: show something impressive. Show me how using your LLM will actually help me do something better. How come if this stuff is so great, it's just not all that obvious? I'm looking around and over the past year or 18mo I'm just not seeing a whole lot of change in software. Maybe increased bugs shipped?
How many times have we heard this? If it wasn't true all the other times why must I believe it now?
It was true the first time somebody said, "Hey, check out this ChatGPT thing." It blew my socks off. I still haven't found them. I guess they're probably behind the dryer or something.
I'm looking around and over the past year or 18mo I'm just not seeing a whole lot of change in software. Maybe increased bugs shipped?
I think you're just demanding too much too soon. Peoples' workflows are still adjusting. As you said yourself, correctly, management is being stupid about this whole thing.
The improvements won't all be visible at once. I will ship my next hardware product sooner than I would have, because Fable routed a board for me. Specifically, it wrote a Python program to solve a nasty routing problem that I just didn't feel like working on.
This morning, I was pissed because the volume shadow copy program I use for backups, Casper, screwed up a 30-hour job because it had scheduled a task behind my back, without my knowledge, that tried to perform the same backup to the same drive at the same time. Fable figured out what happened; all I knew was that the boot sector on the target drive was hosed. I will avoid that problem in the future by telling Fable or Astra to find me a simple command-line shadow copy utility that doesn't suck, and if no such utility exists, write it from scratch. That will not be a problem for Fable or Astra, but I wouldn't have dreamed of relying on an LLM to do that last year.
Will this win be visible to you, as a consumer? No, because LOL at anybody trying to sell something like that from here on out.
The software that I develop to support the hardware? I rarely work on it anymore, as of a few weeks ago. When I want a new feature added, I ask Claude (or, again, Astra, which is now better than Fable in some respects.) Claude could do a lot of that work last year, but it needed extensive babysitting. Now it has taste. It chooses the controls, lays out the dialog box and writes the help text. You won't notice the details as a consumer, you'll just see more rapid incremental improvements coming out for my software and ultimately the hardware as well.
Speaking of my very-obscure hardware, last week I ran into a very obscure firmware bug in some code I wrote. Or, rather, my customer did. Different customers are demanding both new features and bug fixes, and I only have the bandwidth for one of those. So: "Claude, see if you can figure out why the board stopped responding to input X when input Y went away. Here are the component data sheets." Took it about an hour but it would have taken me longer.
I would like to say I used the time it saved me to work in parallel on new features, but in reality I spent it here instead, arguing with Luddites. They say "you are your calendar," so I guess I enjoy that even more than building new stuff. Funny how much the clankers are teaching me about myself!
LLMs do not produce repeatable results, by their nature. Two people can give the exact same prompt to the exact same LLM and get different results. It's not a straightforward 1 + 1 always equals 2 process. This is like telling someone else to code something for you. You relinquish control of all the details.
Calling it gatekeeping is just laughable. That's like saying it's gatekeeping to say that the painter painted their painting, and that the person who commissioned the painting did not paint it. It's wholely absurd.
Anybody can pick up a book and learn to actually code themselves. Or you can use an LLM to try to make things without bothering with that. But even if the LLM worked perfectly, pretending these are the same thing is silly.
The history of the word computer is obviously irrelevant. Words change, it turns out.
It isn’t really by their nature that they don’t give repeatable results, right? They’re just a bunch of math, but they perform better with randomness injected so we choose do to so.
(I’ve heard about some GPU compute nuance meaning that even without randomness injected they still wouldn’t quite be deterministic, but that’s also not core to their nature)
You are just talking about the output though. If you only think at a "higher level" you aren't doing the actual thinking. Its the same with code. The output may be good enough, but over time you lose touch with the details to the extent that you can no longer serve a useful steering function for the organization. Before coding agents I'd seen this with many humans when they get promoted passed the point where they work with code directly and can't figure out how to add value there.
Expands into a document for _who_ to read? another LLM to re-compress?
It's baffling you people are in control of such a strong product when you are obsessed with this intellectual pornography; wow - look at how smart it made my thoughts look (n.b. look, not read). Don't look too close. And certainly don't ask me what it means.
Many programmers don't write long text; their way of getting a deep understanding of a problem domain is to build something, is to write code - in a process very similar to writing a long piece of text - it has the same reflection and externalization of thought.
The widespread introduction of LLM code generation is very destructive to that.
Perhaps LLMs can be brought to support human cognition in the same way writing can; but that has yet to be designed and it does not seem to be the way things are heading.
LLM prompts definitely don’t feel like “writing” to me in the way that writing a blog post (or even an HN comment) does or writing code used to. There is nothing to work out, you don’t really need to think. You’re _typing_ sure, but I don’t think it counts as writing maybe because the text that you write is thrown away.
I'm way more articulated now than I've ever been, because in the past I didn't have to -- I never write a blog post -- but I've learned that well thought-out writing, with clear description, will produce better code.
The bottom line is, prompting is definitely writing.
Idk man I get a ton out of gaming and other media. If I say “I’m a cinephile” no one bats an eye, it’s seen as elevated and intellectually stimulating. Your examples reflect more on the gate keeping we do with what’s considered “worthy of our time” and “art” than the value of LLM’s.
If you get an AI to review the code especially for security, it does a very good job st finding issues. Better than any human reviewers I have worked with, and getting better. As someone who works in security , I feel much less worried about security bugs on code reviewed by a AI for security issues, be it written by AI or human.
Compilers like GCC are deterministic and the source code already fully defines the behavior. LLMs are non-deterministic and will accept ambiguity, filling in details where you haven’t. These sorts of comparisons aren’t really fair.
In the case of writing, it’s like hiring someone to write a book for you vs. hiring someone to translate a book you wrote into another language. In the first case, you didn’t really define the message for readers, whereas in the second case you did, and the translator is converting that same message for another audience to consume.
Sure, but I don't know what GCC's behavior is, and I don't vet behavior differences between compiler upgrades. As long as the output works, why does it matter that the black box is deterministic?
It doesn’t matter how exactly GCC works, as long as the behavior is deterministic and consistent (GCC is likely maintaining backwards compatibility between versions, so the behavior of your code likely hasn’t changed). In that case, you can reason about the behavior you need and write your code appropriately.
In the case of LLMs, the behavior is non-deterministic and inconsistent. If I don’t explain how handle an edge case or give a performance constraint, the LLM will still produce code and may do so in different ways, handling edge cases differently and with different performance characteristics. I can’t reason about how the LLM will fill in those gaps, it’s “random.”
Maybe you don’t care about how the LLM handles those edge cases or handles performance, but that’s different than a deterministic abstraction whose implementation details you don’t care about, but whose logic and performance is deterministic and consistent
Sure, I manually test the output of the LLM. Manual testing is actually the main role for humans doing software engineering these days.
I wouldn't use it for flight control software yet, at least not without careful review, but most software isn't exactly critical. At the same time, I wouldn't trust flight control software that was only reviewed by humans, since AI is so much better at debugging.
We'll probably need humans in the loop for safety critical software for at least a year or two, before AI fully outpaces humans at generating correct code.
How so? As long as it works to spec, I haven't had anyone care. They literally hire people so they don't need to care about the details. Put money in, get working software out.
And, AI is rapidly getting better than people at both code review and authorship, so a human deeply involved is turning into nothing but a slowdown. The main purpose people have is testing that the specs were, in fact, implemented properly.
I guarantee your specs/testing are either inadequate and/or you're not leveraging lots of existing (and probably free open source) code that was already written by humans and meets the spec better without ever needing an LLM.
The vast majority of properly written software was already plumbing well over a decade ago. The software engineering is making high level decisions based on experience with respect to the existing tools and the needs of the business. If you're not already using LLMs that way, you would have been a similarly bad manager of human devs writing similar inadequate slop. Less code has always been better code.
The line in the sand for these arguments really ought to be whether you think LLMs are better than humans who actually know what they're doing.
If you think LLMs are better, or could get better while continuing to use statistical methods, you automatically lose the argument (delusional/ignorant) and any hope of regaining credibility. That's not dogma. That's the science.
No, because GCC doesn't randomly fuck up the assembly generation (much less on a fairly frequent basis the way LLMs do). If it did, you bet I'd be reviewing the assembly line by line, or decline to use such a poorly performing tool (as I have with LLMs).
For instructions you really care about, yes of course you review the assembly output! Usually when you're doing SIMD or want to check atomics are doing what you expect.
You can do that with LLMs for the parts you really care about too. The LLMs aren't regenerating the codebase from scratch every time, so the results stick around.
> wonder if long form writing will go the way of code.
I worry about AI Loopidity here though. Think about the similar analogy of email. If my set of ideas is condensable to bullet points, but I use AI to expand the content, then I add no information density and a lot of noise. Other folks then use AI to summarize the content to a list of bullet points, ideally the same but not certainly the same, and thus communication has been only partially successful.
> it's just Claude working on the code, so the details matter less
If you're not billed for usage, anyway.
Otherwise, for the other 99% of folks, that attitude is of course a pit trap that captures code bases and makes them maintainable only through the providers -- presumably one or few -- with a rich enough model to keep up with the growing mess. Preserving a code base that's legible, organized, and fundamentally maintainable by both humans and trailing commodity models is of imminent concern for anybody who doesn't want their margin strangled by your employer once it's too late to have other options.
As frontier capabilities advance, the details don't matter less; they matter more.
Writing is already amenable to many different levels of abstraction, though. If an LLM can expand your outline into writing, then you aren’t writing at the correct level of abstraction in my opinion; you should instead be explaining how you arrived at your chosen outline. You don’t need to explain the details because any party can generate those with an LLM; same as how many PRs today can be auto-generated and no one needs to read implementations; that is no longer the correct level abstraction to work at. This should actually free us to do work at a higher level of abstraction —- more consideration of strategy, objectives, etc and less worry about implementation details.
This only applies if LLMs aren't making mistakes 20% of the time and that's the problem. When you're only saving time on the easy part, it doesn't matter if you're working twice as fast because review of the tricky parts is still going to take 80% of what it would have taken to do the whole thing. Total effort ends up being more rather than less if you want the same quality.
I mean these are cold inhumane companies and their employees reflect it. SF is truly where human ingenuity goes to die, truly a blight on the industry as a whole and holding us back tremendously.
[non-AI org] I despise this and call it out every time I see it. Some dude hooked up an LLM autoresponder to his email, sent some nauseating AI slop to a huge distribution list.
I couldn’t help myself, replied and asked him for a recipe for delicious apple cobbler and hiking trail recommendations in Glasgow, which “he” immediately provided. Highlight of my career.
I think my core argument is this: I have access to every bit of information your AI does, so if I want an AI answer I’ll get one myself. If that isn’t true, why are you hoarding information? Push it somewhere we can all see it. So the only reason I would send you a message is to access _your_ brain. I have no interest in talking to an AI through a worse interface.
You could try this [0] I’ve started doing this and it’s helped a lot.
1. I understand fully the code and everything it does
2. You can pick up on mistakes super early and it can adjust the plan is it goes.
3. Faster than writing it by hand but slower than letting the LLM do it.
One could imagine a universe where the agent fills in citations and supportive points and so on, or makes a more conclusive argument but it seems you’d get better results leaving that to read time if it’s a one-shot. Steering prompts etc. with tool use to bring in other sources etc of course change this entirely. And regardless, I doubt we will read content like that directly ever again. Agents will act as per-person highly specialized adapter layers for information transmission.
The entire point is what runtime you’re running your code on. A computer with any modern stack requires a lot of text for you to communicate “spin a square around on its center” to it. A human requires only that short string because they have a faster natural language interpreter.
Text meant for a human can communicate “spin a square around its center” much better than any code that mimics it. In some sense, all programming is boilerplate expansion because computers have (until now) been unable to be programmed with anything approaching natural language.
> In some sense, all programming is boilerplate expansion because computers have (until now) been unable to be programmed with anything approaching natural language.
Maybe sometimes, but not always. When you need to actually render the thing you have all kinds of micro decisions, like where to put the square, what color, how fast it spins, etc.
You might not care about the details, but maybe you do. If it spins at 10000 rpm, will you care then?
Natural language, and human communication in general, is ambiguous, and coding is in great part about disambiguation.
Sure, you can use English to disambiguate as much as needed, but wouldn’t you then end up with some yaml-like spec that wasn’t much easier to create in the first place?
>(I work at Anthropic) I agree. I use an LLM to write my code, but I do all of my writing by hand, since it helps me think.
You get pushback for this? I saw an anthropic job post recently, and they wanted you specifically to have claude muck with your resume before applying.
I suspect some amount of long form writing will go the way of code - long form writing for the purpose of consumption by other AIs. Writing as a means of exchanging qualitative information, with no regard for how the reader will feel about it (beyond understanding what the words mean). Not everything can be distilled into data, but this doesn’t mean it is beyond the reach of LLMs.
On the other hand, long form writing for human consumption seems like it may evade LLMs for much, much longer.
What makes you think it will take a long time? AI seems capable of imitating any writing style if prompted to do so already, and I think it will get better on this quickly since the AI writing style is a main focus of AI labs right now. I can see no reason at all to believe this is a matter of years still, more like a few months.
The style you refer to is the "container" of the writing. The medium. Like the specific encoding of the message. What @arctic-true was talking about was the "content" of the writing, which is bounded from above[1] by the information content of the prompt.
So, I'm not sure if it's a question of time at all: if a LLM text contains some piece of information beyond the information that went into the prompt, where does this "extra" information come from? [Note, I'm not thinking about facts which could trivially come from the training corpus, I'm thinking specifically as information in the sense of intended message from sender (author) to receiver (reader)]
You can have a great “writing style” and still put together really crappy long-form work. The problem is that AI writing, particularly creative writing, is too repetitive, too predictable, too trope-laden.
All of the things you say are very true in the near term for short form writing - a page or two of Claudeslop will probably be much easier to swallow in a year or two than it is now. But I don’t see a path to fully AI-generated novels or long-form investigative journalism becoming mainstream in the next couple of years.
> I wonder if long form writing will go the way of code. You and the AI agree on an outline or other high level representation, then the LLM expands it into a document.
You can already do this. And you can build pipelines where AI performs fact checks on what it writes, with citations a human can reference as well.
> I do all of my writing by hand, since it helps me think.
Later
> I wonder if long form writing will go the way of code. You and the AI agree on an outline or other high level representation, then the LLM expands it into a document.
So in the future, it won't be necessary for you to think?
Kinda. Walking the dog with me this evening, Christa saw the license plate 8531 PRI and asked me if 8531 really was prime. The 2, 3, 5 checks are automatic, and 8531-8400 = 131, which obviously isn't divisible by 7, but I would've had to check the rest of the two-digit prime factors except 97 - 8531 is greater than 90 squared, less than 97 squared, though, I reckon. So I said I don't know. But Google would know, you know? If your LLM buddy is hanging out active on your phone all the time, it can - maybe not yet, but foreseeably - answer every question, no thought required, and carry out any expressed desire.
"You and the AI agree on an outline or other high level representation, then the LLM expands it into a document."
I am a subject matter expert in certain fields of real estate in Canada. This is how I draft my teaching materials, articles and educational content. I use it as a human amplifier of my brain as it increases my output which other people will pay money for. People who complain that LLM writing is slop have not encountered good AI-human hybrid outputs. Like visual effects in movies, the best examples are imperceptible and do not get in the way of storytelling.
Note: this is for Cowork, not sure if that makes a difference, I don't use the desktop app for coding.
Claude asked me a question at 12:05pm my time, came back at 12:40 and the question prompt disappeared and it spat back a message. Previously when I was writing a Google Doc, it would prompt me for questions, I'd come back and it would have timed out like this and just made a new version of the doc.
> The auto mode classifier uses a small number of extra tokens per tool call, and we're no longer charging Claude Code users on Pro, Max, and Team plans for that classifier overhead, effective today
This just sounds like they bump their unspecified limits by N% to cover this usage. Which of course means nothing because the next time they re-evaluate their limits they will just ignore this bump.
For those using Claude Code, I recommend Learning mode to instruct Claude to walk you through implementing the solution yourself rather than doing it for you. It’s very helpful when diving into a new domain, and helps build lower level intuition.
To enable it, run /config > output styles > Learning
Learning mode has been a huge help for me, it quickly became my favorite way to learn. I ended up created a “Coaching Mode” output style that took some of the learning concepts like stubbing todos for the users and added other intructions that better fit how I learn
A few of us from the Claude Code team will be hanging around if anyone has questions! Very excited for this launch -- dynamic workflows have been a game changer for engineering here at Anthropic. Can't wait to hear what you think.
Hi Boris. Love the velocity of features. Are you planning on adding a secrets manager? Enterprise workflows almost always require an encrypted parameter or calling a secret.
Personally, I am happy paying 1password for my personal secret management. Their security credibility and bona fides are well-established. I'd strongly consider them for a business contract too.
Thanks to you and the anthropic team for developing such exciting tools! The blog post seems to position workflows for “breadth”: generating fixes / refactors against large code bases. What about for “depth”: developing specific new features and functionality end-to-end? I’ve struggled to make this work reliably using the current experimental agent teams. Does this replace or augment that functionality?
Yes, it also helps! That's a place where raw model capability is the most helpful, but we do find that some dynamic workflow configurations can be helpful too.
Cool! If you can point to any examples of those types of workflow configurations I’d be super interested. For example, to have a team of agents review a PR and iterate on it until all requirements are met including UX, security and product functionality goals. If they could “converge” to a solution like workflows seems to be designed for that would be amazing.
Using the keyword “Workflow”like “Ultrathink” is problematic?
Ultrathink is uncommon enough that it is unlikely to be used in code or prompt outside its intended purpose.
Workflow is generic keyword and used in so many contexts both inside the codebase and orchestration tooling like say temporal.io or others that name their constructs “workflows”.
This is really dissapointing release for such a promising technique. Long walks with fanned vectors can actually be token optimizing vs token burning when combined with self grading each agent along the walk and compared to manual long coding walks to solve first pass problems. But instead this frames it (assumptively) as a tokenmaxxing strategy. There are also many other strartegies that can prove effeciency and wider solution consideration with consensus, but none of this is explained why its an improvement or better than other technqiues.
Its like you guys aren't even aware of the primary problem you are all facing: your token burns aren't paying off anyore against standard coding -- and looking net negative. I have to ask, are you this unaware of your core problem set here?
There are no any examples, proofs, or scenarios that show why there is improvement either in complexity or reliability of the solution or effeciency to the path of the solution. I'm baffled.
How granular is the control over the internal process?
In my experiments I've had some success modeling the work to be done as a DAG of typed artifacts with a combination of code + LLM doing decomposition, transforms, synthesis, and fitness checking to generate the output. It took me a lot of tries to arrive at that formula and it would be cool to have something more general. I also run part of it against local compute because it would be far beyond my budget to do it all on Opus, so something for that would be nice too.
Personally I would just like to be able to read more than 2 lines of an AskUserQuestion on the iOS app. Ever since the feature launched it's truncated the question, so you cannot actually read it.
Can you please fix the issue where like 99.99999% of the time Claude tries to launch a subagent on its own accord it gets "Prompt is too long" and tries several more times, then gives up and does it without the subagent. Big waste of time and tokens and not getting almost any subagent advantages. Not kidding that this happens about 100 times a day.
I tried creating a workflow in Claude 1.9255.2 (1dc8f7) 2026-05-27T01:57:20.000Z
and got
API Error: 400 messages.3.content.11: `thinking` or `redacted_thinking` blocks in the latest assistant message cannot be modified. These blocks must remain as they were in the original response.
Tried again in
Claude 1.9659.1 (193bcb) 2026-05-28T16:22:15.000Z also but may need a new chat
VSCode has an official client? Given IDE usage is being restricted from Claude Code via the CC SDK tokens going to the Claude API rather than your CC Subscription, i'm unclear which IDEs can actually use claude code now.
Eg is Zed capable of using a Claude Code Subscription?
Oh, yea here's all the proof you need. Even Zed themselves admit you won't be able to use Claude Code via ACP via Subscription: https://zed.dev/blog/terminal-threads
So yea, bcherny didn't reply to me but as far as i can tell - No, Zed nor VSCode will have Claude Code natively in it. The best we can do is embed a Terminal into the editor and run CC in that.
With that said, because bcherny advertised VSCode, i'm going to guess VSCode is going to get special treatment. Really annoying.
to be clear, i'm referring to the recent fact where it appears that they're disabling all Claude Code (Subscription) usage from the SDK. Which ACP would be included on.
As usual though it's not super clear exactly what is allowed or not.
Is there an example of how y'all use Dynamic Workflows internally that you could share with the rest of us here so that we can mimic something similar?
Hey, yep. A few things I personally used dynamic workflows for over the last few weeks:
1. Autonomously landed 20+ optimizations to reduce Claude Code's token usage by ~15%
2. Ported tree-sitter, color-diff, yoga-layout, and a number of other WASM and Rust native modules to TypeScript, improving CPU and memory use by 2-10x in the process
3. Made our CI faster, and repeatedly found and fixed flaky tests (with /loop)
4. Migrated from regex-based bash static analysis to tree-sitter, reducing false positive permission prompts by 45%
5. Reduced Claude Agent SDK startup time by 61%, by repeatedly profiling and optimizing the startup path, putting up a number of PRs in the process
> Ported tree-sitter, color-diff, yoga-layout, and a number of other WASM and Rust native modules to TypeScript, improving CPU and memory use by 2-10x in the process
Curious to learn more on this (unless there’s a write-up in the works). I’m naive on this matter but:
1. is this because it’s higher cost when passing objects back and forth across the JS/native boundary?
2. Does this have anything more specific to do with use of Bun?
3. is the stance for claude code then to keep all the deps in raw TypeScript?
4. How do you folks keep these ported deps up-to-date?
Very cool. What % of the CC team's engineering would you say goes into QoL (as opposed to new feature development)? Obviously some live in a grey area, while others are more clear like making CI faster.
Is there not a reason to instead port claude code to rust? Do you have internal benchmarks that show that claude code is better at typescript than rust?
just wanted to say thank you, just did a 2 days "ai computer use" workshop - think a virtual desktop on hetzner with claude code in yolo mode, a github account, vercel and logged in into a google account and claude had all the credentials and then let a mix of marketing / product manager / sales / customer support let loose. 2k token budget ... and just let them see do magic again and again.
Hi Boris, what is the advantage of using /code-review vs just asking Opus to “code review”?
As a casual user working on hobby projects, I struggle to keep up with the pace of changes and knowing what to use when. My default now is to use Opus for all coding (sonnet is fine but seems dumber) and to prompt it for everything I need. I’ve had great success with this but clearly I’m missing power user functions with the slash commands and such.
The advantage is that /code-review supplies a structured idea of how to review and what that process should look like and then launches independent subagents to approach the issue from multiple angles.
It's analogous to how in the early days you could see benefits by telling the models to "think step by step". /code-review is something like "review angle by angle". "Consider removed behavior" and also "Look at language gotchas" and also "Look at test changes"...etc. Yes these are all somewhat implicitly already part of what "code review" means, but the models perform best with explicitness.
If you want my 2c as a power user: just don't think about it and use /code-review xhigh --fix. This will cover like 98% of what you want out of code review. It's a good skill.
I don't even bother looking at the code until I've run a code review pass on it. Why waste my time with trivial bug fixes? I find the best way to spend time right now is like:
- Defining the issue/ticket, what "success" looks like (if I have a good idea of this), high level approach guidance 50%
- Dispatch agent to work on it 5%
- Occasionally return and nudge agent + send /simplify or /code-review 5%
- Look at the code/session summary, divergences from the plan, ask followup questions 40%
Occasionally yes there is some solution the AI chose that is suboptimal and I would prefer fixed in a different way. Mostly though it's straightforward.
Are you thinking of the /effort level in Claude Code? I would just go with xhigh as a reasonable default. Most important thing in prompting is specifying what "done" and "success" looks like to you. Ask Claude to help you come up with a well formed request and spend most of your time on that, then paste that into a brand new session.
No more like is there a specific slash tool to be using when coding or planning. I guess that’s just Claude code in general but since there’s a specific review tool I was curious about specific coding tools
And why would someone use the various levels? Is a low code review even worth running? And how do I know what level to use in the first place?
This stuff all seems so nebulous to me and I’ve yet to see anything that says use x in y situation. So I default to higher effort levels than I likely need.
Hey Boris, thanks for the great product and for listening!
I find the mix between slash commands that are programmatic harness configuration and control commands (/config, /model, /feedback, /fork, /usage, etc.) and ones that are little more than prompt template insertion (/code-review, /<skill>, etc.) to be a little confusing and unnecessary. A slash command should be one thing, and one thing only: a command for the harness, not the agent.
When I invoke a slash command like /code-review, I should be invoking some additional harness functionality, something above and beyond the agent's sphere of influence - not just pasting some hidden text into the next turn. Otherwise, why wouldn't I just say "Claude, review this code"?
Yet most of these "added value" commands bloating the slash command list, are just shortcuts for copy and paste. I don't want to go to have to learn the syntax of a special /code-review command (which options are positional args, which are --flags, etc.), and I'm much less likely to use or even be aware of a command like this, when I can just ask "Do a balanced code review and fix the issues", or use the GUI to set the effort level to xhigh before asking "Review my code." That way I can also be more specific about exactly what I need, rather than relying on what's in the canned prompt - a prompt which I'll probably never read and vet myself anyway. The value added by the slash command needs to be really high compared to just typing a prompt, for it to justify the friction of discovery and learning the syntax.
So I suppose I'm advocating for a different system. Keep slash commands for meta-level harness control and configuration, and add a new mechanism for canned prompt insertion, one which is tailor made for that purpose rather than overloading the slash command system. Let the user see what's in the canned prompts, and even make adjustments or edits as needed before sending them, one-time or persisted. Provide a GUI in the app with the user's favorite prompts, where the user can add, delete, and edit them, making it easy to invoke and insert them as needed. Or let the agent automatically discover and use them as needed, rather than requiring the user to remember and recall their magic shortcuts and their arguments. That's just one idea.
Skills, plugins, commands, and so on, need to be consolidated not just for code review of course but across the full architecture of how prompt templates are managed.
What clicked for me recently was treating skills as composable. Having meta-skills that call smaller skills in order. The "skill vs command vs subagent" confusion partly dissolves once you let skills call other skills. The meta-skill holds the workflow state, the smaller ones each do one job well.
> # do an expensive and extremely thorough review (reliably catches >99% of bugs, costs $3-20 per review depending on complexity):
/code-review ultra
main suggestion would be to sound a lot less optimistic about that it finds 99% of bugs or that its at all thorough, and instead list that it is time capped, and will only find bugs that you explicitly tell it to look for.
i used my three runs of ultrareview.
the first run with no other prompting found a couple typos in markdown only
the second one i prompted it with several themes of known open bugs in the code, and it found 6 items
and then the third one i ran after doing an actual long audit through gemini to make a much more detailed prompt about issues in the code
and for that one, instead of doing an exhaustive run, it just never started, so no idea if it worked
but the experience had no relation at all with the reliability or thoroughness claims
Hey Boris, some feedback. I like the new /code-review skill but was disappointed you guys removed /simplify because I quite liked the focus on finding code reuse/efficiency opportunities.
I see now in 2.1.152 you added those focus areas back to /code-review, but still bundled with the correctness finding. It would be great to have more fine grained control over the /code-review angles beyond just effort level. Or maybe you would recommend that I just specify that as freeform input after effort level?
Yep, you can add free-form input. Will update /simplify to only check for code quality and not bugs (the way it used to work), that's a good suggestion.
We did both -- we did a number of UI iterations (eg. improving thinking loading states, making it more clear how many tokens are being downloaded, etc.). But we also reduced the default effort level after evals and dogfooding. The latter was not the right decision, so we rolled it back after finding that UX iterations were insufficient (people didn't understand to use /effort to increase intelligence, and often stuck with the default -- we should have anticipated this).
Having a "Recovery Mode"/"Safe Boot" flag to disable our configurations (or progressively enable) to see how claude code responds would be nice. Sometimes I get worried some old flag I set is breaking things. Maybe the flag already exists? I tried Claude doctor but it wasn't quite the solution.
For instance:
Is Haiku supposed to hit a warm system-prompt cache in a default Claude code setup?
I had `DISABLE_TELEMETRY=1` in my env and found the haiku requests would not hit a warm-cached system prompt. E.g. on first request just now w/ most recent version (v2.1.118, but happened on others):
w/ telemetry off - input_tokens:10 cache_read:0 cache_write:28897 out:249
w/ telemetry on - input_tokens:10 cache_read:24344 cache_write:7237 out:243
I used to think having so many users was leading to people hitting a lot of edge cases, 3 million users is 3 million different problems. Everyone can't be on the happy path. But then I started hitting weird edge cases and started thinking the permutations might not be under control.
> people didn't understand to use /effort to increase intelligence, and often stuck with the default -- we should have anticipated this
UI is UI. It is naive to expect that you build some UI but users will "just magically" find out that they should use it as a terminal in the first place.
It took you a month to revert after multiple complaints. You still blamed users for using the product exactly as you advertised it. And all of your official channels were completely quite for two months, whether it was about new draconian peak hour limits, or about the new defaults, or about exponentially increasing token costs.
People literally started seeing issues immediately as you changed the defaults: https://x.com/levelsio/status/2029307862493618290 And despite a huge amount of reports you still kept it for a whole month.
And then you shipped a completely untested feature with prompt cache misses and literally gaslit users and blamed users for using the product as advertised.
Now untold umber of people have been hit by these changes, so as an apology you reset usage limits three hours before they would reset anyway.
Good job.
Edit. By the way, a very telling sentence from the report:
--- start quote ---
We’ll ensure that a larger share of internal staff use the exact public build of Claude Code (as opposed to the version we use to test new features); and we'll make improvements to our Code Review tool that we use internally
--- end quote ---
Translation: no one is using or even testing the product we ship, and we blindly trust Claude Code to review and find bugs for us. Last one isn't even a translation: https://x.com/bcherny/status/2017742750473720121
Off topic, but I'm hoping you'll maybe see this. There's been an issue with the VS code extension that makes it pretty much impossible to use (PreToolUse can't intercept permission requests anymore, using PermissionRequest hooks always open the diff viewer and steals focus):
It reminds me of the transition over the last year from AI-assisted coding to AI doing all the coding. At first the code output wasn't good enough, and humans read and iterated on the code all day, so the details of the source code mattered. Now, the code is largely high quality and it meets a large set of guardrails we've set up over the years (linters, typecheckers, security checks, LLM-assisted code quality checkers), and it's just Claude working on the code, so the details matter less and engineers think a level or two up (machine code < assembly/bytecode < source code < conversation with agent < artifact with high level design).
I wonder if long form writing will go the way of code. You and the AI agree on an outline or other high level representation, then the LLM expands it into a document. But writing and coding are different enough in a number of ways that this is far from inevitable.
reply