告诉HN：我对与人工智能合作和构建软件的一些领悟
好的，这是我的总结。
我意识到的是：人工智能是你自身特质的放大器。它不是替代品——它只是反映并放大你带来的东西。
年轻时，我常常直接冲向墙壁，试图快速攀爬。我会对问题抛出大量代码。这并不是因为粗心大意——我是在快速迭代，寻找一个能给我反馈的可行原型。结构和架构对我来说并不那么重要——我想要的是达成目标、概念和具体结果。
这实际上是有效的。我以这种方式构建了很多东西。
但我以为人工智能会“处理”其余的事情——它会照顾复杂性，或者清理问题。而我现在看到的是，人工智能只是反映你的方法。如果我处于“把代码扔向墙壁”的模式，人工智能只会帮助我更快地做到这一点。这可能有帮助，但它不会让问题消失。它只是加速了你已经在进行的节奏或方法。
如果你在设计系统，它可以帮助你做得更好。如果你陷入了迭代的漩涡，它可能会让你更快地被卷入——除非你有意识地走出来，采取更广阔的视角。
这是我一直在努力追求的成熟——退后一步，花时间更广泛地思考，看看架构需要如何演变以支持我想要构建的真实模型。因为最终，构建良好的软件不仅仅是实现功能，而是掌握应用程序中的数据和逻辑流。
这里有一些微妙的东西——就像跨越“所有技术上都能作为概念验证”的门槛到“这是一个稳健、可扩展的系统”。复杂性不在于功能本身，而在于处理状态空间、过渡和边界。它在于将实现与模型对齐。当这些不同步时，你会不断感受到无形的摩擦——即使你无法立即指出它，你也知道它的存在。
今天我有一个时刻帮助我理清了这一点。我专注于一个功能——切换标签并保持焦点状态——乍一看，这似乎没什么大不了。但我就是知道它很重要。事后看来，这是一种天才的直觉。因为解决这个功能意味着证明对数据流和应用程序内部一致性的更广泛掌握。它迫使架构朝着正确的方向演变。
所以这是第二种复杂性——不是关于实现概念验证，而是关于将系统打磨成真实且可用的东西，能够在增长的同时保持完整。能够将这种无形的挑战聚焦成一个具体的目标——这就是工艺的一部分。这是我随着时间的推移慢慢学到的。
我想到了像诺依曼（Knuth）这样的人——他坐下来编写TeX或sendmail的传奇，结果它就……能工作。或者像贝拉德（Bellard）这样的人，他们持续产生大量高质量的系统。我认为软件的魅力在于，它是一种你随着年龄增长而不断提升的工艺。构建干净、可扩展系统的能力不仅仅是天赋——它是一个过程，并且随着时间的推移而深化。掌握。
所以，是的，我已经走过了从尽可能快地实现功能的日子。我想采取一种压力更小、更深思熟虑的方法。
人工智能不会为我完成那部分工作。但一旦我做出了正确的决定，它会帮助我更快地前进。一旦我选择了一个好的方向，它会帮助我更进一步。这是一个强力工具。就像所有的强力工具一样，它只是让你变得更加符合你本来的样子。
这就是我的反思。我也对其他人的看法很感兴趣——你们的系统构建方法随着时间的推移发生了怎样的变化？在尘埃稍微落定后，你们现在如何看待人工智能？你们的软件之旅是怎样的？
查看原文
Okay, here's my debrief.<p>What I've realized is this: AI is an amplifier of what you are. It's not a substitute - it just reflects and scales whatever you bring to the table.<p>When I was younger, I'd often just run at the wall and try to scale it fast. I'd throw a lot of code at the problem. Not out of carelessness - I was iterating quickly, looking for a working prototype that gave me feedback I could work with. Structure and architecture didn't matter to me as much - what I wanted was to hit the goal, the concept, the tangible result.<p>And that actually worked. I built a lot of stuff that way.<p>But I assumed AI would kind of "handle" the rest - that it would take care of the complexity, or clean things up. And what I've come to see is that AI just reflects your approach. If I'm in "throw code at the wall" mode, AI will just help me do that faster. Which can help. But it won't make the problem go away. It just accelerates whatever rhythm or method you're already in.<p>If you're designing systems, it can help you do that better. And if you're caught in a whirlpool of iteration, it can pull you in faster - unless you consciously step out and take a broader view.<p>That's the maturity I've been leaning into - stepping back, taking the time to think more expansively, seeing where the architecture needs to evolve to support the real model of what I'm trying to build. Because ultimately, building good software isn't just hitting the feature, it's about achieving a kind of mastery over the data and logic flow in the application.<p>There's something subtle there - like crossing the threshold between "everything technically works as a PoC" to "this is a robust, extensible system." The complexity isn't in the features themselves, it's in handling the state space, the transitions, the edges. It's in aligning the implementation with the model. When those are out of sync, you're constantly rubbing against invisible friction - and you know it, even if you can't immediately name it.<p>Today I had a moment that helped crystallize this. I was focused on this one feature - switching tabs and preserving focus state - and at first glance, it didn't seem like a big deal. But I just knew it was important. And in hindsight, it was a kind of genius intuition. Because solving that feature meant proving out a broader mastery of the data flow and internal consistency of the application. It forced the architecture to evolve in the right direction.<p>So this was the second kind of complexity - not about hitting a proof-of-concept, but about finessing the system into something real and usable, something that can hold together even as it grows. And being able to focus that amorphous challenge into a concrete goal - that's part of the craft. That's something I've learned, slowly, over time.<p>I think about people like Knuth - the legend of him sitting down and writing TeX or sendmail, and it just ... worked. Or people like Bellard who consistently produce numerous high-quality systems. I think what's cool about software is that it's a craft you can keep getting better at as you age. The ability to build clean, extensible systems isn't just raw talent - it's a process, and it deepens over time. Mastery.<p>So yeah, I've come a long way from the days of just hitting features as fast as possible. I want to take a less stressful approach, that's more thoughtful.<p>AI won't do that part for me. But it'll help me go faster once I've made the right decisions. It'll help me push further, once I've picked a good direction. It's a power tool. And like all power tools, it just makes you more of what you already are.<p>So that's my reflection. I'm curious about others' too - how has your approach to building systems changed over time? How do you think about AI now that the dust has settled a bit? What has your journey with software looked like?