DEV Community

Cover image for Is Software Engineering Cooked? Not Yet. But Maybe.

Is Software Engineering Cooked? Not Yet. But Maybe.

Morgan Willis on March 03, 2026

"Software engineering is solved." This is all I see lately when scrolling LinkedIn, X, or Reddit. The message is loud and clear: developers are co...
Collapse
 
gass profile image
Gass

I liked the read, but it is a bit too much within the box of the mainstream. AI is a hype, it will definitely change software development but not as much as people think right now. The same happened with .com era, bitcoin, and so on.

When you write software by hand and something brakes you can have a quick sense of how and where the problem might be. In the case of developing software relying too much on dependencies and/or AI, the codebase becomes more and more of a black box (due to the numerous layers of abstraction and lack of understanding of how things work under the hood).
Which approach would you choose ? ... The second approach will probably require you to depend on another tool to navigate the black box and the process becomes even more bloated.

In personal projects I usually use the minimum amount of dependencies, libraries or frameworks. Because I enjoy the freedom that working with plain languages offer. If you build styles only with CSS the process might be more tedious and slower but the quality, freedom and innovation is superior. Conventions = boring = old. All libraries, frameworks, etc.. add limitations. The lower the level of the tech stack you use, the more freedom you'll have. If we were able to code directly in bits without a hussle, the level of freedom we would have would be out of this world.

Collapse
 
morganwilliscloud profile image
Morgan Willis AWS

I can see your perspective. I think I’m between two ideas: I think developers who deeply know software will win this game over the black box approach. To your point. People who understand what’s beneath the layers of abstraction will be able to produce better results and make more reliable systems.

I also think that this innovation allows us to do much more with less, and move a lot faster. So it’s not that devs disappear entirely, but how many no longer have a job and when does that really start to become a problem? A few very smart senior engineers can handle a lot.

There will probably be an uptick in specific types of dev roles in the near future as companies race to make the AI hype real and try to automate as much as they possibly can.

That’s what I’m struggling to wrap my mind around. At what point do we reach a critical mass and we can call software dev as a field “cooked”? I think we have time, but I think we’re headed towards a serious culling of white collar jobs in the long run.

My point about the adoption tail being long outside of the AI hype bubble leads me to hope that the job market shift happens at just a slow enough pace to offset things to where there isn’t a total collapse of the white collar job market.

Collapse
 
gass profile image
Gass • Edited

Thanks for getting back to me with such a rich answer.

People who understand what’s beneath the layers of abstraction will be able to produce better results and make more reliable systems.

👏 completely agree and that is something that has been happening for ever. Old generation programmers, the ones who started with C, kobalt, etc.. are so much better. Because they understand low level better than following generations. As times goes by, the harder it is to deep dive the tech stack.

A few very smart senior engineers can handle a lot.

