大豆与硅

我成长于一个小农场。家里的主要收入靠大豆。雨点敲打谷仓铁皮屋顶的声音，听起来就像小军鼓。父亲那台老迈的梅西·弗格森拖拉机，前端装载机、后端割草刀，一车包办所有农活。嘈杂屋顶下，还停着一台绿色的约翰迪尔拖拉机和一台锈迹斑斑、巨大的联合收割机——它们曾是我的游乐场。

同龄孩子住得很远，得骑很久的自行车才能到。所以七月午后，我常爬上车库阁楼。那里热得像烤箱，塞满尘封纸箱，装的全是廉价通俗小说。我就坐在那儿，一读数小时。

家里第一台 Windows 电脑到来时——一台嗡嗡作响的米色方盒，放在客厅书桌。父亲只能求助懂电脑的朋友。那位朋友电话里指导八岁的我：进入 DOS，插入软盘，键入 “NUKEM.EXE”。按下回车，色彩与声响瞬间炸裂，《毁灭公爵》跃上屏幕。自那一刻起，我被彻底俘获——电脑既是救命索，也是我见过最迷人的东西。

工具一夜变了样

大家好，欢迎收听 CoRecursive，我是 Adam Gordon Bell。今天想聊一个正在撕裂开发者社区的话题——AI 编码助理。这并不是“AI 将接管一切”或“AI 被过度炒作”的老生常谈。

我要谈的更私人与更深层：当你的身份与“创造”紧密相连，而用于创造的工具却在一夜之间天翻地覆时，会发生什么？我们为何本能地抗拒？又为什么值得推开恐惧、继续前行？我自认观点务实，或至少提供一个有趣视角，邀你一同听听看。

天生局外人

《怪奇物语》里的八十年代小书呆，在地下室玩《龙与地下城》，骑车穿梭社区。但那不是我的童年。我在乡下，没有邻居。小学同学大多来自农耕家庭，如今他们依旧打理那些家族农场。

我们常常兴趣迥异。我算是班里的捣蛋鬼，因无聊而闹腾。我知道自己与众不同，却说不清究竟不同在哪里。

高中毕业后读计算机科学。和专业同学也谈不上多亲近。有几位朋友，大多数时间我独来独往：写程序、搭网站、鼓捣电子音乐，下载盗版 Photoshop 硬着头皮学。

成为软件工程师后，我终于遇见真正了解且舒展自我的人。朋友 Don 身上洋溢典型“极客文化”自豪感。但我从没看过《星球大战》，也没玩过《魔兽世界》，依旧难以完全融入。直到发生一件意想不到的事。

找到同温层

记得去旧金山一家创业公司面试——离 Twitter 总部不远。一下子就感觉那里的氛围熟悉：白天写业务代码，私下里学 Haskell、用 Unity 做游戏、纯粹为了好玩。我说最爱的作家是特德·姜，立刻有人回应：“我也爱，但最近更迷格雷格·伊根。”我们的兴趣高度重叠。

那种感觉奇妙极了。我发现的其实不仅是同类，更像真正发掘了“自我”。

对“创造”的上瘾

几年前，我和妻子在佛罗里达度假。我抱着笔记本坐泳池边，从零写一个 Markdown 解析器。她看书，我沉入心流：追踪边界条件、代码契合瞬间，多巴胺汹涌。

这情景让我想起少年时：父亲买了雪地摩托想我出去玩；朋友骑越野摩托来喊我冒险。但我蜷在电脑前，用 Turbo Pascal 写《珠玑妙算》。我也会出门，但最让我亢奋的永远是创造瞬间——算法覆盖所有边界时，你知道自己做出全新且可运行之物，那种纯粹快感令人上瘾。

承认这点，我花了太久——尴尬地久。我宁愿周六耗十小时研究新框架，也不去派对；宁愿自动化一件其实无需自动化的事，也不做别的。一旦真正接受了这一点，我不再为周末“潜入代码洞穴”道歉，也不再为在聚会里喋喋不休新语言感到内疚。这不是怪癖，而是我，也可能是我的超能力。

数字俱乐部

那之后，我留在安大略省，却整天泡 Hacker News——那里像为我这种人设立的非官方俱乐部。人们沉迷创造，欣赏优雅代码，拿空闲时间学新语言、钻研数学。在多年“局外人”体验后，这里让我感觉回家。

巨大的编码裂痕

时间来到 2025 年。如今逛 Hacker News，我感到昔日归属被撕裂：一边是用 Cursor、Claude 兴奋展示作品的人，一边是痛斥 LLM 让程序员变懒的人。俱乐部骤然分裂为“它改变一切”与“它毁掉一切”的战场。

靠近二十年职业生涯的我，更偏向兴奋——历经太多工具更迭，总能辨认何者值得探索。我相信：如果你热爱创造，没有人能夺走它——老板不能，新工具不能，甚至你自己也不能。AI 夺不走驱动力，或许还能助你一臂之力。

即使 Claude 7 或 ChatGPT 6 强到碾压人类，也不代表我会停止创造、你会停止创造。也许“创造什么”会变，因为某些技能被 API 调用替代令人失落；可驱动力依旧。市场与期望会变，但总能既拥抱变化，又保持与创造本能的连接。

用会议换代码

我曾体会到另一个恐惧：升任工程经理后，大量时间被会议、文档、消息路由吞噬，几乎不再编码。偶尔需要改行小代码，拉取时发现上次 git pull 已是 37 天前。写完 PR，几分钟就获批，可满足感稍纵即逝，因为余下全是 Confluence 更新和跨团队协调。

我告诉同时升任管理者的朋友 Ted：“别担心，你代码功底在，退回来随时能补。”可我自己却焦虑不已：在终于弄清什么能让我快乐后，竟把它换成了 endless meetings。

工具 vs. 身份

很多人抵制 AI 编程工具，深层是怕失去定义自己的东西：当编码是身份与价值来源，一个可能削弱它的工具自然令人畏惧。

我想说：把恐惧先放一旁，当成学习实验去探索。Claude Code、AMP、Cursor 这类工具，正是为“建造者”而生。掌握之后，你会爱上它们。没错，有些技能贬值很可怕；但新的技能威力与价值将是旧日的十倍——这值得兴奋。

