Beyond the Prompt: The Founder-Engineer's Guide to AI-Assisted Development w/ Kamil Mansuri (Part 1) - Ep. 32

In the AI gold rush, the barrier to building and shipping software is lower than ever. But is faster always better? Kamil Mansuri, founder of Bad Command AI, argues that the very tools accelerating development can introduce massive security, financial, and business risks. He reveals why the "vibe coding" approach of just prompting an AI to build something often leads to low-quality products that fail. This episode is a masterclass in leveraging AI as an assistant—not a replacement—to build a true moat around your product through tactical shipping and an obsessive focus on user experience.

💡 Unlocking the Playbook

Don't Let AI Be Your Head of Product: While AI can rapidly generate code, it lacks the strategic foresight of a product team. Relying on it completely means you're trusting an algorithm to make critical decisions about your database, pricing, and security architecture without human consensus. This "shortcut" bypasses essential planning stages, creating significant financial and security risks for your business and your customers down the line.

Make User Experience Your Moat: In a market flooded with AI-generated apps, a simple, intuitive, and beautiful user experience (UX) is the ultimate differentiator. Kamil emphasizes that while AI can build functionality, it can't yet replicate the human-centric design that makes a product feel effortless and enjoyable to use. Obsessing over the small details, like how a user zooms or navigates, is what separates a forgettable tool from an indispensable one.

Connect AI Directly to Your Design System: To bridge the gap between your vision and the AI's output, connect your coding agent directly to your Figma files. By giving the AI access to your component library, fonts, and wireframes, it gains a complete understanding of your brand's visual language. This ensures the frontend it generates is not only functional but also perfectly aligned with your design standards from the very first line of code.

Seek Brutal Feedback, Not Biased Praise: Friends and family will cheer you on, but they won't give you the harsh feedback needed to build a resilient product. Kamil advocates for sharing your work on platforms like Reddit, where users provide unfiltered, often jarring, critiques. This raw feedback is invaluable because it exposes flaws you're too close to see, ultimately making your product exponentially stronger.

🤫 PART ONE's Playbook Secret (The official No Trade Secret drops in PART THREE, but here is the hidden secret of PART ONE!)

The modern founder's mantra shouldn't be to just ship fast; it should be to ship tactically. Before you can earn the ability to ship quickly, you must first establish a rigorous cadence of building, testing, and validating. Don't let the allure of AI-driven speed cause you to skip the foundational work of ensuring your product is something you can stand by and be proud of.

🗣️ Words to Build On

"The moat really, to me, is user experience now." – Kamil Mansuri

"You now are trusting the AI to be head of product... In that becomes risk, financial risk, security risk, and ultimately risk for your business and for your customers." – Kamil Mansuri

"If this product sucks, like, let me have it. I mean, I'll suck it up and I'll deal with it, but the product will be stronger because of it." – Kamil Mansuri

👤 About Kamil

Kamil Mansuri is the founder of Bad Command AI, a Princeton, New Jersey studio building native AI applications for Apple platforms. Bad Command AI builds practical AI products, including Telescopo (a Markdown workspace for macOS), Telepath (an on-device AI voice agent call center for Mac), and Telefoto (an AI headshot platform). Before founding Bad Command AI, Kamil was VP of Engineering at Vapor IO, leading engineering across edge computing, cloud infrastructure, private 5G, automation, observability, and AI infrastructure. He previously led mobile backend engineering at Take-Two Interactive, helping launch Garden Tails on Apple Arcade, and served as CTO at Momentum Technology, working on telecom infrastructure and automation for products including Robokiller, SpoofCard, and TapeACall. 

He also worked as Lead Automation Engineer at Comcast, building foundational software for enterprise change management and alerting systems supporting NBC Sports and Xfinity Business Internet. His background spans finance, software engineering, telecom, cloud infrastructure, gaming platforms, native Apple software, and AI products, including award-recognized products like Robokiller and Garden Tails, and today he focuses on building software that is practical, fast, private, reliable, and thoughtfully designed. 

🔗 Links & Resources

• Connect with Kamil on LinkedIn
• Check out Kamil's Blog
• Visit the Bad Command AI Website
• Telescopo Markdown Studio
• Telepath Voice
• Telefoto

 🎧 Make sure to listen to PART TWO and keep waiting for that momentum to hear Kamil Mansuri’s ultimate "No Trade Secret" in PART THREE

