fpereiro

> It's all pretty decent and better than chiselling coal out of a pit for 10 hours a day.

Your comment has made my day, perhaps my week. Well said.

> By 2 pm, I was mentally destroyed. Not tired in the way you get after a hard day of focused coding. Destroyed in the way you feel after four hours of air traffic control.

Excellent article.

@reachableceo thanks for checking it out! Hope it's useful to you. Send any feedback my way any time!

Great point. The thing is that most code we write is not elegant implementations of algorithms, but mostly glue or CRUDs. So LLMs can still broadly be useful.

I think that we can already experience a revolution with LLMs that are not fully autonomous. The potential is that an engineering-like approach to a prompt flow can allow you to design and review (not write) a lot more code than before. Though you're 100% correct that the analogy doesn't strictly hold until we can stop looking at the code in the same way that a js dev doesn't look at what the interpreter is emitting.

Mario Zechner has a very interesting article where he deals with this problem (https://mariozechner.at/posts/2025-06-02-prompts-are-code/#t...). He's exploring how structured, sequential prompts can achieve repeatable results from LLMs, which you still have to verify. I'm experimenting with the same, though I'm just getting started. The idea I sense here is that perhaps a much tighter process of guiding the LLM, with current models, can get you repeatable and reliable results. I wonder if this is the way things are headed.

@manuelabeledo: during 2025 I've been building a programming substrate called cell (think language + environment) that attempts to be both very compact and very expressive. Its goal is to massively reduce complexity to turn general purpose code more understandable (I know this is laughably ambitious and I'm desperately limited in my capabilities of pulling through something like that). But because of the LLM tsunami, I'm reconsidering the role of cell (or any other successful substrate): even if we achieve the goal, how will this interact with a world where people mostly write and validate code through natural language prompts? I never meant to say that natural language would itself be this substrate, or that the combination of LLMs and natural languages could do that: I still see that there will be a programming language behind all of this. Apologies for the confusion.

Hi HN! OP here. Thanks for reading and commenting -- (and @swah for posting!). It's unsettling to hit the HN front page, and even more so with an article that I hastily wrote down. I guess you never know what's going to hit a nerve.

Some context: I'm basically trying to make sense of the tidal wave that's engulfing software development. Over the last 2-3 weeks I've realized that LLMs will start writing most code very soon (I could be wrong, though!). This article is just me making sense of it, not trying to convince anybody of anything (except of, perhaps, giving the whole thing a think). Most of the "discarded" objections I presented in the list were things I espoused myself over the past year. I should have clarified that in the article.

I (barely) understand that LLMs are not a programming language. My point was that we could still think of them as a "higher level programming language", despite them 1) not being programming languages; 2) being wildly undeterministic; 3) also jumping levels by them being able to help you direct them. This way of looking at the phenomenon of LLMs is to try to see if previous shifts in programming can explain at least partially the dynamics we are seeing unfold so quickly (to find, in Ray Dalio's words, "another kind of those").

I am stepping into this world of LLM code generation with complicated feelings. I'm not an AI enthusiast, at least not yet. I love writing code by hand and I am proud of my hand-written open source libraries. But I am also starting to experience the possibilities of working on a higher level of programming and being able to do much more in breadth and depth.

I fixed an important typo - here I meant: "Economically, only quality is undisputable as a goal".

Responding to a few interesting points:

@manuelabeledo: during 2025 I've been building a programming substrate called cell (think language + environment) that attempts to be both very compact and very expressive. Its goal is to massively reduce complexity to turn general purpose code more understandable (I know this is laughably ambitious and I'm desperately limited in my capabilities of pulling through something like that). But because of the LLM tsunami, I'm reconsidering the role of cell (or any other successful substrate): even if we achieve the goal, how will this interact with a world where people mostly write and validate code through natural language prompts? I never meant to say that natural language would itself be this substrate, or that the combination of LLMs and natural languages could do that: I still see that there will be a programming language behind all of this. Apologies for the confusion.

