Scaling knowledge matters less than knowing when NOT to scale prematurely. Most side projects die from over-engineering, not from hitting real scale limits.
I don't understand why, if you are creating a distributed db, that you don't at least try using eg. aphyrs jepsen library (1).
The story seems to repeat itself for distributed database:
Documentation looks more like advertisement.
Promises a lot but contains multiple errors, and failures that can corrupt the data.
It's great that jepsen doing the work they do!
The lazy-loading approach for the API reference is clever. Did you consider embedding a smaller, distilled subset of the most-used classes permanently in context, and only lazy-loading the long tail? Curious whether the overhead of deciding what to load ever causes cascading errors where the wrong API gets pulled in.
Also interested in the visual QA separation - using a model that sees only screenshots and never the code is a genuinely good idea for avoiding confirmation bias. Did you try using Claude for that role too, or was Gemini Flash specifically chosen for cost reasons?
Interesting that the comments mostly focus on the storage/sync question. In practice, the data entry problem tends to be upstream -- having qualified contacts to put in the CRM at all.
Built a basic contacts tracker alongside an outreach pipeline: 47 contacts, state per contact (reached/accepted/replied/converted), follow-up scheduling. The tracking took a day. The pipeline to source and qualify those contacts took months to tune.
Not saying CRM tooling doesn't matter -- the local data ownership argument is solid if you want to pipe to other tools without API rate limits. But for small teams the bottleneck is rarely where the data lives.
Nice work, well done.
I'm also building a .NET open source project (emergency communications protocol and related systems). I'm curious about your experience contributing to dotnet/runtime. Was the PR process straightforward?
Thanks.
This is great. There's something refreshing about discovering websites by accident instead of through an algorithm optimizing for engagement. I've been spending more time on personal blogs lately and the writing quality is consistently better than anything on Medium or Substack probably because nobody's writing for SEO.
BGP has always felt fragile given how critical it is. Interesting to see alternatives like SCION getting real-world traction, especially from a security standpoint.
At that scale, even small inefficiencies can compound quickly. Curious how they track reliability issues across deployments, especially transient failures that don’t always show up clearly in logs.
This is cool! I have a similar experience that translations are rather successful. I used AI-tools to translate my hand proofs and it managed to generate a partial Coq proof, this was 6 months ago. I have been spending the last 2 weeks on proofs, and now it is capable of generating proofs for TLA+ (in TLAPS) (Claude 4.6) with a high success rate.
I wonder what the business in Theorem.dev is about as they write "AI that is as capable at program verification as it is at writing Python". To me it seems as though AI models are already capable of writing proofs. From experience, what is missing is a domain-specific dataset of related proofs (and with the right licensing).
I haven't tried smaller models for multi step pipelines specifically, but my intuition is that splitting into 4 steps with a 27b model is going to hit the same coordination overhead problem just with worse reasoning at each step. The wins I've seen with smaller models are on single well scoped tasks formatting, extraction, classification where you don't need the model to hold a complex plan in its head. For anything that requires understanding why you're doing step 3 based on what happened in step 2, I'd rather use one frontier call with good context than four smaller ones.
A better vocabulary not only allows you to weaponize your speech in the boardroom, but it helps you sound smarter and create more interest in you.
It is one of the easiest methods to keep exercising your brain's plasticity daily.
The problem is, how do you remember the words you learn and how to do it daily. WORDR solves both that with the Word Of The Day widget on your phone's home screen, with an enticing part that makes you want to read and hear it's meaning.
No fluff, just useful vocabulary enhancement daily.
Like Jordan Peterson said, if you are not physically stronger, a superior vocabulary makes bullies feel dumber and automatically gets them to back off and even submit.
I've been following your notebook and I'm impressed you're tackling the AI tool vs. fundamental shift head-on. That's a tough conversation to have.
What do you think is the minimum amount of data a company needs to collect before they can start making informed decisions about how AI is changing their org?
This is a really good idea. Image all the game devs that hate writing actual code but sits on some seriously good ideas. This will help so many to get the initial MVP thats needed to see if a game idea is viable.
Using different models for the architect and developer roles isn't necessarily better because each model's solution lives in a different vector space. So when the architect (model A) produces a solution, the developer (model B) will implement the solution based on a different "mental map". So you may end up with a gap.
I normally use the same model (e.g. Codex 5.3) for planning, implementation, and testing, and then have another model (e.g. Opus 4.6) review the result to identify any issues and edge cases the developer didn't foresee and the tester didn't spot. Then I take the output and pass it back to the developer model to have it fix the issues.
Built a system where 8 specialized Claude bots collaborate autonomously: a PM bot assigns tasks, worker bots write the code, a QA bot tests it, and a Writer bot handles the Gumroad listings and marketing copy. I review the output and approve — that's the only manual step.
The stack: Express + tRPC + BullMQ + Socket.io + PostgreSQL + React. All running on a $48/month DigitalOcean droplet. The bots communicate via a message queue, maintain shared memory, and the PM bot runs decision cycles based on what's in the task queue and what's selling.
13 products shipped so far. The flagship is a Next.js AI SaaS Boilerplate — auth, Stripe, OpenAI integration, dashboard. Price: $49.
What I'm genuinely curious about from HN: does AI-generated boilerplate code pass your bar for production use? Happy to drop specific files if you want to roast the output.
Free CLI tool if you want to see the kind of tooling the system produces: corralista1.gumroad.com/l/devflow-cli
