526 karma · joined July 19, 2025
"In knowledge work the bottleneck is not the external availability of information. It is the internal bandwidth of processing power which is determined by your innate abilities and the training status of your mind."
"Let's get straight to the point: I didn't “code” a single line of the website... I only prompted Cursor.
BUT I prompted him, knowing what I wanted and, above all, what I did NOT want.
I was very methodical in the project, first asking him to create a simple front page using the colors I had explicitly provided him with.
For example, I had to specify that he should use a minimal CSS framework, not use a JavaScript framework, and use simple HTML to start with.
If you let the “AI” get excited, it will very quickly pull up “Ok, let's start a project with Vue.js” ... Hold on, buddy. I want a simple page, just with HTML and Pico CSS that’s all."
"Yet I suspect that vibe writing will be no more successful than vibe coding, in large measure because reading itself is becoming a lost art. Furthermore, since writing is a form of thinking, if you haven't developed the skill of formalized thinking through writing and reflective reading then your interaction with an AI chatbot will essentially be nothing more than vibe thinking."
For messaging, JSON, used in the same way and with the same versioning practices as we have established for evolving schemas in REST APIs, has never failed me.
It seems to me that all these rigid type systems for remote procedure calls introduce more problems that they really solve and bring unnecessary complexity.
Sure, there are tradeoffs with flexible JSONs - but simplicity of it beats the potential advantages we get from systems like Avro or ProtoBuf.
Other than that the discovery process of what you should build is the hardest and the costliest part, the main conclusion from the article seems to be that if you outsource the first iterations to AI via vibe-coding, you will have much harder time changing and evolving it from there (iterating); to this, I agree
The one thing I don't necessarily agree:
"Privileged ports in rootless mode not working? Good! That's security working as intended. A reverse proxy setup is a better architecture anyway."
I usually use Ngix as a reverse proxy - why not have it set up in the exact same way as the rest of your apps? That's a simplicity advantage. So with Podman, I would just run this one exact container in root mode - that's still better than all of them, but quite.
I am not a fan of docker-compose - a classic example of a tool trying to do too much for me, so the lack of something similar in Podman is not a drawback for me :)
Not sure about tooling around logs and monitoring though - there is plenty for Docker.
"Unfortunately, working on hypothesis generation remains extremely attractive to AI in drug discovery researchers: (1) day-to-day generating more and more ideas subjectively feels like progress is being made - after all, you’ve created an enormous and ever-growing database of almost-medicines - and (2) science has trained researchers to value invention over doing the hard work to validate ideas, leading to a world in which everyone wants to be the idea-person and comparatively almost no-one wants to be doing the hard and unrewarding work to take these ideas all the way. And so, AI-driven drug discovery researchers still largely pursue hypothesis-generation machines and consequently, as a field, we unfortunately continue to make the same mistakes."
Tests on the other hand were executed on multiple different machines - it's all described in the article. Sleep works properly, because there's an unbounded thread pool that makes http request - each request has its own virtual thread.
I know that you can have significantly bigger machines; network-mounted DB storage on the other hand is not slow - it's designed specifically for these kind of use cases
Maybe we will just go back to pay content as it was before the Internet era? Magazines and such
Same with db - I wanted to see, what kind of load a system (not just app) deployed to a single machine can handle.
It can be obviously optimized even further, I didn't try to do that in the article
Both the app and db are hosted on the same machine - they are sharing resources. This fact, type of storage and other details of the setup are contained in this section: https://binaryigor.com/how-many-http-requests-can-a-single-m...
I think you're right that I didn't mention the details of the db connection pool; they are here: https://github.com/BinaryIgor/code-examples/blob/master/sing...
Long story short, there's a Hikari Connection Pool with initial 10 connections, resizable to 20.
Probably it was said many times already, but it will rather be the competition between programmers with AI and programmers without one, rather than no programmers with AI.
In particular, I love this part:
"I had serious doubts about the feasibility and efficiency of using inherently ambiguous natural languages as (indirect) programming tools, with a machine in between doing all the interpretation and translation toward artificial languages endowed with strict formal semantics. No more doubts: LLM-based AI coding assistants are extremely useful, incredibly powerful, and genuinely energising.
But they are fully useful and safe only if you know what you are doing and are able to check and (re)direct what they might be doing — or have been doing unbeknownst to you. You can trust them if you can trust yourself."
I know that Rust provides some additional compile-time checks because of its stricter type system, but it doesn't come for free - it's harder to learn and arguably to read