软件工程卷土重来
Coding agents have replaced every framework I used

原始链接: https://blog.alaindichiappari.dev/p/software-engineering-is-back

## 真正的软件工程的回归 人工智能的最新进展,特别是前沿模型和编码代理,正在从根本上改变软件开发——自2025年12月以来,这种转变感受尤为强烈。这不仅仅是“感觉良好的编码”,而是一个新的“自动化编程”时代,类似于过去由印刷机等工具引发的工业革命。 关键变化是什么?消除了繁琐的手动编码。开发者现在可以专注于*架构*解决方案——设计、权衡和边缘情况——而人工智能负责大部分代码生成。这使得快速工具创建成为可能,并回归到核心工程原理,绕过了对复杂且通常不必要的框架和库的需求。 这些框架最初旨在简化开发,但往往会引入更多问题,阻碍真正的创新和知识产权。它们也服务于隐藏的目的:通过创建依赖于供应商生态系统的专业角色(如“React开发者”)来降低劳动力成本。 有了现成的自动化工具,开发者现在可以构建定制化的工具,甚至利用Bash等几十年历史的技术,并专注于解决*实际*问题,而不是预期的那些问题。这代表着回归到真正的软件工程——构建针对独特需求量身定制的解决方案,而不是将想法塞入预定义的框架中。革命已经到来;现在是时候构建真正属于你自己的东西了。

## 软件工程的潜在转变 最近Hacker News上的一场讨论集中在人工智能是否真正改变了软件工程,还是仅仅改变了编写代码的*方式*。虽然人工智能可以自动化代码生成,但许多评论员认为核心挑战不是代码本身,而是*思考*——定义需求并将它们转化为功能系统。 一些用户指出,这与Vim/Emacs等工具的争论相似:如果编写代码一直以来都是价值最低的部分,那么仅仅自动化它并不一定能增加显著价值。人们担心依赖人工智能可能会阻碍对底层代码的理解,尤其是在复杂领域。 另一些人则对人工智能能够超越“管道”和繁琐任务的潜力表示兴奋,从而使工程师能够专注于更高层次的设计和创新。人们渴望摆脱渐进式改进,拥抱更具未来感的软件开发方法。然而,一个关键点是需要避免盲目采用人工智能生成的解决方案而没有批判性评估,以及失去宝贵的抽象技能的风险。最终,这场争论凸显了对系统设计和概念理解*高于*纯粹编码能力的重视的转变。
相关文章

原文

I don’t post a lot. But when I do, it’s because I think few people are saying out loud what I’m noticing.

I’ve been building a product from the ground up. Not the “I spun up a Next.js template” kind of ground up. I mean from network configuration to product design to pricing decisions. Truly end to end. And I’ve been doing it using frontier models and coding agents for hours and hours every single day, both on this project and in my full time work. I’ve been trying to stay away from the chaos and the hype, filtering hard for what is actually valuable.

Since December 2025, things have dramatically changed for the better. Many have noticed. Few are drawing the right conclusions.

Antirez likes to call it “automated programming”, and I really like that framing. It captures the essence far better than the shallow, almost dismissive label of “vibe coding”. Automation was at the core of most of the work and cultural revolutions of human history. The printing press, the loom, the assembly line. This one doesn’t differ much.

Most of my work is still there. I still have to deeply think about every important aspect of what I want to build. The architecture, the trade offs, the product decisions, the edge cases that will bite you at 3am. What’s gone is the tearing, exhausting manual labour of typing every single line of code.

At this point in time, models and tools, when put in a clean and maniacally well set up environment, can truly make the difference. I can be the architect without the wearing act of laying every single brick and spreading the mortar. I can design the dress without the act of cutting and sewing each individual piece of fabric. But I can do all of this with the experience on my back of having laid the bricks, spread the mortar, cut and sewn for twenty years. If I don’t like something, I can go in, understand it and fix it as I please, instructing once and for all my setup to do what I want next time.

Automated programming especially allows me to quickly build the tools I need so fast that every blacksmith that ever existed on this earth would envy me deeply. Finally able to really focus on the things they have in mind. Finally dedicating more time of their craft to the art they conceive, not the sweat of the forge.

It’s been months now that I have this thought crystallized in my mind. It is so clear to me that I genuinely don’t understand why everyone is not screaming it to the world.