@heikkilevanto & @matheus-rr: Mario Zechner has a very interesting article where he deals with this problem (https://mariozechner.at/posts/2025-06-02-prompts-are-code/#t...). He's exploring how structured, sequential prompts can achieve repeatable results from LLMs, which you still have to verify. I'm experimenting with the same, though I'm just getting started. The idea I sense here is that perhaps a much tighter process of guiding the LLM, with current models, can get you repeatable and reliable results. I wonder if this is the way things are headed.

@woodenchair: I think that we can already experience a revolution with LLMs that are not fully autonomous. The potential is that an engineering-like approach to a prompt flow can allow you to design and review (not write) a lot more code than before. Though you're 100% correct that the analogy doesn't strictly hold until we can stop looking at the code in the same way that a js dev doesn't look at what the interpreter is emitting.

@nly: great point. The thing is that most code we write is not elegant implementations of algorithms, but mostly glue or CRUDs. So LLMs can still broadly be useful.

I hope I didn't rage bait anybody - if I did, it wasn't intentional. This was just me thinking out loud.

For what it's worth, I believe that shaming is generally not helpful. For people to step out of a difficult situation, they need to be empowered. They will probably find your help more useful than you shaming them, or at least your sympathy. At least that's how I see it.

Hi HN! OP here. Thank you everyone for reading and commenting. Thanks to your feedback I have done the following edits to the post:

- Added a comment on GLP-1 agonists. I wrote the article like it was 2023, not 2025. These drugs now exist and their benefits massively outweigh their drawbacks, particularly for people that really need help. Anything that helps out of the trap, particularly with this effectiveness, should be front and center. Thank you for pointing it out.

- Added a comment on my take on the usefulness of exercise for this process. I don't believe in exercise as a calory burner, but as something you need in order to be strong, fit, flexible and feel better mentally. It supports you in your journey. Exercise in order to burn calories to get lean is counterproductive. It is a thick wall of the mental fat trap.

- I realize that my struggles (and I don't say this lightly) have been a small fraction of what many of you had to go through, or are still going through. I also mentioned this in the article now. For some, it can be ten, a hundred, a thousand times harder than for others to break free from being overweight and be able to regulate their food in a way that is mentally healthy.

- I also added this: "Incidentally, I don't think this is about willpower (this is another parallel with Carr's insight). The decision to change comes from a deeper source. When I was most obsessed about asserting willpower over my eating, I was having the worst time and making bad choices. Getting out involves awareness, work, and a willingness to fail and keep on trying. The authors above say it much better than I can."

Hope again this was helpful for those with like struggles.

Hi HN! OP here. I would have never expected to find interest here for ultra running. But of course there is -- thanks for the comments!

@n4r9: I avoid peanuts because I find them somewhat allergenic. I'll update the post.

ekr____: regarding fat, I think it's a personal thing. I get really tired of getting my calories through carbs when ultra running. I find it quite easy to scarf down 2000-3000kcal of nuts and they seem to sit well. But then again, I'm a slow runner (even by ultra standards). Also, indeed, the 30k stops are for a context with no race organization (no drop bags) where there's always a supermarket nearby.

@swah: thanks for posting! Stopping every 30k sounds crazy because it is crazy. But crazy is what ultra is, after all. I'm currently trying to "get used" to run 100k. In that context, carrying supplies for 30-40k (4-5 hours of running/shuffling) is reasonable. Stopping too often gives me more opportunities to get distracted, burn time and give up sooner than I would have otherwise.

Hi there -- I'm the OP of the article.

> If you were my boss I'd be putting on my parachute and heading for the airstairs and expecting to see a plume of smoke wherever you impact.

(Ouch!)

You raise an interesting point. Perhaps, without a large amount of "bin #2" work, it's impossible for "bin #1" work to really take off. I've experienced this firsthand, and end up always doing a lot of "bin #2". But I wonder how much better it could be if I dared to focus even further. Or if it's at all possible and I'm just risking it too much.

Do you have any examples of the 80/20 idea actually killing a startup? I'm genuinely interested.

Thanks for commenting!

@swah, thanks for posting!

Thanks for the reply!

Thanks for the reply!

This could be interesting. My team works with Tailwind and we don't have a workflow that brings anything from Figma into Tailwind. So basically, we put Figma and our Tailwind prototype side by side, and make the latter converge to the former by trial and error.

I just burst out laughing with your last sentence.

Great tip about Google Cloud! I would never have thought of that one. I'll check it out.

Hi! Arriving a bit late to the party...

We're building ac;pic, a cloud-based service that saves and organizes your pivs (pictures & videos). These are the things we do differently from most of what's out there:

- We use tags, not albums, as the organizational principle. Tags are associative; albums are hierarchical and resemble traditional folder structures (and a file cannot be in two folders at the same time).

- We tackle the overwhelm produced by having tens of thousands of pivs. We aim to replace that overwhelm by an "arcade" feeling, that makes the hard into easy and the easy into trivial.

- We identify duplicated pics & videos regardless of filename or metadata.

- We are a cloud service, but all our code is open source (https://github.com/altocodenl/acpic).

- We charge with a fixed + variable subscription model. The fixed part helps to maintain our fixed costs (salaries, working capital, etc), the variable is what every user pays for space used - at cost, we don't mark up storage prices.

- We use no AI; if we implement some AI in the future, it will be strictly opt-in.

- We allow import from Google Drive & Dropbox, as well as upload from all devices.

- We don't own your data, we only safeguard it. Exporting and importing all your data from and into our service is done as easily as possible.

If you're interested in using ac;pic, you can check it out and request an invite for the upcoming beta at https://altocode.nl/pic/ We'll send you an invite when the app is ready. Our horizon for release is measured in months.

If you're developing another solution that solves the same problem or works in the same area: feel free to contact us and share your experience; or browse our repo to see how we do things. Perhaps we were able to solve a problem that you were trying to solve yourself; our code is public domain, so you can borrow whatever you want from it. We're interested in solving the problem, not necessarily being the only ones that solve it.

Beautiful answer, thank you!

Since I want to support as many browsers as possible, I'm going to still use CSRF tokens, but a single token per session as you suggested. I just outlined the approach here: https://news.ycombinator.com/item?id=22268152 .

Thanks for your detailed feedback, it's very valuable to me.

It looks like Lua is the main scripting language; which is a fine choice by me; the few times I worked on redis transaction scripting in Lua (since Lua is the language for doing that) the experience was very pleasant.

Are you building a project (or projects) on OpenResty?

I stand corrected, you're right! I hadn't heard about OpenResty.

It's amazing that this exists, I would have never thought it possible (because of what I saw as inherent limits in what can be expressed in terms of nginx configuration), but now that I see it, of course it is :). From what I gather, custom code can be written as Lua scripts, and many of the modules are written in Lua themselves.

Thank you for sharing this!

I added recently a bit more of detail in the document explaining when I would use redis (and when I wouldn't) to build production systems, here: https://github.com/fpereiro/backendlore#redis . For most applications, I think it's a viable alternative.

Modeling data with redis is great fun, and quite different to the relational paradigm. I hope you enjoy a lot your upcoming project!

Before your comment I didn't know about the existence of KeyDB, but now I do - thank you for that!

My main issue with scaling Redis is not performance or throughput, but doing it in a controlled, understandable manner which maintains consistency and ideally controlling what information goes on which node. In any case, it's great to find out about KeyDB. Thanks!

I don't think it is at all possible to use nginx to write application logic otherwise than serving static files and perhaps doing some URL transformations. node gives you a full programming language that's necessary for implementing an API.

That's a good question. I'm going to try first with Hetzner and measure latencies from different places; if this becomes an issue, I'll definitely consider complementing the infrastructure from elsewhere. But I'd rather start simple.

I currently run a web service from North American servers and the performance here in Europe is quite good. I think this experience - very, very limited - gives me confidence that the wires across the world are good enough, provided your data center is close to the main pipes.

I've never really tried, but it looks like lists and hashes could be implemented in Postgres through json blobs. That would still leave out sets and zsets, which I also find essential in most work I do with Redis.

Besides having all the data structures, I love just connecting to Redis without specifying a database name (there's just a database number, which defaults to 0), a database user, or needing to create a table or a schema. Redis is, so to speak, just there. Not saying this is better than Postgres objectively - I just like it more.

This is not an easy question to answer, but in my experience it pays off to ponder it carefully.

So far, the heuristic that seems to work better for me is to keep the overall surface of the app small and try to keep everything in a single app. Lately, however, I'm convinced that extracting parts of the code as separate services (in particular, for handling users, logs, and statistics) would make the overall structure simpler. Dissecting this a little bit, an external user service is equivalent to middleware, whereas logs and statistics are write-only, after-the-fact side effects (from the perspective of the app), so bidirectional interaction with them is not needed for the purposes of serving a particular request. What I try to avoid is to have a server route that involves (necessarily) asynchronous logic between services to check the consistency of an operation.

In terms of "business logic", I feel that whatever lies within a transactional boundary should be in the same service; i.e., if two users share a resource, both the information of who owns the resource and who can access the resource should be in the same service. But I suspect there might be a lot more of thinking to be done in this regard.

Using websockets for a collaborative app makes all the sense in the world (incidentally, I realize I've never written one an app of that kind).

My pleasure! Being part of this thread has been an amazing learning experience.

Redis gives you fundamental data structures (lists, sets, hashes - plus a few other like zsets and hyperloglogs) that represent a powerful way of expressing computation. I'm not acquainted with the full spectrum of Postgres' data structures, so I cannot do a fair comparison; all I can say is that Redis is awesome and I can't get enough of it.

Glad you find them interesting!

As for a redis-like disk-first database, it would be amazing, but I don't know if it is really possible (unless performance was severely sacrificed). This could be an interesting area to explore.