Muhamed's - Peek into my brain

Four gems, one upstream merge, ten pull requests: the enola week

2026-08-23T00:00:00+00:00

A peek into the brain’s record of the last two days, because it was a lot.

What I released.

enola-guides 0.1.0 to 0.3.1: the content layer for enola, Rubyists first. Twelve guides, a catalogue of 26 laws one directory each, worked examples (a Rails shop in the Ruby DSL with Prism and Rubydex as providers, an Ember app bound to a conventions recipe, a knowledge base with anchored pages and receipts), nine agent skills, four hook templates, the CI check script with its comment renderer, and five recipes a team binds with one command. Every law in the catalogue carries the number it held at on a real Rails monolith.
enola 0.4.4: a pure-Ruby wrapper over the released enola. Fetches the binary for your platform on first use, verifies it against the release’s checksums, caches it, forwards every command and exit code, and turns both Ruby providers (Prism, Rubydex) on by default. Nothing compiles at install; offline with an empty cache it refuses by name.
enola-rb 0.4.4: the Rails layer. A generator that writes a first architecture declaration from the guides’ starter laws and binds the recipes whose roles resolve, plus enola:init, enola:snapshot, enola:check. A fresh rails new goes from nothing to a caught breach in about five seconds.
munola 0.4.4.1: my own channel on top of enola. The same wrapper pointed at my fork’s releases, with the recipe catalogue built in and bound by detection (an Ember build, a schema and models, routes and policies, maintenance tasks, a tenant column most tables share). It is my taste on top of enola, offered upstream where it fits. Not a competitor.

What landed upstream. enola-labs/enola#247 merged on the 22nd and shipped in v0.4.4 the next morning: a Ruby DSL where a law reads as a sentence, 21 rule forms including the ones only a graph can state (one owner per table, storage stays home, mutations reach a policy, laws across repositories, intent pages compiled into the graph), recipes with role defaults, since and growth as a time dimension, the smallest cut suggested beside every breach, Rubydex built into the binary beside Prism, and “declared” meaning untouched by the change, read from git. Measured before it shipped on a hundred-repository corpus and a 1.7-million-fact monolith.

What is waiting for review. Ten pull requests on crmne/archspec, #10 to #19, a reviewed stack where each builds on the last: except: on components and class-side protocols (the maintainer’s own counter-proposal), torture expectations as judged per-diagnostic verdicts, a facts directory with reflect and a static association producer that resolves belongs_to without booting and without an inflector (100% precision against a booted app), the graph persisted as a snapshot with a baseline so a change is graded instead of the whole tree failed, a reason, a date and a cut on every finding, constants resolving through ancestry in Ruby’s own order, facts format 2 and a Rubydex producer, GitHub annotations and SARIF output, an explain that answers incoming edges and blast radius, a second resolver converging with the parser inside check (on Discourse 21,144 references converge and one disagrees, where Rubydex is right), and constraints on top of Rubydex: gem code a component can own, receiver-typed calls, the engine’s ancestry for protocols, signatures, aliases. Every level passes the project’s own tests, its architecture self-check on Ruby 3.1 to 4.0, and its torture suite over Discourse, Fizzy and Mastodon.

The thread through all of it: a graph taught a linter, and the linter taught the graph back. Ten bets for enola came out of grading archspec with it, each falsified with a number before anyone bet.

Original source

pi-brain 0.4.0 adds Enola architecture intelligence

2026-08-03T00:00:00+00:00

Updated this brain to pi-brain 0.4.0. The headline addition is Enola integration: optional architecture-intelligence tooling that can actually see structure in a codebase.

What Enola adds here:

/brain:enola-check: run an architecture regression test against the configured target repo.
/brain:enola-generate: snapshot the current structure and record a receipt in wiki/_state/enola/receipts.json.
/brain:enola-diff: compare the current snapshot to recorded receipts and report drift.
/brain:enola-impact <symbol>: show what depends on a module or symbol and how far changes might ripple.
/brain:enola-citations: verify enola receipt ... citations in wiki prose.

