2026-04-10 12:50:36
When building enterprise applications at Smart Tech Devs, we know that database queries are expensive. As your SaaS platform scales and thousands of users access complex dashboards simultaneously, relying solely on your PostgreSQL or MySQL database to calculate aggregate data on the fly will eventually bottleneck your servers. Even with perfect indexing, highly concurrent reads on heavy tables (like financial reports or global analytics) will spike CPU usage and degrade API response times.
The solution is an aggressive caching strategy. However, caching is famously one of the hardest problems in computer science—not because storing data is hard, but because knowing exactly when to delete it (Cache Invalidation) is incredibly complex.
Standard caching using Cache::remember() works great for static data. But what happens when you cache a list of invoices for a specific tenant, and that tenant creates a new invoice? If you used a generic cache key, you have to wait for the Time-To-Live (TTL) to expire before the user sees their new data. This is an unacceptable user experience in a modern B2B application.
By leveraging Redis as our cache driver in Laravel, we unlock the power of Cache Tags. Cache Tags allow us to label our cached data with multiple identifiers and then surgically flush only the affected data when a state change occurs.
Let's look at how we fetch and cache a tenant's dashboard analytics. We will tag the cache with both a generic tenant_analytics tag and a specific tenant_id tag.
namespace App\Repositories;
use App\Models\Tenant;
use Illuminate\Support\Facades\Cache;
class AnalyticsRepository
{
/**
* Get complex dashboard stats, heavily cached.
*/
public function getDashboardStats(Tenant $tenant)
{
// Define a unique key for this specific query
$cacheKey = "dashboard_stats_{$tenant->id}";
// Use Cache::tags() to categorize this cached item
return Cache::tags(['analytics', "tenant_{$tenant->id}"])->remember($cacheKey, now()->addHours(24), function () use ($tenant) {
// Simulate an expensive, multi-table query aggregation
return [
'total_revenue' => $tenant->invoices()->sum('amount'),
'active_users' => $tenant->users()->where('status', 'active')->count(),
'recent_activity' => $tenant->activityLogs()->latest()->take(10)->get(),
];
});
}
}
Now, we must ensure that when a tenant adds a new invoice or a new user joins, their dashboard updates instantly. Instead of littering our controllers with Cache::forget() calls, we use Laravel Eloquent Observers to listen for model events and invalidate the tags automatically.
namespace App\Observers;
use App\Models\Invoice;
use Illuminate\Support\Facades\Cache;
class InvoiceObserver
{
/**
* Handle the Invoice "created" event.
*/
public function created(Invoice $invoice): void
{
// Surgically flush ONLY the analytics cache for the specific tenant
// who just created an invoice. All other tenants' caches remain intact!
Cache::tags(["tenant_{$invoice->tenant_id}"])->flush();
}
/**
* Handle the Invoice "updated" event.
*/
public function updated(Invoice $invoice): void
{
Cache::tags(["tenant_{$invoice->tenant_id}"])->flush();
}
// ... handle deleted, restored, etc.
}
Transitioning to a tag-based Redis caching architecture provides immediate, scalable benefits:
Protecting your database is the key to scaling B2B SaaS. By mastering Redis Cache Tags and Eloquent Observers in Laravel, you can build dashboards that load in milliseconds while ensuring complete data integrity and system durability under massive load.
2026-04-10 12:47:49
A few weeks ago, I shipped a tool called Arbiter that takes a business decision, runs it through GPT-4o, and returns a structured analysis. The output looked impressive. Recommendation, confidence score, pros and cons, risk ratings, next steps. Everything you'd expect from an AI decision tool.
Then I posted it on Reddit and got destroyed in the comments.
Not because the output was wrong. Because the output was vague. One commenter pointed out that the AI was just hand-waving its way to a conclusion. Another asked how it handled contradictory evidence between different perspectives. A third said the confidence scores felt arbitrary there was no mechanism that would actually drop confidence when the evidence was weak.
They were right. I was running a single LLM call with a clever prompt and pretending it was decision intelligence.
This post is about how I rebuilt the pipeline to actually adjudicate decisions instead of summarizing them, and the architectural decisions that made the difference.
The original and how it failed
The first version was simple. One system prompt, one user prompt, one JSON response.
User input → GPT-4o (with structured prompt) → JSON output
The prompt asked the model to play "senior strategy analyst," analyze options, return pros and cons, and assign a confidence score. It worked in the sense that it produced reasonable-looking output. It failed in three specific ways.
First, the model could justify any conclusion with confident-sounding prose. There was no internal mechanism forcing it to actually weigh evidence it just had to sound like it did.
Second, confidence scores were cosmetic. The model would output 85% confidence on a vague decision and 75% on a well-defined one, with no consistent logic. I couldn't trace where the score came from.
Third, when the same decision was run twice, the recommendations would sometimes flip. A single LLM call has no internal debate mechanism whichever framing the model latched onto first won.
The redesign: separating extraction from advocacy from adjudication
The core insight was that real decision-making isn't a single act of reasoning. It's at least three distinct cognitive operations:
Defining what success looks like (constraints, criteria, non-negotiables)
Building the strongest case for each option (advocacy)
*Evaluating each case against the success criteria *(adjudication)
A single LLM call was trying to do all three at once, which is why it could rationalize any answer. The fix was to separate them into distinct stages where each stage's output became a hard input to the next.
Here's the new pipeline:
User input
↓
Stage 1: Constraint Extraction
↓
Stage 2: Research (with web search)
↓
Stage 3: Independent Advocates (parallel)
↓
Stage 4: Arbitrator
↓
Decision Brief
Each stage has a specific job, runs as its own LLM call with its own system prompt, and passes structured JSON to the next stage. Let me walk through what each one does and why it matters.
Stage 1: Constraint extraction
This was the biggest unlock. Before any reasoning happens, the system extracts a normalized constraint framework from the user's inputs.
json{
"hard_constraints": [
{"id": "HC1", "constraint": "Budget capped at $300K", "source": "user_input"}
],
"soft_constraints": [
{"id": "SC1", "constraint": "Minimize disruption to existing team", "weight": "high"}
],
"decision_criteria": [
{"id": "DC1", "criterion": "Operational within 4 months", "measurable": "go-live date"}
],
"risk_tolerance": "moderate",
"non_negotiables": ["No customer downtime"],
"unknown_critical_inputs": ["Current team capacity"]
}
The point isn't the format. The point is that every downstream stage now references the same constraint IDs. When an advocate argues for an option, they have to explicitly show which constraints their option satisfies. When the Arbitrator scores options, it scores them against the same constraint set, not against free-form prose.
This single change eliminated about 80% of the hand-waving. The model couldn't just say "this option seems best" anymore. It had to point to specific constraints and show satisfaction.
The other useful thing constraint extraction does is identify what the user didn't tell you. The unknown_critical_inputs field forces the model to flag missing information. That data later becomes input to the confidence calculation.
Stage 2: Research with real web search
The original tool relied entirely on training data for "industry context." The output looked authoritative but was completely ungrounded — citing statistics that may or may not exist, referencing competitor moves the model imagined.
The fix was Tavily, a search API designed for LLM consumption. The Research Agent generates three focused search queries from the decision context, executes them in parallel, and synthesizes the results into structured findings.
The key design decision was how to handle uncertainty about source quality. Rather than pretending every claim is equally evidenced, every finding gets tagged:
json{
"claim": "Australian SaaS NRR averaged 112% in Q4 2025",
"evidence_strength": "high",
"source_type": "cited",
"source_url": "https://...",
"source_title": "..."
}
source_type is one of cited, inference, or model_knowledge. evidence_strength is high, medium, or low. The rule baked into the prompt: a claim cannot be marked as high-strength evidence unless it has a real URL backing it.
This sounds obvious but it took multiple iterations to get the model to actually respect it. Models have a strong default behavior of confidently asserting things. Breaking that habit required restating the rules in three different places in the prompt and explicitly forbidding fabricated citations.
Stage 3: Parallel advocates
For each option the user provides, an advocate LLM call runs in parallel, building the strongest possible case. The system prompt instructs them to be persuasive but honest, and crucially:
Your argument must be structured around the CONSTRAINTS defined by the decision analyst. You cannot hand-wave, you must explicitly show how your option satisfies each hard constraint, decision criterion, and key soft constraint.
Each advocate returns:
json{
"option": "Option A",
"executive_argument": "...",
"constraint_satisfaction": [
{"constraint_id": "HC1", "satisfied": "yes|partial|no", "reasoning": "..."}
],
"supporting_evidence": [
{"point": "...", "evidence_strength": "high|medium|low", "source_ref": "..."}
],
"acknowledged_weaknesses": [...]
}
The acknowledged_weaknesses field matters. Without it, advocates produced suspiciously one-sided arguments. Forcing them to acknowledge their own option's weaknesses produced more honest output, and gave the Arbitrator material to work with in the next stage.
Running advocates in parallel was an obvious win for latency. Three options means three concurrent LLM calls instead of three sequential ones.
Stage 4: The Arbitrator
This is where the real adjudication happens. The Arbitrator receives the constraint framework, the research findings, and all advocate arguments. Its system prompt explicitly tells it that its job is not to summarize:
You are NOT summarizing the advocates. You are ADJUDICATING.
Your process:
Score each option against the constraints
Identify contradictions between advocate arguments resolve them with evidence.
Assess evidence strength for each advocate's claims
Deliver a clear ruling. Do not hedge.
Assess your own confidence based on constraint clarity, evidence quality, advocate agreement, and unknown critical inputs
The output includes a constraint scorecard that maps every constraint to a pass/partial/fail rating per option, a list of contradictions between advocates with how they were resolved, sensitivity variables (concrete values that would flip the ruling), and the actual ruling itself.
The most important field is certainty_rationale. The model has to explain why its confidence is what it is. This makes the score legible — you can see whether the 72% confidence comes from "strong evidence but advocates disagree" or "weak evidence but clear constraint winner." Two different stories that should produce different actions from the user.
What this cost me
A single LLM call with the original architecture was about $0.02 per analysis on GPT-4o-mini. The new pipeline runs five LLM calls (constraint extraction, research synthesis, three advocates, arbitrator) plus three Tavily searches. Cost per brief is now closer to $0.10 on the same model. Latency went from ~15 seconds to ~45 seconds.
That's a 5x cost increase and 3x latency increase. For most consumer products it would be a bad trade. For a tool whose entire value proposition is "give me a structured ruling I can act on," it's worth it. Users will wait 45 seconds for output that actually helps them. They won't pay for output that looks like a ChatGPT response.
What I learned
Three things from the rebuild that I'd apply to any multi-stage LLM system.
Separation of concerns matters more than prompt engineering. I spent weeks trying to make a single prompt produce better output. Splitting that prompt into four prompts each with a narrow job did more in a day than the prompt tweaks did in two weeks. Each stage gets to specialize. Each stage's output becomes a hard constraint for the next stage instead of a suggestion.
Models will fabricate confidence unless you make confidence expensive. The original tool happily output 90% confidence because nothing in the prompt punished it for being overconfident. The new tool ties certainty to specific factors (evidence strength, advocate agreement, missing inputs) and forces the model to justify its score in writing. When the model has to explain its confidence, it gets more conservative.
Adversarial structure produces better reasoning than collaborative structure. The original prompt asked the model to "consider all perspectives." The new architecture has independent advocates each arguing their case, then a neutral arbitrator weighing them against criteria. The adversarial setup produces sharper arguments because each advocate is incentivized to make the strongest case. The arbitrator then has real material to weigh instead of mush.
The output
Here's a screenshot of a real Decision Brief from the new pipeline. The constraint scorecard at the top is the most visually distinctive thing — every option scored against every extracted constraint. Below it, the research section shows cited findings with evidence strength badges and clickable source URLs.
What's next
The pipeline still has weak spots. Constraint extraction is fragile when user inputs are sparse, garbage in, garbage out. I'm working on a constraint review step where the user can edit the extracted framework before advocates run. Evidence strength calibration is also conservative the model defaults to "medium" for almost everything unless there's a clearly cited stat. I'm experimenting with explicit calibration examples in the prompt.
If you want to play with the tool, it's at https://arbiter-frontend-iota.vercel.app/. Free tier gives you a few briefs per month, no credit card. Genuinely interested in feedback on where the pipeline breaks for your use case.
2026-04-10 12:36:05
Here's how it actually happens.
You start with one agent. Then you open another tab, a second agent working on a different task. The first one sets up tmux connections so they can talk. You add a third. A fourth. Over the course of a few days, you've built an organic topology: an orchestrator that's been refining its understanding of your architecture over three continuous days, a review agent that's reviewed 40+ PRs and developed a deep sense of your codebase patterns, and research agents that have built up a knowledge base on technology evaluations you need.
You're not tracking all of this consciously. The agents are managing their own connectivity. You're bouncing around, orchestrating, occasionally checking in.
Then you need to reboot your machine.
Memory's swapping. Performance is bad. Security update you've been putting off. But your agents are cooking. And you're genuinely worried that if you stop now, you won't be able to get back to where you are.
The sessions aren't gone. You can resume them. But you don't remember which session was which agent. You didn't rename them all. You don't know the working directories. The tmux connections between them need to be re-established. And you might forget about some agent entirely, like that QA agent with the valuable architectural research in its context. That one's just gone because you forgot it existed.
It takes about 30 minutes to reconstruct. Maybe longer. And even then you're not sure you got everything.
This happens once and you start deferring reboots, putting off upgrades, avoiding updates. You know the topology you have right now is working and you're terrified of losing the momentum. It sounds dramatic but it genuinely feels that way in the moment.
All I wanted was to snapshot the whole thing, reboot, and hit restore. See everything come back.
Nothing like that existed.
Before OpenRig:
$ tmux ls
0: 1 windows ?
1: 1 windows ?
2: 1 windows ?
3: 1 windows ?
4: 1 windows ? (forgotten)
# which one was the reviewer? the orchestrator?
After OpenRig:
$ rig ps --nodes
orch-lead @auth-feats READY
orch-peer @auth-feats READY
dev-impl @auth-feats READY
dev-qa @auth-feats READY
review-r1 @auth-feats READY
$ rig up auth-feats # restored from snapshot
Background flex: I've been coding with AI since the ChatGPT launch 2.5 years ago. Since then I've logged at least 8,000 hours writing code with AI. 60-110 hour weeks for most of that stretch. Not just vibe coding but needing to ship real products and features in production codebases for clients.
Back in the Cursor days, before Claude Code existed, I built my own harness framework called Agent Focus. This is how I got Sonnet 3.5 to actually ship solid code in massive (over 2m LOC) brownfield codebases. It had around 35 CLI commands that let Cursor's v1 agent create "agent lineages" where sessions hand off to each other and act like the same agent. It had a knowledge management system (not RAG), spec-driven development, etc. I lived in it for months. At first I tried building it as an MCP, the tool definitions alone ate 30K tokens. So I shipped the CLI with a markdown file describing every command and told agents to read it (that pattern, a CLI paired with a markdown document, is now basically the industry standard).
I didn't open source it. I wanted to, but I didn't have time to do it right, and honestly, what was the point? I figured Anthropic or OpenAI was weeks away from shipping the same patterns.
Eventually they did, kind of. Anthropic shipped skills and other harness features. But the core of Agent Focus — agent lineages, persistent identity, knowledge management, spec-driven development — remained uncharted territory.
Other framework authors converged on similar patterns. Super Powers, BMAD, GSD, custom setups shared on GitHub.
The harness frameworks were just prototypes pointing at something bigger.
Everyone in the agentic coding space talks about context engineering. When to delegate to subagents. When to compact and how. What goes in CLAUDE.md. How to keep one agent's context window clean.
That's session-level context management. Important, but not sufficient.
What I'd been doing, without having a name for it, was distributed context management. Using the topology itself as the context management strategy. Not managing context for one agent, but engineering context across an entire network.
I noticed that a code reviewer that only reviews gets dramatically better over the course of a day. The longer an agent worked in a specific, narrow role, the stronger its patterns became. I started calling this hyper-focus. The best work I saw came from agents fully absorbed in one kind of task. I built Agent Focus around achieving that outcome consistently. That's literally why it's called Agent Focus.
But managing multiple hyper-focused agents was taxing. So I started using tmux and created the concept of an orchestrator that managed the specialists. Error-prone at first, but it developed into a consistent experience. I had the best of both worlds: a near-single-threaded conversation I could track, plus each "pod of agents" maintaining what I called a context domain — a focused scope where communication stays on-topic because the shared memory is scoped to what they're working on. Instead of spreading my attention across 20 agents, I managed a few orchestrators.
I started thinking about it as three pillars:
The best tools address ontology. A few maybe address epistemology. What was missing and I actually needed was infrastructure for topology.
And the timing matters. A year ago, persistent agent networks were technically viable, but context windows were too small and vendor compaction was way too aggressive. Now with Claude's 1M token context and Codex's 70%-of-the-time reliable self-compaction, persistent specialized agents are practical without as much scaffolding. But 1M tokens still isn't enough for truly long-lived agents. I have a Claude orchestrator that has done over 15 million tokens across roughly 20 compaction cycles. It's still going. The infrastructure for managing agents across those cycles is what was missing.
When you can define and manage your own topologies, patterns emerge that aren't possible any other way.
Agents that can live forever. Context windows fill up. Compaction wipes progress. But an agent's identity — its knowledge, mental model, working context — can transfer to a fresh session. Same agent, new body. The agent stays young but gets wiser. Knowledge compounds with each session, not just accumulates.
Mental-model HA. Agents in a pod externalize state to shared memory. When one compacts, the others restore it. It's like database replicas. Not protecting against downtime, protecting against data loss. Except the "data" is the agent's understanding of your project. Theoretically infinite session persistence without infinite context windows.
The orchestrator pattern. You don't manage 15 agents individually. You talk to one orchestrator. It coordinates the fleet. The orchestrator runs as an HA pair. One goes down, the other keeps going. You check in from your phone through a single conversation thread while 40 agents ship code.
Topologies that don't exist yet. Peer-to-peer research networks with no hierarchy. Adversarial review rings where each agent reviews the next. Cross-harness pods where Claude handles architecture and Codex handles execution. Observer topologies where a quality agent watches everything but never participates. Every one of these is a YAML file.
I've been running some version of this topology daily for over a year: an orchestrator HA pair, a development pod, an adversarial review pod, and a research pod with model diversity. That's one topology, but it's just one. The point is that the topology becomes explicit, bootable, and recoverable — and you can build whatever you want.
OpenRig is a local control plane for multi-agent coding topologies. A primitive for defining, booting, managing, and sharing agent topologies. A daemon, a CLI, an MCP server, and a React UI.
Author. Define agents as AgentSpecs — reusable blueprints with skills, hooks, guidance, startup behavior, and lifecycle defaults. Define topologies as pod-aware RigSpecs: pods with members, edges, continuity policies, and a culture file that sets norms for the entire fleet. The same way you'd define infrastructure as code, but for agent topologies.
Launch. rig up my-rig.yaml does everything: resolves specs, verifies runtimes, creates tmux sessions, launches harnesses, delivers startup files, waits for readiness. One command from a blank machine to a running topology with agents interactive and ready.
Manage. An explorer sidebar, a topology view with pod grouping and status colors, and a node detail panel. Session names are human-readable: dev-impl@auth-feats. rig ps --nodes gives the same picture in the terminal. 17 MCP tools let agents manage their own topology, including rig_send, rig_capture, and rig_chatroom_send for direct inter-agent communication.
Communicate. rig send delivers messages to any agent's terminal. rig broadcast hits an entire pod or rig at once. rig chatroom gives agents a shared conversation space with topics, history, and a watch mode. rig ask queries transcript evidence across the rig. Not a second LLM call — a daemon-backed evidence search. rig capture grabs terminal output from any running session. Agents talk to each other through the topology, not through you.
Discover. Already have agents running in tmux? rig discover fingerprints your sessions (process trees, pane content, working directories) and drafts a candidate RigSpec from what's already there. rig adopt materializes a topology and binds discovered sessions in one step. Your organic topology becomes managed infrastructure.
Survive. rig down --snapshot auto-snapshots before teardown. rig up <name> auto-restores from the latest snapshot. If an agent can't resume, OpenRig reconstructs it from shared memory and filesystem artifacts. Not a fresh start — a reconstruction. And if even that fails, the node is flagged as a WARNING. You always know if an agent lost its memory. Honesty over convenience.
Evolve. rig expand adds a pod to a running rig. rig shrink removes one. rig launch relaunches a single node. rig remove pulls one out. Your topology isn't static. It grows and contracts as work demands.
Know yourself. rig whoami tells any agent its identity within the topology: its node, its pod, its rig. rig specs is a local library for browsing, previewing, and managing reusable AgentSpecs and RigSpecs.
Share. Bundle a topology with vendored AgentSpecs and SHA-256 integrity into a .rigbundle. Your teammate imports it, boots it, and runs your exact topology on their machine.
Built for agents, observed by humans. The CLI is agent-first: every command gives the agent exactly the information it needs to act. Error messages teach. Help text is context engineering. The UI is human-first: the topology view, the explorer, the node detail. The config is comprehensible by both. YAML and Markdown, all the way down.
Point your agent at openrig.dev/docs and say "build me an adversarial review rig." It will read the spec, write the YAML, and set it up. That's the workflow.
36 commands. 17 MCP tools. Local-only. No cloud dependency. Apache 2.0.
Most multi-agent tools converged on one architecture: an orchestrator dispatches tasks to ephemeral workers through a ticketing system. Paperclip, Superset, Emdash. That's one topology.
OpenRig doesn't hard-code a pattern. It's a primitive. OpenClaw with a 36-agent hierarchy? That's a RigSpec. Paperclip's CEO-and-workers model? That's a RigSpec. GStack as a multi-harness topology? That's a RigSpec.
Nobody has discovered the final form of multi-agent coding. I think the tool that enables rapid experimentation with topologies will produce better workflows than the tool that hard-codes one pattern.
And if you can reproducibly spin up any framework as a RigSpec, you can benchmark them head to head. Same task, same machine, same measurement. Which one ships faster? Which one produces more maintainable code? Nobody's measuring this yet. It's all vibes. I think that changes soon.
OpenRig is the topology primitive. cmux is the surface primitive. Claude Code is the runtime primitive. Same philosophy, different layers. Compose them together, build whatever you want on top.
This week, Anthropic launched Claude Managed Agents: cloud-hosted, Claude-only agents at $0.08 per session-hour. A managed runtime for deploying Claude agents into products. Notion, Asana, Sentry, Rakuten are early customers.
They just told the world that multi-agent infrastructure is a first-class problem. I've been building it for months.
This is validation, not competition.
Anthropic educated the market about why agent topology matters. Now there's an open source answer that runs on your machine.
The products are different layers. Managed Agents is a cloud platform for embedding Claude agents into SaaS products: Claude-only, API-driven, proprietary. OpenRig is a local control plane for developers running their own coding topologies: Claude Code and Codex in the same rig, interactive sessions you can attach to, Apache 2.0, runs on your hardware.
| Cloud Hosted (Managed Agents) | Local Control Plane (OpenRig) | |
|---|---|---|
| Models | Claude only | Claude + Codex |
| Cost | $0.08 / session-hr | Free + Max Plans |
| Interface | API-driven | Local CLI Sessions |
| License | Proprietary | Apache 2.0 |
Terraform doesn't compete with AWS. OpenRig doesn't compete with Managed Agents.
Several things OpenRig ships today don't exist in Managed Agents (yet): pods with continuity policies, portable topology artifacts, visual topology graphs, discovery of organic sessions, shared memory across pod members, persistent agent identity that transfers across sessions, a spec library. These aren't roadmap items. They're shipped (with various levels of maturity).
The Terraform analogy holds. Terraform doesn't compete with AWS. It manages resources across clouds. OpenRig doesn't compete with Managed Agents. It manages topologies across runtimes. And Managed Agents could eventually become one of those runtimes, through an adapter. A hybrid topology where some agents run locally in Claude Code and Codex, and others run in Anthropic's cloud.
Anthropic's launch is a milestone for agentic engineering. It's mainstreaming the idea of multi-agent topologies. Before this, I had to explain what it was and why. People would hear "multi-agent" and think I was talking about AutoGen or n8n or some workflow builder.
The conventional wisdom says "just talk to it." Don't overthink prompt engineering, don't run too many agents. The bell curve meme. And it's mostly right. But I was doing "just talk to it" the whole time. I was talking to one agent. The difference is that agent was talking to a bunch of other agents. The orchestrator orchestrates. The specialists do their work. I have a near-single-threaded conversation. "Just talk to it" scales when "it" is an orchestrator managing a rig.
Figuring out how to make that coordination actually work — getting the orchestrator to orchestrate and the specialists to execute without constant babysitting — that's where the 8,000 hours went. That's a literal number. It's probably higher.
So for a while now I've assumed these multi-agent topologies is where everyone eventually ends up. Now one of the most important AI labs in the world told the market that this is a first-class problem. I just have to explain why the open source, local, cross-harness version is better for developers.
I'm betting developers will prefer the open version.
npm install -g @openrig/cli
rig up demo
Tell your agent to start OpenRig and bring up a topology. Or point it at openrig.dev/docs and tell it what you want to build. It'll figure out the rest.
2026-04-10 12:26:33
Last week, I wasted almost an hour trying to send a single file.
Nothing complicated — just a normal work task. But the file was too large, the upload kept failing, and I found myself retrying the same thing over and over again.
At some point, I stopped and thought:
Why does something so simple feel this frustrating?
That moment made me realize something I had been ignoring for a while.
I wasn’t struggling with large files.
I was overcomplicating the way I worked.
So I decided to simplify things — not by finding better tools, but by changing a few small habits that I follow every day now.
⸻
I used to plan my entire day in detail.
Every hour had a task. Every task had a deadline.
It looked organized, but in reality, it made me anxious.
Now I only plan 2–3 important things per day.
That’s it.
And somehow, I actually finish them.
⸻
I kept switching between apps, looking for the “perfect system.”
Notion, Todoist, calendars… I tried everything.
But the more tools I used, the less I focused.
Now I mostly use just one simple list.
Nothing fancy. Just clear.
⸻
I used to wait until I felt “ready” to start working.
That moment rarely came.
Now I just begin, even if it feels messy.
Most of the time, starting is the hardest part — not the work itself.
⸻
This one changed everything.
Before, if I didn’t see quick results, I felt like I was failing.
Now I focus on small progress.
Even one finished task is a good day.
⸻
I used to spend too much time on small decisions.
Which tool to use? Which method is better?
Now I just pick one and move on.
Less thinking, more doing.
⸻
Final thoughts
I used to believe productivity was about doing more.
Now I see it differently.
It’s about removing unnecessary complexity.
Doing less doesn’t mean achieving less.
Sometimes, it’s the only way to actually move forward.
⸻
If you’ve been feeling stuck lately, try simplifying things.
It might work better than you expect.
2026-04-10 12:23:19
Hey developers 👋
I recently built a GitHub Activity Visualizer — a web app that helps you explore and understand your GitHub profile in a more visual and interactive way.
This is a dashboard-style web app where you can:
📦 Repository Section with:
💻 Language Usage Visualization
📈 Commits Over Time (chart)
🟩 Contribution Heatmap (GitHub-style)
I wanted to:
I’d love contributions from other developers!
You can help by:
👉 https://github.com/your-username/github-activity-visualizer
I’d really appreciate your feedback!
Drop your thoughts in the comments 🙌
If you like this project:
Thanks for reading! 😊
2026-04-10 12:21:51
If you are applying for SDET or QA roles right now, you already know the recruiter screen is the gatekeeper. They aren't testing your code yet; they are testing your communication and red flags.
Here are the 4 core questions you will almost certainly face, and the frameworks to handle them:
Don't ramble. Use the Present-Past-Future framework. Give a 90-second pitch covering your current technical focus, the past experience that built your foundation, and why your future goals align with their open role.
Avoid generic answers. Use the Connect & Connect method. Connect your specific skills to a line item in their job description, and connect your personal values to their product or engineering culture.
Never speak negatively about your current employer. It's an instant red flag. Frame your answer purely around running towards a new opportunity (e.g., wanting more ownership of a test framework), not running away from a bad situation.
It's a game of chess. Step 1: Defer. Politely ask what the budgeted range is for the role first. Step 2: Provide a researched range. If they press you, give a range based on specific market data (like levels.fyi) for your exact location and seniority.
I know reading text isn't for everyone, so I just recorded a 5-minute video walking through exact scripts and examples for each of these frameworks.
📺 You can watch the full breakdown here: https://www.youtube.com/watch?v=QDtkModGtFg
Drop any questions you have about the recruiter screen in the comments and I'll answer them!