If natural language was an efficient way to write software we would have done it already. Fact is that it's faster to write class X { etc }; Than it is to write "create a class named X with behavior etc". If you want to think and solve problems yourself, it doesn't make sense to then increase your workload by putting your thoughts in natural language, which will be more verbose.

I therefore think it makes the most sense to just feed it requirements and issues, and telling it to provide a solution.

Also unless you're starting a new project or big feature with a lot of boiler plate, in my experience it's almost never necessary to make a lot of files with a lot of text in it at once.

the time spent literally typing code into an editor is never the bottleneck in any competently-run project

if the act of writing code is something you consider a burden rather than a joy then my friend you are in the wrong profession

Code is the ultimate fact checker, where what you write is what gets done. Specs are well written wishes.

you can't use a system with the exact same hallucination problem to check the work of another one just like it. Snake oil

> what gives the most satisfaction (even though this kind of satisfaction happens very rarely) if I discover some very elegant structure behind whatever has to be implemented that changes the whole way how you thought about programming

A number of years ago, I wrote a caching/lookup library that is probably some of the favorite code I've ever created.

After the initial configuration, the use was elegant and there was really no reason not to use it if you needed to query anything that could be cached on the server side. Super easy to wrap just about any code with it as long as the response is serializable.

CachingCore.Instance.Get(key, cacheDuration, () => { /* expensive lookup code here */ });

Under the hood, it would check the preferred caching solution (e.g., Redis/Memcache/etc), followed by less preferred options if the preferred wasn't available, followed by the expensive lookup if it wasn't found anywhere. Defaulted to in-memory if nothing else was available.

If the data was returned from cache, it would then compare the expiration to the specified duration... If it was getting close to various configurable tolerances, it would start a new lookup in the background and update the cache (some of our lookups could take several minutes*, others just a handful of seconds).

The hardest part was making sure that we didn't cause a thundering herd type problem with looking up stuff multiple times... in-memory cache flags indicating lookups in progress so we could hold up other requests if it failed through and then let them know once it's available. While not the absolute worst case scenario, you might end up making the expensive lookups once from each of the servers that use it if the shared cache isn't available.

* most of these have a separate service running on a schedule to pre-cache the data, but things have a backup with this method.

> I’ve seen plenty of people that are okay with picking up a codebase someone else wrote and working with the patterns and architecture in there BUT when it comes to them either needing to create new mechanisms in it or create an entirely new project/repo it’s like they hit a wall - part of it probably being friction, part not being familiar with it, as well as other reasons.

For me, it's exactly the opposite:

I love to build things from "nothing" (if I had the possibility, I would even like to write my own kernel that is written in a novel programming language developed by me :-) ).

On the other hand, when I pick up someone else's codebase, I nearly always (if it was not written by some insanely smart programmer) immediately find it badly written. In nearly al cases I tend to be right in my judgements (my boss agrees), but I am very sensitive to bad code, and often ask myself how the programmer who wrote the original code did not yet commit seppuku, considering how much of a shame the code is.

Thus: you can in my opinion only enjoy picking up a codebase someone else wrote if you are incredibly tolerant of bad code.

You don't really know if the system design you've architected in your mind is any good though, do you, until you've actually tried coding it. Discovering all the little edge cases at that point is hard work ("a total slog") because it's where you find out where the flaws in your thinking were, and how your beautifully imagined abstractions fall down.

Then after going back and forth between thinking about it and trying to build it a few times, after a while you discover the real solution.

Or at least that's how it's worked for me for a few decades, everyone might be different.

> Tracking variables, remembering syntax,

That's why you have short functions so you don't have to track that many variable. And use symbol completion (a standard in many editors).

> trying to think through every edge case, avoiding off-by-one errors.

That is designing, not coding. Sometimes I think of an edge case, but I'm already on a task that I'd like to finish, so I just add a TODO comment. Then at least before I submit the PR, I ripgrep the project for this keyword and other.

Sometimes the best design is done by doing. The tradeoffs become clearer when you have to actually code the solution (too much abstraction, too verbose, unwieldy,...) instead of relying on your mind (everything seems simpler)

I hear you, but without any enjoyment in the process, quality and productivity go down the drain real fast.

The Ironies of Automation paper is something I mention a lot, the core thesis is that making humans review / rubber stamp automation reduces their work quality. People just aren't wired to do boring stuff well.

> you have to realize the world isn't optimizing make things more fun.

Serious question: why not?

IMO it should be.

If "progress" is making us all more miserable, then what's the point? Shouldn't progress make us happier?

It feels like the endgame of AI is that the masses slave away for the profit of a few tech overlords.

I will second this. I believe code review agents and search summaries are the way forward for coding with LLMs.

The ability to ignore AI and focus on solving the problems has little to do with "fun". If anything it leaves a human-auditable trail to review later and hold accountable devs who have gone off the rails and routinely ignored the sometimes genuinely good advice that comes out of AI.

If humans don't have to helicopter over developers, that's a much bigger productivity boost than letting AI take the wheel. This is a nuance missed by almost everyone who doesn't write code or care about its quality.