重塑自我

我从工程师到经理，再到 DevRel，编码时间越发稀少。但我仍需创造，小型示例 App、演示视频都能满足那份“瘾”。我承认：这是一种上瘾的反馈循环。

失控的副项目

网站 CoRecursive.com 上 /rankings 页面，列出各技术播客热门单集。它源于一次“跑偏”的 Bash 副项目——抓取 feed、评论、Twitter 数据，评估哪些单集最受欢迎，最后自动化上线并至今每日运行。我甚至没真正用过这工具，却乐此不疲。

国际象棋引擎时刻

现在的 AI 编码，像 2005 年的国际象棋：人机合作胜过任何一方单打独斗。LLM 能一次生成简单小项目，但要在大型代码库中解决从未遇过的难题，就需要有经验的“建造者”引导——那个人就是你。你带来直觉与分解问题的能力，AI 带来速度与样板处理。合力，你们可完成独自难以企及的项目。

用 AI 构建

再说说我最近折腾的一个项目：

我想写个程序，输入一段 YouTube 视频 URL——

  1. 下载 MP4；
  2. 抽取音轨并生成文字稿；
  3. 抓取视频关键帧；
  4. 最终把它们拼成一篇博客文章。

我在 VS Code 打开侧边栏里的 AMP，直接对着麦克风口述需求（Mac Whisper 实时转写）：

「我要下载视频并转成文字，再识别关键画面插入文中。Python 有没有现成库？不用的话就按我常用的 yt-dl 也行。」

接下来十五分钟，我和代理来回讨论各种实现路径——它有时只见树木不见森林，于是我把它当作“高级橡皮鸭”，一起做设计。第一版搞定后还是个一次性脚本，于是让代理协助重构成“正经的” Python 项目：分模块、加 lint、写 tests。每做完一大步我就 commit，以便随时回滚（确实回滚过好几次）。

过程中，我撞上 Gemini 对上传文件大小的硬性限制。于是我们：

  • 先用 FFmpeg 把视频降分辨率，能省一次二次上传；
  • 再写逻辑：文件超限时走第二通道上传并返回文件引用；
  • 由 AMP 自己去看 API 文档，把所有细节补齐。

一来一回看似磨叽，实际却比我单干快得多；要我一个人写，这玩意儿大概率烂尾。现在有 AI 帮我啃繁琐步骤，偶尔“你忘了这行参数”也只是正常 Pair Programming——总体仍然好玩得很。

超越「不完美」

你或许要问：

「既然得不断手把手指挥，为何不自己写？」

这种质疑并非错，只是忽视了真实体验——它又快又好玩，且最终代码质量反倒更高。另一种声音是：

「要是 AI 真那么厉害，为什么我还得学一堆提示技巧？不该更简单吗？」

要记住：这些只是“工具”，远没到万能 AGI。真有 AGI，你只需说一句「把 Linux 内核某模块改写成 Rust」、坐等它给你 PR。现阶段要想释放潜力，势必要摸索流程、微调提示、投入练习——正因如此也最值得学习。

Hacker News 的误解

在 HN 看到一帖：有人让 Claude 写脚本修复照片朝向。第一次输出笨拙，他指出问题；第二次感觉依旧脆弱；来回两轮才得到可用版本，于是下结论：

「生成器效率低，还得我亲自把关。」

两轮迭代就拿到可用脚本，真不算慢。与其说工具差，不如说需要合作磨合——就像跟人类同事 Pair，也要讨论五遍 API 设计才定稿，这很正常。

我会变差吗？

真正要警惕的是技能萎缩。以刚才的视频项目为例：部分代码是我和代理一起写的，我并未深入每行实现；而自己写的那部分，我能倒背如流。

怎么办？把“与代理协作”视作新技能的培养：如何拆分任务、如何写提示、如何审稿。只要愿意，随时能关掉 AI、自已手撸 Python——底子还在。

自动化的好奇心

ChatGPT 推出深度研究功能前，我用早期代理 Windsurf 写过一个「嘉宾履历时间线生成器」：

  1. Google 搜索目标人物 →
  2. 爬博客、访谈、演讲稿 →
  3. 自动转录与归档 →
  4. 整理出时间线，方便我做播客采访。

第一次实战是 Hatetris 作者专访。AI 挖出几段连作者本人都忘了写进时间线的往事——当场让我折服：效果比我人工搜集更全、更快，而构建这个小系统本身就充满乐趣。

新技巧，旧习惯

  • 代理 + Python：组合最佳；
  • 我把静态类型检查 & Lint 一股脑加进项目，让 LLM 改动后立即过 CI；
  • 还加了重复代码扫描，因为 LLM 偶尔会重复实现已有逻辑；
  • 最近最爽的发现：先手动示范一次复杂重构，让代理批量在几十个文件里复制同样手法，快到飞起。

这让我意识到：工具不仅提速，更扩大了我能动的“改造半径”。

像架构师一样思考

去年圣诞，在墨西哥度假村泳池旁，我试图逆向 Descript 的项目文件格式，好让播客剪辑流程完全脚本化。3 小时后发现项目其实是 zip 包，里面全是 JSON / TS。LLM 解析混淆 TypeScript、抽出我需要的 schema；我设计“只依赖必须字段”的策略，确保 Descript 更新格式后仍兼容。

那一刻我意识到：LLM 承包了底层体力活，我像个“代码建筑师”，专注高层决策——以前绝不敢碰、也没时间碰的事，如今成了泳池边的消遣。

笨拙意味着成长

初学 Mac、函数式编程、强类型语言时，那种“按什么都错”的窘迫我再熟悉不过。现在与 LLM 共事，只是把“尴尬期”重新拉到眼前——而正是那些笨拙时刻，标志着飞速成长。代理像母语者，带我快速领悟 Python 惯用法；我也学会更快放下旧框架的抵抗。

反「反 AI」

朋友 Chris 戏称我是 “Anti-Anti-AI”——既非无脑吹，也非唱衰派，而是务实地玩工具、产出结果。

你不必追随最热潮，也不必抵制一切新物。
试用一下，感受一下，再判断
我写这段文字，就是想给“好奇却观望”的你一个推手。

