alt.hn

5/4/2026 at 8:11:53 PM

Formatting a 25M-line codebase overnight

 https://stripe.dev/blog/formatting-an-entire-25-million-line-codebase-overnight-the-rubyfmt-story

by r00k

5/4/2026 at 9:30:51 PM

One of my first jobs was a small software company writing software for a small number of clients, in MS basic PDS.

The lead developer didn't like to bother with formatting code, so I wrote a tool called makenice to format his nasty spaghetti gibberish into something with good indents and layout to make it easier for us normal people to parse.

He was furious, literally spun in circles about it right in the office in front of everyone, so I wrote makenasty to format code into the way he appeared to like.

I only shared makenasty/nice with a couple of the team, who loved it, as it allowed easy conversion between something readable and something the team lead like.

He never knew about makenasty.

by CrzyLngPwd

5/4/2026 at 10:05:49 PM

Outside of the naming - this is a perfectly sane thing to do for developer comfort and can usually be accomplished with simple transformations.

There are often limitations (like manually added indentation/spacing for alignment) but as long as you're very intentional about what changes you'll allow and have a good understanding of the language it can be an extremely safe operation.

by munk-a

5/5/2026 at 5:03:14 AM

I think git’s naming is actually pretty reasonable: smudge (on checkout) & clean (on stage).

by e28eta

5/5/2026 at 4:57:14 PM

Oh smudge and clean are excellent names. My singly held objection to the OP was that they called one of the scripts "makenasty" instead of like "makemunkastyle" or something more neutral. I think it's an excellent idea I'd just avoid being judgemental in naming. You can consider my deep love of BSD braces super nasty but I'd prefer you didn't label it that way.

by munk-a

5/4/2026 at 10:13:43 PM

If he didn't bother formatting code, it would seem impossible to create a tool that formatted code the way he preferred.

by nitwit005

5/4/2026 at 10:18:18 PM

Sounds like he did format code, and even had opinions on how it should be formatted, but OP disagreed.

by singpolyma3

5/4/2026 at 11:41:56 PM

reminds me of rob pike mentioning gofmt's style is "no one's favorite"

by jameson

5/5/2026 at 1:28:53 PM

The full quote:

> Gofmt's style is no one's favorite, yet gofmt is everyone's favorite - Rob Pike https://go-proverbs.github.io/#:~:text=Gofmt%27s%20style%20i...

The best part about gofmt is there is no discussion about how to format Go code. The style itself is fine, skipping endless hours of pointless debate is priceless.

by infogulch

5/5/2026 at 7:59:07 AM

Having K&R brackets be a syntactical requirement and everything else is a syntax error is okay with me though.

by ErroneousBosh

5/5/2026 at 12:20:43 PM

K&R, ride or die.

by drob518

5/4/2026 at 10:48:00 PM

I find a lot of these conflicts I can't resolve when everybody agrees that the pain of ugly/unnecessary diffs is greater than the pain of minor formatting disagreements.

by Terr_

5/5/2026 at 3:47:00 PM

its because some people learned to put meaning into different ways to layout dense expressions, or different kinds of comments in difference contexts.

python was "weird" at first to C-tribe, because of the strict layout used to eliminate some of the syntax tokens. These stories come from a time before "order over all" in some factory code base was seen as Universally a virtue of some kind

by mistrial9

5/4/2026 at 11:29:38 PM

This kind of passive-aggressive bullshit is exactly what's wrong with tech. People don't decide things: they just passively resist, and authority ends up being a muddle of truncated information flows.

by ethical_source

5/5/2026 at 6:42:16 AM

If someone sharing an old war story with what I felt was a positive and joking tone triggered you this bad, I feel bad for anyone working with you.

Nothing in tech is worth going through life miserable. Nothing.

by wutwutwat

5/5/2026 at 11:33:57 AM

[dead]

by brentcrude

5/4/2026 at 9:54:08 PM

> We chose a Saturday to format the entire codebase to avoid merge conflicts. And while our test suite gave us high confidence we'd gotten everything right, it's always a bit daunting to have a diff so large that GitHub can't render it.

The dart formatter has an internal sanity check. It walks through the unformatted and formatted strings in parallel skipping any whitespace. If any non-whitespace characters don't match, it immediately aborts. This ensures that the only thing the formatter changes is whitespace, and makes it much less spooky to run it blind on a huge codebase.

