> A theoretical “AI dev” will be able to gather these requirements through conversation no problem

Maybe! So far what I’ve seen are AI devs that are too afraid to say ”No you’re wrong this will never work” and can’t ask those awkward questions like ”Ok A sounds great, but you already promised to customer B that not-A will always be true. What do we do about that?”

It is very important to have a working mental model of the system to do requirements gathering effectively. AI struggles mightily in that area.

But all you have to do is tell the AI your mental model and it remembers.

And it will remember all the times some suit promised customer zyx four years ago this feature would be ready, and it remembers the insights the old PM had before they left, and it can read the four bug tickets related about a feature that describes conflicting behaviors...

Out of the box sure. An agent set up specifically for this task with your code and internal docs is a whole different story.

And LLMs aren’t afraid to say “you’re wrong”, they’ve just been configured to be agreeable by default.

There is so much that goes into gathering requirements for any large implementation that is not just about asking the requirements. There is the entire management and navigation of organizational politics and priorities, getting to the bottom of XYProblems, users not really knowing what they want and being able to help them get there, etc.

At that level, that’s the role of a product manager. We aren’t going to see software engineers all transform in to project managers. Most don’t have the skills, but more importantly there’s no need for that many PM’s.

Project managers don’t have the technical skillset necessary.

As far as not having the skills, that’s the entire problem that most software engineers are going to have if they don’t understand the business. If you look at the leveling guidelines of every tech company, the higher you go up, the more you are expected to deal with “ambiguity”.

As a “staff software architect”, I am part project manager, part technical lead. But the last thing I want at that level is to play telephone and have someone constantly coming between me and stakeholder.

And some software engineers will be stuck fighting thousands of other commodity ticket takers fighting for scraps. We see that now without AI taking jobs.

You have basically just circled back to what I said initially:

> I don't foresee software engineers going extinct, but there will most definitely be a lot fewer of them.

Your bad attitude, calling most software engineers “ticket takers”, while envisioning yourself as being an un-replaceable genius is extremely common in these discussions. It’s clearly an emotional reaction.

And I understand. AI is going to decimate the industry (along with many others).

Even for those who are truly un-replaceable, for many their companies business model itself will easily collapse. I can look at the list of b2b sass software I use right now and literally all of them will have zero value soon when an AI agent can in house their service in a day.

A software engineer who is only pulling well defined stories off the board is a ticket taker. Look at the leveling guidelines of any tech company, no matter how good of a coder you are, you are doing mid level developer work.

It’s not that I’m irreplaceable at any given job, it’s the ability find another one.

https://www.levels.fyi/blog/swe-level-framework.html

You notice that “codez real gud” only gets you to a mid level developer?

These definitions are similar to what you will see at Amazon (first hand experience), Google (second hand experience), Dropbox (guidelines are publicly available), etc

I’m definitely not a genius. I do have demonstrably a greater ability to deal with people than most software developers.

These agents aren’t going to magically do things without someone translating business requirements to technology and agents will never take over every implementation that large enterprises need.

As much as I have avoid doing it, it’s not that much of a leap to go from where I am now to sales and being a “solution architect”.