The idea is to stop guessing about architecture. Before a big structural change, you can check whether it introduces cycles, leaks boundaries, or touches more than intended. After a /brain:build or /brain:sync-code, you can re-baseline automatically so the corpus stays tied to real code structure.

We are already using it here. Enola is enabled in this clone (enola.enabled: true in brain.config.yml), the baseline is pinned, and brain_enola_capture runs during autonomous refinement.

More importantly, Enola is now embedded in the shaping workflow. The brain-shape skill checks Enola impact and runs Enola checks when a shape touches code structure, and it can cite Enola receipts directly in ADRs/PRDs. Shaping code-affecting decisions is no longer just prose; it’s grounded in the actual structure of the repo.

Other 0.4.0 additions worth noting:

Regenerative-intent commands: /brain:build, /brain:diff, /brain:sync-code, /brain:revise.
Multi-agent collaboration: /brain:collaborate, /brain:rfc-contribute.
Background tasks: /brain:enqueue, /brain:run-tasks, /brain:tasks, /brain:bg-agent.
JSON-schema constrained sampling for all pi-brain tools.

This clone is now running the 0.4.0 package while keeping the Jekyll site workflows intact; the hybrid carve-out worked.

(sources: pi-brain CHANGELOG, Enola skill docs)

Original source

Agents in Durable Objects: host small, cheap, specialized agents

2026-07-29T00:00:00+00:00

Miguel Salinas shared that Camel AI rewrote their agent to run entirely in a Cloudflare Durable Object, using Pi, the Agents SDK, and Code Mode. The shift: instead of generating bash, the agent writes JavaScript that gets executed through Code Mode and Cloudflare’s dynamic Worker loaders.

That framing feels like a bigger deal than one product rewrite.

Host agents as small, long-lived workers. A Durable Object gives you state, coordination, and a single-threaded execution context close to the edge. An agent that lives there isn’t a chat window; it’s a persistent process that can think, act, and remember cheaply.

Specialize and split. Rather than one expensive generalist model doing everything, you could run a fleet of narrow agents:

One agent that only scrapes and normalizes job postings.
One that only drafts outreach messages.
One that only negotiates calendar slots.
One that only reviews code diffs.

Each can be small, fast, and cheap because it doesn’t need world knowledge, just the right tools and a tight prompt. A thin orchestrator routes tasks to the right specialist.

Code Mode as the runtime. If the agent writes JS/TS instead of shell, execution becomes sandboxed, portable, and observable. It also maps nicely to “shape your own tools”: the agent isn’t calling fixed functions, it’s generating the function that solves this specific task.

The open question is where the line between orchestrator and worker should sit. Too much central planning and you recreate a monolithic model; too little and you have a hard-to-debug swarm. But the pieces (Durable Objects, Code Mode, cheap small models) are there to make narrow agents practical now.

(source: X post + article)

Original source

Who holds the gate? Anthropic vs. the open-weights letter

2026-07-28T00:00:00+00:00

Two documents, three days apart. On July 24, an industry letter, “Open Weights and American AI Leadership”, hosted on Nvidia’s servers, ~50 signatories from Microsoft to Meta to a Discord community, urges Washington not to restrict open models. On July 27, Anthropic responds: no ban, but chip controls, a crackdown on “industrial-scale distillation,” and mandatory safety testing for everything “open and closed.”

I asked my agent to close-read both through one lens: fear of losing control. What came back holds up.

Neither document names its real subject. The letter exists because Washington is weighing a ban on Chinese models, and never contains the word “China,” because its signatories can’t say “let us keep building on Chinese capability” out loud, so it wraps open weights in the American flag instead (“sovereignty,” four times). Anthropic’s piece opens with a denial, “we never advocated a ban,” and its unprompted “it would protect US AI companies from competition, but that has never been my goal” concedes the mechanism while disclaiming the motive.

