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).
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).
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.
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).
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.
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.
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?
Happy to answer questions and compare notes.
Here are the apps: Apple App Store: https://apps.apple.com/us/app/airgradient-map/id6752292182 Android Play Store: https://play.google.com/store/apps/details?id=com.agmap.andr...
(Keep in mind this is version 1, so lots of improvements will come in the coming weeks and months)
crypto_is_king•2h ago
What are your experiences with the debugging hell loop when the ai agent gets lost?
How do you avoid that or get baxk on track?
ahaucnx•2h ago
- sometimes when it’s lost, just roll back. Commit very often. Sometimes it’s getting lost on simple and easy features - very unexpectedly.
- prompt regularly to review the architecture and clean up the code, check for specific things like code repetitions, error handling etc.
- keep an eye on the code yourself. At least on the general architectural side, and review complex code areas by hand
- ask always for larger features to make a plan first. Review the plan carefully. Only when the plan is ok, ask it to start coding.