Writing code is easy, reading it isn't

> We'll soon get to a point where it's no longer necessary to review code, either by the LLM prompter, or by a second reviewer (the volume of generate code will be too great). Instead, we'll need to create new tools and guardrails to ensure that whatever is written is done in a sustainable way.

This seems silly to me. In most cases, the least amount of work you can possibly do is logically describe the process you want and the boundaries, and run that logic over the input data. In other words, coding.

The idea that we should, to avoid coding or reading code, come up with a whole new process to keep generated code on track - would almost certainly take more effort than just getting the logical incantations correct the first time.

“ With LLMs, the volume of code has only gotten larger ”

It’s even worse with offshore devs. They produce a ton of code you have to review every morning.

Basically when you read code you're mentally doing the same thing as when you write code. But your mental model is more likely to be wrong when you're reading rather than producing the code.

I hold KISS above most "Enterprise Patterns" with YAGNI as a close second. I think abstractions should be used to reduce complexity with code as opposed to making it harder to reason about. If a pattern increases complexity in understanding, then it should make sense in more cases than not.

I'm also a fan of feature-oriented project structures. I want the unit test file in or next to the code it's testing. For UI projects, similar with React it's about the component or feature not the type of thing. For APIs I will put request handlers with the feature along with models and other abstractions that go together based on what they fulfill, not the type of class they are.

I consider this practice more intuitively discoverable. You go into a directory for "Users" and you will see functionality related to users... this can be profile crud or the endpoint handlers. Security may or may not be a different feature depending on how you grow your app (Users, Roles, Permissions, etc). For that matter, I'd more often rather curate a single app that does what it needs vs. dozens of apps in a singular larger project. I've seen .Net web projects strewn across 60+ applications in two different solutions before. It took literally weeks to do what should take half a day at most.

All for one website/app to get published. WHY?!? I'm not opposed to smaller/micro services where they make sense either. But keep it all as simple as you possibly can. Try to make what you create/use/consume/produce as simple as you can too. Can you easily use/consume/interact with what you make from a system in $NewLanguage without too much headache? I don't like to have to rely on special libraries being available everywhere.

Struggling with making an algorithm in a big architecture once I felt the same way - just couldn't keep the current state of the code in my head and also imagine the new solution at the same time. Ever since, have been working on http://etchpad.dev to solve this pain (shameless plug). We're trying to make an interface that works with an engineering brain, so we can think in terms of blueprints and wiring, idk just something more tangible than hallucinating wildly in a multidimensional space like we have to right now.

Really agree with the article, ultimately the typing and thinking speed issues can be solved with AI, but trusting it and auditing what it does seems like a job for humans for the foreseeable, you know, so maybe we avert a classic sci-fi AI apocalypse and whatnot