Which Software Engineering Skills Still Matter With AI

An engineer with ten years of professional experience, most of it in payments and finance backends, published an essay this month titled LLMs are eroding my software engineering career and I don't know what to do. It is a first-person account of what agentic coding tools have done to the market value of accumulated expertise, with specific capabilities, tools, and dates. It documents the shift and shows where the pessimism runs ahead of the evidence.

What the essay claims

The author describes his career as three pillars that eroded in sequence.

The first was domain expertise. He spent years in finance, bookkeeping, and payment processing: PCI compliance, double-entry ledgers, escrow, reconciliation, payment lifecycles, bank transfer idempotency. When he joined a finance-focused company last year, he got ChatGPT and Claude Enterprise accounts on day one, with the standing instruction that he review and own every line reaching production. He wrote his first design doc for a legacy payment system rework with minimal AI assistance, back when he still called LLMs "stochastic parrots." His manager's feedback: the code is arriving at a good pace, but the design docs are too slow. "Are you using AI? You should use more AI." When he complied, he found the models could connect the dots on how to structure payment systems, which he considered the hard part that develops after years of hands-on work.

The second pillar was debugging, distributed systems especially, and it eroded on the timeline he gives.

The third pillar, the one he says is still partially standing, is code quality and architecture, which he watches being compressed into the single word "taste."

The debugging numbers

Agentic coding took off in the second half of 2025 with Claude Code, then Codex. Claude 4.5, given a stack trace and some context (in most cases a Sentry link with the Sentry MCP enabled), solved around 60% of bugs, and sometimes returned a fix that sounded plausible but was wrong. Then came 4.6, 4.7, GPT 5.5, Opus 4.8, and the DataDog MCP, and he now reports 90% of bugs one-shotted: race conditions, unexpected corner cases, third-party integration issues, undocumented API edge cases. These bugs previously cost one or two days of full-time debugging, some across distributed systems that lack distributed observability.

The jump from 60% to 90% is partly a model-capability story. Both endpoints have an MCP server in them. Model iteration and direct agent access to production telemetry changed between them. Senior debugging skill has always included knowing where to look: which dashboard, which trace, which log line correlates with which deploy. Once Sentry and DataDog are wired into the agent's context, the search becomes enumerable, and the agent can afford to look everywhere.

Someone at his company gave the model the same evidence the human debugger used by doing the integration work. Engineers who can build that plumbing (connecting observability, defining what context an agent gets, deciding what a one-shot fix must prove before merging) are doing work that still has a buyer, because his own 90% number depended on it.

Did domain expertise lose its market value?

His explanation for the first pillar is that payments is a well-documented domain. There are articles on how acquiring works, technical documentation, blog posts applying the tools to the domain. All of it is training data, so the model picks up in pretraining what took him years to absorb on the job. That explanation holds, and it generalizes: any domain expertise that exists as public prose is compressible into a model, and its market premium will get compressed with it.

A hiring signal supports it. His company ran a layoff about eight months before he wrote (not AI-related, according to the company), and colleagues with deep domain backgrounds are still searching. The company is hiring again, and where it used to list roles as "Software Engineer - Area," it now lists plain "Software Engineer," with team assignment coming after the offer is accepted. Job titles are a lagging indicator of what employers think they are paying for, and that title change says domain familiarity stopped being the differentiator it was.

Tacit knowledge is bound to a single employer: which reconciliation edge cases this company's auditors flag, why the ledger schema carries that vestigial table, what a specific payment provider's support team will escalate. Models have none of that. It makes you valuable where you are and hard to price anywhere else. The portable, resume-legible form of domain expertise got marked down.

Is code architecture still worth learning?

His last pillar deserves more pushback than he gives it. He lists the agent failure modes himself: circular dependency graphs, duplicated code, unnecessary comments, pure functions mixed with side effects, SOLID disregarded. Then he argues nobody needs A or B grade codebases anymore because code is being written for LLMs rather than humans to read, so a C or D is now acceptable.

Every failure mode on his list degrades the agents themselves. A codebase with circular dependencies and heavy duplication forces an agent to load more context per change and raises the odds that an edit in one place silently breaks behavior in another. If 90% one-shot fixes are the new baseline, the structural quality of the repository is one of the variables that baseline depends on. Code quality is now judged by agent reliability. Measure whether an agent can modify the code without breaking it, which rewards explicit interfaces, strong test harnesses, and boring structure over cleverness. Years spent on DDD, hexagonal architecture, and ADRs apply to that metric.

Supply and demand

If models flatten domain expertise, everyone competes as a generalist, and if demand does not grow to match, the price of a generalist falls. He notes the demand side is drying up, and the still-searching ex-colleagues back that up. Employers are paying less for generalist engineers.

His employer attached a clause on day one: review and own every line. He remains employed because of it, and fulfilling it requires the expertise he undersells. At a 60% solve rate, he was catching fixes that sounded plausible and were wrong; distinguishing those from the correct 60% took the expertise he calls worthless. At 90%, the remaining 10% are selected for difficulty, since everything with a clean telemetry trail has already been picked off, and the review burden is now different. An engineer who has personally debugged double-charge bugs knows what a wrong idempotency fix looks like. That knowledge lets reviewers identify incorrect idempotency fixes before merging.

The 90% debugging rate exists because of integration and verification work, and someone gets paid to design it, extend it, and decide when its output can be trusted. The expertise he spent ten years building would make him better at that job than the off-the-shelf engineer he fears becoming. Job listings that say plain "Software Engineer" show the repricing is still in progress.