Software Engineering in the Time of AI

AI is already part of the developer’s toolkit, but it’s not the revolution many are claiming. Its value lies in automation, not intelligence. The future of software engineering won’t be defined by hype or fear of missing out, but by how we choose to integrate AI into our work without sacrificing the depth, creativity, and discipline the craft demands.

Using AI today is a bit like working with a junior engineer. They can take repetitive tasks off your plate and help you move faster on the surface-level stuff. But you still have to do the real thinking. You still have to supervise. You still have to make the decisions. Because bluntly? AI cannot be trusted with important, judgment-heavy work. Not yet.

Where AI Helps (and Where It Doesn’t)

Let’s start with what AI is good at:

Filling in boilerplate.
Speeding up documentation (though often off-mark).
Suggesting quick implementation ideas (90% useless, 10% occasionally sparks a decent thought).

Where it falls short:

System design. AI doesn’t do trade-offs. It doesn’t reason about constraints, growth paths, or long-term maintainability.
Context. Without a massive prompt, it doesn’t grasp the nuances of your business, tech stack, or team dynamics. By the time you explain it, you might as well do the work.
Production quality. If you care about shipping robust, durable software, the AI’s output usually needs a rewrite.

How I Personally Use AI

I design the code structure and architecture myself.
I define the responsibilities and method boundaries.
I write out the logic and intent in plain language.
Then I ask AI to generate an initial implementation.
While it writes, I take a break (grab a coffee, reset).
I return, review the result, and rewrite or refine the parts that fall short.

It’s a productivity booster, not a thinking machine.

Let’s Talk About the Bigger Assumptions

There’s a growing narrative that AI will reshape software engineering by collapsing roles into something like “Product Engineer 2.0”: a multidisciplinary, always-context-switching hybrid. Let’s unpack that.

Assumption: AI will turn all software engineers into “Product Engineers”. All engineers should now do everything (product thinking, tech leadership, implementation, QA) because AI reduces the cost of context-switching.

The problems:

Cognitive Load: Holding deep technical and product context in your head at once is cognitively expensive. You risk doing both poorly.
Burnout Risk: Replacing a team with one overloaded engineer is not transformation. It’s exhaustion dressed up as vision.
False Equivalence: AI helping connect disciplines is not the same as a human mastering all of them equally.
A better alternative: Think in terms of Polymath Teams: small squads where everyone stretches a little outside their core specialty, using AI to assist, but deep focus and domain mastery still exist.

Assumption: Software Engineering Will Be Transformed Like Other Rule-Based Professions

The analogy: Professions that follow predictable, rule-based workflows have been partially automated, so software engineering will follow the same path.

The fallacy: Those fields are built on repeatable patterns with a narrow scope. Software engineering, in contrast, is open-ended, creative, and full of ambiguity. The overlap is superficial at best.

More likely outcome: Software engineering will split:

80% of low-complexity tasks will be AI-assisted or semi-automated.
20% of complex, creative, critical thinking work will become even more valuable.

The focus shouldn’t be on flattening engineers into generalists. It should be on moving people into that 20% zone, the part where judgment, design, and innovation happen.

Assumption: “Zero-touch feature development will happen”

Let’s be honest: This sounds like a pitch deck, not a plan. Zero-touch is utopian, and dangerous if taken literally.

More realistic framing: “Low-touch development”, with AI scaffolding code, tests, or infra, while humans supervise architecture, integration, and quality.

Core Flaw in This Vision

This whole narrative assumes:

Everyone learns at the same speed
Everyone thrives in multidisciplinary ambiguity
Everyone likes context-switching and business fuzziness

That’s not how real teams work. The strength of any engineering team is diversity: of thinking styles, working rhythms, and depth of motivation. Flattening that into a one-size-fits-all Product Engineer mold would be:

Demotivating for specialists
Inefficient for real output
Unrealistic for long-term growth

Final Thoughts

AI doesn’t do the important thinking for you, and it doesn’t help you grow unless you keep doing the hard parts yourself.

The trick is knowing which parts are mindless and which parts are still teaching you something. That line shifts as you grow. Learning to work with AI, not against it, is essential. But it starts with self-awareness.

There’s a tension I feel every day, between pride in my hard-won abilities and fear of being left behind if I don’t adapt.

TL;DR:

If you let AI think for you, you stop growing.

If you use AI to free yourself up to focus on the important parts of engineering, you’re using it right.

*Fun fact:** I used AI to write this post. It drafted, I edited, we argued, and somehow, it still thinks it’s the senior engineer. *¯_(ツ)_/¯

Originally published at https://medium.com/@moosezidan/software-engineering-in-the-time-of-ai-af8756a52ebb.