It's not the typing, obviously, you're right. I think the parent is talking about it being an "intellectual exercise" to organize their thoughts about what they wanted to see as a result, whereas we who enjoy programming enjoy the exercise of breaking down thoughts into logical and algorithmic segments, such that no edge cases are left behind, and such that we think through the client's requirements much more thoroughly than they thought through them themselves. A physician might take joy in finding and fixing a human or animal malady. A roofer might take joy in replacing a roof tile, or a whole roof. But what job besides coding offers you the chance to read through the entire business structure of.. a lawyer, a doctor, a roofing company, a bakery.. and then decide how to turn their business into (a) a forward-facing, customer-friendly website, and (b) a lean data-gathering machine and (c) a software suite and hosting infrastructure and custom databases tailored to their exact needs, after you've gleaned those needs from reading all their financials and everything they've ever put out into the world?

The joy of writing code is turning abstract ideas into solid, useful things. Whether you do most of it in your head or not, when you sit down to write you will find you know how you want to treat bills - is it an object under payroll or clients or employees or is it a separate system?

LLMs suck at conceptualizing schema (and so do pseudocoders and vibe coders). Our job is turning business models into schemata and then coding the fuck out of them into something original, beautiful, and useful.

Let them have their fun. They will tire of their plastic toy lawnmowers, and the tools they use won't replace actual thought. The sad thing is: They'll never learn how to think.

> If AI were a thing that could reliably pluck the abstract ideas from my head and turn them into the corresponding lines of code, i.e. automate the "line by line" part, I would use it enthusiastically.

So I take it you don't let coding agents write your boilerplate code? Do you instead spend any amount of time figuring out a nice way to reduce boilerplate so you have less to type? If that is the case, and as intellectually stimulating as that activity may be, it probably doesn't solve any business problems you have.

If there is one piece of wisdom I could impart, it's that you can continue enjoying the same problem solving you are already doing and have the machine automate the monotonous part. The trick is that the machine doesn't absorb abstract ideas by osmosis. You must be a clear communicator capable of articulating complex ideas.

Be the architect, let the construction workers do the building. (And don't get me started, I know some workers are just plain bad at their jobs. But bad workmanship is good enough for the buildings you work in, live in, and frequent in the real world. It's probably good enough for your programming projects.)

From the way you describe it, our process does not sound that different, except that this

> If AI were a thing that could reliably pluck the abstract ideas from my head and turn them into the corresponding lines of code, i.e. automate the "line by line" part, I would use it enthusiastically. It is not.

... is exactly how this often works for me.

If you don't get any value out of this at all, and have worked with SOTA tools, we must simply be working in very different problem domains.

That said I have used this workflow successfully in many different problem domains, from simple CRUD style apps to advanced data processing.

Two recent examples to make it more concrete:

1) Write a function with parameter deckName that uses AnkiConnect to return a list of dataclasses with fields (...) representing all cards in the deck.

Here, it one-shots it perfectly and saves me a lot of time sifting through crufty, incomplete docs.

2) Implement a function that does resampling with trilinear interpolation on 3d instance segmentation. Input is a jnp array and resampling factor, output is another array. Write it in Jax. Ensure that no new instance IDs are created by resampling, i.e. the trilinear weights are used for weighted voting between instance IDs on each output voxel.

This one I actually worked out on paper first, but it was my first time using Jax and I didn't know the API and many of the parallelization tricks yet. The LLM output was close, but too complex.

I worked through it line by line to verify it, and ended up learning a lot about how to parallelize things like this on the GPU.

At the end of the day it came out better than I could have done it myself because of all the tricks it has memorized and because I didn't have to waste time looking up trivial details, which causes a lot of friction for me with this type of coding.