Confessions of a Programmer: The Three Career Pillars I Spent 10 Years Building Are All Collapsing—Why Not Become a Carpenter?

AI is forcing office workers to undergo a painful transformation. When we focus on an individual's story, this pain becomes very concrete.

Recently, a post titled "LLMs Are Eroding My Software Engineering Career, and I Don't Know What to Do" caught people's attention on Hacker News.

The author is a software engineer with 10 years of experience. His career path seemed quite clear: starting from the front - end, transitioning to the back - end, and delving deep into the finance and payment fields, accumulating a set of professional knowledge such as PCI compliance, double - entry accounting, idempotency to prevent duplicate deductions, and payment lifecycle management. He was once certain that this domain knowledge, gained from "real - world" project experiences, was the foundation for his career in the industry.

However, he described his career experience in the past two years as "Three Pillars Collapsing One by One."

The First Pillar: Domain Expertise

Last year, he was hired by a company in the finance field. Previously, although the companies he worked for also involved payment and finance modules in their operations or products, they were not purely finance - centric enterprises.

This company fully embraced artificial intelligence. So, from his first day at work, he was given enterprise - level accounts for ChatGPT and Claude and was encouraged to use these tools in research, exploration, and even coding. However, he was reminded that he still had to review and be responsible for every line of code that went into the production environment.

One of the first projects he took on was to refactor a messy old - version online payment system. The company valued his past experience in building such systems and entrusted this task to him, placing their trust in him.

Different from other companies he had worked for, this company expected the "design documents" he wrote to be understandable not only by engineers but also by product managers. So, the documents couldn't be overly technical deep dives but rather more like architectural views. He completed the first document with little help from AI. At that time, he even called large language models "random parrots" (he no longer holds this view now) and delivered the results.

He cherished his knowledge and believed that no large language model could replace it.

Then his manager talked to him: "Although you delivered the code at a good pace, it took you too long to write these design documents. Did you use AI? You should use more AI."

He thought to himself, "This will never work." But he still agreed. The models at that time were not as powerful as they are now, but they did significantly improve his writing efficiency and even assisted in decision - making.

Then he began to realize that all the knowledge he had accumulated over the years - the trade - offs between different implementation solutions, how the acquiring mechanism worked, and how to build idempotency to prevent duplicate deductions - all were becoming worthless. Although the models still needed some guidance, they could already piece together the key points of designing such systems on their own, which was the most difficult part and usually took years of practical experience to form in one's mind. This was the first shock he encountered.

But then he thought: The models can do this because there are a large number of articles on the Internet explaining the principles of such systems, all the technical documents, and a large number of blog posts on how to apply technical tools to the business field. It takes a long time for humans to learn all this, but these things are the training data, so the models can naturally learn them.

The area where models will never be good at and humans will shine is - debugging! He has rich experience in debugging race conditions and distributed systems in the production environment. This used to be the guarantee for him to keep his job.

The Second Pillar: Debugging and Distributed Systems

After large language models became good at writing documents and assisting in planning specific implementations, they also became good at coding. This started with the Claude Code craze in the second half of 2025, followed by the emergence of tools like Codex. Although he used large language models to write unit tests every day before, he didn't trust them to directly complete the full implementation.

Naturally, the next step was to introduce more AI into the coding process. To be honest, he liked it. He liked both coding and launching products and seeing satisfied users, so it was just a matter of replacing one thing he liked with another, which was quite fair.

Large language models are getting better and better at coding, but they still can't deal with the mess left by debugging (whether it's the models or humans). So, he still has a role bigger than just "controlling robots" - this is his ticket to keep his job.

Everything seemed to be going well.

Then, MCP, agent workflows, and Claude 4.5 appeared, and the sky started to fall.

To be honest, Claude 4.5 isn't that great. Given a stack trace and some context (in most cases, turning on Sentry MCP and providing a Sentry link is enough), it can solve about 60% of the defects. Sometimes, it gives solutions that sound reasonable but are completely wrong.

