Hacker News: bittermandel

New comment by bittermandel in "The 100 hour gap between a vibecoded prototype and a working product"

bittermandel — Sun, 15 Mar 2026 18:18:13 +0000

This is exactly my experience at Lovable. For some parts of the organization, LLMs are incredibly powerful and a productivity multiplier. For the team I am in, Infra, it's many times distraction and a negative multiplier.

I can't say how many times the LLM-proposed solution to a jittery behavior is adding retries. At this point we have to be even more careful with controlling the implementation of things in the hot path.

I have to say though, giving Amp/Claude Code the Grafana MCP + read-only kubectl has saved me days worth of debugging. So there's definitely trade-offs!

New comment by bittermandel in "The Om Programming Language"

bittermandel — Wed, 25 Feb 2026 19:11:18 +0000

I confused this with https://github.com/omcljs/om

New comment by bittermandel in "Show HN: Gemini Pro 3 imagines the HN front page 10 years from now"

bittermandel — Tue, 09 Dec 2025 21:01:39 +0000

I made this with Lovable as well, it's interesting how it's a bit more extreme in terms of where we are in 2035.

https://hn-frontpage-2035.lovable.app/

> The last JavaScript framework: Why we stopped at React 47 (overreacted.io)

New comment by bittermandel in "AI documentation you can talk to, for every repo"

bittermandel — Tue, 11 Nov 2025 08:34:05 +0000

I use this heavily to navigate the neondatabase/neon repo and it has been invaluable

New comment by bittermandel in "Writing a storage engine for Postgres: An in-memory table access method (2023)"

bittermandel — Fri, 08 Aug 2025 12:24:35 +0000

Neon does a variant of this. The WAL goes through a Paxos consensus directly on NVMe, which then is transformed to page files and stored in Object Storage

Show HN: Kubernetes Operator for Neon Postgres

bittermandel — Thu, 07 Aug 2025 09:04:35 +0000

We're happy to announce an early version of https://github.com/molnett/neon-operator, a Kubernetes operator that allows you to self-host Neon on your own infrastructure. This is the culmination of our efforts to understand the internal details of Neon, and we're excited to share our findings with the community!

Comments URL: https://news.ycombinator.com/item?id=44822248

Points: 9

# Comments: 1

1990–1994 Swedish financial crisis

bittermandel — Mon, 28 Jul 2025 19:50:07 +0000

Article URL: https://en.wikipedia.org/wiki/1990%E2%80%931994_Swedish_financial_crisis

Comments URL: https://news.ycombinator.com/item?id=44714784

Points: 2

# Comments: 0

How TPMs Work and Why We Added Support in Bottlerocket

bittermandel — Thu, 17 Jul 2025 14:21:03 +0000

Article URL: https://molnett.com/blog/25-07-16-bottlerocket-part2-tpm-additions

Comments URL: https://news.ycombinator.com/item?id=44593755

Points: 1

# Comments: 0

New comment by bittermandel in "Happy 20th Birthday, Django"

bittermandel — Mon, 14 Jul 2025 14:59:40 +0000

Django was the whole start of my career and I still thank it for many of my opportunities. I started in 2012 to work with Django at Billogram, then founded a Django consultancy which lead me to work at King 3 years later.

Who knows where I would be today if not for Django!

New comment by bittermandel in "Show HN: Sumble – knowledge graph for GTM data – query tech stack, key projects"

bittermandel — Tue, 08 Jul 2025 17:34:19 +0000

I just tried this. HOLY CRAP its good. How did you achieve this? I'm very impressed.

Also: Please don't evolve the UI. Its perfect as it is

Adding a UI to a Container Registry Is Not Simple

bittermandel — Tue, 08 Jul 2025 15:34:34 +0000

Article URL: https://molnett.com/blog/25-07-07-container-registry-story-part-1

Comments URL: https://news.ycombinator.com/item?id=44500996

Points: 1

# Comments: 0

Adding a UI to a Container Registry Is Not Simple

bittermandel — Mon, 07 Jul 2025 13:21:44 +0000

Article URL: https://molnett.com/blog/25-07-07-container-registry-story-part-1

Comments URL: https://news.ycombinator.com/item?id=44490120

Points: 1

# Comments: 0