Transcript

SPEAKER_01 0:10

Today I'm joined by Camel Mansuri, founder of Bad Command AI, a Princeton-based technology company building native AI applications for Apple platforms. Bad Command AI creates practical AI tools across productivity, voice, and creative workflows, with a focus on speed, privacy, reliability, and thoughtful design. Camel's background spans finance, software engineering, telecom, cloud, infrastructure, gaming platforms, automation, and engineering leadership. He is a grounded view of AI, not just in what makes a great demo, but what it takes to build a real software that people can trust, understand, and actually use. Thanks for being on the show. Thanks for having me, Jerome. It's good to be here. Awesome. So you are in a space that obviously is uh top of mind for a lot of people, especially a lot of founders uh at the moment. And I know that there's an increasing amount of founders, you know, myself included, and and uh and especially a few friends that are close to me, um, where that barrier to using AI and and being able to uh create um with AI, whether it's you know demos on one hand or actual functioning products to use internally or to ship to other people or to take to the market uh is you know the barrier for that is is increasingly getting lower. Um what what is your what's your take on kind of where we're at right now uh with this day and age of of AI and the ability for people to do what you know they couldn't maybe 12 months ago when it comes to engineering and coding and the product development?

SPEAKER_00 2:08

Yeah, it's um I'm gonna I'm gonna take a step back beyond 12 months. I'm gonna I'm gonna take a step back maybe 10 years. Let's go 20 years, right? Let's talk about what came before, what what enabled people to actually build these solutions. And so as engineers, we wanted to actually build these things using programming languages, and these programming languages enabled us to do a lot, but they were very syntax-heavy. So these IDEs, like you know, Visual Studio, and and then later on, we have Visual Studio Code, we have Sublime Text. Um, we had a sense of um we had IntelliSense, we had a lot of a lot of a lot of uh sort of autocorrection and uh a lot of sort of I guess automation in place that could help us build software much, much faster, right? And so fast forward to only about maybe five years ago, right, where you started seeing ChatGPT and you started seeing uh this technology leveraged into building solutions that uh automate the entire coding process. You saw this early on with companies such as Lovable, which is still used by millions and millions of businesses and startups today, um, but you also saw forks or versions of Visual Studio Code uh become agentic, right? And uh you have tools such as Cursor, which is literally Visual Studio Code plus AI agents, um, become the biggest way that people are now engaging with this tooling. But it's taken such a life of its own. So, fast forward to just maybe even 12 months ago, um, you have models now that are much more powerful using tools that are even more powerful uh that let you automate the entire thing. So a couple of years ago, I coined the term five coding, where essentially you type in a prompt, and that's really what lovable is, right? But you type in a prompt and you essentially say, Let's go, and it'll spin up and create whatever it is you want. And you can see this with models such as Opus, um, and of course, uh models such as Codex and then Google's Gemini models uh through their platform anti-gravity. And it really makes it super, super easy for anyone to kind of get started. Um my take on all of this is that as a software developer, there are a lot of different moving parts to building software, not just not just the code, not just the syntax, not just the finished product, right? There's all the pieces in the middle. And to me, it's about what shape does the product take? So that could be something if if you were to build software the old school way, right? You would create um product design documents, like you would create um a component library, let's say. You you would create sort of visual artifacts, wireframes um for the visual, the front-end portion of it. You'd create um essentially data models, right, for the back end data store, how you're actually going to structure the data. Every single piece in the front end and the back end has iteration and thought put into it. And usually you have a team of engineers kind of coming up with a consensus. Engineers are designers and product owners and managers coming up with a consensus to actually say, yes, let's go and build this. Of course, the process, the process with startups, sometimes sometimes we skip over all of that, but still the process remains generally around that that speed, that, that, that, that cadence. And so when you have AI kind of shortcutting all of it, you lose a couple of things. You now are trusting the AI to be head of product, you're trusting AI to uh understand pricing, how to understand what databases you need to use, what programming language potentially, what what um I don't know, what what libraries using under the hood, right? Uh you don't really have a full sense of what it's pulling in, and in that becomes risk, financial risk, security risk, and ultimately risk for your for your business and for your third customers. And so I um my take on AI and using AI is very nuanced. I think it's it's great in a lot of ways. It enables people to build things much quicker, iterate much faster. But at the same time, I temper it with well, I want, and I've always wanted, people to be more educated in how to code, how to code, how to build software, understand that there is some restraint, right? That we need to maybe take a step back and understand what this code does. Maybe instead of saying, yes, this is great, this is working, like let's look at the let's look at the code. Um, let's actually maybe learn some best practices with um how the visual aspect of it works, right? Like what is user experience for a mobile user or somebody using it on an iPad or using it on a very, very large, ultra-wide monitor, right? Um so you want to also understand from a UX perspective how that's gonna feel, how that's gonna look. And those are things that you can learn. And I think if if that is promoted in conjunction with all the advances of technology and AI, I think we could see some really impressive stuff in the future. But I think right now we're in this weird middle phase where we're just getting a lot of very um swiftly coded uh AI projects that necessarily are making it to market but aren't necessarily the best quality.

