upvote
Just to offer a counter-example, using AI makes programming bearable again for me. Most of programming comes down to a short - edit: not quit so short but you may understand the figure of speech.. - list of things which are repeated ad infinitum in myriad variations.

I don't have to slog through yet _another_ way to sort, split, combine a list, open a file, show a UI component, handle events, logging, make data flow through some type of "database", serialize and deserialize endless things, implement yet another protocol in $whateverishotnow, managing authn, authz, the list is endless.

The interesting part of programming, for me, is deciding on and capturing the domain in a tight, surprisingly simple yet powerful architecture. This is hard - for me - and actually has very little to do with "programming" per se, meaning it has nothing to do with wrangling syntax/low-level semantics of whatever platform I'm on and fighting package managers to name just two highly depressing parts of my job. I don't like typing code. I am doing it my entire life and I still don't like it.

I like coming up with invariants and ways of guarding them. To find simple decompositions that turn a hairy, ungodly blob of a problem into a manageable almost trivial network of not-so-complicated things. The not-so-complicated things themselves.. I don't care in the slightest about them. Opening files, managing database connections, forms, the mechanics of i18n, typing the word "class", you name it. I find it exceedingly boring.

Perhaps I am more of the architect type, but I find managing a bunch of AIs and making sure they don't stray from My Path is easy on the mind. Programming works on my level of abstraction finally.

reply
I feel this as well. I think it’s something to do with having to be more “on” as you slowly work with the LLM to define the problem and find a reasonable solution. There’s not much of a flow-state. You have to process mountains of output and identify the critical points, over and over, endlessly. And it will always be an off in this unsettling little way, even when it’s mostly quite good. It’s jarring.

The strange sorts of errors and reasoning issues LLMs have also require a vigilance that is very draining to maintain. Likewise with parsing the inhuman communication styles of these things…

reply
Could it be that what we called flow state was actually a sort of high level thinking time afforded by doing low level routine work?

For instance I'm the old world, if you wanted to change an interface, you might have to edit 5 or 6 files to add your new function in the implementations. This is pretty routine and you won't need to concentrate that much if you're used to it, so you can spend that low-effort time thinking about the bigger picture.

reply
you may be right on this hunch. but I think the old world is no longer there now :( more thinking is expected per unit time
reply
Its the "unsettling little ways", right. So you can't skip whole paragraphs, you literally have to read everything. And sometimes its worded in ways I don't understand at all (due to missing implications that the LLM conveniently omitted), so I have to re-ask it about that point as well. For every major feature or work-unit it takes up to 2 or 3 hours.

I figured out some patterns in the way it behaves and could put more guard-rails in place so they hopefully won't bite me in the future (spelled out decision trees with specific triggers, standing orders, etc.), but some I can't categorize right now.

reply
How do you check if what it produced is even the right thing? Models love to go chasing the wrong goal based on a reasonable spec.
reply
When the end result has problems and needs to be reworked.

You can't figure this out instantly except when you'd review everything the LLM produces, which I am not. So the round trip time is pretty long, but I can trace it back to the intent now because I commit every architecture decision in an ADRs, which I pour most of my energy into. These are part of the repo.

Using these ADRs helped a lot because most of the assumptions of the LLM get surfaced early on, and you restrict the implementation leeway.

reply
Got it. I imagine concurrency bugs will hit hard with this approach because they show up rarely and are hard to debug.
reply
Do they? I haven't experienced models deviating from a spec in a very long time. If anything I feel they are being too conservative and have started to ask to confirm too much.
reply
The problem is not the LLM deviating from the plan (though that rarely also happens when it thinks it has a better idea) but rather if the plan is not strict enough and the LLM decides on the fly HOW it is going to build your plan.
reply
Sounds like you’re using Waterfall Which, if it works for you, go for it. But maybe Agile would feel more dynamic.
reply
To me it’s more like being a super micro-managing TL that would annoy the hell out of their human reports. It comes with all the pros and cons of micro-management.
reply
I think one of the benefits of AI is that it will get started, and keep going.

But maybe pacing/procrastination might be relief valves?

reply
AI does the easy/medium part, leaving only hard stuff and context switching, so naturally it's more exhausting, as the concentration of difficult-work-per-unit-time and context-switching-per-unit-time is much higher.
reply
[dead]
reply