That sanity check has saved my ass a couple of times when weird bugs crept in, usually around unusual combinations of language features around new syntax.

(Unfortunately, the formatter in the past year has gotten a little more flexible about the kinds of changes it makes, including sometimes moving comments relatively to commas and brackets, so this sanity check skips some punctuation characters too, making it a little less reliable.)

by munificent

5/4/2026 at 10:50:03 PM

I imagine a fancier version would be to compare the Abstract Syntax Trees.

by Terr_

5/5/2026 at 5:38:15 PM

The balancing act is that the fancier your sanity check, the greater the chance of something slipping through its cracks too. Walking too strings in parallel is very simple and hard to get wrong. Traversing an AST and skipping a branch is exactly the kind of easy-to-make bug that the sanity check is designed to catch.

What I'd like to do is something somewhere in the middle where I walk the token stream and check that every token of the input ended up in the output, but I haven't figured out a simple and fast way to do that yet. Performance is particularly tricky because I obviously don't want to burn a bunch of CPU cycles on a sanity check that exists only to catch bugs.

by munificent

5/5/2026 at 8:34:05 AM

I've always thought it would make sense for formatters to be baked into the toolchain so that they can reuse the language's parser (presumably exposed as a library) and then be implemented via parsing to AST and then formatted back out so that they're guaranteed to be correct and normalized. This doesn't seem to be how most formatters work in practice though, although I'm not sure if it's because of performance reasons or a lack of support for the parser being exposed in language toolchains.

by saghm

5/5/2026 at 1:31:50 PM

That is essentially what clang-format is.

by kevin_thibedeau

5/5/2026 at 3:09:51 PM

Good point, I hadn't really thought about it, but the name makes it pretty clear it's using clang's tooling. I only have worked a small amount in C++ in my career years back ago, but I distinctly remember feeling like clang-format was essentially perfect from my perspective, so it's nice to know that my abstract ideals bear out in practice.

by saghm

5/5/2026 at 2:36:44 AM

The only issue is then you're at the mercy of whatever parser your formatter uses to construct the AST

by caminanteblanco

5/5/2026 at 4:55:48 AM

Well, if any (common, non-hobby) parser is thrown off by the reformatting, then it's probably not a safe reformatting either way.

by Terr_

5/5/2026 at 4:04:07 AM

Strictly speaking that wouldn’t work, since a1 is different from a 1, for example.

by hyperhello

5/5/2026 at 8:35:15 AM

I don't think they're trying to say that this is a sufficient test for correctness but a necessary one.

by saghm

5/5/2026 at 5:39:58 PM

Correct. It won't catch 100% of possible bugs, but it will catch most.

The kind of bugs that are easiest to write in a formatter is dropping a bit of syntax on the floor and forgetting to include it in the output, and the sanity check will catch those.

It's also definitely possible to miss some whitespace that's necessary for things like identifier separation, but... <shrug> it's a sanity check, not a proof of correctness.

by munificent

5/6/2026 at 12:27:17 AM

In practice, that's how most software testing works anyhow!

by saghm

5/5/2026 at 10:31:12 AM

Lots of formatters also unify things like trailing commas, so it would be slightly more involved than this.

by Skeime

5/5/2026 at 5:40:30 PM

Yes, the dart formatter does that now too. So the sanity check ignores commas and semicolons, which makes it less robust as a sanity check, unfortunately.

by munificent

5/4/2026 at 9:45:25 PM

I'm surprised they went with a all-at-once reformat. Even when doing it over a weekend this is bound to mess with a lot of open PRs at their scale.

I had to introduce a formatter in a few sizeable codebases in the past (few 100k to few million LOC), and I always did it incrementally via a script that reformatted all files that are not touched in any open PR. The initial run reformatted 95% of all files. Then I ran the script every day for ~two weeks and got up to 99.5% of all files and then manually each time one of the remaining ~dozen PRs that were WIP for longer were merged.

by hobofan

5/4/2026 at 10:30:01 PM

both options have their pros and cons. if you utilize some form of ratcheting[1], you can sneak it in without your team knowing.. but all of your PRs for the foreseeable future will have a ton of reformatting screwing with your git blame. if you do it all at once, someone will have to sort out conflicts, but you can utilize `blame.ignoreRevsFile`[2] so that your history remains useful

