DEV Community: Hamza A

Rune: A Rust-Native AI Runtime — And Why It Needs Contributors

Hamza A — Fri, 10 Apr 2026 10:04:38 +0000

I have been building Rune over the past few weeks — a Rust-native AI runtime that acts as a personal agent gateway. It handles multi-provider routing, durable sessions, semantic memory, tool approval workflows, and federated multi-instance orchestration.

It is moving fast — over 1,200 commits since mid-March and I use it daily. But it needs more hands. Here is what it is, where it is going, and how you can help.

What Rune does

Rune sits between your messaging channels (CLI, WebChat, API) and your model providers (OpenAI, Anthropic, Azure AI Foundry, Azure OpenAI). It adds the runtime layer that every serious agent deployment needs:

Durable sessions — survive restarts, crashes, redeployments. Backed by PostgreSQL, SQLite, or Azure Cosmos DB.
Tool call approval workflows — agents propose actions, operators approve or reject. Every decision is logged.
Semantic memory and retrieval — context that persists across conversations.
Provider routing — switch models per task, failover between providers, manage cost.
Cron jobs and reminders — scheduled agent work without external orchestration.
Federated instances — run Rune on your laptop and your server, share state, delegate workloads.

Why Rust?

The agent gateway is a long-running process that holds sessions, queues approvals, brokers every model call, and runs on your infrastructure 24/7. That is a systems programming problem.

Rust gives Rune predictable performance (no GC pauses), memory safety without a runtime, single-binary deployment, and a type system that catches bugs before they reach production. The tradeoff is that Rust has a steeper learning curve — which is exactly why this project needs contributors who enjoy working in that space.

Get it running in 60 seconds

# One-line install
curl -fsSL https://raw.githubusercontent.com/ghostrider0470/rune/main/scripts/install.sh | sh

# Or from source
cargo build --release --bin rune-gateway --bin rune
cargo run --release --bin rune -- setup --api-key "$OPENAI_API_KEY"

You get a working gateway with WebChat at localhost:8787/webchat, a dashboard, SQLite state, and auto-detected local Ollama. Docker Compose is also supported for zero-config deployment.

Native spells (built-in tools)

Rune ships with compiled-in tools called "spells":

rust-patterns — query production Rust patterns by topic, tags, or imports
security-audit — baseline host security checks
code-review — structured multi-dimensional review for files, diffs, and PRs
evolver — self-evolution workflow scaffold

These are not plugins. They compile into the binary and run at native speed.

Where contributors can make an impact

This is where I need help. Rune is an active, parity-seeking runtime — the core loop works, but there is a lot of surface area to cover. Here are the areas where contributions would move the needle:

Good first issues

Documentation improvements — the docs/ folder is comprehensive but can always be clearer
Error messages and diagnostics — make rune doctor run catch more edge cases
CLI UX — better help text, output formatting, progress indicators

Medium complexity

New spells — build a new built-in tool (web scraping, file management, git automation)
Provider integrations — add support for Groq, Mistral, or local llama.cpp
Dashboard features — the TypeScript frontend (10% of the codebase) needs love
Storage backends — help harden the Cosmos DB and Azure SQL paths

Advanced

Federation protocol — improve multi-instance delegation and health checking
Semantic memory — better retrieval strategies, embedding pipeline optimizations
Streaming — improve real-time token streaming across the gateway
Security hardening — audit the approval workflow, session isolation, auth paths

Non-code contributions

Try it and file issues — install Rune, break it, tell me what confused you
Write about it — blog posts, tutorials, comparison articles
Design feedback — if you have opinions about agent runtime UX, I want to hear them

The architecture at a glance

Channels (CLI / WebChat / API)
       |
   Rune Gateway (Rust)
   ├── Session Manager (durable state)
   ├── Tool Executor (approval queue)
   ├── Provider Router (multi-model)
   ├── Memory & Retrieval
   ├── Scheduler (cron / reminders)
   └── Federation (multi-instance)
       |
Providers (OpenAI / Anthropic / Azure AI / Ollama)
       |
