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.
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).
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 [email protected]. 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 [email protected]. 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.
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 [email protected]. 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.)
I believe “vast manority” may be a stretch; do you happen to know if there’s a way to quantify that? In my bubble, almost everyone that I personally know and who generally has reasonable beliefs, is on the Israel’s side of this conflict.
I’m not sure if you’re actually asking or not, but in case you want to hear an answer, it’s because Israel is considered to be defending itself after a horrible attack, not that dissimilar to Ukraine really in some people’s view (me included). This goes back to a worldview where residents of a country share a portion of the blame for their country’s actions. This view is not universal, but has a certain mindshare (again, myself included), and if you imagine it fair for residents of a place to share the fate caused by the cumulative actions of that place, it’s not a big stretch to see how Israel’s actions can be considered natural and just by some, and so can the sanctions against residents of Iran and Russia.
Bubblehouse is a fast-growing custom and private loyalty platform. Headquartered in NYC, the entire team is fully remote and spread across US and Europe. We power loyalty programs for large brands, including household names.
We’re again 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.
Tech-wise, we’re running on Golang, and using 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 [email protected]. 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 provides a white-glove, custom loyalty platform tailored for e-commerce brands — from small enthusiast shops to large enterprises (for example, we're powering loyalty for one of Mattel's brands). We're fast, lean, and love solving niche loyalty challenges.
We need a reliable Magento/PHP freelancer to tackle occasional Magento 2 tasks related to our Magento integration and problem solving for clients. You’ll be our go-to person for ongoing development and problem-solving related to our Magento integration module.
The ideal candidate:
- Has solid hands-on experience with Magento 2 internals (custom modules, observers, integrations).
- Writes clean, modern PHP, uses Composer & Git confidently.
- Knows how to diagnose tricky Magento issues.
- Can overlap partially with our team between 9 am – noon New York time for quick check-ins while actively engaged on our tasks.
- Can self-direct, communicate clearly, and invoice cleanly.
Work style:
- Fully remote, async-first. Occasional calls only as needed, we hate unnecessary calls.
I think your example is perfect. What he gave you is not a complete answer to why, because, as you say, he might have been doing a number of other jobs. So why roofs specifically? Add the description of how he inherited his father’s carpenter business but whenever he visited clients, they all had leaky roof, yadayada, and that he now feels happy enough to not look for any further changes, and you get the kind of answer OP is looking for.
Bubblehouse (bubblehouse.com) is a fast-growing custom and private loyalty platform for Shopify and beyond. Headquartered in NYC, the entire team is fully remote and spread across US and Europe.
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.
Tech-wise, we’re running on Golang, and using 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, and use Tailwind as a design language powering our custom theming engine.
We’re no enterprise company internally, but we power loyalty programs for large enterprises (as well as small enthusiast shops — this entire industry is woefully underserved).
We’re 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. (Not looking for someone who’s just a narrow expert.)
5. Demonstrated care for the software craftsmanship (which can take many forms, including side-, open-source or primary work projects, teaching, or simply playing with the latest tech).
6. Great spoken English (we value our communication beyond simple ability to convey crucial information).
7. Ability to communicate around 9am to noon time in New York time zone.
In return, we give you an environment where we solve very challenging problems with practical advanced technology in a lean and literally fast-paced environment (with features delivered in days) while successfully taking on entrenched market leaders and helping people across small and large businesses be more successful while pursuing their dreams.
Send your plain text cover letter to [email protected] (our CTO will read & respond personally). Help us see how you stand out. Summarize your experience. Perhaps link to 1–5 impressive things you’ve built and proud of, link to where we can see some of your code (or attach some), 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.
Transmit is a file transfer app; it's used to get access to existing files on your own Google Drive without installing Google Drive's native app. Limiting it to a subfolder would defeat what I believe to be the most common use case.
Here’s practical experience from me running the tech side of a startup while sharing the author’s values.
Server-side rendering (the normal kind from 1990s):
1. It is glorious. Everything that 37signals has to say about it is true.
2. However. I really miss React-style components as an abstraction. There are many ways around it that we use depending on the case (plain CSS classes, our own tiny Go/HTML component library, HTML custom tags), but we’re yet to produce something as ergonomic for more complex compositions.
3. We’ve added Hotwired Turbo for smoother page updates. I find it’s a lot more orderly than htmx, but we do miss some things that htmx would offer.
CSS:
1. We started out with just plain CSS, using BEM and CUBE to structure it and manage complexity.
2. That still got us questioning the DIY nature of the U (utilities) part of CUBE — it got increasingly complex and random, and really just like every program grows a broken LISP interpreter inside, every custom CSS utilities library grows a broken copy of Tailwind inside. So we adopted the actual Tailwind for utilities. Tailwind is truly glorious, both for sheer productivity of writing the code, but also as a language for describing styling at just the right amount of detail — more powerful than CSS properties alone (hover:color-red-700, disabled:cursor-default), but more constrained than full CSS.
3. Tailwind introduces a build step, though, which sucks (and slows down the build by the whole second! My m2 Air can probably do a 60s supercomputer-level nuclear explosion simulation during that time.) Thankfully, part of our startup is doing custom themes for each client, for which actual Tailwind sucks even more (themes are edited at runtime, and you wouldn’t want to run actual Tailwind with its million Node dependencies on your server), so we’ve implemented a subset of Tailwind in Go, just the things we actually used, and it runs at runtime, eliminating any build steps for themes.
4. Bottom line: Tailwind is absolutely glorious as a shared design vocabulary. Non-tech people were able to adopt it and handle theming thanks to it. The actual implementation of Tailwind seems unacceptably slow, but I hear a Rust compiler is coming.
JavaScript:
1. Plain old JavaScript is great, but needs some structure. We found that structure in Hotwired Stimulus, which we absolutely love.
2. But again, I do feel the desire for React-style rendering occasionally. We embed our widgets on customers’ e-commerce sites, and a chunk of HTML rendered based purely on data coming from an API with live updates is a perfect case for React.
3. Needless to say, running code on other people’s e-commerce sites is where I would never dare use a React-based stack, because I’d spend the rest of my life doing due diligence on the dependencies. (Our competitors are much less responsible about this, and it works out for them too, so this is more of a principles thing.)
4. This is probably the case where an in-house 500-line implementation of React-style rendering would be preferable to anything else. We already have a 100-line version, but it lacks many desirable features.
Bottom line: Yes, you can (and should) run a modern startup based on a pragmatic server-side rendered stack, but you definitely want to add just a few modern things: something like Hotwired, something like Tailwind, some solution for more powerful components in your templates, and something like Preact for certain use cases.
A very under appreciated aspect of Telegram’s protocol is that it’s designed by very, very weird people. Telegram scooped up a lot of winners of ACM ICPC contests in Russia, some of whom I’ve personally met, and the design of the protocol is exactly in line with the code these people generally write.
It’s really a showcase of how very high IQ and outstanding mathematical abilities mix with a distrust of existing technologies and a lack of expert intuition coming from more normal industry experience.
Just try implementing MTProto, or at least read the low-level docs, and you’ll see for yourself. Crypto isn’t the weirdest part. The whole thing is an attempt to define a binary protocol in terms of grandiose mathematical concepts most of which didn’t even end up ever used in the actual protocol. And there’s zero thought given to what’s actually important, making a bullet-proof syncing between server and client states (and that results in numerous bugs to this day).
Can’t discount malice, but I don’t believe that’s the case.
Maker of LiveReload, CTO of Bubblehouse, focused on startups and startups-within-enterprises my whole life.
Email: [email protected]
meet.hn/city/ge-Tbilisi
Socials: - t.me/andreyvit - github.com/andreyvit - instagram.com/andreyvit
Interests: Entrepreneurship, Mentorship, Mobile Development, Open Source, Remote Work, Startups, Web Development, Writing, Marketing, AI/ML
---