For a long time, I refused to touch them. Here's the problem I kept running into: if you're generating more code than you can actually review, you shouldn't ship it. Full stop. And even when you do review every line, you still miss things. Things you'd only catch if you'd built the system yourself, from the ground up. So I used them, but very carefully. Then I dove into the ICM rabbit hole. Instead of asking the agent to generate code, you describe in text what the program is supposed to do. The agent works in that same text, as the source of truth. The moment you translate intent into code, you lose precision. ICM never makes that translation. The rules stay in plain language, all the way through. And at any point you can read line by line to see the intent. That's what makes it the first form of "vibe coding" I actually trust. You can build genuinely complex systems with minimal effort, and without needing to read a single line of code to verify it's right. It's not a shortcut. It's a different way of specifying software entirely. And what's great is you don't need previous software experience to make it work!

I had 3 hours to build the AI Shopping Assistant of a Shoe Store Website for an AI Engineer interview. The challenge was intentionally oversized to test architectural judgment and prioritization under pressure. Needless to say, ICM killed it. A. The 10-Minute Blueprint From a single prompt structured around ICM principles, I generated a modular context architecture. Rather than building a black-box chain, the entire agent logic was broken into explicit, file-based stages: - 01_route: Intercepts user intent and determines required execution paths. - 02_search: Autonomously gathers external data, stock levels, and size guides. - 03_answer: Formulates user-facing responses adhering to specific channel tones. - 04_log: Records structured audit trails for system inspection. B. Business Rules and Mock Datasets With the structure locked in, I plugged in mock datasets for the shoe inventory and the shoe size conversions (that the tools would query) and isolated business constraints into clear, human-readable markdown files. Because business logic and tones lived entirely in explicit text layers rather than hardcoded scripts, swapping rules required simple text updates without touching code. I used the remaining time to add new tools the agent could call (eg.: currency conversion), implement better search methods, improve the logging system, and extend the data set. C. The Live Interview Experience When the review started, the interviewer didn't just review static code; we ran live tests using complex queries. When asked intricate questions involving inventory checks across sizing boundaries and currency conversions, the interviewer watched Stage 02 autonomously loop, executing tools until it gathered every piece of required context before allowing Stage 03 to draft the final response. Seamless Adaptability: We modified output formatting and added new business constraints live in seconds simply by altering context files, proving how easy system maintenance becomes under ICM.

My mind has been playing tricks on me, telling me that this community might not need my kind of content. Maybe because we are mainly builders and always building here. My information is not heavy on harnesses, labs and experiments (even though I build myself). It’s more leadership focused. I address leaders and how they should lead in this age. I’d love to share but I don’t want to share what we won’t need. So I’m asking. Would we like that?

Perhaps we're governing AI as if it were traditional automation. And that may be part of the problem. Traditional automation encourages a particular expectation: Input X → Rule Y → Output Z. We expect the process to behave as designed. AI, particularly ML-based and generative systems, might require a different mindset. We should assume that it will be wrong sometimes. Not as an exceptional event. As a property we need to design for. Suppose an AI system achieves 95% accuracy. Is that good? The answer isn't really in the 95%. It's in the 5%. - If 5% of automatically generated document tags are wrong, perhaps nobody particularly cares. - If 5% of employment, credit, medical or safety-related decisions are wrong, we have a very different problem. So perhaps one of the first questions in AI governance should be: - “Can this use case tolerate the AI being wrong?” That changes how we think about human oversight too. One response to imperfect AI is: - “The AI isn't 100% reliable, so we'll put a human in the loop.” But if a human has to validate every output, we may have simply created an expensive form of automation, and potentially a rubber-stamping exercise. Instead, perhaps we need to treat AI for what it is: ML, not deterministic automation. That means: → Define the expected performance before deployment. → Build evals around the actual use case. → Understand the failure modes, not just the average accuracy. → Define what kinds of errors are acceptable—and which are not. → Establish thresholds and escalation mechanisms. → Monitor performance after deployment. → Design the process assuming the model will sometimes fail. And then decide where human intervention actually creates value. The objective shouldn't necessarily be: - AI + human checking every output. It should be: - AI operating inside a system designed to tolerate, detect and manage its inevitable errors. This leads me to a principle I increasingly find useful:

This podcast says yes. I can say I disagree…