选择去构建

AI 是否终将替代分析工作、重塑就业？也许吧——那是明天的问题。今天的事实是：工具已在这里，而且好用又好玩。

  • 你可以焦虑被淘汰，
  • 也可以用这些工具做以前没空做的项目。

对我而言答案显而易见：继续创造。

如果你也仍为解决难题时的那股快感而兴奋，不妨从一个小副项目开始，把它当作学习实验，玩起来。喜欢就深耕；不合口味，大可放下。

仍然是建造者

归根结底，我们仍是“建造者”——

  • 看到问题就想解决，
  • 想象不存在之物并令其成真。

工具在变，乐趣未变。依旧是那场伟大、迭代、令人上瘾的游戏——这，正是我所期盼的一切。

本期节目到此结束
如果它触动了你，或许去试试那些工具；如果你身边有仍在怀疑的“建造者”，分享给他 / 她。
感谢收听，咱们下期再见！

Transcript

Note: This podcast is designed to be heard. If you are able, we strongly encourage you to listen to the audio, which includes emphasis that’s not on the page

Soybeans and Silicon

I grew up on a small farm. Soybeans paid the bills, and the rain on the barn’s tin roof sounded like a snare drum. My dad’s old Massey Ferguson tractor, with its front-end loader on the front and its cutting blades on the back, handled every chore. A green John Deere tractor and a red rust-flecked combine that was so large lived under that noisy roof, and they were my playground.

The nearest kids my age were a long, long bike ride away, so on July afternoons, I’d climb up into our garage attic, and it was basically like an oven from the heat. It was stuffed with these old cardboard boxes full of dusty pulp fiction paperbacks. I would sit up there, and I would read for hours.

When our first Windows PC showed up, it was this beige box humming on the family room desk, and my dad had to call a friend who knew computers. That friend coached 8-year-old me through the whole ritual of getting into DOS, sliding in the disk, and typing “NUKEM.EXE,” and then Duke Nukem blinked onto the screen. In that instant, from hitting enter to that explosion of color and sound, I was hooked. The computer was both a lifeline and also the most fascinating thing I had ever seen.

When Tools Change Overnight

Hi, this is CoRecursive, and I’m Adam Gordon Bell, and today I want to talk about something that’s been dividing the developer community, AI coding agents. This isn’t another, you know, AI rule replaces all talk or AI is overhyped take.

It’s more about me and what happens when your identity is tied to building things, and then the tools you use for building fundamentally change. It’s about the resistance that we feel and why maybe we should push through that anyway. I think it will be interesting to the skeptics and the people hyping it up both. I think I have a pragmatic view, or at least an interesting perspective, and I hope you’ll listen along.

Born an Outsider

On Stranger Things that the eighties era and nerdy kids, they play Dungeons and Dragons in a basement and they bike around the neighborhood together. But yeah, that wasn’t my childhood. As I mentioned, I, I grew up in the country, no neighbors nearby. My friends at the tiny school I went to were mostly kids from farming communities, especially when I was young and, and most of them, you know, they run those same family farms.

Now. We didn’t always have a lot in common. I was kind of the class clown in school, the kid who got bored and acted out, and I knew it was different. That was clear, but it was never clear to me exactly who I was and, and why or how I was different.

After high school, I went to computer science and I didn’t get super close with the students in that program either, I had a few friends, but mostly I kept busy on my own, always building something. Not just programming, but making websites and messing around with electronic music, downloading pirated software like Photoshop and trying to figure out how to use it.

When I started working as a software engineer, I finally met people who really understood themselves and were happy with who they were. My friend Don, right? he proudly embodied this nerd culture. But I had never seen Star Wars. I had never played World of Warcraft. I didn’t totally fit in with that crowd either. But then something unexpected happened.

Finding My Tribe

I started meeting people who were just like me. I remember going to a job interview at a startup in San Francisco. It was not far from the Twitter offices; it was in the downtown area. Right away, I noticed people there that felt familiar to me. By day, everyone was writing whatever code needed doing, but on the side, they were learning Haskell, building games in Unity, or just doing these things for fun. I would say my favorite author, you know, was Ted Chang, and somebody else would say, “Oh yeah, I love him,” but I moved on to Greg Egan. They just seemed to have some of the same interests as me.

It was so odd, to be honest. But here’s the thing I didn’t fully understand at the time: I wasn’t just finding people like myself; I was finally discovering who I really was.

Addicted to Making

A couple of years ago, I was on vacation in Florida with my wife, sitting by the pool with my laptop, building this markdown parser from scratch. And she was reading, perfectly content, and I was in this flow state for, you know, where hours disappear, chasing down edge cases and getting that hit of dopamine whenever something clicks into place.

It reminded me of being a teenager, right? Growing up in the country, my dad got a snowmobile and wanted me to come play, or I had a friend who had a dirt bike who would swing by with the engine revving, ready for an adventure. But I was hunched over my computer, building a mastermind board game in Turbo Pascal. And you know, I would go outside and I would go play. But the most exciting things for me were those building moments. The building stuff was when I had the time of my life.

There’s something intoxicating in that moment when you know the algorithm finally handles all the edge cases, when you realize that you built something that didn’t exist before, and it works. It’s pure, and it’s addictive in the best possible way.

So yeah, it took me a long time—like an embarrassingly long time—to admit to myself that I would rather spend 10 hours on a Saturday deep diving into some new programming framework than be at most parties. I would rather figure out how to automate something that probably doesn’t need automating than do almost anything else.

I’m someone who gets genuinely excited about reading the documentation for some new framework. If I think it might solve some problem that’s been bothering me, I see a problem and immediately start thinking about how I could come up with a solution, even if it’s totally overkill. It’s just something I enjoy.

But yeah, once I finally accepted that—like really accepted it, not just tolerated it—I stopped apologizing for disappearing into code caves for weekends. I stopped feeling guilty about getting excited about a new programming language and boring my friend about it at social events. It wasn’t a weird quirk that I needed to fix. It was just who I was. Maybe it was my superpower.

My Digital Clubhouse