We can finally get rid of all that middle work. That adapting layer of garbage we blindly accepted during these years. A huge amount of frameworks and libraries and tooling that has completely polluted software engineering, especially in web, mobile and desktop development. Layers upon layers of abstractions that abstract nothing meaningful, that solve problems we shouldn’t have had in the first place, that create ten new problems for every one they claim to fix.

Think about what happened. We, as an industry, looked at the genuine complexity of building software and instead of sharpening our thinking, we bought someone else’s thinking off the shelf. We wrapped everything in frameworks like wrapping a broken leg in silk. It looks nice. The leg is still broken.

In my mind, besides the self declared objectives, frameworks solve three problems. Two explicit and one obvious but never declared.

“Simplification”. Software engineers are scared of designing things themselves. They would rather accept someone else’s structure, despite having to force fit it into their product, rather than taking the time to start from the goal and work backwards to create the perfect suit for their idea. Like an architect blindly accepting another architect’s blueprints and applying them regardless of the context, the needs, the terrain, the new technological possibilities. We decided to remove complexity not by sharpening our mental models around the products we build, but by buying a one size fits all design and applying it everywhere. That is not simplification. That is intellectual surrender.

Automation. This is the only point I can actually, more or less, understand and buy. Boilerplate is boring work. I hate it. And I especially hate using libraries that I then need to study, keep updated, be aware of vulnerabilities for, just for the purpose of removing the creation of duplicated but necessary code. Think about ORMs, CRUD management, code generation, API documentation and so on. The grunt work that nobody wants to do but everybody needs done. Fair enough. But hold that thought, because this is exactly the point where everything changes.

Labour cost. This is the quiet one. The one nobody puts on the conference slide. For companies, it is much better having Google, Meta, Vercel deciding for you how you build product and ship code. Adopt their framework. Pay the cost of lock in. Be enchanted by their cloud managed solution to host, deploy, store your stuff. And you unlock a feature that has nothing to do with engineering: you no longer need to hire a software engineer. You hire a React Developer. No need to train. Plug and play. Easy to replace. A cog in a machine designed by someone else, maintaining a system architected by someone else, solving problems defined by someone else. This is not engineering. This is operating.

In my opinion Software engineering, the true one, is back again.

I am not speaking out of my lungs only. I’ve been developing this way almost flawlessly for over two years at this point. But the true revolution happened clearly last year, and since December 2025 this is obvious to anyone paying attention. From now on it will be even more so.

We have the chance again to get rid of useless complexity and keep working on the true and welcome complexity of our ideas, our features, our products. The complexity that matters. The complexity that is actually yours.

Automation and boilerplating have never been so cheap to overcome. I’ve been basically never writing twice the same line of code. I’m instantly building small tools I need, purpose built, exactly shaped around the problem at hand. I don’t need any fancy monorepo manager. A simple Makefile covers 100% of my needs for 99% of my use cases. When things will get very complicated, and if they get very complicated, I’ll think about it. But only then. Not a second before. This is engineering. You solve the problem you have, not the problem someone on a conference stage told you that you’ll eventually have.

Agents are really well prepared when it comes to basic tools. Tools that have been around not for months, but literally for decades. Bash was born in 1989, just preceding me by two months. The most mediocre model running at this time knows bash better than any person in the world. Bash is the universal adapter. It is not a coincidence that coding agents are shifting from complex and expensive MCP configurations to a simple agent loop with bash as a way to interact, literally, with the world. The oldest tool turned out to be the most future proof. There’s a lesson in there if you care to listen.

Really think about it.

Why do you ever need, for most of the use cases you can think of, a useless, expensive, flawed, often vulnerable framework, and the parade of libraries that comes with it, that you probably use for only 10% of its capabilities? With all the costs associated with it. From the “least” expensive: operational costs like keeping everything updated because they once again found a critical vulnerability in your Next.js version. To the most expensive one: the cost to your Design Choices. The invisible cost. The one you pay every day without even realizing it, because you’ve been paying it so long you forgot what freedom felt like.

If you keep accepting this trade off, you are not only losing the biggest opportunity we’ve seen in software engineering in decades. You are probably not recognizing your own laziness in once again buying whatever the hyperscalers have decided for you. You’re letting Google and Meta and Vercel be your architect, your designer, your thinker. And in exchange, you get to be their operator.

The tools are here. The models are here. The revolution already happened and most people are still decorating the old house.

Stop wrapping broken legs in silk. Start building things that are yours.

联系我们 contact @ memedata.com