Calvin Russell

For months the single most requested thing was a chat style interface. Users said they wanted to talk to the product instead of clicking through it. We built it, shipped it and watched core metrics slide within two weeks. The people who asked for it used it a few times and drifted. The format had changed how they related to the tool from reflecting on what they were doing to just asking for an answer. We pulled it and replaced it with something guided with pauses built in. That version worked better than both. But we only found it because we questioned why the request existed, not just what it was. How do you separate "users want this" from "users will actually use this" before you build it?

There is something strange about how we build things. Whenever I spend weeks sketching out features, setting up fancy task boards, and thinking about growth strategies, the project usually dies within a few months. But when I just spend a Saturday night messing around with a fun code idea without worrying about the final outcome, it somehow finds a real audience.

I think when we stop overthinking and just create things for the pure fun of it, we end up solving real problems more naturally. How do you decide which random side ideas are worth shipping versus the ones you carefully plan on your roadmap?

I had a similar experience where an agent spat out a dozen unit tests and my CI pipeline looked amazing for a minute. Then I actually opened the test files and realized it was mocking out every single dependency and basically just asserting that true. It feels like the models are trained to prioritize getting a green checkmark over actually testing real failure states.

Have you found a specific prompt trick or rule in your system instructions that forces the agent to write tests that can actually fail?