In San Francisco, I met these people, and it turns out there were a lot of people like me—folks who liked building projects, who liked writing and sharing ideas. A lot of them at this particular place came from Waterloo, another place in Ontario, and then had moved to the Valley. But I was still in Ontario, so I spent hours and hours on Hacker News.

It felt like an unofficial clubhouse for people like me. And it felt like a place where I belonged. Like there finally was a place—these were people who were building things and who understood the joy of solving problems that didn’t need solving, who got excited about elegant code, or who spent their free time learning a new programming language, learning math, or doing whatever just for fun, right?

After years of feeling like an outsider, it felt like home.

The Great Coding Rift

But now, early to mid 2025. If you look at Hacker News, that sense of belonging for me can feel fractured. The community that made me feel understood feels like it’s splitting over LLMs and coding agents. Some folks posting exciting updates about what they’re building with Cursor or Claude, or posting updates about the latest releases of coding agents, and others pushing back hard, arguing these tools produce brittle code and make developers lazy. It feels like the clubhouse turned into a battleground between this changes everything and this ruins everything.

I feel like I’m pretty pragmatic and somewhere in the middle, but I’m definitely leaning towards excitement after, I don’t know, 20 years of coding for a living. I’ve seen enough tool changes to recognize when something’s worth exploring. I feel like if you love building things, if you like to create, nobody can take that away from you. Not a boss, not a new tool, not even yourself. The urge to build these side projects and experiments that I love to create, it’s just part of who I am, right? And AI can’t take that away from me, but maybe it can help me.

But even if you know Claude seven or ChatGPT six drops and suddenly it’s eight times better at coding than anybody, that doesn’t mean that I’m gonna wanna stop building things. It doesn’t mean that you’ll wanna stop building things. Maybe the what will change because it can feel devaluing when some skill you’ve built up over time can be replaced by an API call. But that drive just doesn’t disappear. The job market might change and expectations might shift, but there’s a way to embrace the change that’s going on and also stay connected to this need to build.

Trading Code for Meetings

Let me tell you about a fear that I know intimately. Once I saw myself as a builder, I hit a wall in a way I didn’t expect. When I became a software engineering manager, it felt like a special opportunity. I was working remotely. I’m here in Peterborough, not near any tech hubs, and I’ve been working remotely for quite some time. But this is pre-COVID. The roles were limited, and the chance to be an engineering manager at a large and growing tech company felt very exciting. I couldn’t say no.

I wanted to step up. I wanted to lead this sharp team of functional programmers at this fast-growing company that had recently IPO’d. It seemed exciting, the idea of climbing the ladder of, you know, somewhere with hundreds of engineers. It also just felt like the thing that you’re supposed to do.

But almost right away, anxiety crept in. It wasn’t very long before I wasn’t coding anymore at all, and when I would finally have to do a tiny task, you know, I would open up my VS Code, do a git pull, and see, you know, it’d be 37 days since I’d last pulled the code. All I would need to do is some small task, open a PR, and then Adrian would approve it two minutes later.

And I remember him saying in Slack, “Feels good to ship something, doesn’t it?” It did. But honestly, that feeling faded as fast as the GitHub Actions build because the rest of the day was meetings: Ireland at 8:00 AM, then DC folks, you know, through the middle of the day, Pacific Coast, near dinnertime. I started having my phone on this tripod with earbuds in so that I could go down for coffee while still in a meeting. I spent way too much time reading and updating Confluence. I just hate Confluence. There was a lot of Confluence updating, a lot of digital paperwork, and a lot of being a router for messages between various teams. Time as a manager moved fast.

Ted, a friend who stepped into management at the same time I did, had the same worry. And I remember telling him, “Don’t stress about it. You were a good developer. And so being a manager isn’t going to take that away. Like, maybe your skills will get a little bit behind, but you can always ramp back up if you need to switch. But while you’re a manager, that should be your main focus.” That was my advice to him.

I wish I could take my own advice, but I found that I couldn’t because, as I said, building things and being good at that was a big place where I got a lot of self-worth. But now I was in back-to-back meetings with endless messages flying around, and I just started to worry that after finally figuring out, you know, what brought me joy, I had just traded it all away.

Tools vs. Identity

I think that a lot of resistance to AI coding tools comes from the same place: fear of losing something that has defined you for so long. People are reacting against overblown hype, and there is overblown hype. I get that, but I also think there’s something deeper going on here. When you’ve worked hard to build your skills, when coding is part of your identity and where you get your worth, the idea of a tool that might replace some of that is very threatening.

But here’s what I want to encourage you to do: put some of that fear aside, at least for a learning experiment. Treat these tools like something that you need to get familiar with. Treat it like something you should explore in a side project, something worth spending time on. Not because they solve every problem, but because they’re worth understanding.

And if you are a builder, these tools, Claude Code, AMP, or Cursor, they’re designed for you. But to see that, you need to overcome that fear or at least admit to yourself that it’s there. Because when coding is part of your identity, a tool that devalues it is hard. I guess what I’m trying to say in my long-winded way is that if you’re a builder and you get joy from that, once you master these tools, you’re going to love it. Some of your skills will be less valuable for sure, and that’s scary as fuck. But other ones are 10 times as powerful, 10 times as valuable as they were before. And that’s exciting.

Reinventing Myself, Again

So, as I moved from engineer into management and then left that for developer relations, I found myself coding less and less. DevRel scratched the itch in a different way. You know, writing things and making videos. It was another creative building endeavor, a little bit different. But I still got to code and build small sample apps and show them off.

So it worked, but I wasn’t in the trenches as much as I was on a product team. On the product team, I always wanted to keep up. I always wanted to be the best. So I’d spin up side projects to try out new tools, to experiment with new techniques, or to finally build something that was polished in the way that I wanted to do at work.

But we just didn’t have the time, or that code was too old and scary, or whatever. But even when I was coding less at work, I still needed to build things. Honestly, I find it kind of addictive. There’s this feedback loop where you start building something and you get stuck, and then you try to figure it out, and then you get that rush when you do, and then you wanna do it all again.

When I started playing with languages that had stronger types, the highs and lows got even sharper. This, you know, like excitement and frustration when I’m deep in a coding session, totally focused, and you forget about everything else. It’s just, it’s a great feeling.

