Well, my first comment said "reading code is harder than writing code", your comment said "reading good code is easier than writing good code". I believe the two points are about equally articulated.

This is the thing.

LLM assisted coding ("vibe coding") is just project management.

You ask it to do things, then you check the work to a sufficient degree.

The better the specifications and documentation you give it, the better the result will be. Keeping tasks short and verifiable also helps a lot.

I've written SO many small tools for myself during the last year it's not even funny. Upgraded some shitty late night Python scripts to proper Go applications with unit tests and all, while catching up on my TV shows.

Converted my whole rat's nest of Docker compose files to a single Opentofu declarative setup.

None of this would've gotten done without an LLM assistant.

I’m at the same point as well. Doing more reading than writing.

Just want to add one more point: code is not fiction or even nonfiction, “good or bad” style can be subjective, but correct or not correct is not, regardless of the reviewer’s mental model.

The difficulty of reading code is to understand its logic and logical consequences. The more complex the codebase (not just the line we are reading), the more risky to modify it.

That is why I use LLM to write a lot of tests and let it review the logs to help me understand the logic. Even the tests can be disposable.

I think it has to do with mental model. If you already know what to write and it is reasonably complex you'll have a mental model ready and can quickly write it down (now even faster as LLMs autocomplete 3-4 lines at a time). While reading someone else code you'll have to constantly map the code in your mind with code written and have to then compare quality, security and other issues.