Trusting the Boot Process: Inside Bottlerocket's Security Architecture

bittermandel — Thu, 03 Jul 2025 08:41:20 +0000

Article URL: https://molnett.com/blog/25-06-30-trusting-the-boot-process

Comments URL: https://news.ycombinator.com/item?id=44452938

Points: 1

# Comments: 0

Trusting the Boot Process: Inside Bottlerocket's Security Architecture

bittermandel — Tue, 01 Jul 2025 12:02:18 +0000

Article URL: https://molnett.com/blog/25-06-30-trusting-the-boot-process

Comments URL: https://news.ycombinator.com/item?id=44433019

Points: 2

# Comments: 0

Trusting the Boot Process: Inside Bottlerocket's Security Architecture

bittermandel — Mon, 30 Jun 2025 10:17:29 +0000

Article URL: https://molnett.eu/blog/25-06-30-trusting-the-boot-process

Comments URL: https://news.ycombinator.com/item?id=44421499

Points: 1

# Comments: 0

New comment by bittermandel in "Ask HN: What Are You Working On? (June 2025)"

bittermandel — Mon, 30 Jun 2025 08:52:18 +0000

We're working on a Container Registry for https://molnett.com. We don't really want to use Harbour as we want to manage our own AuthN/AuthZ and are fully multi-tenant, so we decided to build our own on top of Distribution.

Going from Manifest to OCI is a bit tricky and performance for calculating total storage based on metadata is hard to get right. But the result is that we own our full registry implementation and can take it any direction we want. Quite happy with that!

How Long Contexts Fail

bittermandel — Mon, 30 Jun 2025 08:20:18 +0000

Article URL: https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html

Comments URL: https://news.ycombinator.com/item?id=44420775

Points: 1

# Comments: 0

New comment by bittermandel in "The Ingredients of a Productive Monorepo"

bittermandel — Wed, 28 May 2025 12:14:43 +0000

I don't think you are wrong at all. As we are all founders with an OK salary and this is our area of expertise, so we're able to take advantage of our previous experiences and reap the benefits. We're probably uniquely positioned here.

I had massive issues at my previous employer with Bazel. They did not try to make Bazel work for non-SREs, which as you can imagine didn't work very well. So it's definitely not a silver bullet!

We should probably write a blog post about our setup!

New comment by bittermandel in "The Ingredients of a Productive Monorepo"

bittermandel — Wed, 28 May 2025 12:10:33 +0000

I think this take is quite shallow and lacks insight into how one would actually build a somewhat complex technical platform.

We are not using a microservice pattern at all. I am not sure where you get that from. If anything we have several "macro services".

Our final setup is quite complex as we are building a literal cloud provider, but in practice we have a Go API, a Docker registry, a Temporal Worker and a Kubernetes controller. Whats complicated is everything else around it. We run our platform on bare-metal and thus have auxiliary services like a full-blown Kubernetes cluster, Ory Hydra + Kratos, SpiceDB, Cilium, Temporal Cluster + Workers and some other small things. We need to be able to test this locally to feel safe to release to production. And in turn our production environment is almost identical to our local environments.

None of that would be possible unless we've done something similar to what we have built today. Most companies cannot run their entire stack on their laptop, more unlikely that they could run a full cloud provider.

New comment by bittermandel in "The Ingredients of a Productive Monorepo"

bittermandel — Wed, 28 May 2025 09:55:14 +0000

I firmly believe that us at Molnett(serverless cloud) going for a strict monorepo built with Bazel has been paramount to us being able to make the platform with a small team of ~1.5 full-time engineers.

We can start the entire platform, Kubernetes operators and all, locally on our laptops using Tilt + Bazel + Kind. This works on both Mac and Linux. This means we can validate essentially all functionality, even our Bottlerocket-based OS with Firecracker, locally without requiring a personal development cluster or such.

We have made this tool layer which means if I run `go` or `kubectl` while in our repo, it's built and provided by Bazel itself. This means that all of us are always on the same version of tools, and we never have to maintain local installations.

It's been a HUGE blessing. It has taken some effort, will take continuous effort and to be fair it has been crucial to have an ex Google SRE on the team. I would never want to work in another way in the future.

EDIT: To clarify, our repo is essentially only Golang, Bash and Rust.