SPEAKER_01 7:28

Yeah. No, thank you for I mean that's I feel like I see I see a lot of that too. And like especially it's there's an like there's an overwhelming amount of new products shipped uh all the time in in whatever industry you're in. And so there's so many options that are coming out there, and then I think um a lot of them are products uh that are experiencing some of the the flaws that you're talking about here, and and you know, like just even in my own um you know experimenting and playing around and building things, um of the some of those things that you had mentioned uh are things that I had to, you know, I learned over time that um there were pieces there on I was I was missing uh leaving out in the process of building. You know, like for example, if I rewind uh I I don't even know how many months ago, let's just call it you know four or six months ago, um going into you know, like a Claude code and describing what I'm trying to build and um starting from there and then it looking visually terrible and functional, you know, the actual functionality uh of the application being terrible and not actually working, uh was something I would run into frequently. And so then um that was when I had to learn um the importance of the actual design and having the design files um and which led to creating for us a company uh brand kit that uh encompassed not just our fonts and logos and color scheme, uh, but also you know, like little things that I had not thought about prior with like, okay, if you have a button that for this, the button should look like this, it should function like this, uh the you know, all the wireframe uh stuff that you're talking about, like what does a drop-down look like inside the application? Uh if you click a button, like something that um you know, just the the things to follow that will come up throughout the application that you just don't think about when you're you just have this vision in your mind about like, oh, it'd be really cool if we could create something that does this. But you know, one of the things for for example, had a refresh button. And then I didn't know if the refresh was working because there was no uh nothing that popped up saying refreshing, something that all good products have, right? To let you know that the refresh, you know, or the button is doing something if it's something that it takes time to do, uh no loading button. Or I noticed that the coding agent seemingly never put in if you create something that has like a login, it never automatically uh tends to create a log out button. Uh so I was like, uh how do I get out? Um and then going into things like uh, you know, when I first when I first created something uh when Perplexity Computer came out, and uh and it was just like uh it was something it was a uh like a a a lead magnet quite type interactive tool, like just a questionnaire basically to put on our website and it created it. It looked good, it followed our brand scheme, it functioned all the way through, but then I realized Perplexity Computer has no back end, so had to recreate that elsewhere so that I could actually because I didn't understand the pieces that went into actually putting it on the website, and then tr then there's the whole part of the data storage, and okay, well, where's the data going? How are you tracking people's responses? How are you tracking any of the data that's actually useful from it? Uh, where do the the answers actually go? How do you set up the email that sends to them so that they can see their results? All these little things that kind of happen, I noticed like were just things that uh were not thought of at the beginning, and then it be and then it I noticed it was a lot harder to come back and reiterate when you've already created it the wrong way. It's a good call. And so and you you raise a good point on the like the visual aspect too, because I'm very much a uh I like visually appeasing things, right? What i and I think that is something that's very underrated um and not enough emphasis is placed on with all these new products that get shipped, um is that even if the functionality is all there, if it's not easy to use then a lot of people won't use it. Do you like what where do you rank the importance of things? You know, if there is a founder who uh you know, you're talking about uh you need to be a head of design and product and all these different things that you know a traditional team would uh would have when creating a product like uh we're talking. Just an average founder that doesn't have a background really in any, which ones are which what are the most important ones to learn?

SPEAKER_00 13:25