Yeah, but honestly, it can get frustrating. This addiction. You know, I block out time to work on the podcast in the morning, doing the editing or setting up the interviews or hunting for stories, and sometimes I love it, but other days not so much. And it’s always easy to reach for some random coding project and convince myself that it will solve my problem. I just can’t help myself. I just like to build little things.

Side Projects That Spiral

Here’s a weird example. If you check out the podcast website CoRecursive.com, there is a /rankings page, and on it, you’ll find sub pages that list the most popular episodes from other coding podcasts: best Python podcast, best Android, best cloud, best Linux. This started as a weird side project that I got way into at some point, you know, distracting myself.

I had basically this pile of Bash scripts because I was trying to get better at Bash then, and honestly, it became way too much Bash. But I was scraping feeds of podcasts, scraping Twitter, looking at reviews, trying to find for these podcast episodes, which ones were the most popular, right? That would help me find guests to interview on the show. But it kind of took on a life of its own.

And at some point, I was like, I should just put this up on the website. Eventually, I rewrote it in a, and honestly, I never even checked the results. I’m not even sure I used the tool, but yet it still exists, and it’s still running daily, gathering metrics, and probably at some point, I’m gonna try to rebuild it in Python. Because that’s just what I like to do.

The Chess Engine Moment

But right now, we’re at this moment; it’s like 2005, and you’re a decent chess player, not grandmaster level, but you know your openings. You’re pretty good, but you’ve been getting crushed by chess engines. Then someone suggests, like, what if you use the engine to help you think through positions, but you make the final calls the first time you try it?

Something magical happens. The engine spots techniques and tactics that you missed, but you see the long-term strategy that it doesn’t quite grasp. So together, you’re playing better than ever, better than either of you could alone. You’re not just using the chess engine as a calculator; you’re collaborating with something that has different strengths than you do.

That’s exactly where we are with coding tools. Right now, we’re in the 2005 chess mode. That moment of discovery, when you realize it’s not human versus machine, it’s human with machine. These LLMs might be able to single-shot build some simple stuff like a React todo list, but to build something hard, to work in a large codebase, to tackle hard things that haven’t been done before, they need to be paired with an experienced builder who can guide them, right?

And that’s you. You bring your intuition about what needs to be built and the way it should be built, and your sense of when something’s offered. There might be a better approach, your ability to break down complex problems into manageable pieces. And the AI brings its speed and pattern recognition and ability to handle the tedious parts.

And together, you can tackle projects that you never would’ve had time for alone. If you’re someone who isn’t using these tools yet for whatever reason, I want you to set aside your objections and, yeah, treat it as a learning project, not because you have to love it and not because it’s gonna solve all your problems, but because this is a skill worth developing.

Because here’s the thing about learning projects: they can be frustrating, right? When I started at Tenable, I had always worked on Windows, and then my boss just says, “Hey, you’re getting a Mac.” All the devs used Macs, so that was the way, but I was a Windows person, and I didn’t say anything. I just went along with it, and my fingers had, you know, years and years of muscle memory burnt into them. You know, Control C, Control V, Control everything. Now suddenly it’s Command, and my pinky keeps stabbing at the Control key.

Like I’m trying to punch through concrete, and things aren’t working. You know, on Zoom screen shares, I’d fumble to do basic tasks with everyone watching and hitting the wrong keys and getting nothing. You know, “Sorry,” I’d mutter, and I’d be frustrated, and I seemed like I didn’t know what I was doing.

My fingers failing me at the exact moment I needed to look competent. My MacBook was gorgeous, right? Way nicer than my old ThinkPad. But it felt like I was working with oven mitts on. But now I couldn’t imagine going back, right? Learning Haskell was the same torture. I spent hours building this beautiful parser for parsing log lines using Parsec. This was years ago, and the code was so clean and elegant, and it looked like poetry. And then it would break because it couldn’t handle, you know, handling a bracket or a pipe in some random spot.

And it would fail in some completely unrelated way. The code was simple to look at, but building it was hard. Where in C, I could put together a regex with name groups in maybe five minutes, but here the code was prettier, but debugging, it was such a challenge. But that’s the pattern. The moments when you’re thinking, “This is completely stupid,” or “I’m frustrated at how this isn’t working,” or “I feel slower,” that’s when you’re growing the most, and it hurts because everything feels clunky and impossible, and you start wondering if you’re actually getting anywhere or just torturing yourself for no reason.

But that’s what it’s like to learn. That’s why it’s a great time to put aside your fears and frustrations and invest some skills in building with one of these tools. Treat it like deliberate practice, something you do because the skill itself is valuable, and it feels good to learn. It just also feels awkward and frustrating in the way that learning something new always does.

Treat This as a Learning Project

But yeah, if you wanna work with a coding agent, this is what I do. You don’t have to listen to me, but I do want you to consider it, right? Especially if you have a strong aversion to these tools. But also you’re a builder. I just think it’s something you should try. Pick a good tool, you know, pick the one with the strongest coding model right now.

That’s the cloud models with thinking. And then make sure you’re using an agent. Use claude code. Use amp, use cursor. Seems very popular, but there’s a million of them. And yeah, you’re gonna have to spend some money; you need to pay for all these API calls that they consume so aggressively. But commit some time to playing around because there’s all these criticisms I see on Hacker News from people who haven’t taken the time to use and play around with these tools and build the skills. And if you haven’t, then your criticisms actually don’t hold a lot of weight because yeah, when you get over the hump, when you build up some tricks, and even before then, it’s just so much fun.

And I’ll get into some of the fun I’ve had, but first, you know, some advice. You can’t treat these coding agents as some magical AGI that’s gonna fix everything or make you 10 times faster overnight. It’s not that. Think of it as a new tool that you’re learning to use, like switching from Mac to Windows, or moving from imperative to functional programming or learning OOP.

Start Small, Start Smart

Treat it as a chance to learn something new. Start small, right? I like to think of it as like a junior programmer that I’m pairing with. I talk to it, and it does the work. It’s hands on keyboard. One of the fun learning tasks that I’ve done is pick a library that you rely on and don’t understand well. You know, clone its GitHub repo, and then fire up your favorite agent and start asking questions. How does this work? Where’s the control flow? What are the main data structures? Have it generate some quick and dirty docs specific to the way you wanna understand things.

