The Skill Shift: What Enterprise Developers Need to Learn Now

I spent four years in mechanical engineering school learning how to write problem statements. Not how to solve problems. How to frame them. It felt like busywork at the time. My professors kept dragging us back to the same question: what problem are you actually trying to solve? That training has been worth more in the last two years than anything I learned about thermodynamics.

Developers who came up through computer science often start from the problem as it was handed to them in the requirements, ready to implement. They want to get to the code. I keep going back to the customer and asking them to explain the problem rather than the solution they have already chosen. Classical computer science education focuses on data structures, algorithms, and implementation detail. Mechanical engineering taught me to think in systems: inputs, outputs, feedback loops, constraints. Now that so much implementation detail is automated, systems thinking is what separates people. Projects rarely fail because a team built the wrong thing badly. They fail because the team built the wrong thing correctly.

Stakeholders arrive with a treatment, not a diagnosis

Working with stakeholders is like going to the doctor. A patient comes in saying their stomach hurts and that they think it is appendicitis. A good doctor does not dismiss the research, but does not skip the examination and go straight to surgery either. They run tests. They ask questions. They work from the symptoms in front of them.

A few months ago I worked with a client in oil and gas. Smart technical people who know their domain cold. They came to me with a fully formed solution, and once I started asking about the underlying problem it was clear they had not diagnosed it themselves. They had gone straight from pain to treatment. What we built was not what they proposed. It solved the problem they were having rather than the one they believed they had.

The shift is not about syntax

Writing syntactically correct code from memory is becoming less valuable by the month. You still have to read and understand code, but memorizing method signatures and API patterns is increasingly automated. What is not automated is framing a business problem correctly, pushing back when a product owner hands you a solution disguised as a requirement, and recognizing when a customer is describing a symptom rather than the disease.

A two hundred thousand token context window sounds enormous until you work on a real application. On my own website project the model could hold the whole thing at first. Then I added Google OAuth, Amazon SES, a blog, and serious relational database work, and before long it could no longer see the whole application. Anyone carrying a legacy monolith hits this immediately. The answer is to build intermediate structures the model can reference: indexes, abstractions, architectural documentation describing the scope it cannot hold on its own. That is architecture work, and it is not going away.

Three weeks to close a one percent gap

The JetBrains 2025 developer survey found that developers now rank internal collaboration and communication as mattering to their performance as much as their technical tools. That matches what I have seen.

I learned it the hard way on a legacy rewrite. An old VB.NET application, junior developers on the team, me as the architect. The project stalled, so I took the reins, and in one week I rebuilt most of the application, doing what would have taken two months five years ago. I thought I had saved it. It backfired completely. We went from sixty percent finished to ninety nine percent in that week, then spent another three weeks reaching a hundred because of the fallout from how little I had communicated. Three weeks to close a one percent gap. That is where projects fail now. Not in the implementation.

Reading code is most of the job

I still spend most of my day reading code, and what I am looking for is no longer syntax errors. Reviewing generated code, I ask four questions. Can I understand this? If I cannot reason about it, it gets rewritten, because these models are non-deterministic and a small change in a prompt produces wildly different output. Are we mixing patterns? Across context windows the model drifts into different architectural habits, and if you let that slide you wake up with competing paradigms fighting each other in one codebase. Does the code do what it was supposed to do? The model has no context about your users or your business and cannot know whether it understood your intent. And is this the right level of abstraction? A model will get the syntax right and miss the architecture entirely.

That review is most of the work. My day runs as a round robin across three or four projects: write a prompt, let the agent work, move to the next one, come back, review, set the next step. Seventy to ninety percent of that time is reviewing rather than prompting. The failures I catch are the vibe coding failures, and they are consistent: off by one errors, confusing logical branches, conditions filtered so tightly no case ever reaches them. There is no clever way to find them. Run the tests, run the linter, run static analysis, then test by hand and listen to the people using it.

What actually matters now

Problem framing, which is understanding what you are solving before you implement. Communication, which is bringing people with you and explaining decisions in terms your stakeholders can act on. Architecture, which is holding the system in view above the level of individual files. Reading and reviewing, not for syntax but for correctness at the architectural level. And testing, because it is the only thing that tells you whether the intent made it through. The shift is moving faster than most developers have noticed. The people who do well will not be the ones who prompt best. They will be the ones who frame the right problem, design the right system, and bring people along while they build it.