An Engineer's Reflection: Watching the SI Business Model Change From the Inside

#business #ai #career #beginners

Key Points

The identity discomfort is real and widely reported this year. Commentators describe it as bordering on depression for engineers who feel their role slipping from skilled creator to what one report calls "cleanup crew." I don't think that framing is wrong. I think it's incomplete.
What I'm watching happen to the engineers coming through this well isn't that judgment is replacing coding as some abstract virtue. It's that the specific, nameable things they know, a legacy system's quirks, a client's real constraints, when an AI-proposed solution is subtly wrong, are becoming the paid part of the job, while the part that used to define professional identity, writing the implementation, is turning into infrastructure.
Fujitsu's own internal reforms are a useful, concrete marker of how far this is going beyond rhetoric: the company has moved from uniform starting salaries for new graduates to job-competency pay from day one, restructuring roughly 650 roles around it, an explicit break from seniority-based structure that would have been unthinkable at a firm like Fujitsu a few years ago.

Introduction

I want to talk about a specific conversation, not a general trend, because the trend only ever shows up to me one uncomfortable conversation at a time. This one was with a colleague, a genuinely excellent engineer who's spent fifteen years getting better at exactly the kind of implementation work AI tooling is rapidly making cheap. He asked me, not rhetorically, whether he'd wasted those fifteen years. I don't have a fully clean answer for him yet.

The discomfort he feels is widely shared and worth taking seriously on its own terms, not just as a business-model footnote. Commentary this year describes something close to an identity crisis for engineers whose professional self-image has been built on skilled implementation. One widely circulated framing put it as "bordering on depression," with veteran engineers feeling their role slip from skilled creator to what amounts to a cleanup crew reviewing AI output. That's not a business-press exaggeration. I'm watching it happen to people I respect, including, some days, myself.

Here's where I've landed after watching this from inside a role that straddles engineering and business: the resolution isn't that "judgment" swoops in as an abstract replacement virtue for "coding." It's narrower and more specific than that. The things turning out to be worth paying for are nameable: knowing that a particular legacy system behaves unpredictably under a specific load pattern, knowing which of a client's stated requirements are actually politically immovable versus negotiable, catching the specific moment an AI-proposed integration is subtly, dangerously wrong in a way that would only surface months into production. None of that is "judgment" as a vague virtue. It's specific, earned pattern-recognition that's becoming the billable part of the job, because the part that used to be billable, writing the implementation, got cheap. Fujitsu's own workforce reforms are the clearest evidence I've seen that this isn't just rhetoric: the company has broken from uniform, seniority-linked starting salaries toward job-competency pay from day one, restructuring around 650 roles in the process. That's an institution built on decades of seniority-based structure admitting, structurally and publicly, that what it pays for has changed.

An Engineer's Position: What Made You Valuable, Then and Now

Dimension	The Old Basis of Value	Where This Is Heading
What made an engineer valuable	Consistent, correct implementation output	Specific domain and system knowledge, judgment about AI-proposed solutions, willingness to own an outcome
Career ladder shape	Seniority and tenure-linked, fairly uniform within a cohort	Competency-linked from early career, per Fujitsu's own 2026 reform pattern
Most exposed cohort right now	Mid-career implementation specialists with deep tooling expertise, less domain-specific judgment	Likely to settle, but only for engineers who deliberately build domain-specific judgment during the transition
What "keeping up" means	Learning the newest AI coding tool	Deepening specific, nameable expertise a tool can't substitute for
Honest emotional reality right now	Real anxiety, reasonably described as an identity crisis for a meaningful share of the workforce	Likely to settle over time, but the transition is costing real careers and real confidence along the way. Not a costless story

Recommendation: if you're an engineer reading this mid-transition, the actionable version of this table isn't "learn to use AI tools better." It's "get specific about what you know that a tool doesn't": a client's real constraints, a system's real failure modes, a domain's real edge cases. That's the column most likely to survive.

What I'm Telling That Colleague

The fifteen years aren't wasted, but the specific skill that felt most valuable, fast, correct implementation, really is stopping being the paid part of the job. That's a real loss worth naming, not minimizing.
What those fifteen years actually built, underneath the implementation skill, is pattern-recognition about when something is subtly wrong. That's turning out to be the transferable part, and it wasn't obvious that it would be.
The engineers adapting fastest aren't out-learning AI tooling. They're out-specifying their own domain knowledge. They're turning "I've seen this before" into something they can name, price, and sell, instead of leaving it as unpriced background competence.
The institutional signal to watch for isn't a memo about "AI transformation." It's compensation structure actually changing. Fujitsu breaking seniority-linked pay isn't a communications exercise. It's the company admitting what it now pays for, and that kind of structural signal tells you more than any strategy announcement.

Questions to Ask Yourself, Not Just Your Team

What do I know, specifically and by name, that isn't just "I'm experienced": a system's real failure pattern, a client's real constraints, a domain's real edge cases?
Am I still measuring my own value by implementation speed, in a market that's increasingly not paying for that specifically?
If my compensation structure hasn't changed to reflect a competency-based model, is that because my organization hasn't caught up yet, or because it doesn't need to for the kind of work I actually do?
Would I recognize the moment an AI-proposed solution was subtly wrong in my own domain, and could I explain why, specifically, to someone who trusted the AI's output at face value?

Conclusion

This thread started with a pricing unit dying and ends, for now, with what that dying pricing unit is doing to the people underneath it. I don't think the honest reflection is either the doom-laden "identity collapse" framing circulating this year or the tidy "engineers move up the value chain" framing that shows up in a lot of retrospective business writing, including some of my own earlier pieces in this thread. It's both, at once: a real, disorienting loss for people whose professional identity was built on a skill that's stopping being scarce, and a real, achievable adaptation for the people who find the specific, nameable thing they know that a tool doesn't. My colleague hasn't found his yet, as far as I know. I think he will. I don't think it'll be comfortable getting there.

DEV Community