We’ve lost the Tech
FULL TRANSCRIPT
There are some engineering marvels out
there that end up living rentree in my
head for just years on end. And I I go
back and I think about how cool they
are, but there's a new one that's living
in my head. Uh not because of how cool
it is, but because of how ridiculous it
is. I am talking about Claude Code and
their Tui. Now, this tweet caught my
attention and has been just eating me
alive and now I have to make a video
about it. Okay, so let me just read it
to you. Most people's mental model of
Claude Code is that it's just a TUI.
That's what I thought it was at least.
But it's actually really closer to a
small game engine. Okay. Okay. Whoa. I
didn't realize rendering. I mean, I
guess if you if you really think about
it, you know, like if you really dig
down into the nuts and bolts, you can
kind of imagine that a screen every
single one of the characters is kind of
like a pixel, right? Which means it's a
game, right? Except for your bounds are
like 30 by 120 pixels. So, you know,
2400 pixels. We're talking about pretty
easy rendering going on here, right?
Like you could make a decision about
every single pixel many, many times,
right? Wo there, tough guy. For each
frame, our pipeline constructs a graph
from React, then lays elements out,
rasterizes them in 2D, diffs them
against the previous screen, and finally
uses the diff to generate an ANIE
string. If you're not familiar with
ANIE, ANIE effectively is the thing that
allows you a either to color text that's
on the terminal or b you can put your
cursor in places. Uh you can also clear
the screen with an escape sequence. Open
bracket 2J would effectively clear the
entire screen inside your terminal.
There's all these little things. That's
how ANI works, right? It's an escape
character plus an open bracket plus some
sort of code. Don't worry about ANIs.
It's really irrelevant in this situation
other than it just requires a bit more
memory to generate and that's it. And so
they have roughly 16 milliseconds frame
budget. And so we roughly have five
milliseconds to go from React to Ansie.
That means React takes 11 seconds to lay
out something on approximately 2400
pixels. We're going to talk about this.
Okay, I'm going to I'm going to first
off, I'm going to tell you some
engineering management takes that I
have. Okay, and I think they're very
very important. More so, I'm going to
give you some, hey, this is how I think
you should engineer things. And then
lastly, I'm going to show you that I
think whatever they're running up
against is a design of their own making
and a downfall of engineering in the
most truest sense. So, first off, as an
engineering manager, if I had someone
come up to me and say, "Hey, I'm going
to make a TUI and we have all these
constraints and it involves like say
frames per second." My very first
question would be like, "Oh, wow. Okay,
so you must have a bunch of stuff
changing on your scene to require uh
stuff to be rendering at that kind of
rate, right? Like what what's changing?
What's going on? Why do we have to have
a frames per second to ever even begin
with? I want to know. I want to
understand more." And if the answer
isn't we're writing a full a full-blown
game and every single key press and
everything needs to pass through a tick
and we need to have this really verbose
a beautiful way to handle everything. I
would go you got to stop. Something has
gone terribly wrong here. What are you
doing? When I hear this that claude
code, which if you're not familiar with
is just interacting with a model that
lives on the internet that takes seconds
to minutes to respond and leaves little
breadcrumbs along the way, requires 60
fps. This to me feels like a failure in
engineering management and also a
failure in engineering. Now granted I
don't work there. I don't know the
constraints they're working against.
Maybe just maybe there are things that I
don't understand that could make this
very very hard and maybe it's supposed
to make sense if one you know if I were
to understand the difficulty. So I'm
willing to concede that I don't
understand everything. If I were a
manager and I heard this I would say no
way. Back to the drawing board. Now as
far as engineering goes if I was an
engineer attempting to solve this
problem. First off, if I had to generate
text into a fixed box along with the
scroll history background, which is
apparently what they want, you you
should be able to scroll up and see all
your previous stuff. And you want to be
able to have some dynamic elements on
here along with some other stuff.
Obviously, I would have to set up a
situation in which I have some layers,
right? I have my dynamic side of things
right here, and then I have my actual
scroll back going on right here. And
then I have to construct these things to
be able to actually draw what's
happening on screen. Correct? But here's
the deal. I would never set up an FPS
for this. It makes no sense. And here's
why. You only have a few things that
cause a render. One, you have input. So,
when I start typing, I need to see my
characters going on to the prompt,
right? Okay. So, there we go. We have
our characters. For whatever reason,
Claude Code also wants a throbb, right?
That's what they call it. A big old
throber. Something that's like letting
you know like, "Hey, I'm rendering."
Like right here. See, if I say, "Tell me
how to talk to a woman." You can see the
throber right here. It's throberating.
Hey, Blood Code teaching you how to RZ,
just in case you're wondering. Okay,
treat her as an individual person, not a
category. Boom. Nothing says autism like
that answer. [laughter]
Hey there, fellow woman. I hear you like
flower. So, you have the throbb, which
needs a you know that that thing was
rendering like what three, four times a
second. And then lastly, you have output
coming in from Claude. That's really, as
far as I can tell, just looking at the
UI, things that require a change in the
scene to render. So, I'm not even
dogging on React, despite my feelings
about React. I'm just saying this is
what you see. Now, none of these happen
at effectively 60 frames per second.
People aren't typing 60 characters a
second. It's not throbbing plus typing
plus receiving clawed code back at 60
frames per second. So that means you
could make the little diff adjustments
to your screen as each one of these
things come in. There's no running game
loop. It should be completely empty if
nothing is happening. If you're waiting
for Claude, there's no throbbing going
on, no characters being typed. There is
no work to be done. There's no diffing.
There's no reacting. There's no there's
no rasterizing. There's no generating of
antsy. You can say no change, no work.
It's one of these really beautiful
things about writing 2ies is that you
can tell when something has changed.
Therefore, you know when work needs to
be calculated. And so in my head, this
is like what should happen. But
obviously, again, I still may not
understand things and I don't want to
dog on somebody for some engineering
stuff. Uh I I don't understand the
trade-offs they originally used. I don't
understand the React thing. But again,
I'm sure you can explain to me why React
was a good decision. To me, this just
obviously looks like, hey, I want to
write TypeScript. What do you write with
TypeScript? You write React. Okay,
that's what the LLM told me. Hey, I'm an
engineer. I use an LLM. Bada bing, bada
boom. We use React. Or this comes from
some sort of legacy decision that
somebody who thinks that they really
love Tuies, but they also only just want
to write TypeScript was like, yo,
there's this library called Inc. that
uses React, bro. Which is I think what
ended up happening. It doesn't really
matter how you got here. that decision
was made, but the 60 fps is really still
just living rentree because then I
thought, okay, how fast can I render
stuff to the screen? So, I wrote a
little tiny little test right here where
I can say I want to draw a box of one by
one characters and I want to draw it as
fast as possible. So, I'm drawing this
as fast as possible randomly on my
screen. This number right here is me
drawing a thousand of those boxes. How
many milliseconds did it take? So, I
drew a,000 one by one boxes in
effectively 1,000 milliseconds. Okay,
that's pretty cool. I do it again. Let's
do a 2x2. As you can see, I'm writing a
lot more characters. Effectively, no
time has changed. I can do that at
32x32. You can see the screen's going
nut. I bet you YouTube encoding is just
utterly failing at this point because I
have simulated white like white noise
from first principles. Again, I'm also
using Ghosty. This is a modern terminal
with GPU acceleration. So, some of the
older terminals probably couldn't render
as fast as this. I don't actually know
what the real frame rate is because I
don't know if we're actually rendering
at effectively one frame every 1.3
milliseconds, right? We're rendering
some amount at some rate that's very
very astronomically high to the point
that I can't even see what's really
happening on the screen. Just as far as
rendering goes, you can go really really
fast. There clearly is nothing holding
back from just going uh absolutely much
much faster than 60 frames a second even
in a just in a modern terminal. Now
granted again uh legacy terminals I
can't speak for them. I used to use uh
some terminal from 1984. It took a you
know everything was much much slower
when I tried to play Asky Doom. But then
I got curious. So this right here is me
seeing how fast can I render scroll back
history. Okay. So now if I close this, I
can actually take T-Mox and I'm look
like that's the scroll back history
right there. So this is much closer to
what Claude code does is it has an input
area where I can put in some nice input
going on down here and at the same time
you can imagine I'm getting so much
stuff coming back in. Now granted I
didn't use React. This is not nearly as
complicated. I I also included a throbb
that looks pretty similar and along with
like a little Braille little swirly
thing. This is how many new lines I have
created. This is how much of the time
I'm calculating I'm using the CPU in
JavaScript land approximately for every
every frame I'm using a 100 microsconds
and I'm almost idle the entire time. So
again even with this really ridiculous
example which is just you know rendering
at an absurd rate and doing a ridiculous
amount of stuff. I don't know where the
16 milliseconds is going wrong. It
purely seems like a React problem. And
don't just take my word for it. Will
McGugan, uh, if I'm saying that name
correctly, is kind of a longtime
engineer out here that has done a lot of
stuff and I think he has a really
amazing take on this. Sometimes
developers get hyperfocused on tackling
the immediate technical challenges in
front of them that prevents them from
reflecting on past decisions. By the
way, this is one of my greatest
weaknesses. And even after 20 years of
engineering, this right here, it still
rings true today. So much of engineering
is taking a step back and going, why did
I make this decision? Let's let's
actually understand the problem and not
just simply the solution. It's like you
take a fork in a road and find out you
need to climb a mountain. The faster
route to your destination may be to
backtrack and take a more direct route
without the mountain in the way. Tuies
are much more complex than most people
know. Very true. I've written a couple
tuities in my day. You know, I have some
amount of experience in it, but I've
never written a tuy to say to the level
of complexity of claude code. It is a
very impressive tuy. Trust me on this.
But I see nothing nothing in Claude's
output that needs a scene graph. Their
scene is a list of non-interactive
output. It's literally literally a list
of things. Granted, there's a little bit
of like highlighting, a bit of
throbbing, there's some input at the
bottom. They want to preserve scroll
history. Like I mean there's a couple
things. And apparently you can press
like controlB to like expand some stuff.
So there's some like accordion
interactive stuff, though I've never
gotten that to work. Cloud code does not
need to be a small game engine. No game
engine would construct a scene graph and
diff every frame. That would be too
expensive and wouldn't scale. I'm an ex
games developer. Yeah, typically you
just do immediate mode, right? You just
draw the scene, right? Big. You could
draw the entire terminal every single
time. How do I know? I'M DOING IT RIGHT
NOW WITH THE SCENE STORED as a list
tracking what changes rather than
diffing. The caching and see generation
16 milliseconds for a frame wouldn't be
challenging to hit. I don't even think
again I would argue from the beginning
there is no frame rate you need. You
react to changes coming in cuz they're
not going to be that fast. So, by the
way, just in case you're wondering with
input, if you did 60 characters per
second typing, that's 720 words per
minute. Okay? Ain't nobody typing that
fast. Even if I mash my little fingies
as fast as possible, I can't achieve
such speed. I think the mountain is the
React model, a holdover from their ink
days. It allowed TS developers to use a
comfortable pattern for building UIs.
But React was designed to manage the
complexity of a browser UIs, which are
way more complex than Claude's
requirements for a terminal UI.
Absolutely true. And now Anthropic are
expending a lot of engineering effort to
tunnel through this mountain. On top of
it, this also just goes to show,
remember this phrase that people always
say, use the best tool for the job. It
really just goes to show what people
mean when they say that is, I'm going to
use the most comfortable tool for the
job, which is the anti pattern. By the
way, I'm not even upset at JavaScript. I
think JavaScript's perfectly fine here.
I don't even care about that aspect.
Yeah, sure, it's a little bit memory
hoggy. Uh now with RAM becoming the most
expensive thing in the universe, I can
see why that's negative. But
nonetheless, your problem is not
performance. This is not a performance
problem going on here. If there is a
performance problem, it's a U problem.
Perhaps the renderer is too coupled to
the data model and hard to replace. Now,
I wouldn't be surprised if that were
true. But if I were anthropic, I would
have a small team work in parallel to
build a kind of decoupled model and
renderer that you would make if you
didn't have any legacy issues. I would
hire at least one games developer for
this. Honestly, you could hire a games
developer. Just hire a tools developer
in general, not even a games developer.
Hire somebody that doesn't just build
for the web. Really, just anybody else.
You could probably hire half the web
devs and they could just figure it out.
I really think this team would get to
their destination before the team that
is tunneling through the mountain.
Honestly, this is just so true and I
think it's such an interesting point in
engineering, right? Because Anthropic
has been the leading scaremonger about
like the world's going to end, all the
jobs are going to leave. You look at
this and I see a failure of both
engineering management and engineering.
They've got they've dug themselves into
the weirdest place. And it just goes to
show even if they generated all the code
with LLMs and they're saying this is the
best ever, fundamentally the decisions
they have made aren't good. And so
whether the code was generated by hand
or by LLM, it doesn't matter. The
failure already happened. Some more
highlights from Twitter. We apparently
live in a clown universe where a simple
TUI is driven by React and takes 11
milliseconds to lay out a few boxes in
monospace text. By the way, uh, business
right here, excellent blog, excellent
engineer. Layout 0.9 milliseconds.
Rasterization. Still, I still actually
just I've never read what rasterization
means. I'm sure it's really simple. It's
just in my head. I'm like, that's a word
I never know. 2.1 millconds. Diffing 1.2
millconds. Building the React scene
graph 11 milliseconds. I think this one
really is just like this encompasses how
I feel. This company is having a hard
time making a 2D ANC terminal to run at
60 fps and they demand you to take them
seriously when they talk about
revolutionizing programming. I keep
saying this and I feel like this is just
so important. hard skills are still in
demand. The LLM's aren't going to make
the best decisions. They're going to
make the decisions that you tell them to
make crappily. It's not only up to you
to make the decisions, it's up to you to
double check that the decisions you made
were even implemented properly and with
care. So, if you don't have that
foundation, you just might find yourself
in 60 frames per second react diffing
helland hellscape 2i. Lastly, I know
this tweet was made by Tyreek right here
and a bunch of people kind of been
dogpiling him. Hey, my goal wasn't here
to like call him out or single him out
or try to be mean to him. Hey, I've been
in positions in which I've had to make
decisions or follow up with past
decisions that weren't ideal. That did
cause a whole bunch of difficulty. I
just was lucky enough not to have to
make those decisions and explain myself
on Twitter. And I think a lot of you
listening have found yourself in a very
similar situation. So, be nice, be kind.
And all my critiques, as you can see,
are more towards the leadership of
Anthropic, which is their constant
fear-mongering of engineering, saying
it's all over. Because even within their
own company, they suffer from the cost
of legacy. There's nothing more
permanent than a temporary fix. The name
is the primogen. Hey, is that HTTP? Get
that out of here. That's not how we
order coffee. We order coffee via ssh
terminal.shop. Yeah, you want a real
experience. You want real coffee. You
want awesome subscriptions so you never
have to remember again. Oh, you want
exclusive blends with exclusive coffee
and exclusive content? Then check out
Kron. You don't know what SSH is?
>> Well, maybe the coffee is not for you.
[singing]
[music]
Living the dream.
UNLOCK MORE
Sign up free to access premium features
INTERACTIVE VIEWER
Watch the video with synced subtitles, adjustable overlay, and full playback control.
AI SUMMARY
Get an instant AI-generated summary of the video content, key points, and takeaways.
TRANSLATE
Translate the transcript to 100+ languages with one click. Download in any format.
MIND MAP
Visualize the transcript as an interactive mind map. Understand structure at a glance.
CHAT WITH TRANSCRIPT
Ask questions about the video content. Get answers powered by AI directly from the transcript.
GET MORE FROM YOUR TRANSCRIPTS
Sign up for free and unlock interactive viewer, AI summaries, translations, mind maps, and more. No credit card required.