Storage (SQLite / PostgreSQL / Cosmos DB)

How to start contributing

Star and clone: github.com/ghostrider0470/rune
Read docs/contributor/ — development workflow, build instructions, PR conventions
Check docs/parity/ — see what is shipped vs what is next
Pick something from the issues or propose your own
Join the conversation — open a discussion on GitHub, I respond to everything

The codebase is 88% Rust, 10% TypeScript, with comprehensive documentation organized by audience (operator, contributor, reference, strategy). Architecture Decision Records live in docs/adr/.

Why contribute to Rune?

Real Rust systems programming — not toy examples, actual long-running service code
AI infrastructure — the agent runtime space is early and moving fast
Small project, big impact — your PR will not disappear into a 10,000-file monorepo
Learn by building — async Rust, PostgreSQL, provider APIs, WebSocket streaming, federation protocols

If you have ever wanted to work on the infrastructure layer of AI agents — the part that actually runs them reliably — Rune is a good place to start.

git clone https://github.com/ghostrider0470/rune.git
cd rune
cargo build --release

Let's build this together.

GitHub: ghostrider0470/rune
License: Open Source (MIT)

Microsoft Fabric and OneLake: The Unified Data Platform

Hamza A — Tue, 07 Apr 2026 10:28:53 +0000

For years, the Microsoft data story was a shopping list: Synapse, ADF, Power BI, Purview, ADLS, Databricks-or-not. Microsoft Fabric and OneLake collapse most of that into a single SaaS platform — and in 2026, it is finally mature enough to bet a production workload on.

Here is what actually changed and what to watch.

The core idea

One tenant, one lake. OneLake is the OneDrive for data: a single logical data lake across your entire org, built on Delta/Parquet, accessible from every Fabric workload (Data Engineering, Data Warehouse, Real-Time Intelligence, Data Science, Power BI) without copying data.

Shortcuts let you point at data in ADLS, S3, or GCS and treat it as if it lived in OneLake. No duplication.

Why it matters

No more pipeline jungle just to get data into Power BI
Direct Lake mode in Power BI queries Parquet files directly — no import, no DirectQuery tax
Git integration for notebooks, pipelines, and semantic models
Unified governance via Purview baked in
One compute metering model (capacity units) across all workloads

Where it is great

Organizations already standardized on Power BI
Mid-size data estates that never wanted to operate Databricks themselves
Teams that want medallion architecture without assembling six services

Where it is not yet the answer

Very large, very custom Spark workloads (Databricks still wins)
Teams with strict multi-cloud strategies (Fabric is Azure-first)
Workloads that need streaming semantics beyond what KQL and Eventstream provide

Migration tips

Start with one domain, not the whole estate
Use shortcuts before you move data — prove the queries work first
Adopt medallion layout in OneLake from day one (Bronze / Silver / Gold)
Bring Git integration in early — it is the biggest quality-of-life upgrade

Originally published on the Horizon Tech Blog.

Event-Driven Serverless Patterns That Scale on Azure

Hamza A — Tue, 07 Apr 2026 10:28:09 +0000

Serverless hit its awkward teenage years somewhere around 2022. In 2026, it is grown up: the patterns are settled, the tooling is boring (good), and event-driven architectures on Azure genuinely scale when you build them right.

Here are the patterns that actually hold up.

The three building blocks

Event Grid — cheap, low-latency, pub/sub for reactive workflows
Service Bus — durable, ordered, transactional messaging for business logic
Event Hubs — high-throughput streaming for telemetry and logs

Use all three. They are not competitors; they are different instruments.

Patterns that scale

1. Grid → Function → Bus

Event Grid fans out a lightweight notification to a Function. The Function does the minimum work needed to enqueue a durable command into Service Bus. Keeps the hot path fast and the business path reliable.

2. Outbox → Event Grid

Write to your database and to an outbox table in the same transaction. A tiny worker drains the outbox to Event Grid. You get exactly-once-ish semantics without distributed transactions.

3. Saga over Service Bus

Long-running business processes as a chain of Service Bus messages with compensation steps. Durable Functions make the orchestration readable.

