It's hard to argue with the numbers, but starting with a (mostly true!) “research is the most expensive part” premise, this strikes me as an odd direction to go to optimize costs:
1. As others pointed out, we feed all the same research turns to a smaller model, so we pay the uncached price for all of them.
2. During research, the model typically reads more code than is relevant, to figure out what is relevant and what is not. If that's the expensive part, we keep paying for those turns with the most expensive model?
3. There is no quality comparison of the resulting code. Same plan != same code, and AI tokens during the initial implementation phase isn't the only cost attributable to the task.
I do the opposite:
1. Outsource research to a subagent, or several parallel subagents. Let them output the relevant code paths only. Using gpt-5.6-terra-high on Codex and sonnet on Claude. Merge results into a single per-task research file. This saves tokens and context window of the bigger model, and avoids re-researching after compactions and in subagents.
2. Use the smartest agent (Sol xhigh ultra / Fable max) for both planning and execution. Tell it to use the research file where possible.
3. Switch to dumber agents for verbose substeps, e.g. gpt-5.6-luna-medium / sonnet is enough to drive browser use.
Sadly, got no numbers to back this approach.
PS: Of course, different task complexities and codebase complexities demand different approaches. The most expensive part is actually the code review step, which they don't mention/have at all. We should come up with some sort of complexity grading, so that discussions like this can be contextualized.
I'd love nothing more than measure 3), but quality is really hard to assess IMO as even with the frontier models I find myself disagreeing on what is good and maintainable code; so that disqualifies LLM-as-judge, which even at it's best is somewhat RNG and costly.
+ I don't see this replacing anyones workflow to make it clear. This is mostly for fully autonomous agents that are given a task & are asked to execute. For instance, subagents are a perfect example where you can get the aforementioned savings for free, even if you don't run a "software factory" per-se, as you generally do not interact with them.
I've been doing more or less this (from the post) for months:
> plan deeply, then capture the plan as a todo list, then start.
I do the plan deeply phase by writing a 50 line specification myself and then asking Claude to evaluate it, find what I missed, ask questions. I answer the question and we iterate until I know that we have what I had in mind to do.
Then I ask it to write the implementation plan, that I might end up reviewing because it always asks some more question. Finally it implements the steps.
If the planning was good the implementation is fast.
Wondering how many people are like me and hate writing in cursive.
I stopped using it right after graduating high school (where it was required), never used in drafts after elementary school, and only ever used normal print letters in the university (and also included TeX commands because I was typesetting lecture notes later and was figuring out the optimal command set on the fly).
I’m surprised, as the whole points of it are speed and duration (less cramping, less energy when moving the wrist). Discrete lettering is simply slower because it requires more motion.
The point of cursive was make writing efficient with a quill pen. With a quill pen you run the risk of ink dropping off the tip if you lift it from the paper. Therefore cursive tries to keep the pen in contact with the paper most of the time. I've never thought of cursive as a speed tool. My printing has always been much faster than my cursive.
I’m with andreyvit on this one. Maybe I’d feel differently if I had read a subject involving a lot more essay-writing at university. In subjects like the mathematics and computer science that I studied, where you need to be very clear about legibility and you are often writing intricate notations and using a wide variety of symbols, I’ve seen little evidence that not using cursive for the longer text blocks has ever slowed me down. On the other hand, I’ve seen a great deal of evidence that cursive is harder to read generally and can lead to significant mistakes as a result.
Personally, I’m content being a dinosaur who writes one letter at a time (in handwriting that has been praised for its neatness and clarity ever since I was at school myself) or uses computers to render the text for me (where I have long had an interest in typography and quite enjoy making pretty text using elaborate cursive fonts, but for special effects and interest, not for body text and legibility).
I find I get significantly more cramping with cursive since there are fewer "rest" periods between the letters than with engineering block gothic lettering. Gothic lettering is much slower than cursive, but much more readable and (IMO) easier to write.
I'm dysgraphic, which probably plays some part in this.
Same story, except that I could stop writing in cursive after middle school as nobody in high school could be bothered to demand it. The only remnants of my cursive writing days are as part of my signature.
If I need to take notes by hand, I definitely prefer cursive writing (though I have my own variations & preferences, for example I write almost all capital letters in the print versions). I never saw a reason to learn to draw a more type-like font by hand, so that definitely feels much worse whenever I decide to do it (e.g. for filling in certain forms).
I don't hate writing in cursive, It's simply that I do it so badly that I use printing for almost everything except my signature. I deeply admire people who write cursive well. It is a beautiful form of communication.
I had a penmanship teacher in high school advise me to use printing because at least she could read it. I suspect that it pained her to give me that advice, but for me it was a gift.
Let me bite, as someone who usually hates JWT but sometimes uses it, including for browser auth.
Why JWT is bad: it's a cargo cult solving a non-existent issue in a more complicated way than necessary. An HTTPOnly session cookie containing just a random ID is shorter and easier to handle.
Why JWT is also bad: a typical way to use it exposes too much attack surface. Almost every JWT library has way too much functionality, supports multiple algorithms, and many people are too sloppy with their dependencies, so you probably haven't read every line of code that runs in your auth.
How to use JWT safely:
1. Have a use case that cannot be easier solved with just a random session identifier. For example, one party creates tokens and another unrelated party verifies them. If same party issues and validates tokens, you better have a super high load, unique use case -- but then you're senior enough to not take random advice from strangers.
2. Write your own JWT handling code. It's literally a few lines of code to create tokens and a few dozen to validate. Only implement the exact algorithms and claims you use.
3. In a typical scenario, JWT should still carry something like a user ID which you should immediately verify against a database. Stateless sessions doesn't mean no DB lookups on validation. If you DO authenticate based on the token alone, the token should be super short lived (seconds or single digit minutes).
We're a fast-growing custom & private loyalty platform powering programs for household-name brands. Small, fully-remote team across the US and Europe.
We want a detail-obsessed, autonomous mid-to-senior engineer (~5–10 yrs) to investigate customer problems, drive integrations end to end, and own the specs that make them work.
You will use AI to its fullest, but will keep a very close eye on whatever that AI produces. As such, this role is less about coding, and more about figuring out what to build, how that best fits into the system, and why things are as they are, debugging edge cases, anticipating failure modes, talking to people, and plain old debugging.
Tech-wise, we're running on Golang, and using custom database engine on top of local key-value stores, colocating the storage and compute on dedicated hardware servers, and reading data directly from mmap'ed pages of the database. Ever came across HN saying that one can run Twitter on a single machine these days? We're doing that in production. Zero lines of React, few third-party dependencies carefully vetted, every line of JavaScript manually written, and we render HTML server-side like it's 2005.
You: detail-oriented to a fault, self-motivated about investigation/debugging work, comfortable spoken English for client calls, available 9am to noon in New York time.
We are straightforward, driven, personal, and a little messy. We all care, and we expect you to care too.
Bubblehouse is a fast-growing custom loyalty platform, tripling the revenue each year. Headquartered in NYC, the entire team is fully remote and spread across the globe. We power loyalty programs for brands like American Girl and Old Spice.
We’re expanding our lean team of extremely experienced developers. Companies are switching from other platforms thanks to the customizations and flexibility that we offer, enabled by our pace and technical excellence, which we intend to keep for years to come.
We run on Golang and use custom data storage on top of local key-value stores, colocating the storage and compute on dedicated hardware servers, and reading data directly from mmap’ed pages of the database. Ever came across HN saying that one can run Twitter on a single machine these days? We’re doing that in production.
Zero lines of React, almost zero third-party dependencies (carefully vetted), every line of JavaScript manually written with respect and understanding of the web platform. We render HTML server-side like it’s 2005.
Looking for:
1. Top to bottom understanding of the software stack, from the modern-ish web platform to CPU caches.
2. Thinking and problem solving outside the box. (We don’t _always_ go for unconventional solutions, but we do it often enough to require a person who can do justice considering the entire problem space at every step.)
3. Demonstrated ability and hunger to learn new things quickly. (Every month we’re doing things we have never done before.)
4. Broad experience across multiple programming paradigms, platforms and software stacks.
5. Demonstrated care for the software craftsmanship (which can take many forms).
6. Great spoken English, and ability to communicate 9am to noon in New York time zone.
We give you a literally fast-paced environment (with features delivered in days) where you need to solve very challenging problems with practical advanced technology, take on entrenched market leaders, and help entrepreneurs across small and large businesses delight their fans.
Send a plain text cover letter to andrey+hiring@bubblehouse.com. Help us see how you stand out. Summarize your experience. Link to 1–5 impressive things you’ve built and proud of, link to where we can see some of your code, include your portfolio/CV, describe the platforms and stacks you’re an expert in. How did you start programming? What are you most passionate about in technology? What are the most interesting or weird things you’ve done? What are your strongest held professional opinions? Please make your email easy to read, we’ll appreciate that.
(If you have applied before, no need to re-apply, we’ll reach out.)
Bubblehouse is a fast-growing custom loyalty platform, tripling the revenue each year. Headquartered in NYC, the entire team is fully remote and spread across the globe. We power loyalty programs for brands like American Girl and Old Spice.
We’re expanding our lean team of extremely experienced developers. Companies are switching from other platforms thanks to the customizations and flexibility that we offer, enabled by our pace and technical excellence, which we intend to keep for years to come.
We run on Golang and use custom data storage on top of local key-value stores, colocating the storage and compute on dedicated hardware servers, and reading data directly from mmap’ed pages of the database. Ever came across HN saying that one can run Twitter on a single machine these days? We’re doing that in production.
Zero lines of React, almost zero third-party dependencies (carefully vetted), every line of JavaScript manually written with respect and understanding of the web platform. We render HTML server-side like it’s 2005.
Looking for:
1. Top to bottom understanding of the software stack, from the modern-ish web platform to CPU caches.
2. Thinking and problem solving outside the box. (We don’t _always_ go for unconventional solutions, but we do it often enough to require a person who can do justice considering the entire problem space at every step.)
3. Demonstrated ability and hunger to learn new things quickly. (Every month we’re doing things we have never done before.)
4. Broad experience across multiple programming paradigms, platforms and software stacks.
5. Demonstrated care for the software craftsmanship (which can take many forms).
6. Great spoken English, and ability to communicate 9am to noon in New York time zone.
We give you a literally fast-paced environment (with features delivered in days) where you need to solve very challenging problems with practical advanced technology, take on entrenched market leaders, and help entrepreneurs across small and large businesses delight their fans.
Send a plain text cover letter to andrey+hiring@bubblehouse.com. Help us see how you stand out. Summarize your experience. Link to 1–5 impressive things you’ve built and proud of, link to where we can see some of your code, include your portfolio/CV, describe the platforms and stacks you’re an expert in. How did you start programming? What are you most passionate about in technology? What are the most interesting or weird things you’ve done? What are your strongest held professional opinions? Please make your email easy to read, we’ll appreciate that.
(If you have applied before, no need to re-apply, we’ll reach out.)
Hey, I'm sorry, but your Postgres example is completely wrong: because of MVCC, a new version of the data will be stored on every update regardless of the choice of data representation, making the in-place mutability much less of an advantage. (It might be faster than a pair of a compact immutable format + mutable patch layer on top, or it might be slower; the answer ain't immediately obvious to me!)
What you should be imagining instead is a document database entirely built around Lite³-encoded documents, using something like rollback journals instead of MVCC.
We're doing something similar in my company, storing zero-serialization immutable [1] docs in a key-value store (which are read via mmap with zero copying disk-to-usage) and using a mutable [2] overlay patch format for updates. In our analytics use cases, compact storage is very important, in-place mutability is irrelevant (again because of Copy-on-Write at the key-value store level), and the key advantage is zero serialization overhead.
What I'm saying is that Lite³ is a very timely and forward-looking format, but the merging of immutable and mutable formats into one carries tradeoffs that you probably want to discuss, and the discussion into the appropriate use cases is very much worth having.
Hi, you are right in calling out the Postgres example in the context of DBs/MVCC. The purpose of JSONB is to be an indexable representation of JSON inside a Postgres database. It is not trying to be a standalone format for external interchange and therefore it is fulfilling very different requirements.
A serialization format does not care about versioning or rollbacks. It is simply trying to organize data such that it can be sent over a network. If updates can be made in-place without requiring re-serialization, then that is always a benefit.
Write amplification is still a fact however that I think deserves to be mentioned. To tackle this problem in the context of DBs/MVCC, you would have to use techniques other than in-place mutation like you mention: overlay/COW. Basically, LMDB-style.
And yes I think databases is where this technology will eventually have the greatest potential, so that is where I am also looking.
Bubblehouse is a fast-growing custom loyalty platform, tripling the revenue each year. Headquartered in NYC, the entire team is fully remote and spread across the globe. We power loyalty programs for brands like American Girl and Old Spice.
We’re expanding our lean team of extremely experienced developers. Companies are switching from other platforms thanks to the customizations and flexibility that we offer, enabled by our pace and technical excellence, which we intend to keep for years to come.
We run on Golang and use custom data storage on top of local key-value stores, colocating the storage and compute on dedicated hardware servers, and reading data directly from mmap’ed pages of the database. Ever came across HN saying that one can run Twitter on a single machine these days? We’re doing that in production.
Zero lines of React, almost zero third-party dependencies (carefully vetted), every line of JavaScript manually written with respect and understanding of the web platform. We render HTML server-side like it’s 2005.
Looking for:
1. Top to bottom understanding of the software stack, from the modern-ish web platform to CPU caches.
2. Thinking and problem solving outside the box. (We don’t _always_ go for unconventional solutions, but we do it often enough to require a person who can do justice considering the entire problem space at every step.)
3. Demonstrated ability and hunger to learn new things quickly. (Every month we’re doing things we have never done before.)
4. Broad experience across multiple programming paradigms, platforms and software stacks.
5. Demonstrated care for the software craftsmanship (which can take many forms).
6. Great spoken English, and ability to communicate 9am to noon in New York time zone.
We give you a literally fast-paced environment (with features delivered in days) where you need to solve very challenging problems with practical advanced technology, take on entrenched market leaders, and help entrepreneurs across small and large businesses delight their fans.
Send a plain text cover letter to andrey+hiring@bubblehouse.com. Help us see how you stand out. Summarize your experience. Link to 1–5 impressive things you’ve built and proud of, link to where we can see some of your code, include your portfolio/CV, describe the platforms and stacks you’re an expert in. How did you start programming? What are you most passionate about in technology? What are the most interesting or weird things you’ve done? What are your strongest held professional opinions? Please make your email easy to read, we’ll appreciate that.
(If you have applied before, no need to re-apply, we’ll reach out.)
reply