The Code Got Easier. The Product Did Not.

I recently joined Jarome McKenzie for three episodes of No Trade Secrets. We began with AI-assisted development and moved through product design, security, on-device models, voice infrastructure, distribution, and what changes when an engineer becomes responsible for the business around the software. Listening back, I realized that one question followed us through all three episodes: once AI makes code dramatically easier to produce, what work is left for the person building the product?

My answer, after thinking about it, is nearly everything that determines whether the software deserves to exist. These tools have changed what I can build and how quickly I can build it, but I still have to make the product understandable to another person, protect what they trust it with, work through the economics, and keep it running after the demo has ended. AI means I encounter those questions much sooner than I used to, often while the first version is still taking shape.

What AI Changed in My Work

AI coding tools have moved far beyond autocomplete. They can explore an unfamiliar codebase, draft an interface, trace a bug across several files, write tests, and help an experienced engineer move between frameworks without spending days rebuilding context. I use that leverage throughout my work at Bad Command AI to move across native Mac software, voice systems, and AI imaging at a pace that would have been difficult only a few years ago.

The part I have to watch is the temptation to treat implementation speed as product judgment. A model can recommend a database, choose a dependency, propose a pricing structure, and offer a security design in the same calm voice, even though those decisions carry very different risks. I am the one who will support the customer when the dependency changes, work out why the pricing cannot sustain the service, or discover that a convenient integration sent data somewhere it never needed to go.

I learned to think about systems by building and operating them while people were already depending on them. That experience moved through telecom, reliability automation, mobile games, edge infrastructure, and AI systems, but the lesson stayed consistent: the clean architecture is only the beginning. Production introduces handoffs, partial failures, old protocols, vendor assumptions, confused users, and consequences that were invisible when the system existed only on a whiteboard. I wrote about this in Fifteen Years Where Latency Is the Product, and AI makes that education more valuable because one person can now create more software before reality has had a chance to test it.

Implementation became cheaper. Living with the decisions did not.

What Telescopo Taught Me About Product Work

I started Telescopo Markdown Studio because I wanted a better tool for my development workflow and wanted to become better at building native Mac software. The original application opened Markdown and rendered Mermaid diagrams, but releasing it exposed the distance between functional software and a product other people could comfortably use. Early users were direct about where it felt unfinished, and their feedback mattered more than protecting the first version simply because I had built it.

The work that followed was rarely about whether I could implement a feature. It was about where the feature belonged and how it changed the rest of the application. I put themes, fonts, and reading size in Telescopo's toolbar because they are part of reading, not preferences buried in a settings window. When the app grew from a viewer into a split editor, I reconsidered every control because an obvious icon in a reading-only interface could become ambiguous with two sides of the document visible.

The same judgment appears in less visible places. Thirty themes require coordinated background, text, secondary, and code syntax colors rather than thirty attractive swatches. I needed Mermaid diagrams to remain readable across light and dark documents, user-selected backgrounds, and macOS Increase Contrast, while section navigation had to understand the structure of a Markdown file without making a long document feel like a web page covered in controls. None of those problems is individually dramatic, but together they decide whether Telescopo feels like a native workspace or a collection of features.

AI helped me explore and implement parts of that work faster, but it did not tell me which version belonged in Telescopo. That came from using the product every day, watching where the interface made me hesitate, and listening to people who used it differently from me. Reading Controls Are Not Settings and Accessibility Is Product Quality go deeper into two of those decisions.

Telepath and the Problem of Trust

Building Telepath made the limits of implementation-first thinking even clearer. A voice agent is easy to describe as speech recognition, a language model, and text-to-speech connected in a loop. A real phone call brings in SIP providers, carrier behavior, interruptions, transfers, consent, recording rules, latency, call state, diagnostics, and the question of what should remain after the conversation ends. The model is only one participant in that system.

Before Telepath, I had already spent years working with telecom and voice infrastructure, including products such as Robokiller where phone calls were not a demonstration layer but the actual environment the software had to survive. That background is why I designed Telepath to keep local call records, expose what is happening during a call, and treat consent and recording behavior as part of the workflow rather than an afterthought. A business owner should be able to understand what the agent did, what information was retained, and where a failure occurred without needing access to the machinery underneath it.

This is where on-device AI became useful to me as an architectural choice rather than a marketing position. Some local models are not sufficient, and some remote services create a clear advantage, but I still ask whether a piece of work needs to leave the Mac at all. Local transcription, deterministic workflows, and constrained local intelligence can reduce latency, cost, and unnecessary data movement, so I decide where that boundary belongs one path at a time.

Working through Telepath also made me more disciplined about accounting for data before talking about security. I need to know what the product collects, where it travels, which vendors can see it, how long it remains, and whether I need it in the first place. Edge protection, audits, and vendor controls all matter, but they cannot repair an architecture nobody has taken the time to understand. I explored more of Telepath's technical and economic direction in Why I'm Building Telepath.

Privacy is not where the model runs. Privacy is whether the whole system keeps the promise made to the user.

Owning the Business Changes the Engineering

The third conversation moved into the part of building I could postpone until I owned the outcome. Earlier in my career, my partners and I acquired technology we had helped build when the original business divested it. Buying the intellectual property meant engineering was no longer separate from sales, support, distribution, and cash flow. That responsibility is difficult to reproduce when another team owns the commercial consequences of the software.

AI makes prototypes inexpensive enough that this lesson now arrives sooner. I can have a credible application before answering who will find it, what they will pay, what it costs each time the product performs its job, or how much support it will require. Those questions shape the architecture and the product from the beginning.

Each product I have built at Bad Command AI makes that visible in a different way. Telescopo needed distribution beyond the crowded Mac App Store, and Setapp placed it in front of an established global audience of Mac users who could use it immediately. With Telefoto Headshots, I have to communicate a visual outcome before someone downloads the app while also accounting for the real cost of generating high-quality images. Telepath began with my observation that cloud voice agents could cost businesses fifteen to fifty cents per minute or more, so its architecture and business model could never be separated from the question of how much of the stack truly needed rented infrastructure.

I have not had to leave my engineering background behind to think this way. It helps me see which costs are structural, which dependencies I can remove, and where optimizing too aggressively would damage the product. What changed is that I now have to connect those decisions to whether the product can find an audience and support itself, sometimes before I decide whether an interesting technical idea should become a product at all.

Why I Still Build What I Care About

The series closes with a conversation about building what you care about, which can sound shallow if I leave out what that looks like after the novelty wears off. For me, it often means spending another evening correcting a theme, tracing a call path, or studying why a product is not converting because I still care enough to understand it. That feeling is useful, but it does not excuse me from building for a customer, understanding the economics, or listening when criticism exposes something I missed.

I founded Bad Command AI because I enjoy building for Apple platforms and believe native software can still be both powerful and fun to use. That belief is visible in animated themes that nobody strictly needs, in local AI paths that take longer to engineer than another API call, and in the small interaction details that make a Mac application feel settled. The discipline is knowing that those details must support the person using the product, not merely entertain me while I am building it.

I use AI constantly, and it has given me more leverage than I have ever had as an engineer. What I care about now is whether I can use that leverage to make something understandable, trustworthy, economically durable, and good enough that people choose to keep it. Producing more software is easy to measure, but it is not the outcome I am building toward. The code got easier. My responsibility for the product did not.

Listen to the Three-Part Conversation

For an earlier conversation about Kamil's path through telecom, reliability, voice infrastructure, and native Apple software, read From Phone Carriers to AI Voice Agents.