4. Event Hubs → Stream Analytics → Fabric

High-volume telemetry lands in Event Hubs, gets projected into Fabric or ADX for queries. Functions handle alerts off the same stream.

Things to get right early

Idempotency keys on every handler
Poison queues and dead letter alarms
Schema registry for event contracts
Tracing via OpenTelemetry across the whole chain
Backpressure — Functions can scale, your downstream database cannot

When not to go serverless

Long-running heavy compute (use Container Apps)
Very latency-sensitive synchronous APIs (use Container Apps or AKS)
When your team has zero operational experience with distributed systems

Originally published on the Horizon Tech Blog.

Cloud-Native Authentication Patterns for Web Apps

Hamza A — Tue, 07 Apr 2026 10:27:36 +0000

Authentication in cloud-native web apps in 2026 is not about rolling your own login form. It is about picking the right pattern for your topology — single-page app, server-rendered, mobile, or API-first — and wiring it to an identity provider you trust.

Here are the patterns that hold up in production.

The four shapes of modern auth

Authorization Code + PKCE (SPAs and mobile). The default for anything client-side. No client secret, PKCE binds the token to the client, refresh via rotating tokens.
BFF (Backend-for-Frontend) with session cookies. The comeback pattern. Keep tokens on the server, give the browser a signed session cookie. Works beautifully with SSR frameworks.
Client Credentials (service-to-service). For machine-to-machine, scoped to one audience per client. Never reuse across services.
Device Code (CLIs and IoT). For inputs without a browser.

What to put on the identity provider

Entra ID / Auth0 / Clerk / Keycloak — pick one and commit
Configure per-environment tenants or at least per-environment apps
Enforce MFA at the IdP, not the app
Use short-lived access tokens and refresh token rotation

Common mistakes

Storing access tokens in localStorage (XSS steals them instantly)
Treating ID tokens as access tokens
Rolling custom JWT verification instead of using the IdP SDK
Skipping audience and issuer checks
No token revocation story

The BFF pattern in one paragraph

Your frontend talks only to your backend via HttpOnly, Secure, SameSite=Lax cookies. Your backend holds the real tokens, talks to downstream APIs on behalf of the user, and handles refresh. Result: zero tokens in JavaScript, no localStorage exposure, and CSRF is manageable with the usual double-submit pattern.

Originally published on the Horizon Tech Blog.

Azure IoT Operations: Edge Intelligence for Industry

Hamza A — Tue, 07 Apr 2026 10:27:01 +0000

If you run industrial IoT in 2026, the center of gravity has moved to the edge. Azure IoT Operations is Microsoft's Arc-enabled, Kubernetes-native edge stack — and it is finally the answer to "how do I run real logic next to my PLCs without shipping everything to the cloud?"

Here is what it actually is and when to use it.

What IoT Operations gives you

Arc-enabled Kubernetes as the runtime — you can use AKS Edge Essentials, K3s, or any CNCF-conformant cluster
MQTT broker at the edge (replaces the old IoT Edge hub)
Data flows for transformation and routing before data leaves the plant
OPC UA connector for talking to industrial equipment
Schema registry so you are not shipping untyped JSON around
Built-in observability via OpenTelemetry

Where it beats classic IoT Edge

Kubernetes-native, so your existing GitOps and Helm workflows just work
Clean separation of broker, connectors, and data flows
Local processing with cloud-optional operation
Better story for high availability at the edge

Architectural patterns that work

Plant-local MQTT + cloud fan-out. Brokers at the edge, with filtered routes to Event Hubs or Fabric.
Protocol translation at the edge. OPC UA in, Cloud Events out.
Rules at the edge, analytics in the cloud. Fast loops stay local, slow loops go to Fabric or ADX.

Where teams stumble

Treating it like IoT Edge v2 instead of a Kubernetes platform
Skipping the schema registry — you will regret it in month six
Under-provisioning edge clusters for real workloads

Originally published on the Horizon Tech Blog.

Azure IoT Hub: Enterprise Device Management at Scale

