Every day we read about mass layoffs by huge companies. But on the flip side, how do you hire a good technical engineer in the age of AI? I was involved in candidates’ interviews while working at AWS. I helped numerous founders to screen and hire candidates for different technical and management roles. Later on, I worked with those new hires and saw firsthand if those people were a good fit for roles, for teams, for tasks we had envisioned with the founders when we prepared for the hiring process.

I have been experimenting with various AI agentic workflows over the past months, testing different architectural patterns and seeing where they deliver real value. Suddenly, I realized this technology is a perfect fit for IoT workloads that use MQTT (the primary protocol for managing devices). I have worked with MQTT for years, but I had not connected it to AI agents until recently. MQTT’s pub/sub architecture creates something unique: a continuous data stream that agents can subscribe to without impacting the environment.

The overall solution design is a challenging topic in the world of Small and Medium Businesses. I prefer working with those companies as they are very agile (in the day-to-day reality, not only on the powerpoint deck). On the same token, that agility makes it nearly impossible to properly design a solution (when we are halfway through the design/implementation process, the business conditions change, the owner adjusts, and I have to introduce small/medium/major updates).

Typical scenario You hired a vendor to build your platform. They delivered on time, on budget, and it works. Then your investor/board asks: “What happens if this vendor disappears tomorrow?" You don’t know. Your team doesn’t know. The vendor knows - but they’re not telling. This is the Vendor Trap. And way more founders fall into it than would like to admit. What You Think You Bought When you hire a vendor, you think you’re buying:

Today, an AWS infrastructure management agent went down the wrong path. When I realized that, I was about to jump in and terminate the execution. Before I managed to smash the 'Esc' button, the Reviewer Agent caught it and course-corrected his AI colleague. The fix happened automatically. My team of agents self-corrected without my intervention. The root cause? My initial prompt wasn’t precise enough. I was in a hurry, and I assumed they’d read between the lines and fill in the details I neglected to describe.

Let me break it down for you. “Make sure it works.” - That’s what most teams hear when someone mentions testing. So they test the case where everything goes right. Then production happens. And suddenly the “edge cases” aren’t edge cases anymore - they’re Friday eventing. The Happy Path Trap Your tests pass. Green checkmarks everywhere. You ship with confidence. This is what you have neglected to test: The API that times out after 30 seconds The null value that shouldn’t exist but does The concurrent requests that race for the same resource The user clicks “submit” three times because the button didn’t respond The request from someone who shouldn’t have access but found a way Result: You tested the wrong thing, not the actual system.