BinaryIgor

I don't know, there is a very important tradeoff here:

"The potential improvement in the experience an individual has with their government could be substantial. When procedural complexity serves as a gatekeeper, government services become less accessible to those who may need them most. Agentic services could, if implemented thoughtfully, democratize access by removing these procedural barriers without compromising program integrity."

True, but at the same time it disincentives governments from simplifying these processes - that's the root cause of the problem. I highly doubt whether agents will be capable of automating these kind of interactions any time soon, but if they prove to be, they might cement overly complex processes pretty much forever - why improve and simplify them when we have agents to hide the accidental complexity?

Mostly agree, but we do need to have ways of distributing content, published on blogs; that what mostly various platforms and social media right now are for - content discovery

True!

Interesting article; one of the best takeaways:

"How do you develop good taste? It’s hard to say, but I’d recommend working on a variety of things, paying close attention to which projects (or which parts of the project) are easy and which parts are hard. You should focus on flexibility: try not to acquire strong universal opinions about the right way to write software. "

I think that with experience, great programmers learn to recognize and differentiate subjective parts of software engineering form the objective ones; and then to have more lax and open approach to the former and stricter to the latter

...written in Java! Recursion going strong :)

"We just don’t think we will incorporate AI to do more than that, given the current state of things. We will, however, keep an eye in case the technology changes fundamentally."

I wonder whether LLMs are capable of doing more; probably, we need another paradigm for that; still, they are very, very useful when used right

All the time I find that if I know the stack and tools I am working in, it's faster to just write code on my own, manually; If I want to learn on the other hand, LLMs are quite useful - as long as you understand (or learn to) and validate the output

That's why is so crucial for any great product (or striving to be) to have reliable usage metrics - you then have reliable data to decide what's worth focusing on and improving and what's not so much

This section of the article sums it up pretty nicely:

"Humans are creatures of comfort. Just like so many things in this world, we follow the path of least resistance. With access to technology being ubiquitous, and ChatGPT being so widely available, to choose not to use it is very hard. You need to deliberately prioritize your growth and choose to go against the current. You need to deliberately introduce friction to the process."

And as an extension, people who can exist in both words - leveraging AI or any other new shiny tool that will come up, and at the same time - constantly pushing themselves mentally in an old-school way regularly, will be unstoppable.

Tools are only as powerful as their operators; and to be a powerful operator, you must face friction, the often the better.

"Yes, eventually LLMs might perfectly translate "I want monthly subscriptions" into working code. But while we wait for perfect AI understanding, we can build better abstractions."

I don't think it will ever happen in this way; instead, the LLMs could always use the same service (integration with it) to implement such feature.

I wonder whether there isn't even more backdoors of this kind in various popular packages for all kinds of programming languages - after all, it seems like security scrutiny for developer-level packages is something that we are just starting to get that might be important

It depends; not everything that's newer is automatically better.

Web and websites did the heavy lifting of instant and world-wide information sharing.

With social media, open or closed, there are many non-obvious tradeoffs; I am not sure whether on the whole, we are better off with or without them - time will tell

Sometimes I wonder - maybe websites were enough? Most people on most platforms are readers/consumers, not producers anyways. Maybe having a personal website was a good filter for publishing after all? Maybe personal websites + sites like hackernews that allows us to discuss our and other people's work is the best the Internet could be.

As expected, Postgres - especially with Unlogged Tables - is fast enough; additionally, having less things to run on your infrastructure and fewer integrations to manage in your app is a hugely underrated benefit.

I am just a little bit surprised on the relatively low write performance for both Postgres and Redis here; but as I can see, the tests were run on just 2 CPUs and 8 GB of RAM machine. In my experience, with 8 CPUs, Postgres can easily handle more than 15 000 writes per second using regular tables; I would imagine that it can easily be 20 000+ for the Unlogged variety - who needs more than that to cache?

Interesting; I wonder what the limitations of WebAssembly are in this context, as compared to the machine code

Good points - thank you for a thoughtful answer!

Exactly - free market is a better filter

Licensing also means corrupted busy bodies and gate keepers; it doesn't necessarily increase quality, but it surely decrease supply of service providers and give a rather dangerous power to a selected (by whom?) group

Interesting - do they compile Python to WebAssembly or just have a Python interpreter compiled to WebAssembly and running as usual?

Cloudflare have great products and engineering expertise, but it starts to get into a concerning territory; what kind of influence over various protocols of the Internet they (might) have.

Postmark is pretty good as well :)

In principle I agree, but in practice - what the better ways of doing things, as of now?

That's also my intuition, but I would like to test and measure it against a real and non-obvious system use case; some day I will and will write about it :)

That's nice, but to be more concrete, in the Bluesky case - I wonder whether it will not change, when eventually they have to make money; right now, they're running on the investors input

Interesting idea for some kind of blog post:

* come up with requirements for a non-obvious system

* try to vibe-code it

* clean it up manually

* add detailed description and comparisons of before and after; especially, was it faster or slower than just writing everything manually in the first place?

Human legacy code turns into machine-generated legacy code; the nature of work remains, more or less, the same

Great to see Postgres still getting these kind of incremental improvements after so many years of being up and running!

Why focusing on serverless? How cron jobs work in such a environment? They spin up another function? How do you deploy those functions?