[{"data":1,"prerenderedAt":118},["ShallowReactive",2],{"blog-page":3,"blog-posts":15},{"id":4,"title":5,"body":6,"description":7,"extension":8,"links":6,"meta":9,"navigation":10,"path":11,"seo":12,"stem":13,"__hash__":14},"pages\u002Fblog.yml","Notes on delivery",null,"Short, practical writing on ownership, architecture, and AI that holds up under daily use.","yml",{},true,"\u002Fblog",{"title":5,"description":7},"blog","h6iqHL9H8iF2vA0HWUgqRnAYTyrKFxLEX-WjQJxM0dw",[16,55,87],{"id":17,"title":18,"author":19,"body":22,"date":45,"description":46,"extension":47,"image":48,"meta":49,"minRead":50,"navigation":10,"path":51,"seo":52,"stem":53,"__hash__":54},"blog\u002Fblog\u002Fkeeping-ai-features-simple-enough-to-trust.md","Keeping AI features simple enough to trust",{"name":20,"role":21},"Radek Rezac","Founder, RIVER DATA",{"type":23,"value":24,"toc":41},"minimark",[25,29,32,35,38],[26,27,28],"p",{},"We kept the AI feature simple because the workflow was simple. The hard work was making it reliable enough for daily use.",[26,30,31],{},"That is the pattern we see across most practical AI work. The interesting engineering problem is rarely the model itself. It is the retrieval step that feeds it, the evaluation loop that catches when it drifts, and the human review point that exists for the cases where a person still needs to decide.",[26,33,34],{},"A team we worked with needed less noise and more ownership. Every service, including the AI parts, now has a purpose, an owner, and a clear path to change. That ownership rule does not stop at traditional code. An AI feature without a named owner tends to degrade quietly until someone notices the wrong answer in production.",[26,36,37],{},"This is also where security and operations meet AI solutions directly. Access controls, audit trails, and monitoring matter as much for an AI assistant as for any other system that touches real data. Treating it as a special case, exempt from the usual review, is how avoidable mistakes happen.",[26,39,40],{},"Practical AI earns its place by being dependable first. Everything else is secondary.",{"title":42,"searchDepth":43,"depth":43,"links":44},"",2,[],"2026-06-24","Why the hardest part of a practical AI feature is reliability, not the model.","md","\u002Fimages\u002Fstaff-augmentation.png",{},4,"\u002Fblog\u002Fkeeping-ai-features-simple-enough-to-trust",{"title":18,"description":46},"blog\u002Fkeeping-ai-features-simple-enough-to-trust","xjXpv5vFsMqjU7w7f4RYHNEaLbHFw24O_8Op9anFPpE",{"id":56,"title":57,"author":58,"body":59,"date":78,"description":79,"extension":47,"image":80,"meta":81,"minRead":82,"navigation":10,"path":83,"seo":84,"stem":85,"__hash__":86},"blog\u002Fblog\u002Fbuilt-for-the-next-twenty-years.md","Built for the next twenty years of business, not the next trend",{"name":20,"role":21},{"type":23,"value":60,"toc":76},[61,64,67,70,73],[26,62,63],{},"Built for the next twenty years of business, not the next trend. It is easy to agree with that line and still make decisions that work against it.",[26,65,66],{},"Every year brings a new framework, a new pattern, a new tool that claims to remove some category of pain. Some of it is genuinely useful. Most of it adds a dependency that someone will need to understand, maintain, and eventually replace, long after the person who chose it has moved on.",[26,68,69],{},"The way we evaluate a technology choice is to ask who will own it in three years, and whether that person will thank us or curse us. Reliable architecture is not glamorous. It is the codebase a new engineer can read on their second day, the integration that fails loudly instead of silently, the migration plan written down instead of remembered.",[26,71,72],{},"None of this means avoiding change. Legacy systems need modernization, and some technical debt has to be paid down before it compounds. The difference is choosing changes because they reduce risk and improve maintainability, not because a tool is new.",[26,74,75],{},"Software that teams can trust looks unremarkable from the outside. That is usually a sign it was built correctly.",{"title":42,"searchDepth":43,"depth":43,"links":77},[],"2026-06-02","A practical case for choosing maintainable architecture over whatever framework is loudest this quarter.","\u002Fimages\u002Fmvp-development.png",{},5,"\u002Fblog\u002Fbuilt-for-the-next-twenty-years",{"title":57,"description":79},"blog\u002Fbuilt-for-the-next-twenty-years","GYs0ZRoAN2c7xJXvKR-p9o2KEfM3s-u9005Q98wAjAc",{"id":88,"title":89,"author":90,"body":91,"date":110,"description":111,"extension":47,"image":112,"meta":113,"minRead":50,"navigation":10,"path":114,"seo":115,"stem":116,"__hash__":117},"blog\u002Fblog\u002Fclear-ownership-quieter-meetings.md","Clear ownership makes for quieter meetings",{"name":20,"role":21},{"type":23,"value":92,"toc":108},[93,96,99,102,105],[26,94,95],{},"Good software delivery starts with clear ownership. When every feature has a purpose, an owner, and a release path, the meeting gets quieter in the best way.",[26,97,98],{},"That quiet is not a symptom of low ambition. It is what happens when a team stops re-litigating who is responsible for what. A status meeting where the assignment is already settled needs less time and produces fewer surprises later.",[26,100,101],{},"In practice, we ask three questions before a feature moves into a sprint. What is it for. Who owns it end to end. How will it be supported once it ships. If any of those three cannot be answered plainly, the feature is not ready yet, no matter how appealing the idea is.",[26,103,104],{},"This applies just as much to modernization work as to new product features. A legacy system rarely has a single owner. Part of an assessment is figuring out where ownership has quietly disappeared, and putting it back before the technical work starts.",[26,106,107],{},"The payoff shows up later, when a release goes out and nobody has to guess who to call. That is delivery discipline in a sentence: not more process, just less ambiguity about who is accountable for what.",{"title":42,"searchDepth":43,"depth":43,"links":109},[],"2026-05-12","Why naming an owner and a release path for every feature changes how a delivery meeting actually feels.","\u002Fimages\u002Fdedicated-team.png",{},"\u002Fblog\u002Fclear-ownership-quieter-meetings",{"title":89,"description":111},"blog\u002Fclear-ownership-quieter-meetings","HfA8AQPnFOMZVZeZYKTadzk6nelLHozHhagVEKAU54k",1785537448983]