Hamza A — Tue, 07 Apr 2026 10:26:21 +0000

Managing 10 IoT devices is a weekend project. Managing 100,000 is a platform problem — and in 2026, Azure IoT Hub is still the most battle-tested way to do it if you are already on Azure.

Here is what running IoT Hub at real scale actually looks like.

What IoT Hub gives you

Per-device identity and auth (X.509, SAS, TPM)
Bi-directional messaging — telemetry up, commands and direct methods down
Device twins for desired/reported state sync
Message routing to Event Hubs, Service Bus, Storage, or custom endpoints
Device Provisioning Service (DPS) for zero-touch onboarding

The scaling patterns that work

Shard by DPS enrollment groups, not by hub. Start with one hub per region and grow.
Route telemetry out immediately. IoT Hub is a message broker, not a database. Land it in Event Hubs or ADX.
Use device twins for state, not telemetry. Twins are not free — treat them like config, not a data stream.
Back off on ingestion spikes. Use the built-in throttles instead of fighting them.

Operational gotchas

Connection storms after a regional outage can overwhelm DPS — stagger reconnects
Quota limits per hub are real; plan for S2/S3 tiers before you hit them
Message size matters — batch small payloads, compress where you can
Logs are expensive — route diagnostics to Log Analytics selectively

When to look elsewhere

You are fully on AWS → IoT Core is fine
You need MQTT 5 features IoT Hub does not yet expose
You are at the edge and want local-first → pair IoT Hub with IoT Operations

Originally published on the Horizon Tech Blog.

Digital Twins Meet BIM: Smart Building Intelligence

Hamza A — Tue, 07 Apr 2026 10:24:59 +0000

Building Information Modeling (BIM) gave us detailed 3D models of buildings. Digital twins gave us live, data-connected replicas of physical systems. In 2026, combining the two is finally producing the "smart building" outcomes that were overpromised for a decade.

Here is what is actually working in production.

What changes when BIM meets a digital twin

A static BIM model is a snapshot of design intent. A digital twin fuses that model with real-time telemetry — HVAC, occupancy, energy, water, elevators — so operators can reason about a building the way a pilot reasons about an aircraft.

The result is a queryable, time-series-aware model of the building.

Use cases that pay for themselves

Predictive HVAC tuning. Cut energy by 15–30% by learning occupancy patterns instead of running fixed schedules.
Fault detection and diagnostics. Catch failing chillers and leaky dampers weeks before they trigger tenant complaints.
Space optimization. Use live occupancy to rightsize floors, meeting rooms, and amenities.
Tenant experience. Wayfinding, booking, and indoor air quality dashboards tied to the same model.

The architecture that keeps working

Ingestion: IoT Hub or MQTT broker at the edge
Model: Azure Digital Twins (DTDL) or an open twin framework
Analytics: Time-series DB plus a rules engine
Visualization: Unity or web-based 3D viewer bound to the twin graph

Where teams get stuck

Treating the twin as a dashboard project instead of a data platform
Underestimating the BIM cleanup work — most IFC exports need heavy normalization
Ignoring change management — if facilities teams do not trust the twin, nothing ships

Originally published on the Horizon Tech Blog.

Azure DevOps vs GitHub Issues: Choosing the Right PM Stack

Hamza A — Tue, 07 Apr 2026 10:19:57 +0000

If you are picking a project management stack for an engineering team in 2026, the question is no longer "Jira or not." It is Azure DevOps or GitHub Issues — and the answer matters more than it used to, because the new AI-powered developer features are shipping exclusively on GitHub.

Here is the honest comparison after running both in production.

Where Azure DevOps still wins

Enterprise reporting and compliance. Boards, queries, and audit trails that a PMO actually trusts.
Test plans and manual QA workflows. Nothing in GitHub comes close.
Deep integration with the Microsoft stack — AAD, Power BI, Office 365, Teams.
Fine-grained work item hierarchies (Epic → Feature → PBI → Task) out of the box.

Where GitHub Issues pulls ahead