[1] https://github.com/diffplug/spotless/tree/main/plugin-gradle...

[2] https://git-scm.com/docs/git-blame#Documentation/git-blame.t...

by rileymichael

5/5/2026 at 6:48:05 AM

Even if you spread out reformatting over multiple commits in different PRs, you can still make use of blame.ignoreRevsFile as long as your pull request workflow doesn't enforce squash merges even when somebody took extra care to produce a nice commit history.

by yorwba

5/4/2026 at 10:38:08 PM

Yes, that is a good point. This is also why I personally would recommend to let a central person/team handle the reformatting rather than sneaking it into every PR (- see my sibling comment). That way you can be in charge of having a uniform style of commit messages to make the reformat commits easy to identify and create a well kept ignoreRevsFile. I think that provides the best of both worlds.

by hobofan

5/4/2026 at 10:52:11 PM

That’s a neat feature, thanks for sharing.

Unfortunately I find that code bases lacking auto formatting are often littered with non functional changes as developers temporarily instrument code, remove it, but leave whitespace changes behind.

In terms of tracking code changes, one really would have to rewrite the entire history with each commit reformatted.

by BobbyTables2

5/5/2026 at 1:37:42 AM

> I'm surprised they went with a all-at-once reformat. Even when doing it over a weekend this is bound to mess with a lot of open PRs at their scale.

Rebasing PRs should be trivial, just rewrite all commits reformatting the files it touches, then rebase, `git checkout --theirs`, run formatter again, and `git rebase --continue`. It's methodical and scriptable, you don't need to manually resolve any conflicts.

by WhyNotHugo

5/4/2026 at 9:53:12 PM

You can always let the team know so that they can apply the formatter on their PR branch.

by skydhash

5/4/2026 at 10:31:26 PM

In the smaller migrations I did I tried that, but some way or another a decent chunk of the people still managed to get stuck in merge/rebase conflicts. I would almost explicitly not recommend giving that advise to the teams.

My rough blueprint for introducing formatter or linter nowadys would be:

- Recorded knowledge share session around how to set up the tools for local use 1-2 weeks before the initial rollout, and outline how the process will take place

- On the day of the initial rollout send out a reminder + the recording again

- Do the initial PR

- Incrementally do the rest of the migration, and subscribe to the PRs that drag out the process

by hobofan

5/4/2026 at 10:31:01 PM

This is exactly the remedy to the PR issue. I've "lucked" into owning a Prettier formatting pass at two different places now, and did the same process at each - full pass on master, simple step-by-step process to follow to update any PR by running the format script.

by jrajav

5/5/2026 at 12:50:24 AM

It's probably because the author can shit on others (let me guess, a senior principal something engineer).

by zx8080

5/4/2026 at 8:46:51 PM

I’m shocked at the 25M line part! That is a completely unfathomable amount of code for one codebase. I really want to know more about that.

by varun_ch

5/4/2026 at 11:24:55 PM

I am more shocked by the "overnight" aspect. I tried running clang-format on the Chromium source (68,281 .cc files, 21 million lines according to wc):

$ find chromium-149.0.7826.1/ -name ".cc" -exec cat {} + | wc 21640925 55715244 833460441

And that took less than 6 minutes on a single E5-2696 v3 from 2014:

$ time find chromium-149.0.7826.1/ -name *.cc | parallel -j 16 clang-format $x>/dev/null

real 0m5.666s user 1m13.964s sys 0m13.373s

That’s orders of magnitude faster, especially if we assume they’re not running their workloads on potatoes like mine. Is Ruby’s syntax really that much more complicated than C++, or is this a tooling problem?

by phoyd

5/4/2026 at 11:44:28 PM

I don't think the post necessarily means it took multiple hours to format the codebase, I think they're probably just saying they worked on it off-hours and landed it while no one was working so that it didn't run into merge conflicts.

by deets87

5/4/2026 at 11:47:55 PM

My guess would be tooling. I think the Ruby formatters are written in Ruby. I’d guess the clang one is written in C.

by christophilus

5/5/2026 at 5:35:54 AM

Nah the article says it's rust and calling into a C library for parsing.

by riffraff

5/4/2026 at 9:34:36 PM

Only 25 million? :) Google had billions a decade ago...

https://research.google/pubs/why-google-stores-billions-of-l...

by bruckie

5/4/2026 at 11:12:19 PM