It’s low stakes, and it’s a great way to get comfortable with this back and forth process. It can explore the code base probably faster than you can, and then it can help explain to you things, and then you can ask questions back and forth.

Next after that, you know, try a small project, maybe something you’ve built before but with a new twist or in a new language that you’re less comfortable with. Don’t expect the LLM to handle everything. Instead, treat it like a coding partner. Something that helps you with writing, right? You can work together and plan out your project and then tackle the first step, and then the next, ask it things like, can you write a test for this?

The idea is to move forward one piece at a time, learning as you go. Start small. Let the agent handle the code writing and see what it gets right, and what it gets wrong, and then offer input and build up rules, and you’ll get better.

Working with an LLM is like pairing with somebody who’s brilliant at some things and clueless at others, and sometimes has different tastes than you. There’s a learning curve, and the people mastering these tools, they’re the people who have developed intuitions about what works and workflows that work, and learn to lean into the strengths while avoiding the weaknesses. But to get there, you have to give it a chance. Let me tell…

Building With AI

you about a recent project that I was working on. I wanted to build a program that takes a YouTube video, downloads the MP four, pulls out the audio and generates a transcript, and then, you know, I’m creating a blog post version of that video by grabbing pictures, you know, key images from the video itself. So I open up vs code with amp in the sidebar, and I started dictating I literally talk into the box. For the prompt using Mac Whisper, I’ll say, I wanna download YouTube videos and generate a transcript. Then I wanna identify key visuals and note them in this file. You know, is there a Python native way to do this, or should I use the YouTube download program?

I normally do. We have some back and forths, 15 minutes of me rambling and getting input back on different ways. It could work.

Sometimes it misses the forest from the trees. Yeah, we do software design together. I use it as an advanced rubber doc. and yeah, you can tell I do anthropomorphize these agents. I just talk to them back and forth. That’s just how it feels for me to build something this way.

So we got the first version working. It was a clunky one-off script, but I had various stages to add, so we had to convert it to a proper Python project organized by files. You know, I committed after every major change that way I could roll back if things went sideways, which they sometimes did.

But this whole process feels very different than working with something like Devon or these tools where you put together a GitHub issue that you know exactly describes what you want, and then let it run off and do the work. Honestly, I’ve never worked with one of those tools and, and I don’t super trust them because my experience of building is, is very iterative. I like this back and forth. I wanna build in a certain way. And in fact I had to build up a bunch of linting scripts so that the generated code would come out the way I wanted.

But yeah, as we built, I hit Gemini’s file size limits. You can only post files up to a certain size. Anything bigger needs a secondary API upload. Then you send Gemini a file reference. And so we got that working. But Then we have to add FFmpeg to re-encode videos to lower the resolution so that a lot of times we don’t even have to do the secondary upload.

And there’s back and forth and there’s testing and there’s adding new conditions and there’s amp going out and digging through the docks, which is super helpful actually for it to go out and try to find what’s the relevant stuff. And in some ways, it felt like it took ages to build this thing. ‘cause there was a lot of back and forths, but it actually came together pretty fast. And on my own, I would’ve never finished it. I just didn’t have The time. But with amp, I could push through the tedious parts and there was still plenty of frustrating moments, plenty of like, Nope, you forgot about this, you know? But for me personally, having these back and forths isn’t that big of a deal. It’s just communication. It’s just pair programming and the whole process was fun.

Beyond ‘Not Perfect’

Now I can hear all the objections. If I had to constantly guide them, then why not just write it myself? And I feel like that criticism, it’s not that it’s wrong, it’s just kind of missing the point. It’s kind of missing what this experience was actually like. It was fun and fast, and better code in the end than I’d actually do on my own. Another complaint I hear is why bother, right? If an AI is supposed to be so advanced and maybe even replace this, why do I have to learn all these tricks just to use it? Why invest time? If it’s really that good, shouldn’t it be simpler and not harder?

But honestly, these are just tools. These aren’t an AI. If it was an AI, you wouldn’t need to fuss over prompts or workflows. You could just say, you know, watch me using this software. Or can you take the Linux kernel and rewrite parts of it in Rust, and a AI would figure it out and send you a pull request? Or, here’s 50 videos of people getting stuck. Can we smooth out some of the rough edges, and look through this and find performance problems? But we’re not there, right? These tools can boost what we do, but only if you’re willing to experiment and learn and iterate and guide it. And put in the work. Before you do that, you have to get past your own fears and biases.

What HN Gets Wrong

Here’s an example from Hacker News. Someone complained that code generators like Claude are inefficient. They ask Claude to write something to normalize image orientation. You know how sometimes pictures that you take on your phone, they’re actually sideways, but they use a header to say it goes the other way? And then some photo programs like to ignore that header and display them sideways. They wanted a program to fix that. So they asked Claude to do it, and they said that the first solution was clunky. So they pointed out the problem and Claude tried again. But that solution felt brittle, and it took two rounds of back and forth before they finally got to a version that they liked and worked well.

And their takeaway was that these tools, they just lead to less than ideal solutions, and you have to step in and guide them. That’s like actually totally fair criticism, but honestly, taking two rounds to build something that’s not bad at all, maybe your expectations are just too high, or you know, maybe you could have explained it clearer.

But these tools aren’t magic. Like they’re not gonna nail every problem on the first try. I think of it more of like working with a teammate. You need to go back and forth. You need to refine what you’re working on. You need to collaborate to get good results. I mean, I’ve gone back and forth five times or more just trying to nail down the best structure to use for a specific solution. That’s not a flaw, that’s just how building things actually works. Right? The same would happen if I were designing something with a colleague.

Will I Get Worse?

But a real risk with these tools is skill atrophy, and that does worry me. Take the video transcribing program I was talking about. I don’t really know all that code. I certainly don’t know it all well. Meanwhile, there’s code that I built myself that I know inside and out. At least, you know, when I first finish it, I remember how each part was used and how I structured things. The code I didn’t write or that I wrote with the agent, I just don’t have the same depth on it. I’ve read and reviewed most of it, but certainly lots of it I haven’t. Some tests I just never looked at.

