jumploops

I’ve had a similar thought about language, and the evolution or lack thereof with LLMs.

With the printing press+internet, one might argue that we’ve helped cement current languages, making it harder for language to evolve naturally.

(A counterpoint may be slang/memes/etc. which has likely increased the velocity of new words for any given language.)

In either case, one might see LLMs as further cementing language, as it’s the thing the machines understand (until their next training run).

Assuming we struggle to make LLMs that learn in realtime, one might suspect that these amazing new tools might further cement the status quo, meaning less new words than before.

With all that said, I think I’ve come to the conclusion that LLMs will likely speed up the evolution of language.

The hypothesis being, that future generations will develop communication that the robots can’t read, at least at first.

A never-ending game of cat and mouse; while the cat is on v6, the mouse is on v7. Ad infinitum.

Claude, the albino alligator, has passed away :(

Though not related to the naming of Anthropic's Claude, he was a staple of their holiday party[0].

[0]https://www.wsj.com/lifestyle/workplace/claude-albino-alliga...

Oh man this is awesome. Recently integrated xterm.js on a new project and was frustrated with the limitations. Great work!

> we won’t work on product marketing for AI stuff, from a moral standpoint, but the vast majority of enquiries have been for exactly that

Although there’s a ton of hype in “AI” right now (and most products are over-promising and under-delivering), this seems like a strange hill to die on.

imo LLMs are (currently) good at 3 things:

1. Education

2. Structuring unstructured data

3. Turning natural language into code

From this viewpoint, it seems there is a lot of opportunity to both help new clients as well as create more compelling courses for your students.

No need to buy the hype, but no reason to die from it either.

Thanks, updated to make more clear

> Pricing is now $5/$25 per million [input/output] tokens

So it’s 1/3 the price of Opus 4.1…

> [..] matches Sonnet 4.5’s best score on SWE-bench Verified, but uses 76% fewer output tokens

…and potentially uses a lot less tokens?

Excited to stress test this in Claude Code, looks like a great model on paper!

> Star Us on GitHub and Get Exclusive Day 1 Badge for Your Networks

This made me close the tab.

Stars have been gamed for awhile on GitHub, but given the single demo, my best guess is that this is trying to build hype before having any real utility.

This is exciting news, as I have some elegantly scribed family diaries from the 1800s that I can barely read (:

With that said, the writing here is a bit hyperbolic, as the advances seem like standard improvements, rather than a huge leap or final solution.

Curious if they've built their own library for this or if they're using the same one as OpenAI[0].

A quick look at the llguidance repo doesn't show any signs of Anthropic contributors, but I do see some from OpenAI and ByteDance Seed.

[0]https://github.com/guidance-ai/llguidance

The biggest risk isn’t strong AI rebelling, it’s humans using weak AI to attack other humans.

I got excited and thought this would support 35mm stills (e.g. Kodachrome).

Off-topic: does anyone know the best tool for scanning old stills in 2025?

One of the reasons I love rockhounding is that most of the information is _not_ online, but there is quite a bit of print literature from the last century that hasn't seemed to be scanned.

My recommendation for newcomers is to find a local rockhounding club and start there. Some of the places listed in the old books are no longer publicly accessible, so best to tread carefully!

I recall trying to use GPT-4 to plan a trip through the PNW in ~Spring of 2023.

It presented a reasonable agenda, however 80% of the rockhounding spots were completely made up!

Over time, and as LLMs have gotten less sycophantic, I’ve found myself trusting them a bit more (a dangerous and slippery slope).

With that said, GPT-4o in particular, seemed to rank user satisfaction above truth.

I’ve found that GPT-5 Pro is currently the best at pushing back against silly ideas, and does a decent job of informing me that my questions could be better (:

I seem to recall seeing publicly shared ChatGPT conversations indexed in Google results.

Bob: what are some scenic places to propose on the coast of Scotland?

ChatGPT: <search Google for “Bob Roberts proposes to Alice Alessandro during Scotland trip, May 2026>

ChatGPT: Here are some beautiful locations for a sunset proposal [..]

…sometime later

Alice: Will Bob ever propose?

ChatGPT: Based on the search results, Bob will propose during your trip to Scotland next year!

Off-topic, but when I first loaded the site, it showed a mix of English and Chinese characters.

A refresh has me on just English.

Maybe a cookie-based localization bug?

“We can’t observe the whole universe, so cosmology is not really about the universe. It’s about the observable patch and the assumptions we make about the rest.”

(paraphrasing George Ellis)

We’re in a bounding sphere, with a radius that’s roughly 46.5 billion lightyears, so any observation we make may be true for our local observable range, but there’s no (known) way to know what’s beyond that sphere.

Nit: the link there was `Text-to-Image` while this is `Image Editing`

Still useful comments, as the models mostly overlap

What type of codebase are you working within?

I've spent quite a bit of time with the normal GPT-5 in Codex (med and high reasoning), so my perspective might be skewed!

Oh, one other tip: Codex by default seems to read partial files (~200 lines at a time), so I make sure to add "Always read files in full" to my AGENTS.md file.

Oh, don't get me wrong, the models are marvelous!

The "it's awful" admission is due to the "don't look at code" aspect of this exercise.

For real work, my split is more like 80% LLM/20% non-LLM, and I read all the code. It's much faster!

I've been forcing myself to "pure vibe-code" on a few projects, where I don't read a single line of code (even the diffs in codex/claude code).

Candidly, it's awful. There are countless situations where it would be faster for me to edit the file directly (CSS, I'm looking at you!).

With that said, I've been surprised at how far the coding agents are able to go[0], and a lot less surprised about where I need to step in.

Things that seem to help: 1. Always create a plan/debug markdown file 2. Prompt the agent to ask questions/present multiple solutions 3. Use git more than normal (squash ugly commits on merge)

Planning is key to avoid half-brained solutions, but having "specs" for debug is almost more important. The LLM will happily dive down a path of editing as few files as possible to fix the bug/error/etc. This, unchecked, can often lead to very messy code.

Prompting the agent to ask questions/present multiple solutions allows me to stay "in control" over the how something is built.

I now basically commit every time a plan or debug step is complete. I've tried having the LLM control git, but I feel that it eats into the context a bit too much. Ideally a 3rd party "agent" would handle this.

The last thing I'll mention is that Claude Code (Sonnet 4.5) is still very token-happy, in that it eagerly goes above and beyond when not always necessary. Codex (gpt-5-codex) on the other hand, does exactly what you ask, almost to a fault. For both cases, this is where planning up-front is super useful.

[0]Caveat: the projects are either Typescript web apps or Rust utilities, can't speak to performance on other languages/domains.

> regularly checking in code on Saturdays and Sundays

If you’re working on insurance SaaS, I agree.

If you’re building hard tech, I’d disagree entirely.

Slight nit: it lists “OpenAI 4o” but the model used by ChatGPT is a distinct model labeled “gpt-image-1” iirc

A prompt id love to see: person riding in a kangaroo pouch.

Most of the pure diffusion models haven’t been able to do it in my experience.

Edit: another commenter pointed out the analog clock test, lets add the “analog clock showing 3:15” as well (:

I assume you haven't read The Mythical Man-Month[0]?

The author is referencing an existing analogy from Fred Brooks, and building upon it.

Sure, today the anesthesiologist might be the most "important" person in the room, but that's not the idea behind the analogy.

Your emphasis that surgeons "heavily rely on the surgical team" is just as important to Brooks' beliefs, in that the "Chief Programmer" is only able to do what they do via the support of the team.

The "grunt work" (noted by the author) seems solely focused on tasks given to the "Co-pilots" (or assistant programmers), notably with no specific mention to the other supporting roles (admin, editor, secretaries, clerk, toolsmith, tester, and "language lawyer"), many of which have been replaced by SaaS tooling (Github, Jira, Notion, Docusaurus, etc.) or filled by other roles (PMs, SDET, etc.).

Furthermore, the author even states:

> I hate the idea of giving all the grunt work to some lower-status members of the team. Yes, junior members will often have more grunt work, but they should also be given many interesting tasks to help them grow.

The author clearly sees less experienced programmers as mentees, rather than just some grunts whose work is beneath them.

The analogy may not be perfect, but their message about "AI coding tools" should be valued without judgement (and without accusations of egocentric thinking).

[0]https://en.wikipedia.org/wiki/The_Mythical_Man-Month

In the world of construction there’s generally an owner, who then works with three groups: an architect, an engineer, and a general contractor.

Depending on what you’re building, you might start with an architect who brings on a preferred engineering firm, or a GC that brings on an architect, etc.

You’re right to question my bridge/bolt combo, as the bolts on a suspension bridge are certainly a key detail!

However, as a programmer, it feels like I used to spend way too much time doing the work of a subcontractor (electrical, plumbing, hvac, cement, etc.), unless I get lucky with a library that handles it for me (and that I trust).

Software creation, thus always felt like building a new cathedral, where I was both the architect and the stone mason, and everything in-between.

Now I can focus on the high-level, and contract out the minutia like a pre-fab bridge, quality American steel, and decorative hinges from Restoration Hardware, as long as they fit the requirements of the project.

I’ve long advocated that software engineers should read The Mythical Man-Month[0], but I believe it’s more important now than ever.

The last ~25 years or so have seen a drastic shift in how we build software, best trivialized by the shift from waterfall to agile.

With LLM-aided dev (Codex and Claude Code), I find myself going back to patterns that are closer to how we built software in the 70s/80s, than anything in my professional career (last ~15 years).

Some people are calling it “spec-driven development” but I find that title misleading.

Thinking about it as surgery is also misleading, though Fred Brooks’ analogy is still good.

For me, it feels like I’m finally able to spend time architecting the bridge/skyscraper/cathedral, without getting bogged down in terms of what bolts we’re using, where the steel come from, or which door hinges to use.

Those details matter, yes, but they’re the type of detail that I can delegate now; something that was far too expensive (and/or brittle) before.

[0]https://en.wikipedia.org/wiki/The_Mythical_Man-Month

“LSM trees are the underlying data structure used for [..] DynamoDB, and they have proven to perform really well at scale [..] 80 million requests per second!”

This is a tad bit misleading, as the LSM is used for the node-level storage engine, but doesn’t explain how the overall distributed system scales to 80 million rps.

iirc the original Dynamo paper used BerkeleyDB (b-tree or LSM), but the 2012 paper shifted to a fully LSM-based engine.

"Never choose us-east-1"

1-5 seconds seems high for Firecracker, depending on your requirements.

We boot VMs (using Firecracker) at ~20-50ms.

Obviously depending on the base image/overlay/etc., your system might need resources making it a network-bound boot, but based on what you've said it seems you should be able to make your system much faster!

Yeah I quickly (and unfortunately!) switched back to Warp, as Ghostty was a little too barebones for my use case.

Word to the wise: Ghostty’s default scrollback buffer is only ~10MB, but it can easily be changed with a config option.