
Sign up to save your podcasts
Or


Discover how a CTO turned the messy problem of vibe coded apps into a single Claude skill that tells you whether your app is actually safe to ship. This deep dive walks through why asking AI “is this production ready” burns through hundreds of thousands of tokens and still gives you the wrong answer, the seven to ten things a CTO actually checks before an app goes live, and two real internal tools audited on screen, including the moment the skill catches a leaked secret key and app logic sitting wide open on the client side.
In this episode:
* Why maintainability matters as much as security the moment real people start using what you built
* What a non-engineer simply cannot see when they look at a working app, and where it breaks
* Why just asking AI if something is production ready burns 200 to 250K tokens and changes its answer the next day
* How an app ends up split across Vercel, Railway, and AWS when the AI keeps improvising fixes
* The CTO’s checklist: tech stacks, backing resources, code repos, secret scanning, libraries, and schema
* A single-prompt Claude skill that ranks every issue by how soon it will bite you, then hands back a fix list
* Where the skill still traps you in a fix-then-break loop, and the exact moment to bring in an engineer
Timestamps:
(00:00) Introduction
(01:07) The problem: your team can build apps but can’t tell what’s safe to ship
(02:26) Why maintainability matters, not just security and safety
(03:35) What a non-engineer can’t see when they look at working code
(05:27) Why just asking AI “is it production ready” fails
(05:44) The token burn: 200 to 250K per run, and answers that change daily
(06:37) How an app ends up split across Vercel, Railway, and AWS
(07:16) The CTO’s checklist for what makes an app production ready
(08:09) Tech stacks, backing resources, code repos, and secret scanning
(10:19) Live demo: auditing a simple work redesign app
(11:47) The prototype a non-coder built in minutes
(12:43) How the skill runs the audit on the app
(13:14) The biggest risk it caught: all logic on the client side
(14:25) Second example: the asset tool that replaced a SaaS
(17:08) Walking through the audit results and the fixes
(17:51) One prompt to fix a leaked secret key and more
(19:31) Running the skill with Claude in thinking mode
(20:02) Which model and thinking mode to use for fixes
(20:40) How to tell if you’ve overbuilt or burned too many tokens
(22:13) Inside the prompt: sanity checks and severity ranking
(23:14) How non-engineer proof the skill really is
(23:57) Does it explain the risks in plain language?
(24:53) Has the skill ever missed anything significant?
(25:30) The fix-then-break loop and how to get out of it
(27:56) What maintainability actually means
(29:25) Does it work with only the prompt history?
Resources & Links:
* Claude
* https://github.com/impressai/vibe-check-skill
* https://www.12factor.net/
Connect with Dr. Vaisagh VT:
* Impress.ai
By Shipping with AIDiscover how a CTO turned the messy problem of vibe coded apps into a single Claude skill that tells you whether your app is actually safe to ship. This deep dive walks through why asking AI “is this production ready” burns through hundreds of thousands of tokens and still gives you the wrong answer, the seven to ten things a CTO actually checks before an app goes live, and two real internal tools audited on screen, including the moment the skill catches a leaked secret key and app logic sitting wide open on the client side.
In this episode:
* Why maintainability matters as much as security the moment real people start using what you built
* What a non-engineer simply cannot see when they look at a working app, and where it breaks
* Why just asking AI if something is production ready burns 200 to 250K tokens and changes its answer the next day
* How an app ends up split across Vercel, Railway, and AWS when the AI keeps improvising fixes
* The CTO’s checklist: tech stacks, backing resources, code repos, secret scanning, libraries, and schema
* A single-prompt Claude skill that ranks every issue by how soon it will bite you, then hands back a fix list
* Where the skill still traps you in a fix-then-break loop, and the exact moment to bring in an engineer
Timestamps:
(00:00) Introduction
(01:07) The problem: your team can build apps but can’t tell what’s safe to ship
(02:26) Why maintainability matters, not just security and safety
(03:35) What a non-engineer can’t see when they look at working code
(05:27) Why just asking AI “is it production ready” fails
(05:44) The token burn: 200 to 250K per run, and answers that change daily
(06:37) How an app ends up split across Vercel, Railway, and AWS
(07:16) The CTO’s checklist for what makes an app production ready
(08:09) Tech stacks, backing resources, code repos, and secret scanning
(10:19) Live demo: auditing a simple work redesign app
(11:47) The prototype a non-coder built in minutes
(12:43) How the skill runs the audit on the app
(13:14) The biggest risk it caught: all logic on the client side
(14:25) Second example: the asset tool that replaced a SaaS
(17:08) Walking through the audit results and the fixes
(17:51) One prompt to fix a leaked secret key and more
(19:31) Running the skill with Claude in thinking mode
(20:02) Which model and thinking mode to use for fixes
(20:40) How to tell if you’ve overbuilt or burned too many tokens
(22:13) Inside the prompt: sanity checks and severity ranking
(23:14) How non-engineer proof the skill really is
(23:57) Does it explain the risks in plain language?
(24:53) Has the skill ever missed anything significant?
(25:30) The fix-then-break loop and how to get out of it
(27:56) What maintainability actually means
(29:25) Does it work with only the prompt history?
Resources & Links:
* Claude
* https://github.com/impressai/vibe-check-skill
* https://www.12factor.net/
Connect with Dr. Vaisagh VT:
* Impress.ai