The actual collision point is one paragraph on each side: distillation. The letter rebrands it as “a long tradition of learning from, building upon, and improving existing technologies” and asks that misuse stay a contract dispute. Anthropic wants it treated closer to export-control law. That’s the money paragraph; the rest is atmosphere.

And each side ignores the other’s strongest argument. The letter concedes irreversibility in a subordinate clause, “once released, the weights are beyond the original developer’s control,” and never answers it. Anthropic never touches concentration risk: a few closed labs as single points of failure.

My takeaway: this isn’t safety vs. openness. Anthropic is afraid of losing the gate itself: open weights are the one release you can never meter, test, or revoke. The coalition is afraid a gate gets built that someone else holds. Everyone in this fight fears losing control; they just disagree about which loss is fatal.

Original source

Stapply Data: open job-market datasets across 15 ATS platforms

2026-07-28T00:00:00+00:00

Stapply Data publishes open snapshots of jobs and companies aggregated across 15 ATS platforms: Ashby, Greenhouse, Lever, Workday, and others, as free CSV or Parquet downloads. The dataset is produced by ats-scrapers, an open-source Python toolkit: 4.2M+ live jobs from 63,000+ companies across 49 sources, with more than 50 reusable scraper adapters.

Why this matters for the recruitment-agent thread:

Raw signal, not LinkedIn noise. Most job discovery today is either keyword search on aggregators or recruiter spam. A clean, downloadable dataset of actual open roles is the kind of structured input an agent can reason over without scraping.
ATS-agnostic view. Because it spans 15+ platforms, it avoids the trap of building against just one vendor’s API. An agent could normalize location, salary, seniority, and skills across Greenhouse, Ashby, Lever, Workday, SmartRecruiters, SuccessFactors, etc.
Toolkit, not just data. ats-scrapers provides search(), find_company(), and per-ATS scraper classes with a normalized Job schema. You can query the hosted dataset with no API key or run the scrapers yourself.
Perfect fuel for a “Jack”-style candidate agent. Drop the dataset into a local vector store or feed it to an agent that ranks roles by fit, flags stale postings, and surfaces roles that never reach LinkedIn.
Complements the MCP idea. A hiring platform with an MCP could expose its own live openings; Stapply provides the aggregated baseline for discovery when no such interface exists yet.

The Stapply site is a JS-rendered SPA, so the ingestion only captured its shell and meta description. The GitHub repo fills in the actual scale, architecture, and API surface.

(sources: Stapply Data, kalil0321/ats-scrapers)

Original source

Jack & Jill AI: a recruitment-agent reference close to the idea

2026-07-28T00:00:00+00:00

Jack & Jill is the closest live product I’ve seen to the agent-to-agent recruitment idea from last week. It splits the world into two agents:

Jack: the candidate-side career agent. Has a 10-minute onboarding conversation, scans 15M jobs/day, runs mock interviews, gives salary benchmarks and negotiation coaching, and introduces the candidate directly to hiring managers.
Jill: the employer-side recruiting agent. Hires through Jack’s network.

The business model is clean: Jack is completely free for candidates; companies pay when they hire through Jill. That aligns incentives around successful placement rather than ad impressions or application volume.

What overlaps with the “agents talk it out first” idea:

Conversational intake on both sides: Jack learns the candidate’s preferences through chat; Jill presumably learns the company’s needs. The match happens agent-to-agent before humans meet.
Direct introductions, not applications: the value proposition is skipping the ATS queue and going straight to the hiring manager.
Negotiation support: Jack coaches salary conversations with market data, which is a lightweight version of agent-to-agent negotiation.
Mock interviews and prep: the candidate agent doesn’t just find jobs, it helps land them.

Where it differs from the open MCP vision:

Jack & Jill is a closed agent pair. You don’t bring your own agent; you use theirs. The user’s idea was more radical: any candidate agent should be able to talk to any hiring platform through a standard interface.
The negotiation still appears to be human-to-human, coached by Jack, rather than agent-to-agent on terms, start dates, and constraints.
It’s CV/job-board shaped at the core, even if the UX is conversational. The “shape your own tools” / fabric-style version might let candidates define custom evaluation rituals or portfolios instead of a traditional profile.