Yeah, I think yeah, I think you describe me really, really accurately here. I am a back-end and automation engineer historically. And so when I moved in from finance into engineering, uh I focused entirely on back-end engineering. Wasn't a full stack engineer, never claimed to be. Uh, in fact, I just kind of shied away from building frontend altogether because it just seemed very daunting and very insane. Um so focused heads in the clouds, just kind of focused on back-end. Um but over time, when I founded my first startup, realized, well, we have really smart people uh in our in our startup that are just excellent at building UX, excellent at building front end, taught me things about Figma, taught me about component libraries, um, just a lot of the things that I had to remember uh when I started this company, sort of bad command, and that, well, I could hire people or I could get contractors to kind of do this design for me, or I can use the tools I have access to.

SPEAKER_01 14:27

So can you explain for anyone who doesn't understand the difference between front-end and back end? Because I know not it wasn't long ago that I didn't really know fully the what each of those meant.

SPEAKER_00 14:41

Yeah, exactly. So in in in the context of what you shared, um where in your example you had the entire thing wired up and it looked beautiful and it fit your component library and all of that. That visual aspect of it, that's what we call front end. That's the front-end facing of uh of the thing that you've built, whether it's a website, web application, you know, iPhone or Android application, whatever have you. It's it's sort of that user-facing piece. Backend, on the other hand, is more of a blanket term that refers to literally everything else. Think of the data store, the databases that store your data, um, the actual stuff, the computer's running the code, right? The server's running your code, the code itself, the infrastructure that may need to spin up or down to scale some of the workload that you're building. All of that is back end. And so I would say for many products now, uh the back end is significantly more complex than the front end. Um and then the other term that you might hear me use or other founders use is full stack development. Um that's that term isn't really used as much anymore because I think everything is full stack development. Uh, but uh when I when I talk about FigBo, uh, I'm talking about a tool that's it's very powerful. Uh most designers uh keep component libraries in there for building mobile applications. It's very, very powerful for that. You can also use it for web applications. Um I bring it up actually as a um as a as an unlock here, actually, for some of your listeners. So uh something I started doing about three and a half months ago, four months ago, um, that helped me quite a bit was if when I'm using uh agentic coding agents, uh, such as you know, Claude, or if I'm using to gravity or using codex or using whatever, they all have the same concept of agents. And um agents can connect to different services via this protocol called MCP. And I am actually answering the UX question in this, so don't worry. Uh so when it connects to different things, you can actually connect to Figma. So what's really cool is if you already have everything in Figma, all the fonts, all the components, all that stuff, you can actually tell the AI, hey, use my Figma skill, and it'll connect to the Figma thing you've created, and it will pull all of it into your code. Now it now has a complete understanding of all of your components, what it's called. Your entire brain that's in Figma is now inside of this uh system that can access it and actually build the UI around it. So this can make your experiences building things in an automated fashion a bit more tangible because now it's gonna stick to what it can see visually in Figma. The other cool thing I always recommend doing is taking screenshots, and there's ways to kind of automate this, and I think some of these tools let you do this, but send the screenshot itself uh to the AI agent you're using. Show it visually everything. And if the AI agent doesn't understand the screenshot you're using, don't use it. It's it's not it's not the right agent for you to use to build the front end. Um so in this way, I was able to early on uh understand okay, how this AI is sort of helping me learn how to build better front end and better user experience. But the best thing I did was leverage AI to start helping me build it, but then understand how to build it myself and then start using it and making sure it passes my very high standards of usability. And so from a UX perspective, I want something that I'm building to be super, super simple. It should just work straightforwardly. I shouldn't have to think about it. And it should look beautiful. And so Bad Command AI focuses entirely on the Mac platform, on the Apple platform, because there are very, very strict standards with across the entire platform that focus on UX. Google too, Android 2. But um I don't know, I focused on Apple just because it's it's it's what I have and it's what I know, and I've built Apple products before. But um I really like that focus on UX. And so I use the human interface guidelines that Apple provides as sort of the baseline for how I build software. It doesn't look necessarily like native Apple software because I don't always agree with Apple's design direction, but I focus on the user experience in that way. I'll give you an example. So um with uh one of our products, it's a it's a markdown viewer. Markdown is a syntax language used to write complex technical documents, but you can also use it to write literally anything. There's so many different markdown editors out there. But we built something that was called uh Telescope Markdown Viewer at the time. Later on, it became an editor. But I shipped it as a viewer because I couldn't, I could, I was not happy with the user experience in opening the editor. I wanted to, I realized I could build a really, really good viewer, something that just natively instinctively worked. Now, I'll I'll describe that. So when you're when you're reading a file in, I don't know, Microsoft Office, Microsoft Word, right? Um or even Google Docs. Intuitively, if you have a file and it might have different font sizes, you might have a big monitor, you might have a small monitor, you might have a laptop, whatever you have. Um I find it's very intuitive to just zoom in. Sometimes you want the font to be really big, sometimes you want the font to be really small. Um about 12 years ago, Apple kind of made a big change to its user experience, and it doesn't let you do that anymore. And so if you were an older Mac user or iPhone user, like you would be able to zoom in very, very easily on text. And it was it was really great when you had multiple monitor setups or monitors that were much, much bigger. And so part of it was I wanted to build something that could intuitively scale and zoom like a ridiculous amount, really, really small and really, really big. It sounds very simple, but when you're actually dealing with complex markdown, which includes not to get too technical, it includes mermaid document uh diagrams, which are very, very complex diagrams, think Gantt charts, think like timelines. You could do all of this in Telescope, by the way. It's it's awesome. It's super easy now. But when it was a viewer, I wanted to think about how you'd want to scale and zoom these things on ultra-wide monitors, right? And so I have all of these in my office. And so I wanted to just throw up like the most crazy markdown files I possibly could and make sure I can view them within maybe a couple of seconds uh and calibrate them and just make sure they stay that way. And to me, that is good user experience because I feel very happy and comfortable using it just with either a mouse gesture or with a trackpad zoom. It's just intuitive and natural. It doesn't feel heavy, it doesn't feel like you are doing anything complicated by clicking a button and looking for a zoom icon. And I mean, I still have that for the people that need that. But for me, I use trackpad zoom and mouse zoom for everything. Finding um anything in a file, for example, should also be very immersive and intuitive. You should be able to just hit a button and start typing and find whatever you want and just hit enter a few times. Um, in terms of navigating markdown files, you hit left or right arrow, it'll take you, it won't it won't scroll the page left and right. It'll actually take you, it'll understand the chapters and sections of a markdown file, and it'll actually zoom to the next chapter, like within within a file. So you can very, very quickly, it's called telescope and navigator, very quickly navigate. And so these are concepts that I've learned over the last year and a half or so that are UX concepts that are based on kind of Apple human interface, but aren't actually inside of Apple's ecosystem at all. They're just kind of they work alongside it. And I think that thinking about these things in in terms of how as a human we want to use software is kind of that missing piece that AI really can't replicate yet.