iirc they also vendor(ed) many of their dependencies, several layers deep, which still counts for "stores" though it's rather different than "wrote" / "maintains".

by Groxx

5/5/2026 at 3:46:49 AM

Very true. It was still hundreds of millions of lines of first party code a decade ago, and could easily be over a billion at this point.

by bruckie

5/5/2026 at 4:40:35 AM

Yeah, I can definitely believe that Google would break over a billion handwritten. It's a big company that has been around for a long time.

It's still absurd. But believable.

by Groxx

5/4/2026 at 8:55:13 PM

Right, where is the rest of the code?

by jsnell

5/4/2026 at 9:01:12 PM

They're up to 42 million now, as per the article

by mr_mitm

5/4/2026 at 9:19:56 PM

That sounds even more insane to me, but I guess most of that code does not really touch financial transactions, otherwise it would be a nightmare being responsible to verify that.

by lukan

5/4/2026 at 10:08:51 PM

Ruby code touches financial transactions. Card payments were migrated to Java when I left in 2022. Non-card payments (e.g., ACH, checks, various wallets) were still processed by Ruby.

PCI-related/vaulting code lived in its own locked-down repo. I think that was a mix of Go and Ruby.

Once you have the foundations in place for account balances and the ledger, processing a payment isn’t that daunting. Those foundations, however, took a lot to build and evolve.

by clintonb

5/5/2026 at 1:26:18 AM

> Once you have the foundations in place for account balances and the ledger, processing a payment isn’t that daunting. Those foundations, however, took a lot to build and evolve.

Pretty much. I've worked at places with PHP payment processing that worked just fine, and at a place with C++ payment processing (and no testers) and it worked just fine. I wasn't around when the systems were first built though so not sure if there were tears along the way.

by jamesfinlayson

5/5/2026 at 12:04:33 AM

> migrated to Java

I want to know more about this

by varun_ch

5/4/2026 at 10:57:20 PM

My (much smaller than Stripe) company is well over 4.5M at this point, and the graph is very much exponential.

AI has been a huge problem here: the amount of code is just exploding. Quality of the produced code is another matter.

by deathanatos

5/4/2026 at 11:17:11 PM

^^^^^^^^^^^^^^^^^^^

I recently wrote a very esoteric Python script. 100 lines of code. No classes, no functions, but yes argparse.

