I feel like not wanting to read it in depth, even though the topic is unique and something I like to learn more.

It’s a shame because there was probably quite some work that went into it: coming up with the topic, doing the research, polish it up etc.

I have also been using AI a lot for article writing but the last two posts I wrote I went back into handwriting. They are much less “perfect”, but they are me and 100% what I want to say and convey.

Even the imperfections matter.

Maybe like a piece of handmade furniture vs something from IKEA.

In my opinion this really devalues the reputation I am having for a publication and is a pity especially in this particular case as home assistant is such a great community.

This was an honest account of my experience coding this. If you do a bit of research on our company, you might come to a different judgement. But obviously everybody is free to have their own opinions.

- 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.

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)

Comments URL: https://news.ycombinator.com/item?id=45922456

Points: 14

# Comments: 7

By focusing on only one persona, you might focus on one that for reasons NOT covered in this questionnaire does not work out.

Practical example from us at AirGradient. Initially, we had a strong focus on selling air quality monitoring to schools.

Our strategy would have ticked all boxes in this article but selling to schools turned out to be extremely difficult. In our case, the problem was that decision makers are often not the people benefiting from the solution. Another reason for that persona being very difficult was that air quality is not a core competency of a school.

So I actually think that you should have a relatively broad approach because often the customer that you will be successful with you actually might not know when you start.

Unfortunately currently only super expensive instruments can measure this in real-time.

This is why I believe contextual information will become much more important in future.

Detect an indoor short PM2.5 spike around lunch time, probably a cooking event.

Detect medium elevated levels outdoor in a city in the morning and late afternoons, probably traffic related smoke.

I actually made a small tool to simulate different events that contain a quiz. Give it a try here [1].

[1] https://www.airgradient.com/air-quality-monitoring-toolkit/p...

When we first heard about this new sensor, we were quite pessimistic about its performance but have been pleasantly surprised by its performance. It is something we consider now for potential future products.

We are also currently testing the energy consumption because we believe the fanless design should make it quite efficient; but not sure how much the laser needs. So we will keep the article updated as learn more.

Comments URL: https://news.ycombinator.com/item?id=44965955

Points: 3

# Comments: 0

It only defines the diameter of the particles but can be composed of very different elements. From salt that dissolves in the lungs to toxic metals.

Currently it is extremely difficult to get a comprehensive understanding of the health impacts of these particles.

Much more research needs to be done to understand which particle compositions and thus what sources of air pollution (eg traffic, wildfires, factories, landfills, ports etc) have what kind of health effects.

If you are interested to see an image how different PM2.5 particle look like, have a look at the photo in this blog post that one of our in-house scientists wrote [1].

[1] https://www.airgradient.com/blog/pm25-is-not-pm25/

(Edited and replaced weight with diameter)

Purely focusing on the display, I can see a certain logic to say: Display not working => Not recommended. And probably I chose the wrong title for this as it made the article too much focused on this aspect.

However, the main critique for me is actually the general subjective nature of the article and the lack of a systematic testing approach for the monitors. In my opinion this review should not to be called "The Best Indoor Monitors" if Wired has an intention to provide objective and a balanced assessment of indoor monitors.

Of course I am unhappy that our monitor got labelled as "Not Recommended", but the bigger picture to what extent these "Best ..." reviews do provide a fair and comprehensive assessment is in my opinion the much more important discussion that we should have.

As I mentioned above, we are working on a refresh of the indoor monitor. The display is also under discussion but so far with 10s of thousands of the indoor monitor sold, I am only aware of a single digit number of cases of a failed display.

On subjective reviews: I think there's absolutely nothing wrong with reviews based primarily on an author's subjective opinion. However, such reviews should be appropriately labeled. For example, "My Favorite Air Quality Monitors" rather than "The Best Indoor Air Quality Monitors". The title sets reader expectations for objective evaluation with consistent methodology.

On the defective display: Important clarification: we did not ship a broken device. The display issue developed during the review period—this wasn't a QC failure on our part. Hardware can fail during use (as it can with any electronic device), which is exactly why we immediately offered replacement parts, a new unit, and detailed repair instructions when we learned about it.

On the tiny display and lessons learned: We're well aware that opinions on our display vary significantly, as evidenced by this discussion. Some users love it, others find it too small. We actually have differing opinions within the AirGradient team as well. We're planning a refresh of our indoor monitor next year and are currently testing around 10 different display types—including e-ink, colour OLED, touchscreens, and others. So far, we haven't found the ideal replacement, but we're planning to involve our community later this year to gather feedback on the various options.

I actually tried to reach out to Louis Rossmann a few times but haven’t got a response (yet).

I think what’s most interesting is that we figured out a business model based on open source hardware that’s sustainable. Thus a win-win for the manufacturer and the customer.

Repairability was actually a feature we design into the product from the start.

I spend quite a long time writing this post and it actually helped me to see the bigger picture. How much can we actually trust tech reviews?

I am already getting very interesting results from the survey I posted and already planning to write a follow up post.