展示HN：我是一个使用AI编程的CEO——这是我开发的空气质量iOS应用程序
我是AirGradient的首席执行官，我们致力于构建开源空气质量监测器。两个月前，我决定自己动手开发我们的第一款原生iOS应用。虽然我已经有大约15年的编程经验，但之前从未接触过Swift或SwiftUI。尽管如此，我还是在60天内从一个空的代码库完成了应用的开发，并获得了App Store的批准，这段时间我仅在业余时间进行开发。
这款应用本身是一个全球PM2.5地图，包含详细视图、图表，并与我们的开源传感器集成——功能简单，但完全是用Swift原生开发的，现在已在iOS和Android（原生Kotlin版本）上上线。
对我来说，最有趣的部分其实不是结果，而是我所采用的开发过程。代理编程让我能够与AI并行工作：在AI生成代码的同时，我可以切换回首席执行官的工作——回复邮件、评论工单、撰写提案以及思考战略规划。虽然上下文切换并不总是容易，但在一个虚拟桌面上进行编码，而在另一个桌面上处理公司事务，使得节奏出奇地顺畅。这种感觉更像是在监督一个从不休息的非常快速（初级）开发者。有时，当AI在第一次尝试中就正确实现复杂功能时，我感到自己像个超人（当然，也有几次让我感到极度沮丧）。
我得到极大帮助的一点是，我要求AI根据我们现有的网页应用草拟完整的规格，提供了截图和Figma的设计稿。有时这些规格对于一个简单功能来说长达几页，包括API、数据模型、本地化、UI设计草图和错误处理。它生成的SwiftUI代码比任何正常的设计到开发的周期都要快得多。我仍然需要调试、做出架构决策并理解复杂部分，但繁重的工作已经转移到了工具上。
这次经历改变了我对一个长期存在的问题的看法：首席执行官应该编码吗？历史上的答案通常是“其实不应该”。但随着代理编程的出现，我相信这个计算发生了变化。理解AI能做什么和不能做什么，工程工作流程将如何改变，以及非工程师如何能够直接贡献，变得越来越重要。只有通过从头到尾构建一些东西，才能获得这种理解，我认为首席执行官亲自体验这一过程（包括积极和消极的方面）是非常重要的。
对我来说，更大的转变是意识到这如何改变整个软件工作流程。设计师可以交付设计稿，代理将其直接转化为可工作的组件。项目经理可以生成详细的规格，产生真实的代码，而不仅仅是指导它。即使是非工程团队也可以创建小型内部工具，而不会阻碍开发者。工程师并没有消失——他们向上转向架构、调试、约束和系统级推理。但为了让领导层对未来做出良好的决策，光是阅读是不够的。你必须亲自感受这些边界：代理擅长的地方、它们崩溃的地方，以及哪些部分仍然需要深刻的人类判断。
所以，是的，我现在认为首席执行官应该编码。不是永久性的——每周只需几个小时。不是为了永远发布生产代码，而是为了理解他们团队将要工作的新的现实，以及如何在这个新的工作环境中支持他们。
我分享这些部分是想听听其他人在HN上如何看待首席执行官或技术领导者是否仍然应该编码的问题。亲自接触AI工具是否改变了你对领导力、团队结构或战略的看法？
欢迎提问和交流意见。
以下是应用链接：
Apple App Store: [https://apps.apple.com/us/app/airgradient-map/id6752292182](https://apps.apple.com/us/app/airgradient-map/id6752292182)
Android Play Store: [https://play.google.com/store/apps/details?id=com.agmap.android.app&hl=en](https://play.google.com/store/apps/details?id=com.agmap.android.app&hl=en)
（请注意，这是版本1，因此在接下来的几周和几个月中会有很多改进。）
查看原文
I’m the CEO of AirGradient, where we build open-source air-quality monitors. Two months ago I decided to build our first native iOS app myself. I’ve been coding on the side for ~15 years, but had never touched Swift or SwiftUI. Still, I went from empty repo to App Store approval in exactly 60 days, working on it only on the side.<p>The app itself is a global PM2.5 map with detail views, charts, and integration with our open-source sensors -straightforward, but fully native with Swift and now live on both iOS and Android (native Kotlin version).<p>The interesting part for me was actually not so much the result, but on the process that I settled on. Agentic coding let me work in parallel with the AI: while it generated code, I could switch to CEO work - replying to emails, commenting on tickets, working on proposals, and thinking through strategic planning. The context switching wasn’t always easy, but having the coding agent on one virtual desktop and company work on another made the rhythm surprisingly smooth. It felt less like traditional "coding time" and more like supervising a very fast (junior) developer who never pauses. At times I felt super human when the AI got a complex feature implemented correctly in the first shot (and obviously there were a few times when it was extremely frustrating).<p>What helped tremendously was that I asked the AI to draft a full spec based on our existing web app, fed it screenshots and Figma mocks. Sometimes these specs were a few pages long for a simple feature including API, data models, localisations, UI mockups, and error handling. It produced consistent SwiftUI code far faster than any normal design-to-dev cycle. I still had to debug, make architectural decisions, and understand the tricky parts, but the heavy lifting moved to the tools.<p>This experience changed my view on a long-standing question: Should CEOs code? The historical answer was usually "not really." But with agentic coding, I believe the calculus shifts. Understanding what AI can and can’t do, how engineering workflows will change, and how non-engineers can now contribute directly is becoming strategically important. You only get that understanding by building something end-to-end, and I believe it's important that CEOs experience this themselves (the positives & the frustrations).<p>The bigger shift for me was realizing how this changes the entire software workflow. Designers can hand over mocks that agents turn directly into working components. PMs can produce detailed specs that generate real code instead of just guiding it. Even non-engineering teams can create small internal tools without blocking developers. Engineers don’t disappear—they move upward into architecture, debugging, constraints, and system-level reasoning. But for leadership to make good decisions about this future, it’s not enough to read about it. You have to feel the edges yourself: where the agents excel, where they fall apart, and what parts still demand deep human judgment.<p>So yes, I now think CEOs should code. Not permanently - only a few hours a week. Not to ship production code forever, but to understand the new reality their teams will be working in, and how to support them in this new work environment.<p>I’m sharing this partly to hear how others on HN approach the question of whether CEOs or technical leaders should still code. Has getting hands-on with AI tools changed your perspective on leadership, team structure, or strategy?<p>Happy to answer questions and compare notes.<p>Here are the apps:
Apple App Store: <a href="https://apps.apple.com/us/app/airgradient-map/id6752292182">https://apps.apple.com/us/app/airgradient-map/id6752292182</a>
Android Play Store: <a href="https://play.google.com/store/apps/details?id=com.agmap.android.app&hl=en">https://play.google.com/store/apps/details?id=com.agmap.andr...</a><p>(Keep in mind this is version 1, so lots of improvements will come in the coming weeks and months)