I've tried out the latest open source models on the task. They go bananas. It's like Enterprise fizzbuzz (https://github.com/enterprisequalitycoding/fizzbuzzenterpris...). They love classes and imports and reinventing the wheel. A great way for me to tell trash AI slop code is it'll define a useful constant then 15 lines later do it again with a different name.

They love making code that looks impressive. "Wow look at all the classes and functions. It's so scalable. It's so dynamic. It validates every minutae against multiple schema and solves a problem I never thought about." But it was trash code. One really was 400 lines and it didn't even look like it would work. Can't even imagine what it means for 4.5M moderately good human lines to become what? 27M fluffy filler repeat lines that don't even make sense?

by Neywiny

5/4/2026 at 11:40:15 PM

The bad part of LLM is it got trained on bad examples because us humans also don't know WTF we're doing.

by manoDev

5/5/2026 at 1:37:00 AM

Yeah maybe I need to do the old "you are a veteran engineer" nonsense. I've had some success telling it to implement everything it suggests and be production ready. I hate when it takes a shortcut and says I'll have to change it. That's kinda the whole point of me not writing the code...

by Neywiny

5/5/2026 at 5:16:45 AM

Unless I’m mistaken, it’s a monorepo. So it’s not 25M LoC in a single app, it’s (all?) of their server-side code and shared libraries. There’s also a variety of other languages in use.

16 years and thousands of engineers write a lot of code.

by e28eta

5/5/2026 at 7:44:43 AM

Imagine lots and lots of models and stubs generated from swagger, protobuf, sqlc etc.

by il-b

5/6/2026 at 5:42:06 AM

Normally you don't want to format automatically generated code, you adjust the code generator instead.

by a57721

5/5/2026 at 2:19:05 AM

Really reminds me that there's nothing in principle stopping us from storing parse trees and exposing them via something git like so we can avoid even needing to format, let alone also needing to resolve a whole category of merge conflicts based on that formatting. I mean a format is just a theme over your data -- I mean code.

by eigenblake

5/5/2026 at 1:33:03 AM

I don't understand why the felt the need to do a big-bang merge like this. Its a formatter, so the files should be functionally equivalent before and after. Why not just enable it for new files/edit files for a while, then once comfortable apply it to old files in batches? What advantage does the big bang merge give? Seems higher risk for the same reward

by dgrin91

5/5/2026 at 2:06:35 AM

could introduce subtle bugs, so doing it all at once while it's on the front of everybody's mind with as much comprehensive review and testing of parts or the whole to everybody's satisfaction. if you don't do it all at once, you'd need to repeat the same amount of testing multiple times.

>files should be functionally equivalent before and after

when you say something like this, the road you are on is paved with good intentions.

by fsckboy

5/5/2026 at 5:40:06 AM

You can also introduce subtle bugs in your own feature development, and if you change formatting there it's also at the front of your mind.

I think the main argument for doing a big bang rewrite is that you have a defined before/after, otherwise you're stuck into an endless in-between.

by riffraff

5/4/2026 at 10:22:57 PM

> Given that complexity, the hypothesis was simple: tackle the hardest syntax first and the rest will follow.

Always nice to see. I've seen people fall into the trap of designing for the common case, not realizing most of the code will be to deal with the less common cases.

by nitwit005

5/5/2026 at 3:01:06 AM

In another field I have heard it called going for the jugular; the vivid description helps get the point across nicely.

If you want to master something, you will have to know the hardest part. So just deal with that first and then everything else is easy, because you are dealing with it as somebody who has already mastered the domain.

by sgc

5/4/2026 at 9:24:59 PM

The floating spiral thing is so distracting I spent more time deleting it in Inspector than reading the article. I feel like they hate their readers. Awful.

by burnte

5/4/2026 at 10:42:16 PM

If you set `prefers-reduced-motion: reduce`, it goes away

by annaspies

5/4/2026 at 10:23:58 PM

Man must me nice to have the time to put so much work into tabs.

by comrade1234

5/5/2026 at 1:57:07 AM

Clean indenting is about saving time so you don't spend way too long getting lost trying to understand what seems like an insane piece of code until you realize it was a mundane bug hidden by incoherent indentation.

by Pxtl

5/6/2026 at 11:57:53 AM

The practical case is less time spend on rebasing/formatting code - IMO formatting standard is very helpful as then it's the same as storing AST. There's also better preserving of git blame and that's likely why they have done it as single operation as otherwise you would have everybody messing with that part and now you know there's single commit that touched everything and if blame is on it then you check previous edit.

by machiaweliczny

5/5/2026 at 1:07:06 AM

How did I know this was going to be a rewrite in Rust?

by tmaly

5/5/2026 at 3:24:12 AM

Cool story. The treat at the end was fun as well, thank you!

by ryanisnan

5/5/2026 at 3:31:53 PM

[dead]

by hiroto_lemon

5/5/2026 at 12:47:11 AM

[dead]

by failure_arch

5/4/2026 at 8:33:43 PM

[dead]

by exsol

5/4/2026 at 8:36:00 PM

[flagged]

by andrewstuart

5/4/2026 at 8:44:32 PM

Considering that it's been doing so successfully at volume for just over 15 years, I think their language choice was fine.

by mbStavola

5/4/2026 at 9:18:05 PM

This ought to change your mind about Ruby!

by sixo

5/4/2026 at 8:40:26 PM

Why is that terrifying?

by skinfaxi

5/4/2026 at 9:34:03 PM

Some folks don't like shipping

by mikedelago

5/4/2026 at 9:47:11 PM

ive yet to see a compelling elitist programming language opinion. especially when used at big successful companies. these companies don't function in spite of their technology choices.

by fantasizr

5/5/2026 at 12:15:43 AM

The only one that worked on me wasn't even elitist in its framing.

Try TypeScript! It makes your JavaScript better!

That was enough for me.

by NetOpWibby

5/4/2026 at 9:59:26 PM

> these companies don't function in spite of their technology choices.

shows you never worked at "big succesful companies".

by lstodd

5/4/2026 at 8:54:33 PM

It's not particularly terrifying. Some people really just don't like Ruby.

by Jtsummers

5/4/2026 at 8:44:27 PM

The systems have to be written in some kind of programming language, and I think Ruby is a perfectly fine choice.

by sikozu

5/4/2026 at 9:11:25 PM

Not denying that Ruby is a perfectly fine choice but within the article itself it says that Stripe runs the world's largest Ruby codebase so certainly it might be testing the constraints of the language.

The thing I am interested is that I don't suppose that Stripe always had these many LOC's and so I would be curious to know if at any point as the codebase was increasing, were they looking at other new languages which were coming like golang or rust which was more suited for their work or not and what were there decisions/thinking process to continue using ruby.

by Imustaskforhelp

5/4/2026 at 10:11:44 PM

LOC doesn’t have much to do with the “constraints of the language”.

Stripe has dabbled in Golang. There is also a growing Java monorepo.

by clintonb

5/4/2026 at 10:49:47 PM

Stripe uses Sorbet which, in my experience, increases LOC.

by throwaway041207

5/4/2026 at 9:21:00 PM

Things can always be worse. It could be PHP, for example.

by sunrunner

5/4/2026 at 9:38:27 PM

Facebook runs in it, so I think the language itself is probably a fine choice.

by burnte

5/4/2026 at 10:03:01 PM

It's almost like other factors than language choice are more important :)

by Twirrim

5/4/2026 at 11:14:06 PM

If you think that's terrifying, imagine all of the essential code written in COBOL and FORTRAN.

Skippy the Intern, now retired these thirty years...

by msla

5/4/2026 at 9:09:53 PM

I’d hardly call Sorbet Ruby :)

