Every week we get the same request: "Can I just talk to the AI?"
They want a chat interface. A back-and-forth. Something that feels like texting a therapist at 2am. And honestly, it would be the easiest feature we could build. The AI is already there. The conversation engine exists. We could ship it in a week.
Throughput per developer is up 33.7%. Median time in code review is up 441.5%. If you're a solo maker, you are the review queue and you quietly stopped showing up for the shift.
There's a report that came out this spring that I keep coming back to, and I don't think it landed properly with makers because it's written for engineering leaders at big companies. Faros AI published "The Acceleration Whiplash" in April two years of telemetry from 22,000 developers across more than 4,000 teams. Not a survey about how developers feel. Actual measurement of what came out the other end.
When we launched Murror's delete feature, we thought of it as housekeeping. Users write messy drafts, clean up later. Standard stuff.
Then we looked at the data. About 15% of entries were being deleted within minutes of writing them. Not drafts. Not typos. Full, completed entries that users wrote, read back, and chose to erase.
Frontier models now cluster above 90% on the public benchmarks, and Gartner says over 40% of agentic projects get killed by 2027. Those two facts are closer to the same fact than they look here's the eval that actually predicts whether your thing ships.
There's a number that decided which model your product runs on. You saw it on a leaderboard or in a launch post 94% on this, state-of-the-art on that and it did its job: it made you feel safe picking. I've done exactly this. That number is close to useless for the thing you actually care about, and this year it got worse, not better.
There's a pattern I keep noticing across the AI products that actually stick with people vs. the ones that get tried once and forgotten.
The forgettable ones try to be impressive. They show off what the model can do -- generate faster, automate more, produce output at scale. And they're genuinely cool for about 15 minutes.
Building got cheap this year. Judging whether the thing is actually good did not. In 2026 the eval is your spec, and it's the step nearly everyone leaves out.
There's a moment now that didn't exist three years ago. You describe a feature, an agent writes it, and forty minutes later it's running. It works, sort of. It answers, it responds, it does the thing. And you sit there with a genuinely hard question you have no tool for: is it any good?
That question used to answer itself. Old software was deterministic same input, same output, and you wrote a test that either passed or failed. AI features don't work like that. Ask the same thing twice and you get two different answers, both plausible, one subtly wrong. "It ran without erroring" tells you almost nothing about whether it's right, helpful, or safe. The build got easy. The judging got hard. And the gap between those two is where most maker products quietly fall apart around week three.
The discipline that closes the gap has a name this year: eval-driven development. The idea is boring and it's correct. Before you tune a prompt or swap a model, you write down what "good" means as a set of concrete examples, and you check every change against them. Not vibes. Not "seems better to me." A fixed set of cases with expected behavior that you can rerun. The whole shift in how serious teams build with AI in 2026 is the move away from vibes-based iteration toward something you can actually rerun and compare. Eval platforms are multiplying for a reason the demand is real.
When your AI does the work, you can't charge per seat anymore but the fashionable fix, charging per outcome, only works if your outcome is something you can count. Here's how I think about pricing when the thing you sell is subjective.
There's a pricing question sitting under every AI product right now, and most makers are answering it by copying whoever's biggest in their category. That's how you end up mispriced.
There s one thing we re really good at as builders: we constantly try to improve our work and our product every single day. But an honest question I often ask myself is: do we put the same effort into updating ourselves?
At Murror, we re a small team of around five people. For me, it s important not only to improve the product, but to continuously update my mindset, skills, and learnings and share them openly with the team.
I try to communicate everything I learn, ask questions, and clarify problems as much as possible, so the product we re building becomes better, clearer, and more convincing for our users.
To do that, I try to practice a few things consistently:
Models shipped million-token windows this year. Then the research showed they quietly get worse the more you feed them and that flips how you build.
There's a move almost every maker makes the first time they build something on top of an AI model, and I made it too. The window is huge now, so you fill it. All the docs. The whole conversation history. Every tool you might conceivably need. The reasoning goes: the model is smart, more information can only help it, so give it everything and let it sort things out.