However, this time, he no longer doubts the machine's ability. He saw that defects that used to take a whole day of full - time debugging to solve were solved by Claude Code at once. Of course, not all of them, but the trend is obvious.

Then 4.6, 4.7, GPT 5.5, Opus 4.8, and DataDog MCP came out one after another... Now the command - line tools he has can solve defects across distributed systems at once, those defects he couldn't solve in the past, those that needed two full days of dedicated debugging. Those cross - system defects lacking distributed observability. Now 90% of the defects can be solved at once, including strange race conditions, unexpected edge cases, third - party integration issues, and undocumented API boundary situations - everything. He hardly needs to intervene.

Of course, he still has work to do because someone has to review the code and control the robots. But now he's just an ordinary and easily replaceable engineer. Any of his domain expertise can be easily matched by another senior engineer who controls large language models. He feels that all his knowledge in the finance and payment fields, all the debugging intuitions and distributed system knowledge gained through hard work, can now be obtained through prompts.

We were told that generalists and specialists will always have their own places. But now the market is turning everyone into generalists. This isn't necessarily a bad thing - until you look at the economics of supply and demand: If everyone becomes a generalist and there isn't a matching demand, the price of generalists will drop. And we all know that the demand is drying up.

The Third Pillar, the One That Hasn't Eroded: Code Quality and Architecture

However, he still has one pillar standing: code quality and software architecture - what is now simply referred to as "taste."

Throughout his career, he has always liked refactoring, valued high - quality code, and tried to find time to do it during iterations. He is familiar with buzzwords like DDD, hexagonal architecture, and clean architecture. He likes this topic and likes to discuss different trade - offs and ideas for shaping the codebase. He really does.

This is the last standing pillar. It's just that no one cares now.

Agents are really bad at keeping the codebase clean. If you don't guide them, they will quickly run into circular dependency problems. They will duplicate code, add irrelevant comments, mix pure functions and side - effects, and ignore the SOLID principles.

This should have allowed humans to keep their jobs, but this skill has now been reduced to the word "taste." But it's not just a rename - The whole industry is moving towards a world where code organization isn't that important.

Yes, humans should guide agents to prevent a spaghetti - like codebase with circular dependency graphs. No one wants an F - grade codebase that breaks at the slightest touch. But what about a C - grade or D - grade? It's now completely acceptable. There's no need for an A - grade or B - grade codebase anymore because the code is written for large language models, not for humans to read.

He doesn't want to argue whether this is good or bad. If the source code is now written for machines rather than humans to read, then aiming at machines might be okay.

But this is another pillar of his professional skills that is eroding. The large amount of knowledge he has accumulated in this area is no longer as valuable. All the time he spent - reading books, doing practical exercises, discussing with other engineers, and writing architectural decision records - is becoming useless.

What to Do Next?

The author says that he still has a job and believes that he will still be employed in the foreseeable future (at least in this company), but he doesn't know how to view the long - term situation.

He spent ten years (even longer if non - professional experience is included) mastering things that are becoming less and less valuable. His last professional pillar is now reduced to "taste," and it probably won't last long.

And he knows that he's not the only one in this situation. About eight months ago, his current company had a round of layoffs (allegedly not related to AI). Some excellent former colleagues were laid off and are still looking for jobs. Most of them face the same problem: their domain expertise is no longer enough to make them stand out.

The company is now starting to recruit a small number of positions, and domain familiarity is no longer a strong differentiating factor. In the past, they would recruit "Software Engineer - a certain field." Now they just write "Software Engineer," and the team assignment is done after employment.

Of course, this is good for those excellent engineers who never had the opportunity to delve into a specific field and now have better employment opportunities. But it's also sad to think that other excellent engineers who spent their whole lives accumulating domain knowledge now have to compete on the same track.

The author believes that the only way to keep his job in the long term seems to be to shift his domain expertise to areas that are not easily mastered by large language models. But what's left?