Copilot and agent features ship there first and often only there.
Projects v2 is finally good — spreadsheet-style views, custom fields, and automation rules.
Everything lives next to the code. Reviewers, issues, discussions, and CI in one place.
Lower friction for open source and contractor collaboration.

The practical call

Regulated enterprise with a PMO and test teams? Stay on Azure DevOps for now. Use GitHub for source.
Product engineering team shipping fast? Move to GitHub Issues + Projects. The AI tooling gap is widening every quarter.
Hybrid? It works, but pick one as the source of truth for work items. Duplication kills you.

Migration gotchas

Work item history does not transfer cleanly — export to CSV and archive
Custom fields in Azure Boards rarely map 1:1 to GitHub Projects
Pipelines vs Actions is a separate migration — do not do both at once

Originally published on the Horizon Tech Blog.

RFC 9457: Structured Errors Cut AI Agent Costs 98%

Hamza A — Tue, 07 Apr 2026 10:18:36 +0000

If you are still returning {"error": "Something went wrong"} from your HTTP APIs in 2026, it is time to upgrade. RFC 9457 (Problem Details for HTTP APIs) is now the de facto standard — and it obsoletes the older RFC 7807 that most teams copy-pasted into production years ago.

Here is what actually changed and what it means for your services.

What RFC 9457 defines

A standard JSON (or XML) shape for error responses so clients can reliably parse and act on failures:

{
  "type": "https://example.com/probs/out-of-credit",
  "title": "You do not have enough credit.",
  "status": 403,
  "detail": "Your current balance is 30, but that costs 50.",
  "instance": "/account/12345/msgs/abc",
  "balance": 30,
  "accounts": ["/account/12345", "/account/67890"]
}

The required fields are minimal: type, title, status, detail, and instance. Everything else is an extension you control.

What is new vs RFC 7807

Clarifications around extension members — you can safely add your own fields without breaking clients
Better guidance on type URIs — they should be stable and dereferenceable documentation
Explicit support for i18n via content negotiation
Tightened security guidance so you do not leak stack traces or internal IDs

Why this matters for your team

Clients can finally handle errors generically. No more "every service has its own error shape."
Observability gets easier. Your logs and traces can pivot on type without custom parsers per service.
Fewer support tickets. A stable instance URL makes bug reports actually reproducible.

Migration tips

Pick a single type URI namespace and document it
Keep title human-readable and stable; put the variable bits in detail
Never put PII or secrets in detail or extensions
Map your existing error codes to type URIs before changing the wire format

Originally published on the Horizon Tech Blog.

Claude Code Is Reshaping Software Engineering in 2026

Hamza A — Tue, 07 Apr 2026 10:14:14 +0000

Claude Code is now authoring roughly 4% of all commits on GitHub. That is not a rounding error — it is a structural shift in how software gets written.

Over the last few weeks we dug into what agentic coding actually looks like in production across multiple client teams: where it works, where teams are getting burned, and which workflows are quietly becoming the new default in 2026.

The headline stat

4% of commits sounds small until you remember that a year ago it was essentially zero. The adoption curve is steeper than anything we have seen since the original GitHub Copilot launch.

What surprised us

PR velocity is not the real win. Review quality is. Teams that treat Claude Code as a junior dev who needs feedback ship better code, not just faster code.
The biggest gains are not from the heaviest users. The teams winning are the ones with the tightest guardrails around review, testing, and spec-first prompting.
Guardrails are the moat, not the model. Anyone can point an agent at a repo. Very few teams have figured out the review loop that makes it safe.

Where it genuinely saves time

Boilerplate migrations (framework upgrades, test scaffolding, API client generation)
Reading and summarizing unfamiliar codebases before a refactor
Writing tests for existing code with clear contracts

Where it creates review debt

Large cross-cutting refactors without a spec
Anything involving subtle business logic the agent cannot infer from context
"Just let it run" workflows with no human checkpoint

The 2026 default

Spec-first prompting is becoming the norm. The teams that win treat the prompt like a design doc: acceptance criteria, constraints, non-goals, and a plan the agent has to confirm before touching code.

Originally published on the Horizon Tech Blog.