Back when I was a junior frontend dev, I once hit a wall because the .NET dev I depended on went on vacation. No endpoints, no documentation, nothing. I could have spent the week "blocked," but instead, I built mocks—convincing imitations of the data I needed. I didn't learn .NET (I had standards), but I simulated the environment so I could keep coding. When the dev returned, I had a full UI ready to be plugged in. I was praised as a hero, not because I solved the backend problem, but because I refused to let a dependency stop my momentum.
Now that I'm rolling out AI tools at my current company, I see the same pattern. Some of my teammates complain that they can't use a specific AI workflow because "the company hasn't provided the right prompt library" or "the internal API isn't ready for the agent."
They're thinking like they're blocked. I'm thinking about mocks.
If you're waiting for a perfect environment to start your AI deployment, you're wasting time. With tools like Claude Code or custom prompt engineering, you can simulate almost any missing piece of the puzzle. If the internal data isn't flowing yet, create a synthetic dataset. If the official prompt isn't written, iterate on a "fake" one until it's 80% there. The reality of a real-world AI workflow is that the "perfect" setup never arrives. The people who actually get things done are the ones who build the bridge while they're walking on it.
If you're stuck, try this simple shift in your process:
-
Identify the blocker: Is it a person, a piece of code, or a missing tool?
-
Create a mock: Use an LLM to generate a plausible imitation of the missing output.
-
Build the logic: Code your frontend or workflow against that mock.
-
Swap and refine: When the real asset arrives, replace the fake with the real thing.
It's not about being a hero; it's about not standing around with your hands in your pockets.
Next Manual Testing: Skill vs. Job Title →