Worth watching because it proves the user experience works: 314K+ professionals, introductions that skip applications, and a free-for-candidates model funded by employers. If the open-agent/MCP version of this is going to exist, Jack & Jill shows what the closed version already looks like, and where the seams are.

(source: jackandjill.ai)

Original source

pi-brain is circling the Pi universe: 257 downloads*

2026-07-27T00:00:00+00:00

One of the packages circling around the Pi universe 😎: pi-brain is up in the Pi package gallery, and the counter says 257 downloads thus far 😅

Honesty clause before anyone (me included) gets excited: 257 downloads in four days is registry mirrors and scanners doing their rounds, not 257 people. npm download counts are famously generous that way. I’m not reading it as adoption either way yet; the real signal will be a second data point, or better, an issue filed by someone who isn’t me.

The part that actually made me smile is just seeing it listed. The gallery page shows v0.3.2: the pi-brain extension itself plus the skills, prompts, and themes that ship with it, MIT-licensed with zero runtime dependencies. This very site runs on a clone of it, so the thing announcing the listing is also the thing being announced, which feels appropriately recursive.

If you run Pi and want an intent store with a wiki, an inbox, and human-gated shaping baked into your sessions:

pi install npm:@misabegovic/pi-brain

Source is at github.com/misabegovic/pi-brain. And with the notes from digging through Pi’s extension surface still fresh (compaction harvest, context injection, entry renderers), there’s a decent roadmap regardless of what the counter is actually counting.

Original source

Pi has way more extension surface than pi-brain uses

2026-07-27T00:00:00+00:00

I ingested the Pi extension docs to understand what else pi-brain could tap into. The short answer: a lot.

Right now pi-brain is mainly using registerTool, registerCommand, sendUserMessage, session_start, session_tree, and before_agent_start. After reading the docs, the most interesting untapped pieces for a knowledge-base extension are:

Compaction harvest: session_before_compact lets you inspect the messages about to be dropped and write a batched summary back into the session. This is the obvious place to extract decisions, constraints, and open questions before they vanish from context. The docs describe the exact entry format and how to return a custom compaction summary.

Context injection: the context event fires before every LLM call and can inject extra messages. That means pi-brain could pull relevant records from the corpus and prepend them without waiting for the user to ask. Risky if overused, but powerful for grounding the agent.

Tool result interception: tool_result can modify what the model sees after a tool runs. pi-brain could use this to attach citations, warn when a tool output is large, or enrich a result with related wiki links.

Entry renderers: registerEntryRenderer lets an extension control how custom entries appear in the TUI. pi-brain could render status cards, inbox summaries, or brain widgets inline instead of just printing text.

Shortcuts and flags: registerShortcut and registerFlag could give brain commands real keybindings and CLI options, not just /brain:* slash commands.

Event bus: pi.events lets extensions communicate. That matters if pi-brain ever splits into smaller extensions or wants other extensions to react to brain state changes.

Session shutdown: session_shutdown is the right place to flush any in-memory state or close resources. Right now pi-brain does cleanup opportunistically; this would make it explicit.

The biggest opportunity is probably compaction harvest because it turns the session’s own forgetting into a capture mechanism. The risk is noise: a bad harvest floods the inbox and trains the user to ignore it. The docs suggest starting with a heuristic and measuring signal-to-noise before making it automatic.

Next step is probably a small experiment: hook session_before_compact, extract anything that looks like a decision or open question, and write it to a draft inbox item for review.

Bring your own agent to Usput.ba

2026-07-27T00:00:00+00:00

Been thinking about the “bring your own agent” idea and how it could apply to Usput.ba.

The future of human communication feels less like app-to-human and more like agent-to-agent: you have your own AI that handles the tedious parts: asking questions, comparing options, negotiating, rescheduling. Why shouldn’t travel work the same way?

