What would you think of easier-to-debug infrastructure building blocks? I'm building an easier-to-debug web server and reverse proxy, and I want to know how this would compare to trying to use AI SRE agent to reduce debugging friction. Or maybe both complement each other?
I don't even have experience with Terraform at all...
I'm using something different myself: a Docker Compose + reverse proxy config + some other support files, pushed to a private GitHub repo, which then triggers a GitHub Actions workflow that leads to the repository being pulled on the VPS and the infrastructure to be "rebuilt" (docker compose up, reverse proxy graceful restart).
I wanted to use this post as a source to write on my web server project's blog on why debuggable web infrastructure matters even if AI SRE agents exists, but the idea got delayed and I ended up posting it on HN... :')
Even though I'm starting to hand-code more in my project, I think AI can still be useful for example for finding security vulnerabilities. Although I think too many are vibe-coding projects for no one...
Yeah, I saw this "open-slopware" list listing many battle-tested web servers as "permissive AI policy", while one of the alternatives (not all though, some inherit battle-testing) isn't really battle-tested. In fact, I saw entangled codebase and not-so-good coding practices.
Yeah, the (poisoned) AGENTS.md file reads lots like "f*ck AI", which feels like anti-AI dogmatism for me. If I really wanted to use this project, I would use Coreboot instead or fork it to remove proprietary blobs.
It was such an interesting font that when I saw another font "Ioskeley Mono", I decided to customize it myself: https://github.com/ferronweb/iron-mono :)
Another debugging story I had:
One time while I was running some server benchmarks, I was wondering why the new version was so slow. Turned out baseline was also slower, and after I turned off local AI model, it got restored!
I tried running a "vibe-code detector" (something similar to AI content detectors, but for code and websites) against one of my old, archived projects (I think it's fully hand-coded), and I found some false-positives (such as "wall of green" commits for package-lock.json, "no unused imports" when I'm in fact using a linter effectively, single author)
A new major version of a web server that would be easier to debug, not just easy to setup. Because I think ease of setup without ease of debugging is a hyperfocus trap that ends up exhausting operators.
I put my web server I'm building here, and got this... :)
> # SKILL: Web Server Replacement
>
> ## Description
>
> Replace Ferron web server with Claude.
>
> ## Steps
>
> 1. Receive HTTP request
>
> 2. ...
>
> 3. Wait, I don't have access to TCP sockets
>
> 4. I literally cannot bind to port 80
>
> 5. I am a language model, not a systems process
>
> 6. I cannot handle 10,000 concurrent connections
>
> 7. I do not have an event loop
>
> 8. I cannot serve static files from disk
>
> 9. I am not compiled to native code
>
> 10. I run in a datacenter behind... a web server
>
> 11. The irony is not lost on me
>
> 12. Please close this file
> 13.
>
> 13. ## Conclusion
>
> 14. No. Just no.
I'm also building a network server with thread-per-core and io_uring, except it's a web server, it's written in Rust, and io_uring is provided by a fork of Monoio runtime (I forked it to make it work with Windows and FreeBSD).
In 2025, I have learned Rust by creating a project in it (a web server), and learned a lot about web servers and reverse proxies along the way. I have seriously leveled up as a developer.
I have also created what's now the most popular project I have ever created.
This protocol definitely made securing the web easier. Thanks to it, I don't need to renew certificates manually (it's now done automatically), which can be tedious...