by semiquaver

5/4/2026 at 9:04:48 PM

[dead]

by benbristow

5/4/2026 at 9:35:30 PM

Surely, it no longer needs to be human-readable, and the era of write-only code is finally upon us with the dawn of AI writing our mealtickets.

Why bother formatting 25m lines of slop, and why is AI wasting tokens on making code look human-readable anyway?

by CrzyLngPwd

5/5/2026 at 3:13:23 AM

Every LLM I have ever asked about this says they perform better when they receive pretty-printed code because it is easier to see structure and priorities. It has been an almost universal recommendation for me, and it makes sense since LLMs are just mimicking human expression.

by sgc

5/7/2026 at 7:09:25 PM

That doesn't make sense.

A compiler doesn't need pretty code to compile; in my tests, when I ask an LLM to deobfuscate code, it doesn't skip a beat.

by CrzyLngPwd

5/5/2026 at 10:41:46 AM

you asked the llm? i'm confused

you do understand it can't "know" how it performs right?

by throawayonthe

5/5/2026 at 1:52:50 PM

You actually think that LLMs are not fed docs on how they work in order to help users interact with them better? Asking an LLM how to use it is based on the reasonable presumption that the company making it will prioritize making it useful for users and work on programming it with its own best practices.

Again, it makes perfect sense as well based on how they are trained in the first place. Look at how they tokenize whitespace and you will see why it's useful. Each number of repeating white spaces gets a unique token (so 2 whitespaces = token1, 3 whitespaces = token2) - so it actually does make a very clear reinforcing hierarchy readily available. And we all know if there is anything an LLM needs, it is reinforcement of important points.

by sgc

5/5/2026 at 1:08:57 AM

What is even the point of formatting code anymore.

by throwatdem12311

5/5/2026 at 7:33:23 AM

To make it look nice and readable

by voidUpdate

5/5/2026 at 11:38:37 AM

For an agent?

by throwatdem12311

5/5/2026 at 11:46:09 AM

For you, the person reading and writing the code

by voidUpdate

5/5/2026 at 11:56:39 PM

People are still reading the code?

by throwatdem12311

5/6/2026 at 6:54:58 AM

I do... I guess people not reading their own code is why products are so buggy and crap these days

by voidUpdate

5/8/2026 at 9:09:58 PM

Why are you not reading the code?

by Twirrim

5/5/2026 at 10:42:09 AM

clean diffs for one

by throawayonthe

5/5/2026 at 10:00:18 AM

[dead]

by stefantalpalaru

5/4/2026 at 10:05:55 PM

An insight about code is that compared to the scale we operate on data, code as text is tiny. Instantaneous git operations and “run this tool over all the code” are the norm even while we wait for LLMs to stream their tokens to stream back so tool calls can operate on it.

That insight might seem obvious - but if you stay cognizant of it as you work, you can invent some pretty amazing tooling for yourself & your team.

by cadamsdotcom