SPEAKER_01 22:38

Yeah no and I I run into the the same thing I think um I believe you do you you you testing the product like in your office on those ultra wide screens that you use um to make sure that it works and that you're happy with uh the UX. Is that term called dog fooding?

SPEAKER_00 23:05

Yes. And so I actually do dog food those builds to a certain cadence of of of users that kind of early on kind of help me shape the product. And so they're the most vocal critics uh early on but they become some of my my best users because they'll tell me like this this is this rocks comel or this socks comel. Like it's it's um and so if it if it's even a little bit positive of the signal I'll I'll probably ship it. Because I could always I could always adjust it later.

SPEAKER_01 23:34

Yeah. Oh and because I do that with one person in particular uh everything I create I give him a login or give him my login or give him access and and he and we do it for each other and we run through as if we're a user and little things that um I may have not have thought about uh he'll go in and and and be able to say hey like this, this this and I'll be like makes sense and then able to make those updates and I I think that's where I think that's where a lot of a lot of these softwares and applications are kind of missing is I and maybe you'll know the answer to this more but it feels like a lot of these companies that are shipping these products are not dog fooding their own products and testing out how they function and how easy they are to use like themselves, especially when it's in an industry that maybe they're building it maybe they're building a solution with their application or software for a specific industry that they are not in that industry per se and missing any testing prior to launch with any users that are in that industry and just know things that they need to be able to do that you might not in building the product. Do you do you see the same thing?

SPEAKER_00 25:15