Yes, but e.g. you still need good front-end specialists that want to dig deep into CSS bugs, develop unique features (which CSS frameworks don't provide) for the specific utility, etc..

That’s what I’m struggling to wrap my mind around. At what point do we reach a critical mass and we can call software dev as a field “cooked”? I think we have time, but I think we’re headed towards a serious culling of white collar jobs in the long run.

Not sure, this is something that has been worrying people since the 1960's with the massification of computers. Read this TIME article (written in 1965) if you have time, the conversation is pretty much the same😆 time.com/archive/6874126/technolog...

Thread Thread
 
morganwilliscloud profile image
Morgan Willis AWS

True that we always predict doomsday. I think reality will be in the middle. AI will change everything about white collar jobs but it’ll take more time than it seems.

Collapse
 
xl5 profile image
Andy R

I’ve been in software engineering for about 35 years (early 90s onwards) and honestly the AI shift feels inevitable.

What I’m less convinced about is the idea that AI can easily transform legacy monoliths, which is where a huge amount of real-world software still lives.

In the last decade I’ve worked around platforms with massive databases, thousands of stored procedures, triggers firing everywhere, and multiple applications bolted onto the same system over decades. Each generation of developers has added their own patterns, frameworks, shortcuts, and architectural opinions. The result is a system where business logic is scattered across application code, database procedures, triggers, and integration layers.

That kind of system isn’t just code — it’s history.

AI works brilliantly where problems are pattern-based and standardised. Infrastructure is the obvious example: build pipelines, deployments, test automation, security scanning, and observability. Those workflows are almost perfectly suited to agentic systems.

For greenfield projects, AI is already impressive. If the agent writes the code, it can also enforce standards, generate logging, run tests, analyse failures, and redeploy fixes. That feedback loop is powerful.

But monoliths aren’t primarily a code generation problem. They’re an understanding problem.

The hardest part isn’t writing new code — it’s untangling decades of implicit architecture and hidden business rules buried in stored procedures, triggers, and inconsistent design decisions.

AI may eventually help by mapping dependencies, identifying patterns, and surfacing architectural inconsistencies. But right now it still feels like it needs experienced humans to interpret the system first.

My suspicion is that AI won’t “fix” most monoliths.
It will simply make it much easier to replace them.

But I’d be genuinely interested to hear from anyone who has successfully used AI to untangle a real legacy monolith — because that would be a game changer.

Collapse
 
bluehorseshoe23 profile image
Blue Horseshoe

Excellent read. I've run development teams for most of my working life. I'm overseas with my team currently running AI workshops and demos. It's been quite unnerving at times for them and staying ahead is like trying to catch knives. What I have really enjoyed is the 'engineering' side of this. Especially DevOpps. I've had ideas of solutions for years but never the time nor bench strength internally to 'waste' Dev time on my 'experiments' so it's been incredible to define a problems, break it down into individual interlinking engineering experiments and tackle them one by one when I have time, often until 3-4am! All the while creating a knowledge base and better agent interactions as I go. After 18+ such experiments over the course of 2 months, I was able to connect it all together and solve quite a bit challenge which had been regularly thrown at us!

Collapse
 
morganwilliscloud profile image
Morgan Willis AWS

That's awesome! I agree that with AI we can now chase down all the things we've been wanting to do forever but just didn't have the time. There is no shortage of problems to solve.

Collapse
 
avanrossum profile image
Alexander van Rossum

Great perspective, and I pretty much agree with your assessment, but i do think with the right mindset we can push ourselves into a higher "frame" of engineering.

I have already personally shifted to more of an "architect" position - I build strict governance documentation around projects I am working on and "lead" a team of one or more agents (depending on the focus) through the development process.

I'm operating now out of the mindset of "Let me see if i can get this done with Agentic tools first, and if that fails, then i'll either start over or fix what broke.

Professionally, I haven't looked back and this process is paying off considerably for everything I've thrown at it - from refactoring python2 to 3,, fixing legacy codebases, and even some salesforce development.

With personal projects, i'm a bit looser, but that's catching up too.

Collapse
 
morganwilliscloud profile image
Morgan Willis AWS

Yeah I basically do the same thing. I only step in if I have to, but I also do watch the agents work and sometimes I have to step in and get them back on track. Plus I’m not going to sit here and say I have most optimized setup. It’s amazing how much these tools can do basically out of the box.

I think that one of the major things that makes me think we have time here is that I have friends in engineering at Fortune 500 companies who got access to copilot finally in the last like 3 months. The adoption tail is longer across regulated industries.

How long things stay that way? Check in with me in… 2 weeks? lol

Collapse
 
l0st profile image
L0ST • Edited

Old head here,

AI is not hype. If you can't see the writing on the wall where agentic cloud development is already being implemented in cloud services than you should poke around and look at the ability to assign agents to work items in the cloud and further more you should start looking at agents in build pipelines and linters. These are all features implemented to make junior development super easy and streamlined. It also comes with security hench the security compliance checks, no code on your laptop and companies will no longer need to buy high end laptops. Like others said, architects/leads will remain the gate, the human in the loop and in smaller projects they'll likely be one of the few engineers.

If your argument is no tribal knowledge of the codebase that's almost comical cause if you're the seasoned engineer you claim to be than your black box of code would have followed your coding practices via clear instructions and linting and if copilot went haywire on a feature then you probably did something dumb like bombard it with irrelevant context via speckit and hit the token limit. Besides you're a engineer, if you can't hop into a project a read/understand code than that's a bigger problem...

Collapse
 
morganwilliscloud profile image
Morgan Willis AWS

I actually think we mostly agree. The systems you're describing, agents generating code and validating it through pipelines, are exactly the direction I was pointing to in the article. My point was that code generation alone isn't the whole engineering problem. The interesting work now is building the systems around it that validate correctness across security, architecture, performance, and reliability. That's where a lot of the experimentation is happening right now.