As someone who also recently spun up a new VPS to fiddle with claws:

I personally fully support Hetzner on this because, as a on-and-off customer since 21 years, their service has been absolutely flawless and always worth every cent. They care so I'm totally happy to pay whatever they need to make it work for them, too.

Resource constraints have often helped me come up with stuff that I'm actually proud of.

> What this does: apiKeyHelper tells Claude Code to run echo proxy-managed to get its API key. The sandbox’s network proxy intercepts outgoing API calls and swaps this sentinel value for your real Anthropic key, so the actual key never exists inside the sandbox.

Asking "How would you build a 10k year clock?" is one of my favorite ways to get to know people, say, at parties.

With a few seconds to mull it over, so far EVERYONE has had at least one strong, novel and leftfield idea that I had not heard or thought of before.

My favorites included: A mirror on the moon, bio-engineered crops and the Pyramids of Gizeh.

I call it "moonwalk" because, when throwing away the intermediate vibe-coded prototype code in the middle, it feels like walking backwards while looking forward.

- Check out a spike branch

- Vibe code until prototype feels right.

- Turn prototype into markdown specification

- Throw away vibe'd code, keep specification

- Rebase specification into main, check out main

- Feed specification to our XP/TDD agents

- Wait, review a few short iterations if any

- Ship to production

This allows me to get the best of vibe-coding (exploring, fast iterating and dialing-in on the product experience) and writing production-grade code (using our existing XP practices via dedicated CC sub-agents and skills.)

For reference, here are the two heavy-lifting workers:

- https://github.com/akaalias/bipscan/blob/main/src/c/find_seq...

- https://github.com/akaalias/bipscan/blob/main/src/c/check_se...

and here's a screenshot of the thing running:

- https://x.com/SpringStreetNYC/status/1996951130526425449/pho...

and here's the full story:

LOL, I got 100% nerd-sniped by my friend Sönke this week and wound up building a small spaceship.

On Monday he's like "Hey, what if you found obscure seed phrases embedded in public texts? You'd only need to remember the name of the book and the paragraph and go from there."

I honestly could care less about crypto(currencies) and I'm 100% sure this is like cryptanalysis 101. But, yeah, it seemed like an interesting problem anyways.

First, I downloaded a few hundred books from Gutenberg, wrote a ruby script and found BIP39 word sequences with a tolerable buffer for filler-words.

Then, I was like, okay, gotta now check them against actual addresses. Downloaded a list of funded ETH addresses. Wrote the checker in ruby. Ran it. No hits but this was now definitely weirdly interesting.

Because: And what if I downloaded the whole pg19 text corpus to scan! And what if I'd add BTC addresses! And what if I checked every permutation of the seed phrase!

Everything got really slow once I got to processing 12G of raw text for finding sequences and then checking a few million candidates with 44.000+ variations per candidate.

So, let's rewrite this into C! And since I've got 16 cores, let's parallelize this puppy! And since it's a MacBook, let's use GCD! Optimize all the things!

Lol, so NOW this thing is so fucking FAST. Takes four minutes to go through the full pg19 corpus and generates 64,205,390 "interesting" seed phrases. The fully parallelized checker (see Terminal screenshot) processes 460 derived addresses per second.

I really don't care if I get a match or not. I feel like I started with building a canoo and wound up with a spaceship is in itself just the best thing in the world.

Anyways, in 2016, Tero Parviainen (@teropa) shared this really cool long-form exploration called "JavaScript Systems Music – Learning Web Audio by Recreating The Works of Steve Reich and Brian Eno" that I enjoyed tremendously (and I don't even like Javascript!)

Check it out at: https://teropa.info/blog/2016/07/28/javascript-systems-music...

I was with total certainty under the impression that detecting AI-written text to be an impossible-to-solve problem. I think that's because it's just so deceptively intuitive to believe that "for every detector, there'll just be a better LLM and it'll never stop."

I had recently published a macOS app called Pudding to help humans prove they wrote a text mainly under the assumption that this problem can't be solved with measurable certainty and traditional methods.

Now I'm of course a bit sad that the problem (and hence my solution) can be solved much more directly. But, hey, I fell in love with the problem, so I'm super impressed with what y'all are accomplishing at and with Pangram!

We're a classic XP shop. To build new features in our brown-field app, we defined about 8 sub-agents such as "red-test-writer", "minimal-green-implementer" and "refactorer".

Now all I do in Claude Code is: "Build this feature X using our TDD process and the agents." 30 minutes later the feature is complete, looks better and works better than what I would have built in 30 minutes, is 90% tested and is ready for acceptance testing.

Granted it took us years of working XP, pairing, TDD etc. but I keep feeling confused about posts like this.

We've been shipping production-grade code written 95% by AI for over a year now. Non-trivial, complex features.

There is no secret sauce even, in how we do this. It works. Really, really well for us.

Yet, the most unexpected thing happened this year on my team of 4 senior/staff-level developers:

Instead of "splintering/pairing off with AI" individually even further, we wound up quadrupling (mobbing) full-time on our biggest project to date. That meant four developers, synchronously, plus Claude Code typing for us, working on one task at a time.

That was one of the most fun, laser-focused and weirdly effective way of combining our XP practice with people and AI.

I just posted the results of another basic interview analysis (4o vs. Llama4) here: https://x.com/SpringStreetNYC/status/1923774145633849780

To your point: Do I understand correctly that, for example, by running the default model of Llama4 via ollama, the context window is very short even when the model's context is, like 10M. In order to "unlock" the full context version, I need to get the unquantized version.

For reference, here's what `ollama show llama4` returns: - parameters 108.6B # llama4:scount - context length 10485760 # 10M - embedding length 5120 - quantization Q4_K_M

Edit: 1.4, not 1.7

For context:

My wife does leadership coaching and recently used vanilla GPT-4o via ChatGPT to summarize a transcript of an hour-long conversation.

Then, last weekend we thought... "Hey, let's test local LLMs for more privacy control. The open source models must be pretty good in 2025."

So I installed Ollama + Open WebUI plus the models on a 128GB MacBook Pro.

I am genuinely dumbfounded about the actual results we got today of comparing ChatGPT/GPT-4o vs. Llama4, Llama3.3, Llama3.2, DeepSeekR1 and Gemma.

In short: Compared to our reference GPT-4o output, none (as in NONE, zero, zilch, nil) of the above-mentioned open source models were able to create even a basic summary based on the exact same prompt + text.

The open source summaries were offensively bad. It felt like reading the most bland, generic and idiotic SEO slop I've read since I last used Google. None of the obvious topics were part of the summary. Just blah. I tested this with 5 models to boot!

I'm not an OpenAI fan per se, but if this is truly OS/SOTA then, we shouldn't even mention Llama4 or the others in the same breath as the newer OpenAI models.

What do you think?

Feedback: First off, I really like your app's style. I love bold colors. The screenshots and text are clear and understandable - maybe except on how the data gets in there. Even if that's by hand, I still think this is a great first version and a solid product.

While I'm not in your workout target group - nor on iOS - it still resonates with me because I use Oura (the ring) specifically for their detailed heart-rate tracking and stress tracking. My most-used feature in their app is my stress-tracking throughout the day.

Feature request: Only to explain how data gets inserted.