When Coding Stops Being the Hard Part 当编程不再是最难的部分
2026-07-03
Why I'm really doing this
One of the quiet reasons I started Homie was selfish: I wanted to learn, as fast as possible, how software engineering changes when AI is the background radiation of everything we build. Reading about it wasn't enough. I needed a loop — build, watch, adjust, repeat — that I could actually spin fast.
I've tried hard to run that loop at work too. And honestly, two things get in the way.
First, a big enterprise system slows down a lot of what I want to try. It's hard to build a tight "empowered by AI" workflow when the surrounding machinery is heavy. Even so, I've made real progress — the room host project is one example. I built whatever I could build, AI at my side, and I made a lot of commits myself, which is frankly not normal for a group engineering manager. You can argue whether that's the right use of my time. I think I was useful to the team and the project, and I learned a ton. That's the part that matters to me, and I'm genuinely out on the front edge of figuring out how AI lifts our productivity.
But we're moving too slow. I feel it every week.
Second, and more personal: after fourteen years at Microsoft, I've been thinking a lot about where my energy goes and what I want it to add up to. The team is working at the fastest cadence I've ever seen, and that kind of pace makes you ask the honest questions — what am I optimizing for, and over what horizon? Some of that reflection is why I've been pouring more of my nights into building for myself. Not instead of the day job, but as the place where I can run the experiment at full speed and see clearly what's real.
I'm not stepping back, though. I still bring every bit of my learning back to my team, my org, my org leader. Deep down I'm grateful for what Microsoft gave me — it shaped how I think, and I try to pay that forward every day.
Okay. Reflections logged. Back to the actual topic.
Coding stopped being the problem
Here's the shift I keep coming back to: coding is no longer the hard part. Building the thing that fits your needs is.
That reframes everything. If code is cheap, the scarce thing becomes fit — and fit is deeply personal. Full customization is the way forward.
That's the whole idea behind Homie: practice building a fully autonomous system that helps me build and maintain software — self-healing, self-evolving. We are nowhere near "set it and forget it." Humans still need to pay real attention and correct its course. But it gets a little better every day.
A small milestone that made me smile: today I opened the backlog and it was empty. Nothing from the agent system needed my attention. The whole thing had been running reliably on its own. So I got to spend my time on ideas instead of firefighting. I still nudge it now and then — "keep improving the tests," that kind of thing — but that doesn't feel like overhead. It feels like managing something that mostly manages itself.
And the payoff is enormous: turning ideas around in hours, not days or weeks. That single change is a massive tailwind.
What the SW engineer becomes
If I had to bet, most of us become something like an AI infra developer. We won't hand-write features so much as maintain an AI infrastructure — an agent fleet — and use it to empower people to build what they actually need.
Homie is my proof-of-concept for that. If I open-source it along with its agent fleet, the idea is simple: any individual, any family, can take it, deploy it, and just ask it to improve itself to fit their life. Not there yet. But I see solid, real progress toward it.
I'm mapping the same thing back onto my professional life — backfilling every lesson into my teams and encouraging them to do the same. I know the limits. But we have to move; we have to do something. And it's timely: one of my org leaders is now pushing people to build fully autonomous systems. I already have good practices to bring to that. Getting it to work on a big, bulky enterprise system is genuinely hard — but we're trying.
A guess at the business model
Here's where I think this lands:
- Software becomes a skeleton — a company ships a base, but a very rich framework.
- Consumers (or other enterprises) customize it themselves using an AI fleet, building to their own needs.
- Humans sit behind it, on standby, for when it truly matters.
We all drift toward a consulting role: providing customization, not shipping monoliths. I suspect the new Microsoft "frontier" direction is chasing a similar shape.
If that's right, a lot of old furniture goes away. The long DCR-style process — lengthy, ceremony-heavy — is gone. Features should land in hours or days, not weeks. The system self-heals and only surfaces to a human when it genuinely needs one.
What this asks of us
That world needs a different engineer. For a skeleton system, you need people with strong domain knowledge — or the ability to learn it on the fly, in flight. And once the AI fleets are running, you need people who can maintain and keep learning from them, because they'll keep changing under you.
I don't have this fully worked out yet. I'm figuring it out the only way I know how — by running the experiment twice, once on Homie at home and once in my day job — and watching what actually holds.
More once I learn more. :)
我为什么真的在做这件事
启动 Homie 有一个我一直没怎么明说的、有点自私的理由:我想尽快搞明白,当 AI 成为我们构建一切事物的背景辐射时,软件工程到底会怎样改变。光是读文章不够。我需要一个能真正跑起来、而且能跑得飞快的循环——构建、观察、调整、再来一遍。
我也一直努力想在公司里跑通这个循环。老实说,有两件事挡在路上。
第一,庞大的企业级系统会拖慢我想尝试的很多东西。当周围的机器又重又复杂时,你很难打磨出一套紧凑的"被 AI 赋能"的工作流。即便如此,我还是有实打实的进展——room host 项目就是一个例子。凡是我能亲手搭的,我都搭了,AI 就在我身边,而且我自己提交了大量的 commit,坦白讲,这对一个 group 工程经理来说很不寻常。你当然可以质疑这样花我的时间是否值得。但我觉得自己对团队、对项目是有用的,我也学到了非常多。这才是我在意的部分,我确确实实站在"AI 如何提升我们生产力"这件事的最前沿去摸索。
但我们走得太慢了。这一点我每周都能感觉到。
第二,也更私人:在微软待了十四年之后,我一直在想,我的精力都花去了哪儿,我希望这些精力最终汇成什么。团队现在的节奏是我职业生涯里见过最快的,而这种速度会逼着你去问那些诚实的问题——我到底在为什么优化,又是在多长的时间尺度上优化?正是这些思考的一部分,让我把越来越多的夜晚投进了给自己做的东西里。不是拿它取代白天的工作,而是把它当成一个我能全速跑实验、能看清什么是真的的地方。
不过我并没有往后退。我依然把我学到的每一点都带回我的团队、我的组织、我的组织负责人那里。内心深处,我很感激微软给我的一切——它塑造了我思考的方式,我也努力每一天把这份东西传下去。
好了。感想记录完毕。回到正题。
写代码不再是难题
有一个转变我一次次绕回来想:写代码已经不是难的那一环了。做出那个真正贴合你自己需求的东西,才是。
这句话重新定义了一切。如果代码变得廉价,那稀缺的就变成了"贴合"——而贴合是极其私人的事。彻底的定制化,才是往前走的路。
这就是 Homie 背后的全部想法:练习去搭建一个完全自主的系统,让它帮我构建和维护软件——会自我修复、自我进化。我们离"一劳永逸、撒手不管"还差得远。人依然需要真正投入注意力,去纠正它的方向。但它每天都在变好一点点。
有一个小小的里程碑让我会心一笑:今天我打开待办清单,发现它是空的。这套 agent 系统没有任何东西需要我操心。整个系统一直在自己可靠地运转。于是我可以把时间花在想法上,而不是四处救火。我偶尔还是会推它一把——"继续把测试做得更好"之类的——但那不像是额外负担。那感觉更像是在管理一个基本上会自我管理的东西。
而回报是巨大的:把一个想法落地,用的是几小时,而不是几天或几周。单单这一个变化,就是一股巨大的顺风。
软件工程师会变成什么
如果一定要押注,我猜我们大多数人会变成某种AI 基础设施开发者。我们不再靠手写功能,而是去维护一套 AI 基础设施——一支 agent 舰队——并用它去赋能人们,让他们造出自己真正需要的东西。
Homie 就是我为这件事做的概念验证。如果我把它连同它的 agent 舰队一起开源,想法很简单:任何一个个人、任何一个家庭,都能把它拿走、部署起来,然后直接让它去自我改进,贴合他们的生活。还没到那一步。但我看到了扎实、真实的进展。
我也在把同样的东西映射回我的职业生涯——把每一条经验都回填给我的团队,并鼓励他们也这么做。我清楚其中的局限。但我们必须动起来,必须做点什么。而且时机正好:我的一位组织负责人现在正推动大家去构建完全自主的系统。我手上已经有一些不错的实践可以带过去。想让它在一个庞大、笨重的企业级系统上跑起来,是真的难——但我们在试。
对商业模式的一个猜测
我觉得这件事最终会落在这里:
- 软件变成一副骨架——公司交付一个底座,但那是一个内容极其丰富的框架。
- 消费者(或别的企业)用一支 AI 舰队自己去定制它,照着自己的需求去搭。
- 人坐在它身后待命,等到真正要紧的时候才出手。
我们都在朝着一种咨询顾问的角色漂移:提供的是定制,而不是交付大而全的整块产品。我怀疑微软新的"frontier"方向,追的也是类似的形状。
如果这判断没错,很多老家具就该扔掉了。那种冗长的、DCR 式的流程——又长、仪式感又重——没了。功能应该在几小时或几天内落地,而不是几周。系统会自我修复,只有在真正需要人的时候才浮出水面。
这对我们提出了什么要求
那样的世界需要一种不一样的工程师。对于一个骨架式的系统,你需要具备深厚领域知识的人——或者能在飞行途中、一边飞一边学会它的人。而一旦 AI 舰队跑起来,你还需要能维护它们、并持续从它们身上学习的人,因为它们会在你脚下不停地变。
这些我还没完全想透。我只会用我唯一懂的办法去摸索——把这个实验跑两遍,一遍在家里的 Homie 上,一遍在我的本职工作里——然后看什么东西真的立得住。
等我学到更多,再写更多。:)