Hacker News Reader

Comment by tripledry | Hacker News Reader

Putting the performance aside for now as I just started trying out Opus 4.5, can't say too much yet, I don't hype or hate AI as of now, it's simply useful.

Time will tell what happens, but if programming becomes "prompt engineering", I'm planning on quitting my job and pivoting to something else. It's nice to get stuff working fast, but AI just sucks the joy out of building for me.

Trying to not feel the pressure/anxiety from this, but every time a new model drops there is this tiny moment where I think "Is it actually different this time?"

View on HN

I have similar stance to you. LLM has been very useful for me but it doesn't really change the fun-ness of programming since my circumstances has allowed me find programming to be very fun. I also want to pivot out to something else if English prompt becomes the main way to develop complex software. Though my other passion is having worse career horizon in the generative AI world (art making). We'll see.

Yes, not too optimistic on the art side when it comes to commercial stuff - if you can generate it cheaply it will be used.

On the hobby side (music) I don't feel the pressure as bad but that's because I don't have any commercial aspirations, it's purely for fun.

> Time will tell what happens, but if programming becomes "prompt engineering", I'm planning on quitting my job and pivoting to something else. It's nice to get stuff working fast, but AI just sucks the joy out of building for me.

I hear you but I think many companies will change the role ; you'll get the technical ownership + big chunks of the data/product/devops responsibility. I'm speculating but I think one person can take that on himself with the new tools and deliver tremendous value. I don't know how they'll call this new role though, we'll see.

Sure, IF the performance + economics is there. But that doesn't sound like an enjoyable profession to me.

I enjoy the plan, think, code cycle - it's just fun.

My brain has problems with not understanding how the thing I'm delivering works, maybe I'll get used to it.

To me it's more of a mixed bag. On the one hand - disheartening to see how the knowledge base and skills I've worked more than a decade to develop became of little value (not worthless, but not as valuable as before). Also - yeah, the speed of delivery that is going to be expected of devs will make it so we will not be able to hold all the pieces in our heads and rely on A.I (when things break it will suck, hopefully A.I will be able to get us out of the jam). This is also not enjoyable to me.

On the other hand : way less time spent on being stuck on yarn/pip dependency issues, docker , obscure bugs , annoying css bugs etc etc. You can really focus on the task at hand and not spend hours/days trying to figure out something silly.

Pity, prompt engineering is just another kind of programming, I find it to be fun, but I guess lots of other people would see it differently.

Indeed it is another kind of programming, I simply don't enjoy it.

But it is also very early to say, maybe the next iteration of tools will completely change my perspective, I might enjoy it some day!

The venn diagram of engineering and prompting is two circles, maybe a tiny overlap with integrated environments like claude code.

A program, by definition, is analyzable and repeatable, whereas prompting is anything but that.

As long as your program is large and multi-threaded (most programs that matter commercially), it is not very analyzable or repeatable. You replace those qualities with QA and tests, the same is true with prompting.

Eve if "write code -> run QA -> analyze failures -> rewrite code" is cheaper for most commercial software than thorough upfront formal verification, it works precisely because the programs are analyzable.

When the code spit out by an LLM does not pass QA one can merely add "pls fix teh program, bro, pls no mistakes this time, bro, kthxbye", cross their fingers and hope for the best, because in the end it is impossible -- fundamentally -- to determine which part of the prompt produced offending code.

While it is indeed an interesting observation that the latter approaches commercial viability in certain areas there is still somewhere between zero and infinitesimal overlap between prompting and engineering.

Think of it this way, some engineers go into people management, they aren’t coding directly anymore…they are managing people that code. Prompting is a similar lateral promotion, just the people you are managing are dumber AIs, you get a lot of them, and instead of meetings you communicate with them via prompts. The fact that they can also do QA is critical because they make a lot of mistakes, but can actually fix those mistakes, so you just devote more AI time to that.

> they are managing people that code. Prompting is a similar lateral promotion

So prompting is a lateral move away from engineering to management? Are we arguing semantics here, because that's quite what I was saying, just in the other direction.

We aren't really, but I guess it really depends on how you see coding as more than just directly orchestrating computer instructions or not. Prompting is less direct, but it still feels like programming to me, I guess people management would as well.

Sounds like it's time for your LLM daddy to have the Coq talk with you..

Programming without flow state. Nice.

Reply on news.ycombinator.com