So, we just needed to test this condition. So yes, like skill atrophy is a real risk. But once again, I feel like if you treat this as a learning project instead of focusing on building my Python chops, right? Now, I’m looking at building a new skill. You know, figuring out how to use these tools to build things, working alongside a coding agent and getting things done. When I look at it that way, I don’t worry so much, right? If I’m losing my edge, that’s okay. I can always go back to writing Python by hand, which I still do sometimes. Nothing’s stopping me.

Other complaints, they don’t ring as true to me. Right? If you’re having trouble getting real work done with coding agents, it’s probably a skills gap, and that’s okay. Instead of blaming the tools, just try shifting your perspective. What am I missing? How can I get better at using these tools?

Other developers are building real things, so it’s worth asking, you know, what could I be doing differently, and would that be worth it? Because maybe you can’t evaluate things until you really understand how they work. The tools aren’t perfect, and it is totally fair to feel frustrated or want to walk away or try again next year when they got better. But I pushed back a little bit, right? This stuff is new and honestly, it’s fun to mess around with, and I think it’s worth exploring.

Automating Curiosity

Another thing I built before Chat GPT’s Deep research feature existed, I built my own research assistant using Windsurf as the coding agent at that time, because part of my interview prep for the podcast always involves creating a timeline of someone’s career. You know, where they went to school, what their jobs were, what their projects were, and what their pivots were. Right? It’s useful, it’s super useful for guiding the interview, but it’s also time-consuming.

So I built a web app that automates this process. It’ll do a Google search for the person, find their blog, you know, spider the links, try to find all their posts, follow links, evaluate if they’re relevant, hunt for interviews they’ve done, transcribe them, pull all these documents down, and then attempt to build a timeline from that. When I first used it seriously, it was for the Hatetris’s interview, and those guys being very detail-oriented. They prepared their own timeline of them building Hatetris, and I found a couple of things that they didn’t include, and I thought they might be hallucinations, but they weren’t. It was real things that happened that they just forgot to include in their timeline. It was mind-blowing.

I had saved myself so much work, and it was actually doing a better job than I did, but also building that tool was a lot of fun. Working with coding agents has some of the same addictiveness that I’ve always loved with building these feedback loops, these cycles of frustration and then breakthrough that can make programming addictive. I guess the probabilistic nature of them maybe even makes it more addictive. Variable cycles of reinforcement, but also building up new skills. Right? I’ve learned not to micromanage the process. When I’m planning with amp, I’ll use dictation and speak for quite a while various concerns and then send it off and get some feedback, and we iterate and we do some design together.

So I built up my own, you know, bag of tricks. Dictation is definitely one of them. But yeah, I’m just sharing some of my experiences here, uh, in the hopes that if you’re doubtful that you might give these things a try. Or if you’re listening and you’re not doubtful, but you have a coworker that is, maybe you can share this with them. I don’t know. But another thing I do a lot is use the coding agents for just small automation opportunities. GitHub Actions is always a pain for me, or builds in general.

So I like, you know, asking the coding agents to make the changes, or if I make the changes myself, asking it to review the changes and look for any problems before I commit and send it off. Because the build feedback loop is just brutal, right? So if I can catch problems earlier, it saves me a lot of time. It’s like getting a PR review, but instantly, uh, in a way that’s faster than waiting for the build to run, which is sometimes slow.

New Tricks, Old Habits

I wasn’t always programming in Python. Uh, that’s a relatively recent thing, but I’ve been using Python a lot because agents work with it so well. I’ve also found that all the static typing and linting that I’ve always loved is really also a key when working with these agents. Now, I throw every tool that I have at my code: formatting, linting, type checking. That way, when the LLM makes a change, everything runs through the linter step, and we catch problems.

I even use a duplicate code finder since LLMs sometimes will try to re-implement something because they didn’t see that there’s an existing solution somewhere else. The duplicate code finder is super helpful for guiding it. My biggest trick lately, my biggest improvement is doing kind of mass refactorings. Change the signature of something that’s used quite a bit in a way that’s a little bit more complex than your standard refactoring. I’ll do the first one manually. Once we’ve done the first one, I can say, “Okay, now do the rest.”

This exists in a whole bunch of files. Then the call sites need to be updated, or, you know, there are eight more instances of this, and it’ll go off and find them and make all those changes flawlessly. And with AMP, I’m using subagents, and it can do it so fast. It’s so nice.

That, for me, was a big realization lately: these tools weren’t just helping me write code faster. They were changing the size of projects I could tackle and the way I could think about reorganizing things. Of course, they’re also probabilistic, so they can make a mess. I think we’ll come to see the anti-pattern of the AI-empowered engineer as sending in the PRs that rewrite, you know, two-thirds of the codebase or whatever. We still need to be targeted in our changes, even if we’re feeling more powerful with these tools at our disposal. But yeah, the expanded ambition is a real thing.

Thinking Like an Architect

Okay. Another vacation story. Over this last Christmas, Kourtney and I were in Mexico. We were on the Yucatan Peninsula at an all-inclusive resort. It was super nice. I was sitting poolside with her in one of those beach beds, frozen drink in hand, you know, laptop balanced on my knees. And she was reading this massive Robert Caro biography while I was trying to reverse engineer Descript’s file format so that I could programmatically edit my podcast. Three hours in, I had tracked down where Descript stores its project files; it’s a zip file that contains a whole bunch of documents.

Then we were making changes to the documents, reloading the project, testing what breaks and what doesn’t. But some of the processes involved understanding obfuscated TypeScript from Descript’s own code, and I would never be able to understand that on my own. But the LLM could read through it and grab the pertinent details here and there. I realized I was attempting something that I never would’ve tried before, not just because it was technically ambitious, but because half of it was in a language that I didn’t really use and analyzing code that had deliberately been made unreadable.

A breakthrough came when I figured out that I could use this backup and restore workflow in Descript, make changes to the zip file, and then restore the project from backup. Then boom, my edits were in place, but I wasn’t getting bogged down in the grunt work of parsing all these JavaScript files and getting things edited in the right spot or deciphering crazy functions. I was working at a level higher and telling the LLM specific things, like we only want to depend on the parts of this JavaScript file that we need. Because if they make a change in their format, we want our edits to stay stable. So we don’t want to parse the whole thing.