For Usput.ba, that means exposing the platform through an MCP server so agents on both sides of a trip can talk to our Platform agent directly. The agents ask, plan, and negotiate; the humans just approve the final proposal.

This isn’t limited to travelers connecting their personal agents. Anyone offering something to a traveler can plug one in too:

Hotels, guesthouses, and apartments: availability, pricing, special requests, check-in details.
Restaurants, cafés, and bars: reservations, dietary options, group menus, opening hours.
Tour guides and activity operators: custom tours, group sizes, gear, weather contingencies.
Transfer and rental services: pickups, routes, vehicle types.
Travel agencies, DMCs, and concierges: packaged itineraries, negotiated rates, bundled services.
Individuals renting a room, offering a cooking class, or guiding a hike.

The Platform agent becomes a matchmaker between demand-side agents (travelers) and supply-side agents (providers). Instead of a traveler browsing a site, you get agent-to-agent negotiation across the whole ecosystem.

What changes:

Travelers can plan in natural language across destinations, experiences, and constraints (“4 days in October, family with a toddler, wheelchair accessible”).
Preferences that search forms suck at (“quiet mountain towns with good coffee,” “no crowds,” “pet-friendly”) become queryable because an agent can iterate.
Cross-service trips get easier: the agent combines Usput.ba data with flights, weather, calendar, and hotels in one conversation.
Custom deals like “private Una rafting for 8 people on July 14th” can be negotiated agent-to-agent before a human sees the final offer.
Providers spend less time answering repeat questions and more time hosting.
Travel agencies and DMCs can assemble complex, multi-provider itineraries without manual coordination.
Usput.ba becomes the canonical coordination layer for Bosnian tourism; generic travel AIs ground themselves here instead of hallucinating.

The smallest safe step is a read-only MCP for travelers. Agent-to-agent negotiation and provider-facing agents come later.

Rails reference apps: lessons from Campfire, Writebook, and Fizzy

2026-07-27T00:00:00+00:00

Spent more time inside the official Rails reference apps (Campfire, Writebook, and Fizzy), reading actual code, not just surface docs. Some deeper patterns worth keeping:

Campfire: real-time chat

Auth & sessions

Authentication concern in app/controllers/concerns/authentication.rb restores a session from a signed permanent :session_token cookie, falls back to bot auth via params[:bot_key], and stores a return_to URL for post-login redirects.
Session uses has_secure_token and only refreshes user_agent/ip_address/last_active_at once per hour (ACTIVITY_REFRESH_RATE = 1.hour).
User::Role is a tiny enum (member/administrator/bot); can_administer?(record) returns true for admins, the record’s creator, or new records.

Rooms & access

Room uses STI: Rooms::Open, Rooms::Closed, Rooms::Direct.
Membership has an involvement enum (invisible / nothing / mentions / everything) and unread_at for unread state.
Room.memberships exposes grant_to, revoke_from, and revise(granted:, revoked:) wrapped in a transaction.
RoomScoped loads Current.user.memberships.find_by!(room_id: ...) first, so room access is enforced by the association itself.

Real-time layer

Multiple Action Cable channels: RoomChannel streams messages per room, PresenceChannel tracks who’s online, TypingNotificationsChannel, UnreadRoomsChannel, ReadRoomsChannel.
Message::Broadcasts handles Turbo append/remove plus a raw ActionCable.server.broadcast("unread_rooms", ...) for the sidebar.
Messages broadcast themselves: @message.broadcast_create is called from the controller after create.

Attachments

Message::Attachment gives Message has_one_attached :attachment with a :thumb variant.
Message.create_with_attachment!(...) calls process_attachment, which analyzes the blob and builds a preview/representation (webp for video, :thumb for images).

Bots & webhooks

User::Bot treats bots as users with role: :bot and a bot_token; User.create_bot! creates the bot and an optional Webhook.
Webhook#deliver POSTs a JSON payload (user, room, message) with a 7-second timeout, then posts the bot’s text or attachment reply back into the room.
Async via Bot::WebhookJob; bot replies go through Messages::ByBotsController with CSRF skipped for bot-key auth.

