No Compromises

When you install a package, you probably skip the source code. But what about the AI skills and CLAUDE.md files you are feeding directly into your agent?
In the latest episode of the No Compromises podcast, we discuss whether developers are reading the AI skills they install and why it actually matters.
We make the case that unread skills are riskier than unread packages because they quietly shape how your agent thinks and can introduce security vulnerabilities or opinions you would never have agreed to if you had just taken 10 minutes to read them.
We also look at the flip side, where reading those skills can make you a better developer, expose you to approaches you did not know existed, and help you guide your agents more intentionally across every project.

(00:00) - Do developers actually read package source code

(02:19) - Why AI skills are riskier than packages

(05:07) - Security risks hiding in unread skill files

(09:30) - Reading skills as a learning opportunity

(11:49) - Silly bit

Want a second set of eyes on the tools and packages your team is trusting? Find out how our code review service can help

Have you ever added a method to an enum and then wondered if you just turned it into something it was never meant to be?
In the latest episode of the No Compromises podcast, we discuss where to draw the line when adding methods and logic to PHP enums.
We trace the evolution from magic strings to constants to interfaces, and explain why enums were the missing piece PHP needed all along.
We also cover when label methods and data structure helpers belong on an enum, why Eloquent queries cross a line, and how to avoid turning a simple enum into a bloated helper class.

(00:00) - Why magic strings and constants fall short

(01:43) - How PHP enums replaced interface constants

(02:26) - What methods belong on an enum

(06:58) - The rule for keeping enum methods focused

(10:44) - Silly bit

Join developers who think carefully about clean code decisions in the No Compromises community.

Have you ever opened a file to make a quick change, only to find dozens of lines of commented-out code making it nearly impossible to understand what's actually running?
In the latest episode of the No Compromises podcast, we discuss why keeping dead code around is slowing your whole team down.
We make the case that commented-out or unused code creates real confusion when searching a codebase, whether you are a new developer, a consultant, or even an AI agent trying to understand what is actually in use.
We also cover why Git is all the safety net you need, how Git bisect can recover deleted code you thought you might need someday, and why the fear of deleting code is almost always unfounded.

(00:00) - Why commented-out code slows everyone down

(02:03) - How dead code creates false search results

(05:10) - Dead code costs you more with AI agents too

(05:55) - How Git bisect helps you recover deleted code

(10:08) - When commenting out code is actually fine

(11:45) - Silly bit

Join the conversation and share how your team handles dead code in our No Compromises community

When a tool hands you a working solution, how much do you really need to understand about why it works?
In the latest episode of the No Compromises podcast, we discuss whether developers still care about understanding the code they ship, or whether that expectation is becoming a relic of the past.
We explore why knowing the "why" behind a solution isn't just about curiosity. It's about having enough domain knowledge to ask better questions, push back on bad answers, and ultimately produce better work.
We also walk through a real code review example involving a tricky Eloquent query, talk through the pressures that pull developers away from digging deeper, and consider what separates a line cook from a chef in how we approach our craft.

(00:16) - Are developers losing the habit of asking why

(02:16) - How AI changes the copy-paste-and-move-on cycle

(05:25) - Learning by accident while reading the manual

(06:24) - The Eloquent query neither of us could explain

(12:16) - Silly bit

Join a community of developers who still care about understanding the code they ship.

Ever feel like a project requirement says "we need multi-tenancy," and you're not even sure what that means in your specific context?
In the latest episode of the No Compromises podcast, we discuss how to evaluate multi-tenancy needs before committing to an architectural approach.
We break down what multi-tenancy actually means, from separate databases to custom domains and per-tenant configuration, and why the real question isn't which package to use, but whether you need one at all.
We also explore when hand-rolling a simple solution beats adopting a full package, what legal and compliance requirements can force your hand, and why this is one of those decisions that's genuinely hard to undo later.
00:00 Defining what multi-tenancy actually means
02:11 Different ways to structure multi-tenant systems
03:44 When separate databases are truly necessary
04:57 Questions to ask before choosing an approach
08:25 Package vs. rolling your own trade-offs
11:30 Silly bit
If you want guidance on decisions like these, check out our code review service to get expert eyes on your architecture.