But that’s when it hit me. I was being kind of a coding architect. I was always kind of skeptical of this role. You know, you hear of like the enterprise architect who just describes how things work, but here it was working because the LLM was doing all the detail-oriented grunt work, and I was describing what I thought the best approaches would be. We never got a great automated testing loop working because Descript is UI-driven, and this backup and restore I had to do through the UI. So the reloading was kind of manual, and eventually, I got distracted and I never totally finished the project.

But lying there by the pool, iterating on this weird experiment while Kourtney read in her book, I realized something had changed. I was thinking at a different level. I was exploring an interesting problem and just throwing away approaches that didn’t work because the tools had removed enough friction that I could focus on these very interesting parts of the problem.

Awkward Means Growing

I do sometimes hate the uncomfortable feeling of not knowing what I’m doing. You know, when you first start using something, that anxiety kicks in. The same feeling of when I started to use a Mac or learning functional programming, when everything feels clunky or you get in a frustrating feedback loop. But I’ve learned to recognize that that discomfort is often a sign that I’m growing.

You know, when I started working with Python more seriously, I kept trying to bring my SCC habits over, you know, pattern matching and immutable data structures and whatever. And some of it translated well, but some of it was just fighting against the language. But working with an LLM, I can let go of that resistance faster. Instead of forcing old patterns, I can start asking, like, well, what would be the Python way to do this? And the tool can help me discover idioms I would’ve never found on my own. I still kind of like to do Python my own unique way. I’m not huge on these giant classes with a lot of state.

I like to have some known data structures that you pass around, but it’s helpful to have a native speaker when you get into a new area. They can teach you, you know, the rhythm of the language. And because the LLMs behind these agents understand so many different pieces of technology, they can be a great guide. When you start working in a new area, it’s like, remember when you first start coding and everything was new and you stumble across some feature or library and it suddenly made everything click? Working with LLMs makes that easier, right? It brings back that sense of discovery.

Maybe it’s just me, but it feels great to always have this partner who’s there, who’s game to explore weird ideas and try different approaches or just explain things to me from a new angle. They make the whole process feel a bit more playful and a little bit less like grinding through documentation and looking for the exact thing that describes this problem I’m having. But look, I get it. If this whole exploration process doesn’t appeal to you, maybe you love your current tools and workflow. Maybe you’re an expert at the very specific thing that you’re doing, and the agents are nowhere near where you’re at until they’ll just slow you down. Maybe you just wanna focus on other skills right now. That’s completely fine. Not everybody needs to be on the bleeding edge of everything all the time.

Anti-Anti-AI

That’s cool. My friend, and previous podcast guest, Chris Krycho, was telling me that I’m anti-anti-AI. And honestly, I feel like that fits, right? Some folks hype up these tools nonstop. Others push back hard against them and say they can’t do anything. And then there’s people like me, not cheerleaders, not doomsayers, but pragmatically building things and having a lot of fun. I think these tools are useful. I also think, like I come from an odd place right after almost 20 years of coding for a living day in, day out. I don’t spend as much of my day writing code as I used to. And that puts me in a good spot to see how these tools can boost what we do. Because honestly, you don’t have to be a genius to out code me in Python.

I was never a Python expert, but that made it easier for me to just see how much help they’re bringing. It’s totally fine if you don’t agree with me. Not everybody needs to use coding agents for everything. I’m just here to speak up for anyone who’s curious and unsure. So my pitch is like, give these tools a shot. There’s a big gap between the hype and the pushback; but trying them out is the first step to bridging it. It’s just an exciting time to build things. The coding I do now is very different from when I was a full-time backend Scala engineer, you know, working on finding container vulnerabilities. I still love to code, and it’s incredibly fun, and these tools exist and they aren’t going anywhere.

When I think about my career, right, it just feels like another transition from that kid working on basic programs and then VB.NET to then, you know, learning object-oriented programming in college, and then moving from Windows to Mac and from imperative to functional and from individual contributor to manager, and then back again to building things.

Each transition feels awkward at first, but then natural and essential and fun. And right now I feel like I’m drawing on so many skills I already had: breaking down problems, understanding systems, debugging when things go wrong, knowing when something feels off. It’s just the wrong approach. The core of what makes someone good at building software hasn’t changed. It’s just that now you can have this powerful partner that can help out in the process. The same curiosity and the same drive that always excited me to understand how things work and how to build things. There’s just like a new tool, but the fundamental satisfaction of creating something is still there. Like that’s unchanged.

Choosing to Build

Am I worried that an AI breakthrough will come around and replace all analytical thought that will force us to rethink everything about employment and work in the world? I mean, honestly, a little bit. It does seem like these AIs are getting smarter, but that’s a problem for another day.

Right now, these tools exist, and they’re powerful, and they’re incredibly fun to work with. I could spend my time worrying about obsolescence, or I could spend it building things that I never thought I’d have time to build. I could resist these changes, or I could lean into them and see where they lead me.

And for me, it’s obvious what I want to do. I want to build things. That’s why I say, if you’re curious, start small. Pick a side project, treat it as a learning experiment. Have fun. You might discover that working this way scratches the same itch that drew you to programming in the first place. Or you might decide it’s not for you; that’s fine too.

But if you’re like me, if you still get that rush from figuring something out, if you still love the moment when messy ideas crystallize into something that works, then this might be worth exploring.

Because at the end of the day, we’re still builders, right? We’re still the people who see problems and wanna solve them, who imagine things that don’t exist and want to figure out how to make them real.

The tools have changed, but the joy hasn’t. It’s still this great, fun, iterative process, and honestly, that’s amazing. That would be exactly what I would’ve hoped for.

Still a Builder

That was the show. This episode was a bit different, just me sharing my thoughts on something that I’ve been thinking about a lot, and that I know a lot of people also are thinking about, whether you’re skeptical of these tools or already using them. If this show, you know, resonates with you or makes you think about anything, or change your behavior, hopefully just try some things out, and have fun doing it. I love to hear about that.

And also, if you know someone who’s resistant to trying these tools, who’s a great builder, maybe share the episode or maybe they have a more nuanced take, but please share it with them. Until next time, thank you so much for listening.