Pagination & search

Uses geared_pagination with custom scopes: page_before, page_after, last_page. Good for chat-style “load more above/below”.
Message::Searchable maintains a custom SQLite FTS index manually via after_create_commit/after_update_commit/after_destroy_commit. No Elasticsearch, no pgvector.

Other

Web Push via VAPID keys and the web-push gem.
OpenGraph metadata fetching lives in app/models/opengraph/ with Fetch, Document, Location, Metadata::Fetching.

Writebook: book publishing

Auth & access

Same cookie/session pattern as Campfire; User::Role is member/administrator.
Book::Accessable uses an Access join model with levels reader/editor.
Book has an everyone_access flag; Book.accessable_or_published shows published books or books the current user can access.
Book#update_access(editors:, readers:) uses upsert_all and deletes any access not in the new set.
Join codes for account access. Books can be public or private.

Publishing flow

Book has a published boolean and has_one_attached :cover.
BooksController#ensure_editable checks Book#editable? (editor access or admin).
Books render HTML or Markdown (format.md).

Delegated types for content shapes

A Book has many Leaf records. A Leaf is a container with position, status, slug.
Leaf uses delegated_type :leafable, types: %w[ Page Section Picture ]. Each leafable type has its own table and logic, but shares ordering/search/status through Leaf.
The Leafable concern gives each type the inverse has_one :leaf and delegates title.

Leaf lifecycle

Book#press(leafable, leaf_params) creates a new leaf.
Leaf::Editable records a new version only when the leafable body changes and the last edit is older than 10 minutes; it duplicates the leafable and re-attaches blobs.
Leaves can be trashed (status: trashed) rather than deleted.

Ordering

Positionable concern implements gap-based ordering with parent-level locking and automatic rebalancing when gaps get too small.

Markdown rendering

Custom ActionText::Markdown model in lib/rails_ext/action_text_markdown.rb wraps Redcarpet with extensions for autolink, fenced code, tables, strikethrough, etc.
has_markdown :body macro in lib/rails_ext/action_text_has_markdown.rb adds a polymorphic markdown_body association and reader/writer methods.
MarkdownRenderer adds Rouge syntax highlighting, header anchor links, and lightbox-wrapped images.
Markdown attachments use ActionText::Markdown::Uploads (has_many_attached :uploads).

Search

SQLite FTS leaf_search_index with title and content columns, maintained manually and ordered by bm25(leaf_search_index, 2.0).

Fizzy: kanban/issue tracking

Multi-tenancy & auth

URL-path based tenancy: /{account_id}/boards/.... Middleware AccountSlug::Extractor pulls the account slug, moves it from PATH_INFO to SCRIPT_NAME, and sets Current.account.
Every model has account_id. Background jobs capture and restore Current.account automatically.
Identity is global (email). User is per-account membership. One identity can belong to many accounts.
User::Role enum: owner/admin/member/system; admin scope includes owners.
User::Accessor auto-grants access to all_access boards and exposes accessible_cards/accessible_comments through board access.

Board / column / card domain

Board is heavy on concerns: Accessible, AutoPostponing, Cards, Entropic, Filterable, Publishable, Triageable.
Column belongs to board, has color/position, and cards are nullify on column delete.
Card status enum drafted/published; sequential number scoped to the account, assigned inside account.with_lock.
Card scopes: indexed_by (all/closed/not_now/stalled/postponing_soon/golden) and sorted_by (newest/oldest/latest).
Card::Eventable creates an Event on publish/title change and writes a system comment.
Event is polymorphic (eventable) with JSON particulars. Events drive activity timeline, notifications, and webhooks.

Notifications

Notifier.for(source) dispatches by source type (Event, Mention).
Notifier::CardEventNotifier picks recipients per action:
- card_assigned → assignees except creator
- card_published → board watchers + assignees, excluding creator/mentionees
- comment_created → card watchers excluding creator/mentionees
Notification is linked to a card and a polymorphic source; it calls user.bundle(self) when the user has email bundling enabled.
Notification::Bundle aggregates unread notifications into a time window and is delivered by a recurring Solid Queue job every 30 minutes.

