After writing code is no longer scarce, what is left for software engineers?
Scott Bolinger believes that the stronger the models become, the more pure technical skills depreciate. What is truly scarce is judgment, validation, business understanding, and human experience. The comments add more specific points.
Scott Bolinger wrote an article titled 《What a software engineer should do now》, translated and recommended by Baoyu. The core judgment of the article is very direct: every time a new model is released, the value of pure technical skills shrinks by one point.
Scott says he increasingly feels like a product manager managing AI every day, and the need for deep technical knowledge is decreasing. The technical moat he once thought was solid has dried up. Writing a user story as a prompt can even work better than a rigorous technical plan.
He also admits a sense of loss. In the past, developing SaaS was a high-barrier challenge, and he enjoyed burying himself in polishing an app and watching it become reality. Now AI can solve these hard problems he used to handle often, and the skills have become almost worthless, which is a blow. He chooses to turn to fields that still have real hard problems and to enlarge his scope.
He cites David Deutsch’s The Beginning of Infinity: as long as it does not violate natural laws and you master the right knowledge, everything is possible. Innovation has no end. Computers eliminate old jobs, but they also create more new ones. AI is the same: it gives more capability to do things, and it also demands a change in thinking.
By old thinking, making a SaaS app is a big deal. Now developing complex enterprise software is easier than building a simple website five years ago. So-called doing big things requires thinking at a larger scale: national level, global level, cosmic level. What can a team of 100 people do? What about 1,000? Extremely low-cost productivity should not be used only to make a few apps.
Engineers need to broaden their capability boundaries. They need to step out of the tech circle and understand the business loop: product, marketing, sales. Scott’s approach is to learn things AI cannot help with: product positioning, creativity, moving people’s hearts, psychology, marketing. These human problems have no standard answers and no ready-made test sets. AI is good at pattern matching, but it cannot truly understand the experience of being human.
The comments add more specific points: one netizen says that in the past resumes said proficient in eight languages, but in the future they may say able to lead eight Agents simultaneously without crashing. Someone summarizes that writing code will depreciate, but choosing problems will not; the stronger the model, the greater the cost of choosing the wrong direction. Another person tried writing user stories as prompts, and the model understood the requirements faster, saving back-and-forth. But another reminds that people who can write good user stories are often people who have stepped in technical pits.
Validation is a hard problem. Agents following vague acceptance criteria will deliver a bunch of things that look right, and in the end humans still have to verify them line by line. Read the diff or run tests first? Every engineer must have their own answer.
A netizen who managed an organization of 300 to 400 people says that the engineers you truly cannot let go are about 10. They are not just technical experts; they also understand product and integration. Together with product owners and project managers, they keep things moving.
Some also disagree with Scott assigning psychology entirely to humans. AI is very good at finding patterns. A more robust statement might be: coexist and cooperate with AI, do not abandon existing knowledge, build a broader knowledge system, and give up nitpicking details.
The truly piercing part of this piece is not that code is written by AI. The tech stacks you stayed up learning suddenly are no longer core competitiveness; this repricing is harder to digest. After the moat dries up, the threshold shifts elsewhere: judging direction, validating results, understanding the people who pay, understanding human experience. Writing code is still useful, but it has changed from an identity to a tool. The question lands in daily work: can you verify it, can you choose the right direction, and are you close enough to the people who pay?
发布时间: 2026-11-13 08:28