He once considered going back to school to study mathematics, statistics, and advanced machine learning and then applying for research positions in cutting - edge laboratories. However, there are no cutting - edge laboratories in his country. The few existing ones receive a huge number of applications, and he can't move to other countries due to family reasons. By the time he has the conditions to make this leap, RSI might have made researchers redundant.

Finally, he wrote a joking line: "Maybe I should consider turning my woodworking hobby into a career..."

Responding to Controversies

After this blog was published, it was widely spread on social media. The author picked out some representative comments and replied to them.

Regarding "Is Domain Knowledge Really Useless? For Example, Local Tax Regulations"

Some comments pointed out that large language models often make mistakes in dealing with local tax regulations, accounting process details, ledger implementations, etc. How can they replace human domain knowledge?

The author admitted that he didn't make it clear in the original article. LLMs really can't automatically handle all local tax laws or extremely detailed rules - but these are usually handled by the legal team (and the legal team is also using a lot of LLMs to automate routine work). The problem is that the domain knowledge he accumulated over the years (although much shallower than that of the legal team) can now be directly prompted with ChatGPT Pro/Extended Thinking. This is what makes him frustrated - he used to think that having this knowledge would make him stand out in a world of "code - only" programmers, but that's no longer the case.

As for agents not being good at such details before, he admitted it. But with new models, agent - oriented documents, and putting AGENT.md in the root directory of the codebase to force agents to read the documents before writing code, the situation has changed. He needs to ask his colleagues who have been in the company longer and know the details less and less. Now the human input he needs to complete his work has been greatly reduced - think about it, it's scary.

Regarding "Your Company's Manager Asking You to Use AI to Speed Up Design Documents Is So Unreliable"

Some comments thought that a manager in a fintech company suggesting using AI to speed up writing design documents shows that the company is too careless about money - related business.

The author agreed that it was unreliable, but he had his own way to deal with it:

Write general documents: Only put relatively general content like state machines in the design documents, leaving space for himself to implement carefully. After the arrival of AI (and layoffs), everyone is buried in long documents and PR reviews, and the reviewers are far less picky than before.

Make a fuss on the project board: He always adds some end - to - end testing tasks to find defects and submit defect/improvement reports before the function is released. This gives him time to carefully review the implementation. In addition, he splits sensitive core implementations into more task cards than usual to implement and review calmly.

Does he like doing this? Of course not. But what choice does he have? From the feedback of people he knows, his company is not the most extreme case of "ambient programming." It's not worth jumping to a possibly worse environment. At least here, he knows how to control the anxiety of relevant parties (his prudence and carefulness have earned him a good reputation), and the company doesn't force him to fully enter "ambient programming."

Regarding "You Need to Learn to Surf. It's the Same with Every Technological Wave"

Some comments said that you rode the wave of websites/webapps before, and now it's just a new wave. Learn new skills, master the tools, and the game remains the same.

The author said that he agreed and was doing exactly that. He is one of the engineers in the company who continuously improves the agent toolchain, conducts adversarial code reviews with different models, and keeps his skills and prompt tool library up - to - date. He has actually become a so - called "AI - native engineer" (although he hates this term).

But he is more worried about the future.

If the models and their toolchains continue to get stronger at the same pace in the next few years, the software engineering profession will be completely commoditized. Some people will mention Jevons' Paradox (efficiency improvement leads to increased demand), but he doesn't agree. There must be an upper limit to software demand.

He took copywriting as an example. This profession used to require years of practice and had a good income. After the peak demand brought by e - commerce and advertising technology, the market gradually became saturated, and LLMs directly destroyed the jobs of most practitioners. The reason is simple: most of the demand comes from small companies, and the copywriting generated by ChatGPT is enough for them. A few companies will still hire people for prompting, reviewing, and sending, but the demand is not infinite, and not everyone can find such a job. One copywriter can now do the work of ten people in the past, but the total demand is fixed. The demand won't become ten times just because you