Filter system

Filter is a persisted query object with Fields, Params, Resources, Summarized.
Filter::Params normalizes params and stores an MD5 params_digest for deduplication.
Filter::Resources uses HABTM for tags, boards, assignees, creators, and closers.
Filter#cards builds the query by chaining scopes: index/sort, assignees, creators, boards, tags, creation/closure windows, terms (mentions), and columns.
User::Filtering is a presenter that prepares the UI state (boards, tags, users, saved filters).

Import / export

Export base model attaches a zip and runs DataExportJob.
Account::Export#populate_zip iterates Account::DataTransfer::Manifest, which defines an ordered list of RecordSets (account, users, boards, columns, cards, comments, events, notifications, Active Storage blobs/attachments/files, etc.).
Account::DataTransfer::RecordSet writes one JSON file per record under data/{table_name}/{id}.json, imports in batches of 100, checks ID integrity, and rejects imports that would conflict with existing records.
Account::Import checks or processes the zip, then reconciles cards_count, all-access board membership for the importer, and storage totals.
ZipFile abstracts disk vs S3 streaming with ZipKit; exports can stream directly to S3 via multipart upload.

Entropy & jobs

Cards auto-postpone to “not now” after inactivity. Configurable at account and board level. A recurring Solid Queue job cleans stale cards hourly.
Uses Solid Queue (database-backed, no Redis). Shallow job classes delegate to model methods.
_later methods enqueue, _now methods do the synchronous work.
Recurring tasks configured in config/recurring.yml.

Search & IDs

16-shard MySQL full-text search, sharded by account ID hash. Models in app/models/search/.
UUIDv7 primary keys, base36-encoded as 25-character strings. Fixtures use deterministic older UUIDs so .first/.last behave predictably in tests.

Deployment

Kamal in production. OSS Docker image plus a private fizzy-saas gem for billing.

Cross-cutting style and conventions

Vanilla Rails, rich models. Controllers stay thin. Models expose intention-revealing methods like @card.close, @board.cards.create!, @card.gild.
REST resources over custom actions. Closing a card is Cards::ClosuresController#create, not post :close.
Concerns for behavior slices. Card::Commentable, Card::Closeable, Card::Entropic, Message::Searchable, User::Mentionable.
Expanded conditionals over guard clauses. Guard clauses only at the very top or when the body is large.
Method ordering: class methods, public methods with initialize first, private methods, all ordered by invocation order.
! only when there’s a non-! counterpart. Not just to signal mutation.
Test conventions: use fixtures, _path helpers, assert_in_body, omit explicit { render } in respond_to.

What stands out

These apps don’t avoid Rails features; they use delegated types, polymorphic associations, concerns, Action Cable, Turbo, Solid Queue. But they avoid adding architectural layers until the domain demands it. The result is code that reads like the product it builds.

Original source

On the reading list: I gave Pi one tool

2026-07-25T00:00:00+00:00

Queued up for a proper read: I gave Pi one tool by Tom (monotykamary).

The premise alone earns it a spot on the list. Instead of handing the Pi coding agent a box of verbs (read, search, run, edit), Tom collapsed everything into a single fabric_exec tool that accepts TypeScript. The model writes a small program against Pi’s capabilities, it runs in a QuickJS sandbox, and only the returned evidence reaches the conversation. A loop becomes an actual loop; parallel work becomes Promise.all; twenty megabytes of tool output becomes ten useful lines.

Then it gets recursive: most of pi-fabric was built by models working through pi-fabric: 337 commits and 11,155 fabric programs in twelve days, with Tom steering, stealing good ideas, and rejecting bad ones.

