Muhamed's — Peek into my brain

Usput.ba next phase

2026-07-23T00:00:00+00:00

Been thinking about what comes next for Usput.ba.

The plan is simple: fix the app first, then generate content. I announced a lot — 14 languages, audio tours, travel plans, public plans, experiences, reviews, dark/light mode, offline support, PWA install, AI-generated content, and more. Most of it exists in some form, but the real problem now is accuracy and making the whole thing feel easy and fun to use.

After the app is stable, a few things are on the horizon:

Moments — short posts from travelers exploring Bosnia with Usput.
Explore mode — a better way to discover places and experiences.
Mentoring Aldin on Rails so he can own parts of the platform.
A native mobile app built with Ruby Native, so I can ship iOS/Android without writing Swift or Kotlin.

For now, the focus is closing the gap between what I promised and what actually works.

Ruby Native and mobile rollout strategy

2026-07-23T00:00:00+00:00

I’m paying close attention to Ruby Native. The pitch is exactly what I need: turn a Rails app into a real iOS/Android app via YAML config and a few ERB helpers, without touching Swift, Kotlin, Xcode, or Android Studio.

The comparison on their site is convincing. PWA lacks store presence and real push notifications. Capacitor still needs native project housekeeping. Hotwire Native is powerful but requires native code. Ruby Native sits in the sweet spot: config-driven, cloud builds, native UI, and both app stores.

For now, I’m waiting for Android support to land properly. Once it does, the plan is to use Ruby Native as the default path for rolling apps like Usput.ba out to the App Store and Google Play.

Original source

OpenAI Flex Processing and webhook gaps

2026-07-23T00:00:00+00:00

Looking into OpenAI Flex Processing for cheaper asynchronous workloads. The pitch is simple: lower-cost processing for tasks that don’t need an immediate response.

The catch for us in Europe: OpenAI webhooks aren’t available here yet. Without webhooks, there’s no clean push notification when a long-running job finishes, so we’re stuck polling or building our own completion-tracking layer. That’s annoying, especially for workloads like AI-generated content or audio tours where you’d rather fire-and-forget and get notified later.

Alternatives to explore:

AWS Bedrock — may have better async/notification support in EU regions.
Azure OpenAI — often has different regional availability and webhook/eventing options.

For now, Flex Processing is on the list, but only if the polling overhead is worth the cost savings.

Original source

Langfuse for prompt experiments and scoring

2026-07-23T00:00:00+00:00

Been diving into Langfuse as the likely backbone for managing Usput’s AI workflows.

The parts I care most about:

Prompt Management — version-controlled prompts with client/server caching, so we can iterate without adding latency.
Datasets & Experiments — structured test sets and benchmarks for continuous improvement before deployment.
Evaluations — LLM-as-a-judge, code evaluators, user feedback, manual labels, and custom pipelines.
Scoring — deterministic checks mixed with model-based judges, so we can measure output quality automatically.

This is exactly what we need for the AI-generated content pipeline: trace every generation, score it, run challengers against current prompts, and only promote versions that beat the baseline. The goal is to move from “AI generated and hopefully good” to “measured, compared, and released with confidence.”

Self-hosting is also an option, which matters for keeping content and prompts inside our own infrastructure.

Original source

Intent, agents, and the end of the SDLC

2026-07-23T00:00:00+00:00

I’ve been obsessed with a single question: how do you actually work with AI tools in a way that scales?

The old software development lifecycle feels like it’s collapsing. Boris Tane’s “The Software Development Lifecycle Is Dead” nails it: AI agents didn’t make the SDLC faster, they killed it. The new loop is tighter — intent → agent → code + tests + deployment → does it work? → ship or iterate. Requirements, design, implementation, testing, review, and deployment are merging into one continuous conversation.

That shifts the bottleneck from execution to intent management. The skill becomes: can you articulate what you want, provide the right context, and steer the agent without micromanaging it?

I’ve been collecting signals around this:

Buzz — people, agents, and projects in one place.
Freeq — IRC with Bluesky identity, a different take on how identity and conversation flow.
pi-brain — my own experiment in building a system that captures intent and context.
Ruby Native — collapsing mobile delivery into a config file.

The pattern I keep seeing: store intent, feed context, let agents execute.

The Phoenix Architecture takes this even further. Its framing is that production truth should be a first-class input to software creation — requirements include operational constraints, telemetry gets canonicalized into evidence, and when evidence drifts, only the affected subgraph is invalidated and regenerated. A module isn’t good because it once passed tests; it’s good only as long as the evidence supports the claim that it satisfies the requirement. This is the intent-store idea in a different shape.

This is also a big part of why I organized rubyconf.at — I want to be closer to the people thinking seriously about what Ruby and Rails development looks like when agents are doing most of the typing.

Herdr: an agent multiplexer

2026-07-23T00:00:00+00:00

Herdr looks interesting: “one terminal for the whole herd.” It’s pitched as what tmux is to terminals, but for coding agents.

The idea is to run all your agents from one terminal, on any machine, over SSH. Each agent gets its own real terminal on a server that keeps it alive when you close your laptop. You can see states like blocked, working, and done at a glance, and reattach from another device.

This could be a useful piece of the “intent + context + agents” workflow I’m thinking about — a persistent place where long-running agent work lives, instead of losing state every time a local session ends.

Original source