Absolutely I have I have uh I can share some of the best feedback I've gotten has been from Reddit and from just internet communities. They'll tell you what they're thinking um and it's it it it it can sometimes be uh a bit a bit jarring a bit um you know if you wear your heart in your sleeve you you may want to just prepare mentally before doing that. But but like it is it is it is it is a fantastic source of feedback because you want that. You want that feedback early and you want that feedback often. And if you are to to what you said, right, I think do I think most companies are not testing I I'd like to think not. I mean I like to think that they are to a degree. I mean I if if you're if you're ship if you're building products for um for profit you know and you're looking to you have certain projections you have certain commitments you have certain applications you need to make money so it wouldn't make sense not to test but um I would say that they're not testing enough because from a perspective from my perspective there are is there are so many so many pieces of software that that are being built right now like just for you know apps um web applications um and there's just too many and for you to kind of stand out for you to differentiate for you to actually make money in this crazy ocean you need to have very very strong user experience it needs to be simple it needs to solve a painful problem and it needs to be dead simple like for that person to solve that that difficult problem. That's it. And if you can if you can achieve that then everything else is just nuanced. Everything else is sort of like all right well we're just gonna make sure we're gonna adjust this we're gonna tune this we're gonna make everything should be around that moat if that makes sense. The moat really to me is user experience now. I I don't think you know user experience and UI like just making sure it just fully works. Everything else we can use AI to really help us and assist with but man that user experience and just how that that feels when we're using it that's that's that's what will make a company successful if they're building products and solutions. But yeah dog fooding using Reddit um I would I would say friends and family are very good but they're also a little bit biased because they want to they're they're tune for you they they want you to succeed and I don't want that. I do want to succeed the bad stuff. Yeah man like if if if this product sucks like let me have it I I I mean I can I'll suck it up and I'll deal with it. But I will I will the product will be stronger because of it. And it goes back to kind of something else you were saying right like we're building these things in small teams now. Like we have my company's very small studio my employees are contractors right contractor in companies and studios like I'm able to hire these people and pay for contracting services because the product is successful. But I am the engineer right I'm founder and engineer of this I'm building all of this with um AI assistance to a degree but I understand everything I'm committing to code and I understand all of the UX because I don't ship anything unless I absolutely love it and I stand by it. So yeah I think that's the mindset is is don't just don't just ship really fast, ship tactically and test and then ship. And then you get into a cadence where you can ship fast.

SPEAKER_01 28:55

So you know there's I think there's uh kind of two camps as well of people out there like there's uh there's one side there's people that are building products because they want to ship those products to sell for profit and then there's also um a lot of founders out there like myself who um are building tools to be used internally or to be useful tools to uh to help in providing the services that we provide and uh you know the end user is uh who you know the end user being like our clients um and like I and I see like those being kind of like pr pretty distinct in what needs to go into those especially and I think those are really three levels especially if it's internal I feel like that's the lowest barrier of uh but for for founders uh like myself and where I'm wanting to build internal and client facing tools um w especially when it comes to security right and if there's uh client or internal data going into this um you know if you've got through the front end side of it and it it functions well it looks great um and it works obviously um what like where should uh is there a point where someone like myself with that if there's a tool that in uh inv includes or contains data you know of variable sensitivity uh where there's it shouldn't be someone who like me is not a have uh an engineering background coming in and looking at the security risks and the data risks uh like like if I if I were to ask you like I've like uh I can give you a real life example so um right now I'm close to being finished building a uh internal practice management software to replace our current one I did that because we've been through three or four in the last couple of years and none of them do exactly what I they're you know they maybe they're great this one thing and then but these other features suck. And so then I don't like using tools like I won't use uh one function within that platform if it sucks so then it's I'll go and find a company that provides you know that does that thing and does that thing great and so then I found myself with this very wide and growing tech stack um and I'm like these are things that like I'm not the option is not to settle for great at this one thing and then subpar or average at all these other things that it does. So that wasn't an option but then it also it just was making less sense to have such a wide tech stack. And so I said I'm gonna just build the replacement myself and build it how I want it to be for how our myself and our team needs to use it. And so we're at that I'm at that point where uh we're I'm about to roll it out to our internal team and where I'm starting to think about like is there any is there anything on that side especially on the code side when it comes to security and data that I need to be thinking about and how should I approach that?