I've commented elsewhere about this but so many are flippant towards your feelings and it's quite sad.

Comments such as "now that economically 'traditional coding' no longer works" get over it. Or a recent one "get over your anthropocentric view of intelligence, AI is here now".

These views (and many more besides) are short sighted, I do think anthropocentrically. The economy is a proxy for the lives of real people, the economy matters only because it deals with real people. People who feel, have agency, who live and die.

Two super AI's talking to each other maybe the most intelligent things in the universe but they don't matter.

Humans matter, human lives matter, human feelings matter.

> And there's such little empathy out there for anyone going through it like me. AI is here now loser, keep up, get on board or get replaced.

I think that this really needs to be internalized by a lot of people. I really appreciated when my boss sat our team down and said "Yeah this is the new normal, and I know its not what you signed up for. Its fine to feel sad that your job is changing in such a dramatic way." No, it didn't help anyone actually adjust, but sometimes you just need someone to empathize and tell you its OK to feel bad about this when everyone around you is excited.

> If you read this far thanks. And if anyone has any advice for me, how to go from "thinking through problems by coding your way through them" to "doing the thinking upfront" then really, I'm all ears.

I'm trying to replace it with "thinking through with AI" to limited success. A lot of people recommend having the AI "plan" the thing and review the plan, which is OK. I've also had it do a prototype and poked around a bit, summarized the learnings, and then did it again in an iterative manner without rough edges I've found. Whether you are given the space to do that is up to your org -- its hard sell to "do it again" but I've found that the second attempt leads to better results since I can prompt my way around the problems. Sometimes this also leads to a "Not even wrong" moment where I found out that I framed the problem wrong and the AI dutifully carried out doing the wrong thing.

I wrote a thing about this (https://www.klio.org/theory-of-llm-dev-skepticism/) back at the beginning of the year, in a totally different era of AI dev tooling. What you're describing is what I called there "bottom-up" programming.

Unfortunately, I don't have a lot of first-person advice for you; as I say in that essay, I was also a bottom-up programmer for a long time and was deeply skeptical of top-down approaches. What changed my opinion and my practice was just doing things for long enough that I started having a sense of where things were going to go before I did the exploratory work to find it out, and eventually the exploratory work was unnecessary and I could create a basically-correct top-down design early on. I don't know how you build that experience without actually getting in the reps (which has some implications for future generations of developers, if we have any).

That said, my second-person advice would be to use the agents for the design part of things, too. "Here's the problem, how would you design it?" and then have a conversation with them, push back on the things that seem wrong, imagine reviewing this as a finished design from a coworker and seeing where it looks right and where it doesn't. Ask why it designed things a certain way; suggest alternatives for it to evaluate and think about what it's weighing. Basically borrow the robot's experience to augment and build up yours.

I don't have a good answer, but a question of my own. I wonder if there are only the two extremes: write everything manually or one-shotting without looking at the code?

One-shotting without review is very quick but has its downsides: burnout, less understanding of the code base, less interacton with your colleagues, you miss the poor choices the LLM made so the code base might rot.

Writing everything manually is much slower and in some circumstances not what you want anyway.

Is there a middleground where you get significant parts of the productivity/speed increase but retain the most important parts of the manual process? I have found I preferred the copilot style of working, but the interface was not really optimized.

Instead of spewing out code at 20x speed can we settle for 5x and remain in control? That would be my ideal and more sustainable, right?

Actually, most of the stuff discussed in this thread are all ideas that those old-school software scientists already talked about long ago. Go look up the papers Bélády wrote back in the day.

[dead]