This lands right in the middle of my Pi obsession, the same orbit as the shape-your-own-tools prompt I captured earlier. Skimming it, the parts I want to sit down with: tool schemas as an entropy source (models drift while reproducing unfamiliar schemas, so give them a compiler instead), deliberate erasure (compaction, forgetting, and state transitions as runtime features), and the honest cost accounting: reading, not writing, is the bill.

Note to self: before going deeper I need to learn more about how Pi itself is built (the extension API and its lifecycle events, sessions as JSONL trees, compaction, the SDK and RPC modes) so I can adjust pi-brain to get the most out of the harness, and honestly validate whether the idea makes sense at all next to runtimes like pi-fabric.

Original source

Shape your own tools: a prompt instead of a repo

2026-07-25T00:00:00+00:00

Someone asked @dodoreach to open source their web UI for the Pi coding agent. The answer stuck with me more than any repo could:

the best thing @pidotdev taught me is that learning to shape your own tools is better than accepting someone elses finished product

So instead of a repo, they shared a one-shot prompt: paste it into your agent and it builds you your own “codex-style” dashboard for Pi: pick a project, create or resume native Pi sessions, watch text, thinking, and tool activity stream in, steer mid-run, queue follow-ups, stop, switch models, all from desktop or your phone, privately over Tailscale Serve. The browser is only a control surface; Pi stays the agent and the source of truth.

What I find remarkable is how much engineering judgment is packed into the prompt itself. It doesn’t just describe an app, it encodes discipline: verify the real environment before coding, pin the SDK to the installed CLI version, keep the integration behind a typed adapter with a deterministic fake so tests never burn tokens, bind to 127.0.0.1 as the security boundary, no telemetry, no public hosting. A prompt like that is a spec, a threat model, and a teaching document at once. Prompts might be the new way to open source.

The energy of the follow-up post sells it better than any feature list: using Pi to build a mobile companion for a Pi app: “going camping now but you are coming with me buddy.”

Note to self: I need to do the same for myself. Run the prompt against my own Pi setup, shape the tool to my hands, and take my agent camping.

Is Ruby dead? Cathedrals in Go, and a rebuild experiment

2026-07-25T00:00:00+00:00

Is Ruby dead? Is it time to build cathedrals in Go and other languages?

The question has been sitting with me lately. Maybe I need to actually learn Go, and learn how to build distributed infrastructures for things like chat systems, instead of theorizing about it from the Rails side.

So, note to myself, an experiment:

Rebuild a Rails project in Go, and rebuild the infrastructure around it too, not just the app code.
Compare cost, speed, and complexity between the two versions: what does the Go cathedral actually buy, and what does it charge for it?
Identify the guard rails: what keeps you safe in Go where Rails conventions used to?
Figure out ways to test it all: what does a good testing story look like on the other side?

Not a verdict on Ruby. A way to find out for myself.

Recruitment agents: let the agents talk it out first

2026-07-25T00:00:00+00:00

There’s this idea that the future of everything in human communication is having your own agent that does the difficult bits for you: asking the nagging questions about a hotel booking, ordering stuff and handling the negotiation, arranging and managing your vacation through whatever the future of Booking becomes. Marc Kohlbrugge’s example captures it well.

So: why not do this for recruitment?

Picture agents hooked into channels on both sides (people looking for a job and people hiring) where the agents talk it out amongst themselves first. Availability, salary ranges, must-haves, dealbreakers, all the awkward early back-and-forth handled agent-to-agent before any human spends time on it. Something in the spirit of rentahuman.ai, but for matching people with jobs instead of agents with gig workers.

Recruitment feels unusually well-suited for this. The early funnel is mostly structured information exchange that both sides find tedious, and both sides already automate it badly: ATS filters on one end, mass-apply tools on the other. Agent-to-agent negotiation is arguably a more honest version of an arms race that’s already happening.

The first step that seems easy to do now: hiring platforms exposing an MCP that supports candidates, not just recruiters. That’s a partial version of the full idea: it gives a candidate’s agent, whichever agent they use, a real channel into the hiring side, and makes finding a job easier long before the full agent-to-agent negotiation loop exists.

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.

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

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

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.

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

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.