Coder Legion - Recent posts tagged developertools

Bito's Governor Cut Privado's Coding Agent Costs 48% by Ending the Search Loop

Tue, 27 Oct 2026 13:00:00 +0000

Coding agents cost more than they should, and the reason is easy to miss. Most of the bill isn't the work. It's the agent searching your codebase, then re-sending everything it found on every step.

Bito is launching Governor today to go after that cost. Governor is a gateway and model router for coding agents like Claude Code, Cursor and Codex. It does two things. It sends each request to the right model based on the task in progress, not just the newest message. And it gives the agent the code it needs up front, so the agent spends far less time searching.

Bito says it has measured savings of 40% to 70% across about 10 enterprise customers. In one test at Privado, cost per task fell 48%, from $4.12 to $2.14, and every task still succeeded.

I asked Amar Goel, co-founder and CEO of Bito, how Governor works, where it falls short, and what developers can do this week to cut their own agent bills. Answers have been edited for length and clarity.

The Problem

Your white paper says 60% to 80% of agent session cost goes to context gathering. What did you see that led you to build Governor around that problem?

A coding agent works in steps. It searches the code and gets back 10 to 50 results. It reads one file, then another. Only then does it start to plan or answer your question.

Every result gets added to the conversation. On the next step, the whole conversation goes back to the model, because the model keeps no memory between requests. In one Claude Code session we measured, the agent's searches returned about 65,000 tokens of code. By the end, the session had processed about 6 million tokens. Nearly all of it was the same material, re-sent turn after turn.

Routing alone lowers the price of each token. But the agent still searches and re-sends just as much, so the biggest part of the bill stays the same. If a router leans harder on cheap models to make up the gap, quality drops, and developers spend the savings redoing the work. So we built Governor to cut both the price per token and the number of tokens.

Why do keyword-based routers like LiteLLM and Bifrost struggle with coding-agent traffic?

In a coding session, the message that starts the hardest work is often the shortest, like "looks good, implement this." Its meaning comes from the conversation before it.

LiteLLM and Bifrost both pick a model by scanning the newest message for keywords. We ran 12 typical coding-agent messages through LiteLLM's scorer. It sent 11 of them to the cheapest model, including a one-line request to refactor authentication code everywhere it's called. A better keyword list won't fix that, because the scorer never sees the task behind the message.

Here's what that costs. A strong model reads the code and writes a plan. The developer replies "go ahead." A keyword router sends the build step to the cheapest model. The code comes back weaker, the developer sends it back for fixes, and the savings go into the redo. Governor reads the "go ahead" together with the plan it approves, so the build goes to a model strong enough to do it.

How It Works

Walk me through what happens to a request from Claude Code once it hits Governor.

When a developer starts a new request, Governor's classifier reads it along with the task in progress. It places the request in a tier based on the kind of work and what a mistake would put at risk. The tier sets the model and reasoning level, drawn only from models the customer allows.

Before switching models, Governor checks the prompt cache. That's the discounted copy of the conversation the provider already holds. Switching means paying to rebuild it, so Governor switches only when the next few requests will save more than the rebuild costs.

When the agent needs to find code, Governor's code retrieval sub-agent does the search. The main agent gets a short answer with the file and line each fact came from.

Governor keeps a live index of a customer's repositories. Where does it live, and how do you handle teams with strict rules about source code?

The index lives wherever the customer runs Governor, in Bito's cloud or on-prem. It's a structural index of the code across every repository. We don't store the source code itself, and none of it is used to train a model.

Teams with strict rules run Governor on-prem. The index, the lookups and the routing decisions all stay inside their network. Model requests go out on the customer's own provider accounts and keys, the same calls their agents already make. So an on-prem deployment adds no new party that sees the code. Bito is SOC 2 Type II certified.

How does Governor decide whether a request is Simple, Medium, Complex or Reasoning? And what happens when it gets one wrong?

The classifier asks two questions. What kind of work is this, and what would a wrong answer put at risk? Clear, stated changes, including carrying out a plan already agreed to, go to Simple. Vague requests go to Reasoning, because the first job is figuring out what the developer wants. We tested hundreds of versions of that rubric against hand-labeled requests. Early versions put about 60% of requests in the right tier. The current one gets all of them right, across repeated runs.

When it's wrong, guardrails limit the damage. By default, Governor never routes to a model pricier than the one the developer asked for. If it can't place a request, the requested model answers. If the classifier fails partway through a turn, Governor keeps the current model. Teams can pin work, like keeping all planning on Opus. And every request records why it went where it went, so a bad call is easy to find.

Switching models mid-session throws away a paid-for cache. How does Governor decide when moving is worth it?

A warm cache can make the expensive model the cheaper choice. Reading a cached Opus 5.5 conversation costs $0.20 per million tokens. Sending the same conversation to Gemini Flash with nothing cached costs $0.75.

Over a longer stretch, the math can flip. In one 48-request implementation loop, paying once to warm the cheaper model's cache would have cut the cost by a third. The obvious answer is to forecast how long the conversation will run. That's very hard, though we're working on it.

So Governor asks a smaller question it can answer: will the next few requests pay back the cost of moving? It moves only when they will, so a wrong call costs at most a few requests' worth of savings. When we replayed real conversations, a forecast-based rule added 42% to the bill in one case where Governor's rule lost nothing.

The Results

The launch headline says 40% to 70% savings. Where does that range come from, and where should teams start?

We've measured results across about 10 enterprise customers so far. Savings vary because some customers pick Balanced and some pick Cost, and their workloads differ. The longer your coding sessions, the more you save. If you run a lot of short sessions, the savings are smaller. Some customers are getting around 80%, but we didn't want to overpromise.

Here's how the settings compare with Claude Code's default on Opus 5.5 in our long-session benchmark:

Quality keeps the same score at 1.3x lower cost, about 23%, with sessions 12% faster.
Balanced keeps 95% of the score at 1.9x lower cost, about 47%, with sessions 39% faster.
Cost keeps 94% of the score at 7.1x lower cost, about 86%, with sessions 30% faster.

These are benchmark numbers, so treat them as a starting estimate for your own traffic.

I'd start every team in shadow mode, where Governor records what it would have done without changing anything. Then switch on Balanced with planning pinned to the strongest model. Planning is what everything else in a session builds on, so that's where the best model earns its price.

Tell me about the Privado test.

Privado builds a privacy engineering platform, and its developers work in Claude Code. They ran 40 of their own engineering tasks twice, once straight to the model and once through Governor. Same model, same agent setup, so Governor was the only variable.

Cost per task fell 48%, from $4.12 to $2.14. Every task succeeded both ways. With Governor, tasks finished 38% faster. The agent took half as many reasoning turns and made 53% fewer tool calls, because it spent far less time searching the code.

For the developers, nothing changed in how they worked. They kept their agent, their prompts and their workflow. The difference showed up in the bill and in how fast tasks came back.

The benchmarks are Bito's own. What should a skeptical engineering lead know?

We built both benchmarks so a model can only score well by doing the work. Our public study graded 1,800 answers from 30 models on 60 real engineering tasks. Twenty-six run on private code no model could have seen in training. Twenty-eight are graded by running the model's code, so an answer counts only if it works. The session benchmark uses long Claude Code sessions on proprietary code, graded against a written key. Identical sessions vary by 1.5 to 2 points, so we compare averages and read every session that falls well below.

Still, a skeptical lead should trust their own traffic over our numbers. Shadow mode shows what Governor would have done. A/B mode sends a small share of traffic around Governor, compares cost per task, and grades a daily sample with a judge from a different model provider than the one doing the work.

Where does a cheaper setting lose quality, and how should a team protect those steps?

The loss sits in specific steps, not across the whole session. In our benchmark, Balanced fell furthest behind on diagnosing a failure. It earned 67% of the available points on that step, against 90% for the Opus 5.5 default. Quality scored 93%. Cheaper settings also lost points when defending a design against pushback.

Teams can protect those steps by keeping them on the strongest model. Governor lets a team route specific kinds of work up, so diagnosis and design review stay on Opus while the rest of the session runs on Balanced.

Trade-offs and Limits

Code context adds a wait before the first answer. When does it pay off?

Code context takes about 30 seconds up front. But that time isn't new. In our benchmark, Opus 5.5 on its own spends 36 to 41 seconds grepping and reading code before it starts the real work. Governor does that research for the agent, and tasks finish much faster overall.

On one benchmark of real developer requests, including tracing an event through Kafka and planning a feature, the session took 8.5 minutes with code context versus 25 minutes without. The agent made 14 tool calls instead of 162.

It pays off least on short, well-defined tasks, where the agent already knows where to look. It also helps less on steps that depend on reading one edge case line by line. That's what we're working on next.

What doesn't Governor do well yet?

There are four things, and we list them in the paper. First, short tasks. Some levers, prompt guidance in particular, add a fixed overhead that cancels most of the saving on quick jobs. So the Quality setting costs about the same as today on short work.

Second, cache behavior on some providers. With certain cheap models, the cache rule kept nearly every request on the expensive model, which leaves little saving.

Third, Governor decides fresh at the start of each turn. It doesn't forecast where a session is heading, which would help it pick models earlier.

Fourth, it can capture what developers do after an answer, but using that to tune the rubric for each team is still a manual step.

Getting Started

What does setup look like?

It's a base URL change in your existing coding agent. Governor speaks the Anthropic and OpenAI APIs, so pointing Claude Code, Cursor or Codex at it is one environment variable. Requests keep their model, streaming and tool calls. It runs on the team's own provider keys, alongside any gateway they already use, in Bito's cloud or on-prem. For code context, the team connects the repositories Governor should index.

Shadow mode records from the first request. A team can be up and running in minutes.

Which agents and providers are supported, and how is Governor priced?

At launch, Governor works with Claude Code, Cursor, Codex, GitHub Copilot and Pi, plus any agent that calls the Anthropic or OpenAI APIs. It covers Anthropic, OpenAI, Gemini (including on Vertex), Grok and open-weight models, on the customer's own keys or through their existing gateway.

Pricing is usage-based, scaled to the size of the indexed codebase and the volume of routing requests. Model provider costs pass straight through, so the savings show up on the bills teams already pay. Every team starts with a free trial on its own agents.

If a developer wants to cut agent costs this week, with or without Governor, what's the first step?

Look at one long session from your team, token by token. Most teams find the bill is the conversation being re-sent, with the agent's own searches piling up, more than the work itself. Across our model research, cache reads were 77% of all tokens processed.

Then check the reasoning level your tools send. Most send the same level on every request. On our benchmark, lighter reasoning on Sonnet 5.5 saved 9% and kept 98% of the score. And keep planning on your strongest model, since everything after it builds on the plan.

With Governor, start with shadow mode on your own traffic.

The Takeaway

The useful idea here goes beyond routing. Most of a coding agent's bill comes from what it re-reads, not what it writes. Cut the searching and the re-sending, and the choice of model matters less. Bito's numbers are its own, so the right first move is the one Goel suggests: measure one session from your own team and see where the tokens go.

Six agents were running and I could not tell you what any of them did

Wed, 23 Sep 2026 07:51:09 +0000

Six coding agents were running. I could not tell you what any of them had done.

Not roughly. Not approximately. The output was there, the files had changed, and the honest answer to "which one did that" was a shrug. Three questions in particular had no answer: which run burned the tokens, whether they genuinely ran at the same time or merely started together, and whether two of them had quietly edited the same file.

That last one is the expensive question. An agent working on the wrong file looks exactly like an agent working on the right one, right up until you read the diff.

The thing that was already true

Every one of those runners writes a transcript to disk while it works. Claude Code does. So do Cursor, Codex, Gemini CLI, Copilot CLI and Kiro. The record of what happened was sitting in my home directory the entire time, in six different formats, none of which I had ever looked at.

So runlanes does not wrap anything. There is no SDK, no instrumentation step, no account, and nothing to start before the run starts. It reads what the runner already wrote.

The consequence is the part I did not expect to matter as much as it does: it works on runs that already finished. Most tools in this space need you to have decided, in advance, that this particular run was worth watching. This one can answer a question you only thought to ask afterwards.

npx runlanes

That opens a console on 127.0.0.1:4180 for whatever project you are standing in. There is no configuration file to write first.

What it actually shows

Now is every live session, across every runner it found, with what the main conversation spent against what it handed to subagents. On the session that motivated the whole thing, that split was 8.3 million tokens of conversation against 2.1 million delegated, which was not the ratio I would have guessed.

The parallelism figure is the one I keep coming back to. Peak concurrency was four agents. The share of elapsed time where anything genuinely overlapped was 9%. Four agents were running, and for 91% of the wall clock they were politely taking turns. Nobody reports that number, and it changes how you plan a fan-out.

Graph links runs to the files that more than one of them touched.

The distinction that makes this worth having: an edge exists because a run opened that file. Not because a prompt said it would. Those are different claims, and only one of them is evidence.

History is every session found for the project, with spend and agent time. Docs is the plans, skills and agent instructions sitting beside the project, which turn out to be the thing you most want to read when a run has gone sideways.

Refusing to make numbers up

Kiro bills in credits, not tokens. Its transcripts record which files were touched and which documents were read, and no usage at all.

The console shows a dash.

It would be trivially easy to show 0 there. It would also be a lie of the most ordinary kind, the sort that makes a dashboard feel authoritative and quietly poisons every total on the page. An unmeasured run is not a free run. It is left out of the sums rather than counted as nothing.

The same instinct runs through the token arithmetic. Tokens counted are input plus output plus cache creation. Cache reads are deliberately excluded, because they re-report the entire prompt on every single turn, and summing them across a session counts the same context dozens of times and produces a number several times larger than anything that happened. They are still included in cost, because they are still billed. Those are two different questions and the tool answers them separately.

The claims are tests, not sentences

runlanes reads local files, makes no outbound network calls, and binds to 127.0.0.1. Every tool in this category says something like that in its README.

The difference here is that CI fails the build if any of it stops being true. There is a step that greps the source for fetch, axios and https.request and fails if it finds one. A step that asserts 127.0.0.1 still appears in the server. A step that fails if a runtime dependency ever appears, which is how the dependency count stays at zero rather than aspirationally low. And one that fails if a vendor name leaks outside the adapter directory, which is what keeps six runners from turning into six special cases scattered through the app.

A README claim is a sentence somebody wrote once. A CI step is a claim that has to survive every commit. I would rather ship the second kind.

Where the package came from

Published from GitHub Actions through OIDC trusted publishing, so npm records the commit, the workflow and the runner that built the tarball. npm audit signatures reports a verified attestation, and anyone can check that what is on npm matches what is on GitHub. Sigstore signs it with a certificate that lives about ten minutes and files the record in a public transparency log, so there is no long-lived signing key to steal.

For a tool whose entire argument is "these numbers survive checking", it seemed inconsistent to ask anyone to take the tarball on faith.

The demo is the product

runlanes --export writes the whole console to a single self-contained HTML file. The live demo is that export, rebuilt by CI whenever the source changes. It is not a screenshot and not a mock, which means a change that breaks the console breaks the demo in CI before it reaches anybody.

The demo also says in its first line that its runs are staged. A tool arguing that its numbers can be checked should not open with invented data presented as real.

It was called something else

This shipped as "agenttrace" for about a fortnight. Then I looked properly, and five published CLIs already install a binary by that name, one of them with a near-copy of my own opening line in its README.

The registry entry was still free. Taking it would have meant winning the package name while losing the command name, the search result and the repository name, which is losing three arguments to win one.

"runlanes" is also just a better description. The timeline draws one lane per run, and whether those lanes overlap is the entire question.

Try it

npx runlanes

MIT, Node 18 and up, zero runtime dependencies, 95 tests running on Node 18, 20 and 22. The source is on GitHub and the package is on npm.

If you run more than one agent at a time, the data is already on your disk. This just reads it.

FireMigrate: leave Firebase for Postgres without dumping everything into JSON

Tue, 22 Sep 2026 04:51:20 +0000

It’s a small MIT CLI. The interesting work is still open.

Most Firebase → Postgres guides do the same thing: export the project, stuff documents into a jsonb column, call it migrated. You kept the data and lost the shape.
FireMigrate does the opposite. It reads Firestore and Firebase Auth first, prints a relational schema you can argue with, and refuses to write until you say so.

npx @ezekielreu6/firemigrate init
npx @ezekielreu6/firemigrate inspect
npx @ezekielreu6/firemigrate schema
npx @ezekielreu6/firemigrate migrate --dry-run

Website
npm
Repo

Why this exists
Firestore is a document store. Postgres is tables, types, and foreign keys. A real move has to admit uncertainty:
this field is a string in 80 documents and a number in 4
this userId looks like a reference
this collection has nested subcollections the sample never saw
FireMigrate treats those as warnings, not as something to hide in JSON.
What it does today
The package on npm is @ezekielreu6/firemigrate (currently 0.1.3). MIT. CLI-first. Node 20+.
Command

What actually happens

init
Writes firemigrate.config.json and .env.example. Will not overwrite unless you pass --force.
inspect
Read-only. Collection counts, sampled field types, mixed-type warnings, Auth provider summary.
schema
Prints Postgres SQL. One table per top-level collection. Mixed/maps/arrays → jsonb. Timestamps → timestamptz.
migrate --dry-run
Default. Streams documents, reports counts, writes nothing.
migrate --write
Only if the flag and "dryRun": false are set. Creates tables, upserts by id in batches, then checks row counts.

verify

Compares Postgres row counts to Firestore document counts.
Credentials live in env vars (FIREBASE_PROJECT_ID, FIREBASE_CLIENT_EMAIL, FIREBASE_PRIVATE_KEY, DATABASE_URL). The config file starts empty on purpose. Do not commit service-account keys.
What is still sharp (this is the contributor pitch)
This is an early foundation, not a complete migration product. That is the point of the repo.
Open work, if you want a useful PR:
Subcollections — detected, not migrated. Need a mapping that becomes real tables instead of a JSON blob.
Better relationship guesses — name-based FKs should stay warnings until confidence is high. Improve the analyzer, don’t silently emit fake constraints.
Auth users — inspect already summarizes providers. Actual Auth → Postgres (no plaintext passwords) is unbuilt.
Storage — not covered.
Sample bias — schema is inferred from up to 100 docs/collection (max 1000). Fields outside the sample get dropped and reported. Smarter sampling would help.
Tests — domain tests for inspect/schema/migrate, with fake fixtures and no real credentials.
Docs of edge cases — mixed types, colliding id fields, paused writes, verify mismatches.
What we will not merge: a PR that writes to the destination by default, logs private keys, or fakes inspect output.

Repo shape

packages/core inspect, schema, migrate, verify
packages/cli the firemigrate binary
Local loop:
pnpm install
pnpm build
node packages/cli/dist/packages/cli/src/index.js inspect
Small PRs. One adapter or one workflow change at a time. Keep dry-run as the default.
If you only have 20 minutes
Run init + inspect on a throwaway Firebase project. File an issue with:
what the inspect report got wrong
a redacted collection shape (field names + types, not documents)
what you expected the schema to look like
That kind of issue is more useful than a star.
If you want to implement something, open the issue first so two people don’t build the same subcollection mapper.
FireMigrate is for people who are leaving Firebase on purpose, not for people who want a magic dump. If that sounds like work you already do, the repo is here:
Repo

agentsmyth

Thu, 17 Sep 2026 19:31:38 +0000

Picture the last thing an AI agent built for you. The diff landed. It probably worked. Now answer three questions without scrolling back: which requirement did line 40 satisfy, what did you decide against and why, and what evidence proved it worked.

If you cannot, you did not lose the code. You lost everything around it.

agentsmyth exists to keep everything around it.

It is a portable AI engineering lifecycle, shipped as an npm package. You run one command, say one sentence to your agent, and the agent installs a gated seven-phase workflow into your repository. From then on, every non-trivial change moves through the same loop:

Requirements captured
Plan written
Code built
Reviewed
Tested
Shipped,
and reflected on, each phase leaving a

"durable file on disk".

Those files are the point.
Chat memory is smoke. It looks solid, then it is gone.

An artifact is steel: cold, inspectable, and still there when a different agent picks up the work three weeks later.

It is not a framework, not a linter, not an agent. It is a contract that the agent you already use agrees to follow.

Drop it into any repo; your agent drives it and leaves durable artifacts behind, not chat smoke.

Over the past two years, most of us relied on inline autocompletion or sidebar chat panels inside VS

Sun, 13 Sep 2026 12:48:35 +0000

Anthropic released Claude Fable 5.1 and Claude Code (a CLI-native agent operating directly inside bash/zsh). We put together an architectural deep-dive analyzing context caching, benchmarks, and terminal pipeline mechanics.

Key Technical Points:

Cache Read Economics:
Prompt cache reads are reduced by 75% ($0.25 per million tokens), cutting real-world agentic execution costs by ~45%.

CLI Operating Perimeter:
Runs as a native OS process rather than an IDE plugin. It parses stdout/stderr from test runners (jest, pytest), inspects uncommitted git diff states, and handles file I/O.

Persistent State (CLAUDE.md):
A repo-root configuration file acts as an architectural memory layer for build commands, lint rules, and stack constraints.

Benchmarks:
Scored 1,662 Elo on the AA-Briefcase Index for multi-week knowledge tasks.

Full breakdown with CLI installation guides and a production CLAUDE.md setup:
www.thefluxread.com

OpenAI Agents API (Public Beta) Breakdown: Managed Infrastructure vs Custom Orchestration

Sat, 12 Sep 2026 15:00:06 +0000

OpenAI launched its Agents API in public beta, exposing the managed harness behind Codex and ChatGPT for Work.

Here is a quick dev-focused summary of what changed:

The Core Stack
Agent: Model + system instructions + defined tools.

Session: Maintains state across multi-turn jobs without cold starts.

Sandbox: Managed code execution layer (OpenAI, custom VPC, or 9 partners including Modal, E2B, Daytona, Vercel, Cloudflare).

Tools: Native support for MCP (Model Context Protocol) servers and custom functions.

Agents SDK vs. Agents API
SDK: Embedded directly inside your app logic. Maximum control over execution loops, but you maintain the infrastructure.

API: Managed service endpoint. Abstracted session persistence, context compaction, and subagent coordination, but less low-level control.

Current Tradeoffs
No ZDR (Zero Data Retention): Unusable for compliance-strict environments (finance, health).

Security: Autonomous execution across multi-day sessions still demands external guardrails and monitoring - managed infrastructure doesn't imply inherent application safety.

Full breakdown and evaluation: https://www.thefluxread.com/2026/09/openai-just-opened-its-agents-api-to.html

Catching AI Agent "Schema Drift" before production breaks 🛡️

Sat, 05 Sep 2026 01:13:31 +0000

Got challenged by a senior SRE recently: "Generating MCP configs isn't enough. You need to validate the runtime surface to prove reliability."

They were 100% right. Silent API changes (Schema Drift) are the #1 reason autonomous AI agents break in production.

So we built the SEOSiri Drift Detector.

Now, when you test an endpoint on our portal, it doesn't just ping the server. It executes a live JSON-RPC 2.0 handshake at the Cloudflare Edge and generates a timestamped, cryptographically tagged JSON Drift Receipt.

It captures:
✅ The exact edge gateway target
✅ The tools/list request snapshot
✅ The bounded response schema
✅ A cryptographic DRIFT_PROOF signature

You can download this receipt and plug it directly into your CI/CD pipelines to run automated diffs. If an upstream schema drifts, your pipeline catches it instantly. No manual monitoring required.

Check out the live sandbox and export a receipt yourself:
🔗 SEOSiri MCP Portal

ModelContextProtocol #DevOps #SRE #AIAgents #CloudflareWorkers #SEOSiri

Orchestrating Model Context Protocol in IDEs: The SEOSiri VS Code MCP Manager (v1.0.2)

Fri, 28 Aug 2026 16:15:26 +0000

If you are running multi-server Model Context Protocol (MCP) setups across Cursor, Claude Desktop, and VS Code, you already know the friction: syntax errors in mcp.json, mismatched npx vs uvx arguments, un-sandboxed extension permissions, and zero visibility into remote edge health.

To solve this, we engineered and open-sourced seosiri-vscode-mcp-manager (now live on the Visual Studio Marketplace):

🛠️ What it does under the hood:

vscode_generate_mcp_config: Auto-compiles validated .vscode/mcp.json and claude_desktop_config.json snippets for zero-setup execution.
vscode_audit_extension_manifest: Audits package.json extension manifests for activation triggers and permission leaks.
vscode_sync_workspace_settings: Synchronizes linters, TypeScript configs, and approved MCP tool lists across development teams.
vscode_inspect_live_gateways: Real-time sub-10ms health and latency checks across Cloudflare Workers edge nodes (vscode.seosiri.com).

📦 Lightweight Architecture:

Bundled with esbuild down to 73 KB (single-file CJS runtime, zero bloated node_modules in the VSIX bundle).

VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=SEOSiri.seosiri-vscode-mcp-manager
Architecture Guide: https://www.seosiri.com/2026/08/vscode-mcp-manager.html
Developer Portal & Topology: https://developers.seosiri.com/

Would love feedback from engineers building autonomous agents and custom MCP tools!

Built an MCP server nobody can find?

Tue, 28 Jul 2026 07:05:40 +0000

We run a curated MCP Registry on AgentShare — for developers and builders who want distribution, not another dead directory.

List your MCP and you get:

A public profile page on the hub (reviewed before publish)
Open analytics — see how often people click through to your MCP
Traffic breakdown — referrers, countries, client types (browser vs bot vs MCP client)
A path for AI agents to discover and connect to your server
Registration is human-reviewed today (quality + safety). The stack is being built so agents can self-register their own MCPs soon — still with review on our side.

Submit your MCP: https://agentshare.dev/registry#submit
Browse the registry: https://agentshare.dev/registry

Building the agent economy — one listing at a time.

What Self-Hosting a Workflow Engine Actually Costs You

Sun, 26 Jul 2026 14:30:00 +0000

Every automation conversation reaches the same fork: pay per execution on someone else's runtime, or run it yourself. The honest version of that decision is not about ideology, it is about which costs you are willing to see as a line item and which ones you would rather absorb as your own time. Here is what self-hosting a workflow engine actually costs, using the one we build and maintain as the worked example.

One PHP Application and One SQLite File

Workflow Chain Engine is deliberately small. The whole system is one PHP application with a single SQLite file, no framework, no build step, and no dependency install, so it runs on a three dollar shared host as happily as on a VPS or in a container. The visual editor ships inside the project, so nothing loads from anyone else's servers while you work.

That shape decides the operating cost. Backups are a folder copy. Moving hosts is a folder copy. There is no queue service to keep alive, no database server to tune, and no upgrade that needs a migration weekend. The code is MIT licensed and lives on GitHub, so the version you run is the version you can read.

Four Triggers, One Run History

A flow is only useful at the moment it starts, and there are four of those: a webhook another service calls, an authenticated run API for your own code, a schedule, and a button. All four fill the same workflow variables from whatever they carry, and all four land in the same run history.

One webhook detail is worth stealing no matter what you run. The response carries the run's real result, meaning the resolved success or fail message with its variables filled in, the step count, the run ID and the duration. Services that display webhook responses then show something meaningful, and services that retry on failure can react to a genuine Fail instead of guessing from a status code.

Where Self-Hosting Actually Bites

The server is not the hard part. Observability is. A hosted product hands you run history, alerting and retries as table stakes, and the moment you self-host those become things you have to insist on. Every node in our engine logs after the placeholders resolve, so a run detail shows the real URL that was called, the real comparison that was made, and the value each variable ended on. That is the difference between a two minute fix and an afternoon spent reproducing a failure.

The second real cost is credentials. They now live in your database, which is exactly why some teams self-host and exactly why others should not. If nobody owns rotating them, self-hosting moved a risk rather than removing one.

Who Should Not Bother

If your workflows are mostly connectors between large SaaS products, the volume is modest, and nobody on the team wants to own an upgrade path, pay the per-run price and get on with your work. Self-hosting earns its keep when data cannot leave your environment, when execution volume makes per-run pricing look silly, or when you want the workflows themselves as artifacts you version alongside the rest of your infrastructure.

What To Take Away

Self hosting is not cheaper by default. It is cheaper when the things you need most are control over your data, predictable cost at volume, and a run log you can actually read. Judge any engine on that last one, ours included, by looking at what it tells you after a run fails rather than how the editor looks when everything works.

Full documentation, the six node types, and the source.

A Practical Guide to Model Context Protocol (MCP) Servers for AI Developers

Mon, 20 Jul 2026 15:11:35 +0000

As AI agents become more capable, they also need a standardized way to interact with APIs, databases, files, developer tools, and external services. That's where the Model Context Protocol (MCP) comes in.

To help developers explore the ecosystem, I put together a practical guide covering:

🔹 What Model Context Protocol (MCP) is
🔹 Why MCP Servers are important for AI applications
🔹 Popular open-source and enterprise MCP Server implementations
🔹 Security and authentication considerations
🔹 Common deployment approaches
🔹 Real-world use cases for AI agents, SaaS platforms, and developer tools

The goal is to provide a concise reference for developers evaluating or implementing MCP-based architectures.

📖 Read the guide:
https://www.seosiri.com/2026/07/seosiri-mcp-servers.html

I'm interested in hearing from the community:

Have you integrated an MCP Server into your AI projects?
Which implementation has worked best for your use case?
What challenges or lessons have you encountered?

Constructive feedback and additional resources are always welcome.

Why Local Webhook Testing Still Feels Broken

Wed, 15 Jul 2026 05:29:04 +0000

Building webhook integrations shouldn't require deploying your application every time you make a change.

One of the first things you discover when working with webhooks is that your local development environment isn't reachable from the internet.

Your application might be running perfectly on localhost:3000, but webhook providers like Stripe, GitHub, Clerk, Shopify, or Discord can't send requests to your machine.

So the usual workflow begins.

Start a tunnel.

Copy the public URL.

Update the webhook endpoint in the provider dashboard.

Restart the tunnel.

Copy a new URL.

Update the provider again.

Repeat.

It works.

But after doing it dozens of times across different projects, it starts to feel like unnecessary friction.

Local Development Shouldn't Slow You Down

When you're building a webhook integration, the goal is to iterate quickly.

Receive an event.

Inspect the payload.

Change some code.

Try again.

Instead, developers often find themselves spending just as much time managing tunnel URLs as writing application logic.

A tunnel expires.

The URL changes.

Every webhook provider now needs to be updated.

If you're integrating with multiple services at once, that overhead grows quickly.

It's a small problem that becomes surprisingly repetitive.

Tunnels Are More Than Just Public URLs

Most people think of a tunnel as a way to expose localhost.

That's true.

But for webhook development, it's also the bridge between your local application and the outside world.

It allows you to receive real production-like events without deploying your application every time you want to test a small change.

That feedback loop matters.

The faster you can receive, inspect, and replay events, the faster you can build reliable integrations.

Why I Built Tunnels into Hooktrace

While building Hooktrace, I realized developers were already using one tool to expose localhost and another to inspect webhook deliveries.

That felt fragmented.

Hooktrace already understands webhook events.

It already captures requests, payloads, headers, retries, and delivery timelines.

Adding tunnels means developers can expose a local endpoint and immediately start inspecting events from the same platform.

No context switching.

No juggling multiple dashboards.

Just one place to receive, inspect, debug, and replay webhook traffic.

It's Not About Replacing Existing Tools

There are already excellent tunneling tools available, and I've used many of them myself.

The goal isn't to replace them.

The goal is to make the webhook development experience feel more connected.

Instead of thinking about tunnels, event inspection, retries, aggregation, destinations, and observability as separate tools, I think they should work together.

That's the direction I'm taking with Hooktrace.

Building Hooktrace in Public

Every feature I build starts with a problem I've run into while building integrations or backend systems.

Sometimes it's webhook observability.

Sometimes it's event aggregation.

Sometimes it's routing events to different destinations.

This week, it was local webhook testing.

I'm documenting that journey in public—not just the finished product, but the engineering decisions, trade-offs, and lessons learned along the way.

If you're building event-driven systems or working with webhooks every day, I'd love to hear how you're solving these problems.

Good developer tools are shaped by real developer feedback.

Follow Along

I'm building Hooktrace in public and sharing the engineering journey one feature at a time.

🌐 Hooktrace: https://hooktrace.xyz

💻 Portfolio: https://www.codilad.dev

⭐ GitHub: https://github.com/hooktracehq/hooktrace

𝕏 Follow the build: https://x.com/yasirbuilds

Thanks for reading.

🚀 Get 5 Lifetime Production Projects for Free. Announcing Beta 1 of Thinking Differently.

Wed, 24 Jun 2026 20:20:55 +0000

For the past few months, I’ve been obsessing over a single problem: Why does building high-performance, multi-tenant backends still come with so much architectural friction, messy database bottlenecks, and unpredictable orchestration?

I built Thinking Differently to fix that. It’s a Backend-as-a-Service engineered with an absolute obsession for ipmact on the user

We are officially opening our doors for Beta 1, and we’re looking for developers who want to push our infrastructure to its limits.

🎁 The Founding Developer VIP Bonus:
The standard public tier will eventually cap free accounts at 2 active projects. But as an early adopter in Beta 1, your account will be permanently grandfathered into our Founding Developer Tier:

⚡ 5 Active Projects Slots (Instead of 2)
🏎️ Priority Rate Limits (60 req/min clean bucket to build smoothly)
🛌 Extended Project Windows (Your side-hustles won't be aggressively put to sleep)
🛠️ Direct Engineering Channel (Direct access to me to request custom features/endpoints)

⚠️ The Catch? I don't want passive sign-ups. I want builders who will write messy code, trigger rapid frontend refreshes, spin up client MVPs, and tell me the exact millisecond our API lags.

Ready to build differently?

👇 Grab one of the limited Beta slots here:
https://docs.google.com/forms/d/e/1FAIpQLSenXYnC9scSGY4_8YAoH6wB3KhzmgrqW8EHrextuPqPL8Fhrw/viewform

Your Password Strategy Is Probably Broken. Here's What Actually Works.

Wed, 17 Jun 2026 15:26:13 +0000

Let me guess your password strategy.

You have a "base" password — something memorable, maybe with a capital letter and a number at the end — and you reuse it across most sites with minor variations. MyDog2019! here, MyDog2019# there. Maybe you add the site name somewhere: MyDogNetflix2019!. Feels secure because it's complex. Feels manageable because you can actually remember it.

This strategy is broken. Not "slightly suboptimal" broken. Actually broken, in ways that have real consequences.

Here's why — and more importantly, here's what the alternative actually looks like in practice.

The Problem With Memorable Passwords

Memorable passwords have one fatal flaw: they're guessable. Not necessarily by someone who knows you personally, but by the automated systems that attackers use to crack passwords at scale.

When a database gets breached — and breaches happen constantly, to companies you've definitely used — the stolen password hashes get fed into cracking tools that try billions of combinations per second. These tools don't guess randomly. They use wordlists, common patterns, known password formats, and permutations of all of the above.

MyDog2019! isn't in a wordlist literally. But "common word + year + symbol" is absolutely a pattern these tools know about. They'll try every word in a dictionary combined with every year from 1950 to 2030 combined with every common symbol. Your password gets cracked. And because you reused variations of it, multiple accounts go down at once.

The other problem: sites you used five years ago that got breached five years ago are still circulating in credential dumps. Your old password — even if you've changed it on the big sites — might still be working credentials on some forum you signed up for once and forgot about. Attackers try those credentials against every major service automatically. This is called credential stuffing, and it works surprisingly often.

What "Actually Secure" Looks Like

A genuinely secure password has three properties:

Long. Length beats complexity every time. correct-horse-battery-staple is harder to crack than P@ssw0rd! despite being easier to type, purely because of length. The math on brute force attacks makes longer passwords exponentially harder to crack regardless of character set. Most security researchers now recommend 16+ characters as a minimum for anything important.

Random. Not "random-ish" — actually random. Human-generated "random" passwords have patterns. We gravitate toward certain characters, avoid others, put numbers at the end, capitalize the first letter. Real randomness comes from a cryptographically secure random number generator, not from a human trying to think of something unpredictable.

Unique. One password per site, no exceptions. This is the one people resist most because it seems impossible to manage. It's not impossible — it just requires a password manager, which we'll get to.

Generate One Right Now

The free Password Generator at sadiqbd.com/developer/password-generator creates cryptographically random passwords instantly — you set the length, choose which character types to include (uppercase, lowercase, numbers, symbols), and it generates a genuinely random password client-side in your browser. Nothing gets sent to a server. Nothing gets logged.

Try generating a few 20-character passwords and notice something: they look completely different from anything you'd ever come up with yourself. No recognizable words, no patterns, no structure your brain would naturally produce. That's exactly the point. That randomness is what makes them secure.

The Character Set Question

People agonize over which characters to include and the answer is: as many as the site allows, within reason.

Uppercase + lowercase + numbers gives you a character set of 62. Add symbols and you're at 94+. Every character you add multiplies the total possible combinations. For a 16-character password, the difference between a 62-character set and a 94-character set is massive — billions of times more combinations.

The practical caveat: some sites have terrible password policies that limit length (anything under 16 characters is a red flag in 2026) or ban certain symbols (another red flag — it often means they're storing passwords in a way that makes certain characters problematic, which suggests their password handling is suspect). Work with what the site allows, but if a site caps you at 8 characters or bans symbols, that's worth noting as a signal about their security practices.

You Need a Password Manager. Full Stop.

Here's the part people always push back on: "I can't remember random unique passwords for every site."

Correct. You're not supposed to. That's what a password manager is for.

A password manager stores all your passwords encrypted behind one master password. You remember one strong passphrase — something long and memorable, like correct-horse-battery-staple style — and the manager handles everything else. It generates passwords, stores them, and autofills them. You never have to type MyDog2019! again.

Good options that are widely used: Bitwarden (open source, free tier is genuinely good), 1Password (excellent UX, paid), KeePassXC (fully local, nothing in the cloud). Each has tradeoffs but all of them are dramatically better than the alternative.

The common objection is "what if the password manager gets breached?" It's a fair concern. The answer: reputable password managers store an encrypted vault, not plain-text passwords. Even if their servers get breached, what attackers get is your encrypted vault, which is useless without your master password. Bitwarden has had a security audit. 1Password has had security audits. Compare this to your current strategy, where a breach of one site potentially exposes variations of your password across dozens of others.

Two-Factor Authentication Changes the Math

Even a weak password becomes dramatically harder to exploit if you have 2FA enabled. Even a strong password benefits from 2FA as a backup.

The hierarchy, roughly:

Unique strong password + 2FA (authenticator app, not SMS) — excellent
Unique strong password, no 2FA — good
Reused password + 2FA — mediocre (credential stuffing still works until 2FA catches it)
Reused password, no 2FA — what most people are actually doing, what attackers rely on

SMS 2FA is better than nothing but has real weaknesses — SIM swapping attacks can intercept SMS codes. An authenticator app (Google Authenticator, Authy, or built into your password manager) is meaningfully more secure than SMS.

For Developers Specifically

If you're building something, a few things that matter here:

Never roll your own password hashing. Use bcrypt, Argon2, or scrypt. Not SHA-256, not MD5, not any fast hashing algorithm — those are designed to be fast, which is exactly wrong for password hashing. You want slow. The sadiqbd toolkit has a Bcrypt Generator if you need to test hash outputs.

Enforce reasonable password policies without being annoying. Minimum 12 characters, allow all printable ASCII, don't force regular rotation (forced rotation leads to weaker passwords, not stronger ones — NIST updated their guidelines on this years ago). Don't cap length at 20 or 32 characters — there's no technical reason to do this and it penalizes password managers.

Check against known breached passwords. The HaveIBeenPwned API (haveibeenpwned.com/API) lets you check if a password appears in known breach data without sending the actual password. It uses a k-anonymity model — you send the first 5 characters of the password's SHA-1 hash, get back a list of matching hashes, and check locally. Integrating this into your signup flow costs maybe an hour of work and meaningfully improves your users' security posture.

The Bottom Line

Password security isn't complicated in theory. Long, random, unique passwords managed by a password manager, with 2FA on everything that supports it. That's the whole strategy.

The gap between knowing this and actually doing it is mostly inertia. The password manager setup takes an afternoon. Migrating your existing passwords happens gradually as you visit sites. Within a month you're essentially fully migrated without it feeling like a big project.

Start by generating a few passwords at sadiqbd.com/developer/password-generator to see what genuinely random looks like. Then pick a password manager and set it up this week. Future you — especially future you dealing with a compromised account at the worst possible time — will appreciate it.

Your Folder Tree Is Already a Context Engine

Sun, 14 Jun 2026 03:55:48 +0000

Most developers think of a folder tree as a way to organize files.

For AI systems, it can be much more than that.

The Interpret-able Context Methodology (ICM), also known as the Model Workspace Protocol (MWP), introduced by Jake Van Clief and David McDermott, explores how structured project workspaces can improve AI reasoning and navigation.

My article explores this idea further and introduces MWP-Tool, an experimental visualization layer that transforms a repository into a navigable terrain map. The objective is to help AI agents and developers discover context through project structure instead of relying solely on larger prompts or increasingly complex retrieval systems.

If the repository already contains hierarchy, relationships, and intent, perhaps the folder tree itself is one of the most valuable context artifacts we have.

mwp-tool repository

Meta-Architect

Sat, 06 Jun 2026 01:25:28 +0000

Acknowledge to @OpenAI Thanks for delivering this skills into reality

Most AI tools look impressive in demos. Very few feel usable when you actually install them. Meta Architect v0.1.13 changes that — 33 plugins, a live demo, and a cleaner path from install to first skill.

I've just shipped the most complete release of the Codex skills bundle yet, with a real demo, a restructured onboarding story, and 33 documented plugins and features across the full skill surface.

Repository: https://github.com/JustineDevs/meta-architect

Why this release matters v0.1.6 was about coherence getting the packaging, identity, and install story right. v0.1.13 is about showing the product clearly and making it easier to trust.

The gated lane sequence hasn't changed. But everything around it has: the manager is smarter, there are more skills to reach for, the install surface covers more platforms, and the README now leads with a live demo and a capability table instead of release-maintainer details.

If v0.1.6 was "ready enough for people who want to use it in anger", v0.1.13 is "ready enough for people who want to understand it in 30 seconds and then use it in anger".

What v0.1.13 focuses on A real demo, not static copy

The README now opens with a live demo GIF that shows install, $maestro orchestration, Obsidian brain context, learning reliability, environment awareness, Ralph handoff, and release verification — with real runtime functions, not screenshots of documentation.

Cleaner onboarding path

The README now leads with:

Install command

Demo media

Capability summary table

Grouped feature inventory (expandable)

Long-form release-maintainer details are collapsed into blocks. A first-time viewer can follow the product story without wading through packaging rules.

"What You Get"

capability table A new top-level table makes the full surface scannable at a glance:

An expandable section now lists every plugin and feature across six categories: Core & Orchestration, Memory & Knowledge, Intelligence & Learning, Code Quality & Testing, Security & Compliance, Architecture & Methodology, DevOps & Observability, and Extensibility.

How you use it

Visit Setup Guide

Who this helps For developers

The demo shows the full workflow end-to-end before you install anything
The helper skills give you targeted tools between gates — alignment, diagnosis, test scaffolding, cleanup — without disrupting release state
ma setup / ma bootstrap / ma doctor remove the manual setup friction that tripped people up in earlier versions

For new architects

$maestro as a bounded autonomous manager means you can ask it to choose the next step rather than tracking the sequence yourself
The "What You Get" table and 33-plugin inventory give you a map of the surface before you start

For experienced architects

The gate model is explicit: CLEAR, APPROVED, VERIFIED, PARTIAL, GREEN,
RED, WAIVED, LOCKED, READY — each status has a defined meaning and a
defined effect on what is allowed next

Evidence must come from repository-form GitMCP endpoints. A generic docs endpoint does not count as VERIFIED for build unlocking

The Redaction Gateway, MCP policy, and exposure catalog give you explicit control over what context crosses trust boundaries

I'm especially interested in feedback from people who:

are running the gated sequence on real projects and hitting edge cases
want to use the helper skills ($align, $diagnose, $tdd, $cleanup) and have opinions on where they fall short
are on Linux and trying the native package install path for the first time
watched the demo and found something that didn't match what the runtime actually does

If that's you, the repo is here: https://github.com/JustineDevs/meta-architect

The Real Reason Developers Love Dark Mode

Sat, 30 May 2026 09:33:14 +0000

If you've ever walked into a room full of developers, you'll notice something interesting.

Almost every screen looks the same.

Dark background.

Colorful code.

A setup that makes the room look like a hacker movie

And naturally, the question comes up:

Why do developers love Dark Mode so much?

Is it better for coding?

Does it improve productivity?

Or is there another reason?

Let's investigate

The Official Reason

Ask a developer why they use Dark Mode and you'll usually hear:

Less eye strain
Better focus
More comfortable at night
Easier to look at for long hours

And honestly...

These reasons are valid.

If you're staring at code for 8 to 10 hours a day, a bright white screen can feel like staring into the sun.

Especially at 2 AM during a production issue

The Unofficial Reason

Let's be honest.

Dark Mode looks cool.

There, I said it.

A terminal with green text on a black background just feels more powerful.

Even if you're only running:

npm install

For a few seconds...

You feel like you're breaking into the Pentagon.

You're not.

But it feels that way.

The Developer Transformation

Normal person:

Opens laptop.

Checks email.

Closes laptop.

Developer:

Opens laptop
Opens 17 tabs
Opens VS Code
Opens terminal
Switches everything to Dark Mode
Suddenly becomes a software engineer

Coincidence?

I think not.

⚡ Dark Mode and Productivity

Now here's the funny part.

Many developers genuinely believe:

Dark Mode = Better Code

Reality?

Your bugs don't care.

The bug that took 4 hours to find in Light Mode...

Will happily take 4 hours in Dark Mode too.

Technology has limits

Dark Mode Is Basically a Developer Starter Pack

Along with:

Mechanical keyboard
Multiple monitors
Coffee
Too many browser tabs
Stack Overflow open somewhere

Dark Mode is practically mandatory.

Nobody officially says it.

But everyone knows.

The Real Benefit

Jokes aside...

Dark Mode can actually help during long coding sessions.

Many developers find it:

More comfortable
Less distracting
Easier on the eyes in low-light environments

The key word is:

Many

Not everyone.

Some developers genuinely prefer Light Mode.

And surprisingly...

They still write good code.

Shocking, I know.

The Great Developer Debate

Few topics start arguments faster than:

Tabs vs Spaces
Vim vs VS Code
Mac vs Windows
Light Mode vs Dark Mode

Entire friendships have survived these debates.

Barely.

The Truth Nobody Wants to Hear

Dark Mode doesn't make you a better developer.

It doesn't improve algorithms.

It doesn't fix production bugs.

It doesn't reduce technical debt.

Unfortunately.

What it does do is make your environment more comfortable.

And sometimes that's enough.

Final Thought

The real reason developers love Dark Mode?

Partly comfort.

Partly habit.

Partly aesthetics.

And maybe...

Just maybe...

Because staring at a glowing dark screen filled with colorful code makes us feel like we're building the future.

Even when we're spending three hours debugging a missing semicolon

Team Dark Mode or Team Light Mode?

Be honest.

And remember:

This discussion is completely civil and never starts arguments... right?

Developers #Programming #SoftwareEngineering #DarkMode #DeveloperLife #CodingHumor

Why Modern Browsers Deserve Better Developer Tools

Tue, 26 May 2026 19:39:59 +0000

Most developers still treat the browser like a lightweight preview window.

But modern browsers already power:

Figma
VS Code Web
AI applications
GPU rendering
WebAssembly runtimes
Real-time collaboration platforms

So why does the average online IDE still rely on slow cloud containers and loading states?

That question pushed me to build NitroIDE.

NitroIDE is a browser-native, Monaco-powered online code editor focused on zero-latency frontend development. Instead of routing every action through remote infrastructure, NitroIDE executes directly inside the browser for an instant live preview experience.

The goal wasn’t to build “another code playground.”

The goal was to make browser-based development feel immediate, lightweight, and modern again.

If you work heavily with frontend prototyping, HTML/CSS/JS experimentation, or rapid UI iteration, I’d genuinely love feedback from other developers here.

Still early. Still improving every day.

Building A Laravel Google Sheets Package That Imports, Exports, Caches, Formats, And Tests Cleanly

Wed, 20 May 2026 15:09:00 +0000

Google Sheets often starts as a quick operational tool. A support team tracks users in a sheet, finance exports monthly reports, or an internal dashboard needs a simple spreadsheet backend. The challenge is keeping that workflow Laravel-friendly once it grows beyond a few API calls.

This package wraps the Google Sheets API with a fluent Laravel API for common application tasks: importing rows, exporting reports, managing multiple spreadsheet connections, caching reads, formatting tabs, and testing without hitting Google.

Installation

composer require olamilekan/laravel-google-sheets
php artisan vendor:publish --tag=google-sheets-config

Add your service account credentials path:

GOOGLE_SHEETS_CREDENTIALS_PATH=/path/to/service-account.json

Then configure named spreadsheet connections:

'sheets' => [
    'users' => [
        'spreadsheet_id' => env('GOOGLE_SHEETS_USERS_SPREADSHEET_ID'),
        'sheet' => 'Users',
    ],

    'reports' => [
        'spreadsheet_id' => env('GOOGLE_SHEETS_REPORTS_SPREADSHEET_ID'),
        'sheet' => 'Monthly',
    ],
],

Import Users From Google Sheets

For a simple import, read rows from a named connection:

$rows = GoogleSheets::connection('users')->all();

For a reusable import, create an import class:

use App\Models\User;
use Olamilekan\GoogleSheets\Imports\SheetImport;

class UsersImport extends SheetImport
{
    public function rules(): array
    {
        return ['email' => ['required', 'email']];
    }

    public function model(array $row): User
    {
        return User::updateOrCreate(
            ['email' => $row['email']],
            ['name' => $row['name']]
        );
    }
}

Run it from code:

GoogleSheets::import(new UsersImport(), 'users');

Or from Artisan:

php artisan google-sheets:sync "App\\Imports\\UsersImport" users

Export Reports To Google Sheets

Export classes keep reporting logic out of controllers and commands:

use App\Models\Report;
use Olamilekan\GoogleSheets\Exports\SheetExport;

class ReportsExport extends SheetExport
{
    public bool $replace = true;

    public function headings(): array
    {
        return ['Date', 'Name', 'Total'];
    }

    public function collection()
    {
        return Report::query()
            ->latest()
            ->get()
            ->map(fn (Report $report) => [
                $report->created_at->toDateString(),
                $report->name,
                $report->total,
            ]);
    }
}

Then export:

GoogleSheets::export(new ReportsExport(), 'reports');

Header-Aware Appends And Upserts

Sheets usually have headers. Instead of manually ordering every cell, append associative arrays:

GoogleSheets::connection('users')->appendAssoc([
    ['name' => 'Alice', 'email' => '*Emails are not allowed*', 'role' => 'admin'],
]);

Upsert rows by a key column:

GoogleSheets::connection('users')->upsert('email', [
    ['name' => 'Alice Updated', 'email' => '*Emails are not allowed*', 'role' => 'owner'],
    ['name' => 'Bob', 'email' => '*Emails are not allowed*', 'role' => 'user'],
]);

Validation And Required Headers

Catch bad spreadsheet data before it reaches your app:

GoogleSheets::connection('users')->requireHeaders(['name', 'email', 'role']);

$rows = GoogleSheets::connection('users')->validate([
    'name' => ['required', 'string'],
    'email' => ['required', 'email'],
]);

Multi-Connection Workflows

Named connections make it easy to separate workflows:

$users = GoogleSheets::connection('users')->all();

GoogleSheets::connection('reports')->append([
    ['2026-05-17', 'Monthly Revenue', 15000],
]);

Caching

Enable caching with Laravel's cache system:

GOOGLE_SHEETS_CACHE_ENABLED=true
GOOGLE_SHEETS_CACHE_STORE=redis
GOOGLE_SHEETS_CACHE_TTL=600

Or turn it on per call:

$rows = GoogleSheets::connection('users')->enableCache(300)->all();

When writes happen, the package clears remembered read cache keys for that spreadsheet so later reads can refresh.

Formatting, Formulas, And Named Ranges

Reports often need more than raw data:

GoogleSheets::connection('reports')
    ->sheet('Monthly')
    ->boldHeader()
    ->freezeRows()
    ->autoResizeColumns(1, 4);

GoogleSheets::connection('reports')->append([
    ['Total', GoogleSheets::formula('SUM(C2:C100)')],
]);

$summary = GoogleSheets::connection('reports')
    ->namedRange('MonthlySummary')
    ->get();

Testing

You can fake Google Sheets in tests:

$fake = GoogleSheets::fake([
    'users' => [
        ['name' => 'Alice', 'email' => '*Emails are not allowed*'],
    ],
]);

GoogleSheets::connection('users')->appendAssoc([
    ['name' => 'Bob', 'email' => '*Emails are not allowed*'],
]);

$fake->assertAppended('users', ['name' => 'Bob', 'email' => '*Emails are not allowed*']);

Useful Commands

php artisan google-sheets:list users
php artisan google-sheets:clear reports --sheet=Monthly --range=A2:D100
php artisan google-sheets:sync "App\\Exports\\ReportsExport" reports

Closing

The goal is to make Google Sheets feel like a natural Laravel integration: fluent for simple reads and writes, structured for import and export classes, cache-aware for production use, and fakeable in tests.

The Meeting Nobody Could Follow -The format of AI output is a design decision.

Tue, 19 May 2026 06:58:44 +0000

Our team runs fast. Everyone uses AI — for code review, architecture decisions, issue triage, sprint planning. The individual work is solid. The outputs are good.

The problem shows up in the meeting.

Someone opens a PR and shares the AI-generated action plan in the standup. It is a .md file, 200+ lines, logically structured, accurate. The engineer who ran it knows exactly what is in it.

The two people looking at it for the first time are scrolling, skimming, trying to locate what matters while the conversation moves on.

Our lead eventually just asked:

“Can you highlight what’s actually blocking us right now?”

That was not a knowledge gap. Everyone in the room was technical. It was not a preparation gap either — the work had been done well.

The gap was between the person who had been living in that context and everyone else trying to enter it in 90 seconds from a flat text file.

That is a format problem.

And it compounds every time AI-generated work crosses from one person’s context into a shared one.

The Post That Reframed It

On May 8, 2026, Thariq Shihipar, an engineer on the Claude Code team at Anthropic, posted nine words on X:

“HTML is the new markdown. I’ve stopped writing markdown files for almost everything and switched to using Claude Code to generate HTML for me. This is why.”

The post linked to a companion site: 20 self-contained .html files, each one an agent-generated artifact covering a different category of engineering work.

No build step.
No framework.
Just a file you open in a browser.

The line that stopped us was from Thariq’s framing of the Code Review category:

“Diffs and call-graphs are spatial information; markdown flattens them.”

That was the exact problem we’d been circling for weeks without naming it. Our action plans weren’t hard to read because they were long.

They were hard to read because the information inside them was spatial — priority relationships, status changes, size deltas, dependency chains — and we were delivering it as a flat sequence of text.

Simon Willison, whose writing on developer tooling is widely followed, read the piece the same day and wrote that it caused him to reconsider his three-year default of asking for everything in Markdown.(3)

His note: Markdown won because of constraints — the 8,192-token GPT-4 era, where every character counted. Those constraints are largely gone. The reasoning that locked in the default hasn’t been re-examined.

That evening, we ran our own action plan through Claude with one change:

“Output this as a standalone HTML file with priority-coded sections, status badges, and a visual summary header.”

Thirty minutes of iteration.

The document we’d been failing to share effectively for weeks was suddenly something a new set of eyes could navigate in under a minute.

Why This Works: Source for Machines, Interface for People

Before going further, the actual rule is worth stating clearly, because the headline “HTML is the new markdown” gets misread.

This isn’t about replacing Markdown everywhere.

README files, commit notes, audit logs, agent-to-agent context passing — Markdown stays. It’s compact, diffable, searchable, and parseable without a browser. Those are real advantages that don’t disappear.

The shift is narrower: when AI-generated work reaches a human who needs to review, navigate, and act on it, Markdown hands the translation cost to the reader. HTML absorbs it into the document.

Karpathy replied to Thariq’s post with a practical note:

“This works really well btw — at the end of your query ask your LLM to ‘structure your response as HTML’, then view the generated file in your browser.”

He added the underlying reason: roughly a third of the human brain is dedicated to visual processing — the 10-lane superhighway of information into the brain. Audio is the preferred input to AI. Vision is the preferred output from it.

That is why the format question matters beyond aesthetics. If AI output is increasingly something people have to review, navigate, and act on quickly, then the container is no longer a neutral wrapper.

A February 2026 Harvard Business Review study tracked 200 employees at a U.S. tech company over eight months and found that AI adoption intensified work rather than reducing it — 83% reported it increased their workload. (5)

The study doesn’t prove a format problem by itself. What it describes is the broader environment in which format problems become expensive: workers moving faster, taking on broader scope, with less time per handoff.

In that environment, a document format that requires translation before action isn’t a minor inconvenience. It’s a recurring tax.

The 20 Examples: A Map Worth Keeping

So what does a better container look like in practice?

Thariq’s companion site at thariqs.github.io/html-effectiveness is worth opening in a separate tab.

It’s not a gallery — it’s a structured argument across 9 categories, each one showing where Markdown flattens information that HTML can spatialize.

Here’s the full map for reference. Skim it — it’s a map, not a reading list. The three categories that actually changed our workflow are below the table.

#	Category	What HTML replaces	Examples
01	Exploration & Planning	Sequential walls of text you try to hold in memory	Three code approaches side-by-side · Visual design directions rendered live · Implementation plan with timeline and risk table
02	Code Review	Flat diff output, call-graph prose	Annotated PR with margin notes and severity tags · PR writeup with file-by-file tour · Module map as boxes and arrows
03	Design	Token/component descriptions	Living design system with swatches · Component variants on a single sheet
04	Prototyping	Prose descriptions of motion and interaction	Animation sandbox with easing sliders · Clickable flow across four screens
05	Diagrams	Text-based flowcharts	SVG figure sheet · Annotated flowchart — click any step to see timings and failure paths
06	Decks	PowerPoint export, PDF	Arrow-key slide deck — one HTML file, no build step
07	Research & Learning	Linear explainer dumps	Feature explainer with collapsible steps and tabbed config · Concept explainer with live interactive ring
08	Reports	Weekly status emails, post-mortem docs	Weekly status with a small chart · Incident timeline with minute-by-minute breakdown
09	Custom Editors	Text-box instructions for spatial decisions	Ticket triage board · Feature flag editor with dependency warnings · Prompt tuner with live re-render

Code Review (02).
The annotated PR demo made the problem undeniable. Our action plans were spatial data — P0 vs P1 vs P2, open vs fixed, size deltas — delivered as a flat sequence. Moving to HTML turned priority into visual hierarchy, status into badges, and growth from 163 to 212 lines into an amber callout. The reviewer’s eye went to the right place without being guided there by more text.

Decks (06).
A handful of <section> tags and a little JavaScript becomes a slide deck you can arrow-key through in a meeting. No Keynote. No export. The charts can stay live, the regional breakdown can be filterable, and the presenter stops defending the format and starts defending the idea.

Custom Editors (09).
This is the category most people miss. It isn’t about pretty reports. It’s about asking for a throwaway interface for one specific decision — triaging tickets, toggling feature flags, tuning a prompt template — then exporting the result as structured Markdown for the next agent call. The loop gets tighter.

How We Applied It in Practice

The next step was turning the rule into a workflow.

We didn’t replace Markdown. We added an HTML render layer on top of it.

Every agent run now produces two files. The raw .md stays for version control, diffs, and agent context — passing HTML between agents adds token cost without value. The HTML is what the team opens.

The status bar at the top shows Open / Fixed / Partial counts at a glance. P0 items have a red left border and a pulse. Fixed items are muted. A function that grew from 163 to 212 lines shows the delta in an amber callout — visible without reading the note. The filter bar lets anyone drill to just the P0 items in one click.

Below is the representative example we use. Content has been generalized — no internal identifiers — but the structure, priority system, and status logic are exactly what’s in production.

PR Action Plan Dashboard

Same information. Different container.

One standup dropped from 25 minutes to 12. The questions changed from “wait, which ones are actually blocking?” to “who’s taking P0–1a?”

Beyond the PR: Every Document That Has to Survive a Room

The dev PR use case is where we started. It’s not where this ends.

Think about the last time you sat through a presentation built in PowerPoint. Someone had spent hours on slides, exported a PDF, shared it over email. Half the room opened it on their phones and couldn’t read the charts. The presenter spent the first three minutes explaining the color coding. Someone asked about a specific number and the answer was “I’ll have to check the spreadsheet.”

That’s the same problem. Spatial information delivered as a fixed object, forcing everyone in the room to translate before they can respond.

A quarterly review as a single HTML file looks different. The slides are still there — arrow-key navigation, no build step. But the charts are live. Each person hovers over the number they care about.

The regional breakdown is filterable. A response field at the bottom lets stakeholders flag a concern or submit a priority vote before leaving the page. That input comes back as structured data the next agent call can act on. The meeting doesn’t end with action items in someone’s notebook. It ends with a file.

This is what “sending a document” becomes when the format is HTML. A PDF is a fixed object. An HTML file is an environment. The person receiving it navigates it on their own terms — without matching your reading pace, your zoom level, or your familiarity with the data. And if you’ve built in the export button, what they do inside it comes back to you.

The pattern holds wherever AI-generated work has to cross a context boundary. A business proposal needing sign-off from people who weren’t in the original conversation. A research summary that has to land with someone from a different discipline.

A vendor comparison that three stakeholders need to filter differently. In each case, the question is the same: does the format help the next person enter the work, or does it make them translate it first?

The Tradeoff, Honestly

Every format shift moves cost somewhere. HTML is no exception.

HTML costs more to generate. For a document the size of our action plan, the HTML version runs approximately 4,200 tokens. The equivalent Markdown is around 1,150. That’s a 3.6× multiplier on output tokens.

At Claude Sonnet pricing as of May 2026, the delta is roughly $0.009 per document. At 100 documents per day, that’s about $0.90 extra per day — real, but not significant for most teams.

The more useful frame: one missed P0 finding costs more than a month of that overhead. The token cost is the price of a format that gets reviewed properly instead of skimmed and hoped at.

But token cost is only the first tradeoff.

Three rules keep the format honest.

Rule 1: HTML is for human review, not machine handoff.
HTML is not a good input for agent-to-agent pipelines. Keep Markdown for source, diffs, archives, and machine context. HTML earns its cost only at the human review surface.
Rule 2: visual authority is not factual authority.
A red P0 badge doesn’t mean the agent got the priority right. A well-structured HTML artifact can make a wrong AI output look more credible than a flat Markdown file would. Faster comprehension helps — it doesn’t replace judgment. The render layer should make review faster, not make the model more trusted.
Rule 3: interactivity needs a safety contract.
A useful HTML artifact should be self-contained, with no remote scripts, so it works offline and doesn’t phone home. It should use text labels alongside color and hover states, so it still works for color-blind readers and keyboard-only users. And if it re-enters an agent loop, it should run sandboxed, without external network access.

None of these are hard to ask for in the prompt. They’re worth adding to your template.

The Prompt Change

You do not need new tooling. One line at the end of your existing prompt.

Instead of:

“Generate a PR action plan covering all open issues by priority.”

Try:

“Generate a PR action plan covering all open issues by priority. Output as a standalone HTML file: color-coded priority badges (P0=red, P1=amber, P2=yellow), status indicators (OPEN/FIXED/PARTIAL), delta callouts for size changes, and a summary header with open and fixed counts.”

For code review, Thariq’s own prompt is worth borrowing directly:

“Help me review this PR by creating an HTML artifact that describes it. Render the actual diff with inline margin annotations, color-code findings by severity and whatever else might be needed to convey the concept well.”

The harder shift isn’t the prompt. It’s recognizing that the format of AI output is a design decision. We used Markdown for three years because that’s what the GPT-4 era trained us to expect. The models have moved. The context windows have moved. The use cases have moved.

The next bottleneck isn’t what the agent can generate. It’s whether the next person can enter it fast enough to act.

References

Thariq Shihipar, “The Unreasonable Effectiveness of HTML” — original X post, May 8, 2026
Companion examples site — 20 self-contained HTML artifacts across 9 categories
Simon Willison, link post and notes — May 8, 2026
Andrej Karpathy, reply to Thariq’s post — visual processing argument
Ranganathan & Ye, “AI Doesn’t Reduce Work, It Intensifies It” — Harvard Business Review, February 2026

How I Built and Deployed WebToolkit Pro: 40+ Free Client-Side Developer Tools in 2026

Sun, 17 May 2026 19:23:00 +0000

Introduction: The Need for Client-Side Tools

In early 2026, I got tired of using fragmented, bloated, and privacy-risky online developer tools. Every time I needed a JSON formatter, password generator, or meta tag tool, I had to sign up, deal with ads, or worry about where my data was being sent.

So, I decided to build WebToolkit Pro — a complete collection of 40+ free, fast, and 100% client-side developer tools. This is the story of how I built and deployed it as a solo full-stack developer from Lahore, Pakistan, focusing heavily on performance and privacy.

Why Client-Side Architecture Matters in 2026

With increasing data privacy concerns, rising cyber threats, and stricter regulations, developers are actively looking for tools that don’t send their code, passwords, or sensitive data to third-party servers.

Key Benefits of Client-Side Processing

Zero Data Collection: Everything stays in the browser.
Instant Performance: No network latency or server round-trips.
Offline Capabilities: Tools work even when the connection drops.
Frictionless Access: No sign-ups or paywalls.

Choosing the Tech Stack for WebToolkit Pro

To achieve lightning-fast load times and a great developer experience, I chose a modern frontend stack:

Frontend Framework: Next.js 15 (App Router) + TypeScript
Styling: Tailwind CSS + custom reusable components
State Management: Zustand + React hooks
Deployment: Vercel (for blazing-fast edge delivery)
Analytics: Privacy-friendly Plausible

Tip: When building a suite of tools, establishing a strict component system early on is crucial. It allowed me to add new tools in under two hours each!

Overcoming Development Challenges: Performance and Security

Building 40+ tools as a solo developer came with unique hurdles, particularly around optimization and accuracy.

1. Performance Optimization for Heavy Inputs

Some tools, like the large JSON formatter, needed heavy optimization to run smoothly on low-end devices without freezing the main thread. I had to rely heavily on efficient parsing and memoization.

2. Maintaining Cryptographic Accuracy

Tools like the Password Generator and Hash functions had to be cryptographically secure. Relying on standard Math.random() isn't enough for security tools.

Here is a simplified snippet of how I approached generating secure passwords entirely on the client side using the Web Crypto API:

// Secure password generation using Web Crypto API 
const generateSecurePassword = (length) => { 
  const charset = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%^&*()_+"; 
  let password = ""; 
  const values = new Uint32Array(length);

  // Generate cryptographically strong random values
  window.crypto.getRandomValues(values);

  for (let i = 0; i < length; i++) {
    password += charset[values[i] % charset.length];
  }

  return password;
}

console.log(generateSecurePassword(16));

Explanation: By using window.crypto.getRandomValues, the tool ensures high entropy and secure randomness directly in the user's browser, avoiding the predictability of standard Math functions.

Key Tools Available on WebToolkit Pro

Currently, wtkpro.site features over 40 tools, including:

JSON Formatter & Validator
Secure Password Generator with entropy meter
Meta Tag & Open Graph Generator
JSON-LD Schema Generator
JWT Decoder
Base64, URL, and Hash converters

Lessons Learned as a Solo Maker

Speed beats perfection: Launching with 15 tools and iterating worked much better than waiting to finish 50 perfect ones.
Privacy is a killer feature: Many users told me zero-data-collection was the main reason they switched from competitors.
Content + Tools = Growth: Writing blog posts alongside building tools dramatically increased organic traffic.

Note: If you are building your own tools, always start with the ones you personally need daily. You are your own best beta tester.

FAQ: Frequently Asked Questions

Q: Are all 40+ tools really client-side?
Yes, all processing happens locally in your browser. No form data is sent to a backend.

Q: Will you add more tools?
Absolutely. I am constantly taking feedback from the community and expanding the suite while moving into deeper niche verticals.

Conclusion

Building WebToolkit Pro taught me that you don’t need a big team or VC funding to create something highly useful. With the right mindset, modern tools like Next.js, and a strict focus on privacy and performance, a solo developer can build a meaningful product that helps thousands. If you are tired of bloated tools, I invite you to try WebToolkit Pro. Let me know which client-side tool you find the most useful for your daily workflow!

Expressions in .NET: From "Hello World" to "Matrix Architect"

Mon, 04 May 2026 21:24:58 +0000

They live among us, but do we notice how wonderful they are?

Have you ever stared at a line of code and wondered: "Is this data, or is this an instruction?" If the answer is "yes," congratulations—you've had a software existential crisis. In .NET, Expressions are that middle ground where code becomes data and data becomes executable logic.

Basic Level - "Don't hurt me, I'm new"

What is an expression?

In human terms: An expression is anything that returns a value.

2 + 2 is an expression.
DateTime.Now is an expression.
Your boss saying "we need to talk" is an expression that returns a value of StressLevel.Maximum.

We use them constantly without even realizing it, especially with Expression-bodied members (those => arrows that save us from typing return and curly braces).

using System;
namespace BasicExpressions;
public class Developer
{
    public string Name { get; set; } = "Junior Dev";
    public int CoffeeCups { get; set; } = 0;

    // Expression-bodied property: Short and sweet
    public bool IsFunctional => CoffeeCups > 3;

    // Expression-bodied method
    public void DrinkCoffee() => CoffeeCups++;

    public override string ToString() => $"Dev: {Name}, Status: {(IsFunctional ? "Coding" : "Rebooting")}";
}

public class Program
{
    public static void Main()
    {
        var dev = new Developer();
        dev.DrinkCoffee();
        dev.DrinkCoffee();
        dev.DrinkCoffee();
        dev.DrinkCoffee();

        Console.WriteLine(dev.ToString());
    }
}

The Joke: If you're still using curly braces { return x; } for a single line in .NET 9, the compiler won't say anything, but a kitten somewhere in the world will stop purring.

Intermediate Level - "I'm not (that) scared anymore"

Expression Trees: Look, but don't touch (yet)

This is where things get interesting. An Expression<Func> is not code that executes immediately. It is a data tree that describes the code.

Think of it like a cooking recipe:

Delegate (Func): This is the cooked meal. You just eat it.
Expression (Expression): This is the recipe written on paper. You can read it, swap "salt" for "sugar" to troll someone, or decide never to cook it at all.

This is exactly what Entity Framework uses to translate your C# into SQL.

using System;
using System.Linq.Expressions;

namespace IntermediateExpressions;
public class Program
{
    public static void Main()
    {
        // This is NOT a function; it is a DESCRIPTION of a function
        Expression<Func<int, bool>> isLargeNumberExp = n => n > 100;

        // Let's "gut" the expression to see what's inside
        var parameters = isLargeNumberExp.Parameters[0]; // 'n'
        var body = (BinaryExpression)isLargeNumberExp.Body; // 'n > 100'
        
        Console.WriteLine($"Parameter name: {parameters.Name}");
        Console.WriteLine($"Left side: {body.Left}"); // n
        Console.WriteLine($"Node type: {body.NodeType}"); // GreaterThan
        Console.WriteLine($"Right side: {body.Right}"); // 100

        // If we actually want to use it, we have to compile it "on the fly"
        var compiledFunc = isLargeNumberExp.Compile();
        Console.WriteLine($"Result of 150 > 100: {compiledFunc(150)}");
    }
}

Tip: Use this when you need dynamic logic that depends on database fields or filters that change at runtime. But don't overdo it—reading these trees later feels like trying to decipher Egyptian hieroglyphs.

Advanced Level - "The Architect"

In .NET 9/10, optimization is king. Sometimes, you need to generate code at runtime because you don't know what you're processing until the app is already running. Here, we build expressions by hand, block by block, like LEGOs—but with the risk of blowing up the memory.

using System;
using System.Linq.Expressions;

namespace AdvancedExpressions;
public class Program
{
    public static void Main()
    {
        // Goal: Create (salary, performance) => salary + (salary * performance) manually
        
        var salaryParam = Expression.Parameter(typeof(double), "salary");
        var perfParam = Expression.Parameter(typeof(double), "performance");

        // Step 1: salary * performance
        var multiplier = Expression.Multiply(salaryParam, perfParam);
        
        // Step 2: salary + (result of multiplier)
        var totalExpression = Expression.Add(salaryParam, multiplier);

        // Step 3: Wrap it in a Lambda
        var lambda = Expression.Lambda<Func<double, double, double>>(
            totalExpression, 
            salaryParam, 
            perfParam
        );

        // Step 4: Compile to IL (Intermediate Language)
        var calculateBonus = lambda.Compile();

        // Step 5: Execute
        double mySalary = 50000;
        double myPerformance = 0.15; // 15% bonus
        double finalPay = calculateBonus(mySalary, myPerformance);

        Console.WriteLine($"The formula generated was: {lambda}");
        Console.WriteLine($"Final calculated pay: {finalPay}");
    }
}

How are we doing? Good? Boring? Let's recap:

Basic: Use => to keep your code sexy and readable.
Intermediate: Understand that Expressions = Data. This explains why LINQ sometimes fails at runtime instead of compile time.
Advanced: Build your own trees if you want to create the next great .NET Framework, or if you simply hate the teammates who will have to maintain your code.

Expert Level - "The Logic Interceptor"

Expression Visitors: Modifying code while it's in transit

Imagine you have a filter coming from a UI, but you want to "intercept" it and change part of the logic (for example, adding a global IsDeleted == false check or masking sensitive data) without the developer knowing.

This is done with the ExpressionVisitor. It’s essentially a "Search and Replace" but for compiled logic.

using System;
using System.Linq.Expressions;
namespace ExpertExpressions;
// We inherit from ExpressionVisitor to "walk" the tree
public class MathTrollVisitor : ExpressionVisitor
{
    protected override Expression VisitBinary(BinaryExpression node)
    {
        // If we find a Plus (+), we swap it for a Minus (-)
        if (node.NodeType == ExpressionType.Add)
        {
            return Expression.Subtract(node.Left, node.Right);
        }
        return base.VisitBinary(node);
    }
}

public class Program
{
    public static void Main()
    {
        Expression<Func<int, int, int>> addExpression = (a, b) => a + b;
        Console.WriteLine($"Original: {addExpression}"); // (a, b) => (a + b)

        var troll = new MathTrollVisitor();
        var modifiedExp = (LambdaExpression)troll.Visit(addExpression);

        Console.WriteLine($"Modified: {modifiedExp}"); // (a, b) => (a - b)

        var result = ((Func<int, int, int>)modifiedExp.Compile())(10, 5);
        Console.WriteLine($"Result of 10 + 5 (trolled): {result}"); // Output: 5
    }
}

Note: This is how Multi-tenant systems automatically inject TenantId filters into every Entity Framework query without the dev writing .Where(x => x.TenantId == ...) every single time.

God Mode - "High Performance & .NET 10"

Dynamic LINQ and Caching (The Memory Tax Fighter)

Since you hate the "Memory Tax," here is the danger: Expression.Compile() is expensive. If you compile the same expression inside a loop, your CPU will cry.

In advanced scenarios, we use Expression Hashing. We analyze the tree, generate a unique hash, and store the compiled delegate in a ConcurrentDictionary.

using System;
using System.Collections.Concurrent;
using System.Linq.Expressions;

namespace GodModeExpressions;
public static class FastPropertyAccessor
{
    private static readonly ConcurrentDictionary<string, Delegate> _cache = new();

    public static TValue GetValue<TTarget, TValue>(TTarget target, string propName)
    {
        var key = $"{typeof(TTarget).FullName}_{propName}";

        var func = (Func<TTarget, TValue>)_cache.GetOrAdd(key, _ => {
            var param = Expression.Parameter(typeof(TTarget), "t");
            var property = Expression.Property(param, propName);
            return Expression.Lambda<Func<TTarget, TValue>>(property, param).Compile();
        });

        return func(target);
    }
}

public class ServerNode
{
    public string NodeName { get; set; } = "Cartago-01";
}

public class Program
{
    public static void Main()
    {
        var server = new ServerNode();
        
        // First call: Compiles the expression (Slow)
        // Subsequent calls: Uses the cache (Fast as native code)
        var name = FastPropertyAccessor.GetValue<ServerNode, string>(server, "NodeName");

        Console.WriteLine($"Reflected Value: {name}");
    }
}

Why .NET 10? With the push toward Native AOT (Ahead-of-Time), standard Expression.Compile() is a problem because it generates JIT code at runtime. Future versions are focusing on Source Generators that turn these Expressions into actual C# code during compilation, giving you the flexibility of Expressions with the zero-overhead of native code.

Insanity Level - "The Vertical Slice Fusion"

The Concept: Expression Splicing with Records

In a standard architecture, you have a slice for "Data" and a slice for "Business Logic." Usually, you fetch data, map it to a DTO, then process it. That's two allocations. In "Insanity Mode," we take the Data Expression and the Logic Expression and "splice" them together using Expression.Invoke or a custom ParameterReplacer. The result? One single SQL query (if using EF) or one single CPU pass that outputs a final Record.

using System;
using System.Linq;
using System.Linq.Expressions;

namespace InsanityExpressions;

// The ultra-lean result using C# Records
public record HeroDashboard(string Name, string Rank, bool IsLegendary, double PowerLevel);

public class Program
{
    public static void Main()
    {
        // Slice 1: The Data Mapper (From raw DB entity to basic info)
        Expression<Func<string, double, HeroDashboard>> dataMapper = 
            (name, power) => new HeroDashboard(name, "Unranked", false, power);

        // Slice 2: The Business Logic (Determines if they are legendary)
        // We want to "inject" this logic into the first expression
        Expression<Func<double, bool>> checkLegendary = p => p > 9000;

        // THE FUSION: We build a single expression that does both
        var fusedExpression = FuseHeroLogic(dataMapper, checkLegendary);

        Console.WriteLine($"Fused Expression: {fusedExpression}");

        // Compiling and testing
        var finalFunc = fusedExpression.Compile();
        var result = finalFunc("Goku", 9001);

        Console.WriteLine($"Name: {result.Name}");
        Console.WriteLine($"Is Legendary: {result.IsLegendary}"); // True!
    }

    public static Expression<Func<string, double, HeroDashboard>> FuseHeroLogic(
        Expression<Func<string, double, HeroDashboard>> mapper,
        Expression<Func<double, bool>> logic)
    {
        var nameParam = mapper.Parameters[0];
        var powerParam = mapper.Parameters[1];

        // We "invoke" the logic expression using the power parameter of the mapper
        var logicInvoke = Expression.Invoke(logic, powerParam);

        // We rebuild the Record constructor, but replacing the 'false' with our logic
        var ctor = typeof(HeroDashboard).GetConstructors()[0];
        
        // This is where the magic happens: creating the Record on the fly
        var newRecord = Expression.New(ctor, 
            nameParam, 
            Expression.Constant("S-Tier"), // Hardcoding a rank change
            logicInvoke,                   // Injected Logic!
            powerParam
        );

        return Expression.Lambda<Func<string, double, HeroDashboard>>(newRecord, nameParam, powerParam);
    }
}

Note: The "Vertical Slice" Impact, Imagine your GetHeroById handler. Instead of calling a service that calls a repository, you compose the expressions from those layers into one.

Database: "Oh, I see you need Name, Power, and a calculation of Power > 9000. I'll do that in SQL."
Result: You get a HeroDashboard record back. No extra loops, no extra Select statements.

Summary
By the time you reach this level, you aren't just writing code; you are writing code that writes code.

Pro: Your app is incredibly fast and memory-efficient. You bypass the "standard developer overhead."
Con: If a Junior developer opens this file, they might think you're performing a ritual to summon a demon.

My advice? Document this like it's the recipe for eternal life. Because if you lose the context of how these expressions are fused, you'll be debugging "Parameter count mismatch" errors until 2027.

Furthermore, but no less important, respect: If you're thinking, "This is impractical" or "I'd do it differently," congratulations: you're already analyzing. But before you dismiss anything, remember that here we build bridges, not walls. If you're looking for a rigid formula, there are a thousand manuals out there; if you're looking to collaborate and expand the boundaries of what's possible, stay. We respect the code, but we respect the process even more. Keep learning wherever you want, but here... here we come to create.

By One Garlos P. 2026

From Chatbots to Coworkers: What Google Cloud Next '26 Means for Developers

Mon, 27 Apr 2026 10:26:55 +0000

Originally published on dev.to.

A developer's breakdown of everything that matters from the Google Cloud Next '26 keynote and what to build with it next.

For the last two years, every AI keynote has felt like a magic show "look at this thing that can write a poem."

Google Cloud Next '26 was different.

The magic show is over.

The actual machinery is here.

Thomas Kurian and Sundar Pichai opened the keynote with a single, quietly disruptive idea: we're done with chatbots that talk. The new era is about agents that do: systems with persistent reasoning and autonomous execution that can hold context for days, plan multi-step workflows, and verify their own work.

2024 and 2025 asked, "Can we build an agent?", 2026 asks, "How do we manage thousands of them?"
For developers especially those of us building at the intersection of frontend, data, and distributed systems this is the most consequential Next in years. Here's what actually shipped, what it means, and where to start.

The Agentic Enterprise Blueprint

Kurian framed the entire conference around one concept: The Agentic Enterprise. The pitch is that the org chart of the future doesn't just have humans it has digital teammates working alongside them, and every employee becomes a builder who orchestrates a swarm of agents instead of executing tasks manually.

The strategy rests on two ideas:

Persistent reasoning: Unlike a chatbot that forgets you the moment you close the tab, agents maintain state across days. They can pause, wait for an external trigger, resume, and finish the job like a human colleague would.
Owning the full stack: Custom silicon (TPUs), the data layer (BigQuery), and the UX (Workspace) all built to work together. Kurian's not-so-subtle jab at competitors: they "hand you the pieces, not the platform."

Whether you buy that framing or not, the takeaway is clear Google is betting that vertically integrated infrastructure wins the agent era. And the rest of the keynote was them showing receipts.

Gemini Enterprise Agent Platform (The Vertex AI Rebrand)

The biggest rebrand of the event: Vertex AI is now the Gemini Enterprise Agent Platform. It's no longer a model garden it's a unified environment for the entire agent lifecycle, from prototype to production to post-deployment monitoring.

The core features that make up the platform:

Agent Studio: A low-code, visual builder inside Workspace. Defines agent goals in natural language, wire up tools, and ship.
Agent Development Kit (ADK) v1.0: The pro-code framework for the rest of us. Supports Python, JavaScript, Java, and Go, and lets you build graph-based agent networks (think LangGraph, but native).
Agent Identity: Every agent gets a unique cryptographic ID. Every action it takes is auditable. This is huge for compliance finally, a real answer to "Which agent did that, and why?"
Agent Gateway: Air traffic control for your agent fleet. Enforces policy, manages traffic, and uses Model Armor to block prompt injection attacks at the edge.
A2A (Agent-to-Agent) Protocol: A standardized handshake that lets a Google-based agent securely delegate tasks to a Salesforce or SAP agent. Cross-vendor interoperability, finally.
Agent Runtime: A re-engineered execution environment built for long-running agents. Your agent can fire off a task, wait three days for an external API to respond, and pick up exactly where it left off.
Agent Simulation & Evaluation: Stress-test your agent against thousands of simulated user interactions before it ever sees production. Catches logic drift before your users do.

What's Actually Shipping

If Day 1 sold the strategy, Day 2 showed the developer loop underneath it. The framing: build an agent system that plans a marathon for 10,000 runners through the Las Vegas Strip, using three agents — a planner (generates routes), an evaluator (scores them against constraints), and a simulator (runs the route end-to-end). The entire codebase and every demo were open-sourced as a GitHub repo plus Codelabs. The platform was anchored around four pillars and each pillar got its own demo segment.

️️ Build

ADK (Agent Development Kit): the code-first framework, supporting Python, JavaScript, Java, and Go, with a new graph-based runtime for defining how agents collaborate.
Agent Studio: the low-code counterpart. Define agent goals in natural language, wire up tools, publish.
Managed MCP: Google now hosts the Model Context Protocol layer, eliminating a week of self-hosting plumbing.
Agent Registry: described as "the DNS of your internet of agents." Auto-indexes every agent deployed to Agent Runtime, making them discoverable and governable.
Agent Marketplace: third-party agents from Atlassian, Box, Lovable, Oracle, ServiceNow, Workday, and more, deployable directly from Gemini Enterprise.
Model Garden: explicitly supports Claude, Gemini 3.1 Pro, Gemini 3.1 Flash, and others. Pick your model, swap when needed.

Scale

Serverless Agent Runtime: handles long-running state across days. Agents pause, wait for an external trigger, and resume without losing context.
A2A (Agent-to-Agent) Protocol: the cross-vendor handshake. Created by Google, donated to the Linux Foundation. A Google agent can hand work to a Salesforce or SAP agent without brittle API code.
A2UI (Agent-to-User Interface): an open standard letting agents generate dynamic UI components instead of returning plain text. The marathon simulator's UI (Angular + 3D rendering of the Las Vegas Strip) was assembled live by the agent itself, not hardcoded.

The evaluation layer is now first-class. A separate model as a judge scores outputs across deterministic criteria (a marathon is exactly 26 miles 385 yards / 42.195 km) and non-deterministic ones (community impact, route quality). Agents auto-generate their evaluation UIs from the schema of their own outputs the path from "fragile, unpredictable agentic loops" to "a rigorously evaluated network of experts."

Govern

The framing here was sharp: stop telling developers to "shift left" (own everything earlier) and start letting them "shift down" push the responsibility into the platform layer.

Agent Identity: every agent gets a unique, immutable cryptographic credential. Every action is auditable back to a specific agent instance.
Agent Gateway: air traffic control for the agent fleet. Understands MCP and A2A protocols. Uses IAM policies to scope which sources can invoke agent actions.
Agent Policies: configurable guardrails. An agent permitted to read from BigQuery but blocked from triggering spend over a threshold.
Model Armor: inline protection against prompt injection, tool poisoning, and sensitive data leakage at the gateway layer.

Optimize

The end-to-end debugging story for when an agent breaks in production:

Agent Runtime trace view: surfaces exactly where the reasoning chain or tool call failed.
Gemini Cloud Assist Investigation: takes a natural-language query and explores logs and events to surface the failing component down to a specific line.
Antigravity IDE: powered by Gemini 3, connected via MCP. Proposes parameter-level remediations. In the demo: a missing token_threshold on the event-compaction config that was silently truncating the agent's working memory.
Wiz Green Agent inside Claude Code with Opus: Wiz now scans both agent code and infrastructure, and the same remediation surface runs inside Anthropic's IDE on Anthropic's model. An explicit multi-vendor signal: security tooling travels with the developer, regardless of stack.

What it means for you

Day 1 sold the agentic enterprise. Day 2 laid out the loop you'll actually live in: build → scale → govern → optimize. Three things to actually act on:

The evaluation layer is the part most teams will sleep on and regret. Judge models, deterministic + non-deterministic checks, auto-generated eval UIs: this is where agentic systems silently fail today, and it's now baked in.
A2A and A2UI are open standards, not Google-only. The Linux Foundation handoff matters. Don't dismiss them as vendor lock-in.
Antigravity is the bet to watch. It's Google's claim on what "agentic developer experience" means in 2026 and the multi-vendor Wiz/Claude Code integration shows the surface area is intentionally portable.

The AI Hypercomputer: 8th-Gen TPUs

To run millions of persistent agents in production, you need silicon designed for the workload. Google's answer is the 8th-generation TPU and crucially, it's a dual-chip strategy that splits training and inference into purpose-built hardware. This is Google explicitly attacking the "memory wall" that's been bottlenecking large models.

What it means for you: Cloud developers now have a dedicated inference engine in the TPU 8i. The economics of running a complex, multi-turn agent for every single user in your app just got real. The "one agent per user" pattern was a fantasy in 2024 at these unit costs, it becomes a default architecture.

Agentic Data Cloud: From Passive Storage to System of Action

"Reasoning without context is just a guess" that's how Karthik Narain, Google Cloud's Chief Product and Business Officer, framed the thesis behind the Agentic Data Cloud, which reimagines data as something agents act on, not just query.

Three pieces matter most:

Knowledge Catalog: Replaces traditional metadata catalogs. It auto-maps the business meaning of data across your entire estate (Google Docs, Slack, SQL warehouses, the lot). Your agents now understand that "ARR" in finance means the same thing as "Annual Recurring Revenue" in your CRM.
Memory Bank: Long-term memory for agents. Where chat sessions used to forget you in five minutes, Memory Bank persists user preferences and project history across months of interaction.
Managed MCP: You no longer host your own Model Context Protocol servers. Google now manages the connective tissue between Gemini and your databases, which kills a whole class of plumbing work.

Agentic Defense: The Wiz Integration Goes Live

With the $32 billion Wiz acquisition fully closed, Google rolled out a "Cyberforce" of defensive agents. The pitch: stop reacting to alerts, start hunting threats autonomously.

Threat Hunting Agent: Proactively scans for novel attack patterns that signature-based firewalls miss.
Detection Engineering Agent: Writes and deploys new security rules in real time as threats evolve. The rule that catches tomorrow's attack didn't exist yesterday.
Wiz "Red Agent": An autonomous penetration tester that constantly probes your cloud infrastructure for unlocked doors before real attackers find them.

The Agentic Taskforce: Companies Already Shipping

The keynote closed with proof points companies actually getting ROI from agents in production right now. The pattern across all of them: agents handling the long-tail repetitive work, humans focusing on judgment calls. A few standouts worth zooming in on:

KPMG's Tax Swarms are the clearest A2A protocol use case in the wild; their tax agent talks directly to a client's audit agent.
Virgin Voyages going from 6-hour rebookings to 11 minutes is the clearest "Agent Runtime + long-running state" example.
Goldman Sachs querying 10,000+ page filings in minutes is what the Knowledge Catalog actually unlocks at enterprise scale.
Walmart and Bosch prove agents work at the edge — store floors and factory floors, not just data centers.

So What Should You Actually Do With This?

If you take one thing from Next '26, take this: the agent era isn't a future bet, it's a current one. The infrastructure is shipping, the protocols are standardizing, and Fortune 500s are already in production.

Concretely, here's where to start depending on your stack:

Frontend devs: Play with Agent Studio. The low-code builder is the fastest way to feel what an agentic UX is even supposed to look like.
Backend / data folks: The Knowledge Catalog and Memory Bank are the most underrated announcements. Try wiring an agent to your own data with Managed MCP and skip a month of plumbing.
Infra / platform engineers: Watch the TPU 8i pricing closely. The economics of "an agent per user" change your architecture decisions for the next two years.
Security teams: Don't wait. Threat Hunting and Red Agent are the kind of tools your blue team will quietly start depending on by Q3.

The chatbot era taught us how to prompt. The agent era is going to teach us how to delegate. The developers who figure that out first are going to look like wizards by the end of 2026.

If you watched the keynote too, what stood out for you? Drop a comment especially if you've started prototyping with the ADK. I'm curious what's actually working vs. what's still demo-ware.

How AI Actually Writes Code (Simple Explanation for Developers)

Thu, 16 Apr 2026 06:03:04 +0000

AI writing code feels like magic.

You type a prompt…
And suddenly, you get working code.

But what’s really happening behind the scenes?

Let’s break it down in simple terms

First Truth: AI Does NOT “Understand” Code

This might surprise you.

AI does not:

Think like a developer
Understand logic like humans
Know your exact intention

It only predicts the next best word/token

Just like:
When you type on your phone → it suggests the next word

AI does the same… but at a much bigger scale.

How AI Was Trained

AI models are trained on:

Millions of code examples
GitHub repositories
Documentation
Stack Overflow discussions

From this data, it learns patterns like:

How functions are written
Common coding structures
Error patterns and fixes

It becomes very good at “pattern recognition”

⚙️ What Happens When You Ask for Code

Let’s say you type:

“Create a login API in Node.js”

Here’s what AI does:

Breaks your prompt into tokens
Matches patterns from training
Predicts the most likely next tokens
Generates code step-by-step

It’s basically “auto-complete on steroids”

Why AI Sometimes Gives Wrong Code

Because:

It doesn’t test the code
It doesn’t know your full project
It guesses based on probability

So sometimes:

Logic is wrong
Edge cases are missing
Code looks correct but fails

That’s why blind trust = danger

⚡ Why AI Still Feels So Powerful

Even though it doesn’t “understand”…

It has seen:

Thousands of similar problems
Different coding styles
Multiple solutions

So it can:

Generate code fast
Suggest better approaches
Help debug issues

It’s like learning from millions of developers at once

The Right Way to Use AI

Don’t use AI like this:

❌ Copy → Paste → Done

Use it like this:

Ask “why this code works”
Break down the logic
Modify and test
Learn from outputs

Treat AI as a mentor, not a shortcut

Simple Analogy

Think of AI like:

A very smart student
Who has read everything…
But doesn’t truly understand anything deeply

It can answer fast
But you still need judgment

Final Thought

AI is not magic.

It’s prediction + data + patterns.

If you understand this…

You’ll stop fearing AI
And start using it smartly

And that’s what makes a real developer

The Infrastructure of Autonomy: Beyond the 'Plumbing' of AI

Sun, 12 Apr 2026 13:00:00 +0000

A year ago, enterprise teams that wanted to run autonomous AI agents in production faced a common problem. The capability was real, but the infrastructure wasn't. To run an agent reliably — with proper security boundaries, state persistence across sessions, and coordination between multiple agents — teams had to build it themselves.

That calculus is changing fast.

What used to be custom is becoming standard

Anthropic's managed agent capabilities and Microsoft's Agent Framework 1.0 both represent the same underlying shift: the foundational plumbing of agentic systems is being productized. Secure sandboxed execution environments, persistent memory, tool access controls, and multi-agent orchestration are moving from hand-rolled internal frameworks into off-the-shelf platform features.

This is not a small thing for enterprise development teams. Building agentic infrastructure from scratch is expensive and slow. It requires deep expertise in areas — secure process isolation, stateful distributed systems, inter-agent communication protocols — that most application development teams don't have on hand. Every team that had to figure this out on their own was spending engineering cycles on infrastructure instead of features.

Microsoft's Agent Framework 1.0 formalizes patterns that engineering organizations at companies like Stripe, Ramp, and Coinbase had already developed internally. These teams built multi-agent systems at scale before commercial frameworks existed for it, and the architecture patterns they converged on — isolated execution, shared memory with access controls, explicit agent handoff protocols — are now the design principles baked into the open frameworks.

The rebuild calculus has shifted

For a long time, the question of whether to build or buy agentic infrastructure was not really a question — there was nothing mature enough to buy. Teams that wanted autonomous agents in production had no choice but to build.

That's no longer the case. And it changes the math.

A team that previously spent six months building a custom agent orchestration layer can now adopt a framework and spend that time on what the agents actually do. The barrier to running agents in production is lower. The barrier to running them safely — with appropriate guardrails, audit trails, and rate limiting — is also lower, because those features are increasingly built in rather than bolted on.

What still requires your attention

None of this means the infrastructure problem is solved. It means the commodity layer is getting commoditized, which is how software always evolves.

What remains genuinely hard is everything above the infrastructure layer: defining what agents should be authorized to do, building the observability tooling to understand what they actually did, and designing agent workflows that degrade gracefully when something goes wrong. These are not problems that a framework solves for you. They require domain knowledge and careful architecture.

Security is the clearest example. Giving an agent access to a production system — even within a sandboxed environment — creates a new attack surface. Prompt injection, where malicious content in a document or API response hijacks an agent's behavior, is a real risk that frameworks are still catching up to. The infrastructure gives you the walls, but you still have to decide what goes through the door.

The practical implication

For development teams evaluating agentic platforms right now, the useful question is not whether a framework handles orchestration or sandboxing. Most of the serious ones do. The useful questions are: How does it handle failure? What does the audit trail look like? How do we debug an agent that went sideways in production?

The plumbing is no longer the hard part. Knowing what to build on top of it is.

From Prompts to Goals: The Rise of Outcome-Driven Development

Sat, 11 Apr 2026 13:00:00 +0000

Most AI coding tools work the same way. A developer spots a problem, writes a prompt, and the agent executes. It's useful. But the developer still drives every single decision.

Google appears to be rethinking that model entirely.

The company's Jules agent — already available on free and paid tiers through Google AI Pro and Ultra — operates differently than most coding assistants. Rather than requiring developers to wait for output after each prompt, Jules operates asynchronously, running in the background so developers can stay focused on other tasks. During its beta, developers tackled tens of thousands of tasks through Jules, resulting in more than 140,000 publicly shared code improvements.

That asynchronous model already puts Jules ahead of synchronous tools like Cursor and Windsurf. But Google isn't stopping there.

Enter Jitro

The Jules team is working on something new internally. The project, referred to as Jitro, appears to be the next generation of Jules — and it represents a different way of thinking about what a coding agent actually does.

Instead of asking developers to instruct an agent on what to build or fix, Jitro is reportedly designed around high-level goal-setting. Think KPI-driven development: the agent autonomously identifies what needs to change in a codebase to move a specific metric in the right direction.

Rather than telling the agent what to do, a developer would define the desired outcome — lower error rates, better test coverage, improved accessibility compliance — and the agent figures out the path to get there. A dedicated persistent workspace suggests Google envisions Jitro as an ongoing collaborator rather than a one-shot tool.

Why this matters for enterprise teams

This shift has the most immediate value for developers managing large, mature codebases. On a greenfield project, the ability to set goals and step back may feel unnecessary — you already know what you're building. But for enterprise engineering organizations seeking to measure software quality at scale, a goal-setting agent with a persistent workspace changes how they plan.

Incremental improvements in performance, test coverage, and security posture compound over time. Giving an agent a target and letting it work — across a large codebase, over time — is a fundamentally different workflow than the current prompt-and-review cycle most teams are running.

The deeper shift

The move from prompts to goals isn't just a UI change. It reflects a different model of what developers do.

Today, even with powerful agents in the loop, the developer is still functioning as a project manager — writing instructions, reviewing outputs, deciding what comes next. Jitro-style goal-setting changes that dynamic. The developer becomes more like an engineering director: setting strategy, defining success criteria, and reviewing results.

That's a harder transition than it sounds. Writing a good prompt requires precision. But defining a meaningful outcome requires judgment — an understanding of the codebase, the business, and what "better" actually looks like. That's not something an agent can define for you. It also means the developers who understand their systems deeply will get more out of these tools than those who don't.

Timing and context

Google I/O 2026 kicks off May 19, and Jitro is exactly the kind of showcase-ready capability Google would want to announce alongside its broader Gemini ecosystem updates. Whether it ships as described remains to be seen. But the direction is clear.

The current generation of coding agents has made developers faster. The next generation is setting its sights on making them more strategic.

And that's a meaningful distinction.

RepoWrit: Documentation on Autopilot

Thu, 09 Apr 2026 04:13:09 +0000

We're killing "Documentation Debt" once and for all.
RepoWrit uses AI to turn messy git history into living architecture maps and CEO-ready executive briefings along with architecture maps and semantic search Documentation on Autopilot PM Panel for Engineering Leads Visual Architecture Maps.

10 Tools Every Gen Z Developer Should Know About (2026 Edition)

Sat, 14 Mar 2026 12:32:58 +0000

10 Tools Every Gen Z Developer Should Know About (2026 Edition)

If you’re a Gen Z developer trying to survive the chaotic tech world, knowing the right tools isn’t optional — it’s your superpower. The right tools can save hours of work, make your projects look professional, and even help you land your dream job.

Here are 10 tools that will level up your coding, design, and productivity game — fast.

1. AI Coding Assistants – ChatGPT & GitHub Copilot

AI is no longer sci-fi. These assistants can write code snippets, debug, and even explain complex algorithms in plain English.

Why it matters: Speeds up coding and learning simultaneously.
Pro tip: Ask ChatGPT to explain your own code — it’s like having a tutor 24/7.

2. Modern IDEs & Editors – VS Code & JetBrains Fleet

Your development environment can make or break your workflow.

Why it matters: Extensions and smart suggestions turn small projects into pro-level apps.
Pro tip: Use VS Code extensions like Live Share to collaborate in real-time.

3. Cloud Development Platforms – Replit & CodeSandbox

Set up a dev environment in seconds, no heavy installations needed.

Why it matters: Instantly share your projects with anyone online.
Pro tip: Experiment with new frameworks without messing up your local machine.

4. Version Control Tools – GitHub & GitLab

Version control isn’t just for pros — it’s how developers keep their work organized.

Why it matters: Collaboration, portfolio building, and job-ready skills.
Pro tip: Use GitHub Copilot integration to save time on pull requests and commits.

5. Design & Prototyping Tools – Figma, Canva, & MidJourney

Modern developers aren’t just coders — design matters.

Why it matters: Build prototypes, mockups, or AI-generated graphics for your projects.
Pro tip: Use Figma community templates to speed up your UI design process.

6. API & Backend Tools – Postman, Supabase & Firebase

You don’t need to be a backend wizard anymore.

Why it matters: Build full-stack apps quickly with minimal server setup.
Pro tip: Connect Firebase authentication and database in under 30 minutes.

7. Dev Automation / Productivity Tools – Notion, Obsidian & Linear

Managing projects can be messy. These tools make it clean and automated.

Why it matters: Organize your projects, track progress, and automate repetitive tasks.
Pro tip: Use Notion templates to manage your coding projects like a startup.

8. Learning & Experimentation Platforms – LeetCode, Kaggle & HackerRank

Practice makes perfect. These platforms turn learning into a challenge.

Why it matters: Sharpen skills, prepare for interviews, or compete globally.
Pro tip: Kaggle competitions are perfect for building a real portfolio.

9. AI-Powered Design & Writing Tools – ChatGPT, Runway, Copymatic

Content, docs, and even marketing materials can be handled with AI.

Why it matters: Helps solo developers focus on coding while AI handles the rest.
Pro tip: Generate README files or documentation instantly — makes your project look pro.

10. Emerging Tech Tools – Web3 Dev, LangChain & Quantum SDKs

Stay ahead of the curve. The future belongs to developers who innovate.

Why it matters: Skills in emerging tech give you an edge in the next 5–10 years.
Pro tip: Experiment with LangChain for AI-powered apps — it’s the next big trend.

Closing Thoughts

These 10 tools won’t just make you a better developer — they’ll make you unstoppable. The trick is to pick a few, master them, and build projects that showcase your skills.

Which of these tools have you tried? And which one are you starting with today? Drop a comment and share this with your coding squad!

I Built a CLI to Find the Riskiest Code in Any Repo — Introducing Hotspots

Fri, 13 Mar 2026 20:35:35 +0000

Every team has those files. The ones everyone knows are dangerous. The ones where a "simple" change takes three days of careful testing. The ones that keep showing up in postmortems.

I spent a long time noticing that pattern—the same 10% of a codebase causing 80% of the pain—and wondering why our tooling didn't just show us where that 10% was. ESLint can tell you a function has high cyclomatic complexity. But that doesn't tell you whether it's actively being changed, who's touching it, or whether it's likely to bite you in the next sprint.

So I built Hotspots — a Rust CLI that finds risky code by combining structural complexity with real git activity.

The Core Idea: Complexity × Change

Raw complexity metrics are useful, but they're incomplete. A gnarly function that hasn't been touched in two years isn't your emergency today. The real danger is complexity plus active change — functions that are structurally hard to reason about and are being modified regularly.

Hotspots computes a risk score for every function in your codebase by combining:

Structural signals: cyclomatic complexity (CC), nesting depth (ND), fan-out (FO), non-structured exits (NS)
Activity signals: git churn in the last 30 days, touch frequency (commit count), recency, call-graph influence

The result is an activity-weighted risk score — a prioritized list of functions that are both dangerous and active. Not functions you should eventually clean up. Functions you should care about this sprint.

Getting Started

Install with a single curl:

curl -fsSL https://raw.githubusercontent.com/Stephen-Collins-tech/hotspots/main/install.sh | sh

Point it at any repo and run a snapshot:

hotspots analyze . --mode snapshot --format text

You'll get a ranked output grouped into risk bands:

Critical (risk ≥ 9.0):
  processPlanUpgrade    src/api/billing.ts:142    risk 12.4  CC 15  ND 4  FO 8

High (6.0 ≤ risk < 9.0):
  validateSession       src/auth/session.ts:67    risk 9.8   CC 11  ND 3  FO 7
  applySchema           src/db/migrations.ts:203  risk 8.1   CC 10  ND 2  FO 5

For a shareable HTML report:

hotspots analyze . --mode snapshot --format html --output report.html

Explain Mode: Why Is This Function Risky?

Once you have the list, you want to know why something ranked high — and what to do about it. Pass --explain-patterns and Hotspots annotates each function with antipattern labels:

hotspots analyze . --mode snapshot --format json --explain-patterns > snapshot.json

In v1.2.0, Hotspots detects two tiers of patterns:

Tier 1 — Structural:
complex_branching, deeply_nested, exit_heavy, long_function, god_function

Tier 2 — Relational & Temporal:
hub_function, cyclic_hub, middle_man, neighbor_risk, stale_complex, churn_magnet, shotgun_target, volatile_god

A function tagged god_function + cyclic_hub is both monolithic and at the center of a dependency cycle — a very different refactoring situation than one tagged exit_heavy + long_function. The labels make the action obvious.

CI Policy Checks: Stop Regressions Before They Merge

Identifying hotspots is useful. Preventing new ones from landing is better. Hotspots has a delta mode that compares the current branch against the baseline and applies configurable policy checks:

hotspots analyze . --mode delta --policy

Policies you can configure:

Critical Introduction — fail if a new function lands in the critical band
Excessive Regression — fail if a function's risk score jumps by a large delta
Rapid Growth — flag unusually fast complexity growth
Watch/Attention — warn when functions approach thresholds

Add it to CI and complexity regressions fail the PR before review. Start it in warn-only mode, get the team used to the signal, then flip to blocking when you're ready.

Here's a minimal GitHub Actions step:

- name: Hotspots policy check
  run: hotspots analyze . --mode delta --policy

Exit code 1 if any blocking policy fails. Zero if clean.

hotspots.dev — Automated OSS Analysis

Alongside the CLI, I've been building hotspots.dev — a blog that runs automated Hotspots analyses on trending open-source repos every night.

The pipeline:

A GitHub Actions crawl job selects a fresh trending repo
Hotspots analyzes it and extracts the top functions and antipatterns
An AI draft gets generated and opened as a PR for review
Once merged, it deploys automatically

It's a real-world showcase of what the tool surfaces in popular codebases — eslint, Flowise, and more. The HTML reports are hosted at reports.hotspots.dev so you can drill into the full ranked analysis for any repo.

I find it genuinely interesting to run Hotspots on codebases I use every day and see where the structural risk actually lives. It's rarely where you'd guess.

Try It

# Install
curl -fsSL https://raw.githubusercontent.com/Stephen-Collins-tech/hotspots/main/install.sh | sh

# Snapshot your current repo
hotspots analyze . --mode snapshot --format text

# Full JSON with pattern labels
hotspots analyze . --mode snapshot --format json --explain-patterns > snapshot.json

# CI policy check
hotspots analyze . --mode delta --policy

Docs: docs.hotspots.dev
Live analyses: hotspots.dev
Source: github.com/Stephen-Collins-tech/hotspots

It's MIT licensed, written in Rust, and works on any language — since it operates on git history and AST-level metrics rather than language-specific rules.

If you've ever looked at a PR and thought "this feels risky but I can't explain why" — run Hotspots. It'll tell you why.

TL;DR:

Complexity metrics alone miss the point. Hotspots combines structural analysis with real git activity to surface the functions that are both hard to change and actively being changed. It's a Rust CLI, it works on any language, and it can gate PRs in CI. Try it.

The Future Skills Every Developer Should Master Beyond Coding

Fri, 13 Feb 2026 22:56:50 +0000

A guide to soft and technical skills in an AI augmented world

For years, the formula for becoming a great developer seemed straightforward: learn a language, master a framework, build projects, repeat. But today, we’re entering a different era one where AI tools can generate code, refactor functions, write tests, and even explain documentation in seconds.

So what sets developers apart now?

In an AI augmented world, coding is still essential but it’s no longer enough. The developers who thrive over the next decade will master a combination of technical depth, systems thinking, communication, and adaptability.

Let’s explore the future skills every developer should master beyond coding and why they matter more than ever.

1. AI Collaboration Skills (Not Just AI Usage)

AI isn’t replacing developers it’s amplifying them. The key skill isn’t "using AI." It’s collaborating with AI effectively.

That includes:

Writing clear prompts
Reviewing AI generated code critically
Identifying hallucinations and inaccuracies
Refining outputs with domain knowledge

AI tools can generate solutions fast but they can’t fully understand your architecture, edge cases, or product context. Developers who know how to guide and audit AI outputs will outperform those who blindly accept them.

2. Systems Thinking & Architecture

When AI handles repetitive coding tasks, the real value shifts to higher level thinking.

Future ready developers understand:

System design principles
Scalability trade offs
Performance bottlenecks
Infrastructure decisions
Security boundaries

Knowing how components interact matters more than memorizing syntax. Architecture, not autocomplete, becomes your competitive advantage.

3. Communication & Technical Storytelling

Clear communication is becoming a superpower.

Developers must:

Explain complex systems to non technical stakeholders
Write clean documentation
Contribute meaningfully in design discussions
Provide constructive code reviews

In distributed and remote teams, written communication often defines your impact. The ability to articulate ideas clearly can accelerate your career faster than mastering another framework.

4. Product Thinking

Great developers don’t just ask, "Does it work?"
They ask, "Does it solve the right problem?"

Product thinking includes:

Understanding user pain points
Considering UX implications
Balancing technical debt with feature velocity
Evaluating trade offs from a business perspective

As AI reduces the cost of writing code, the value of building the right solution increases dramatically.

5. Deep Debugging & Problem Solving

AI can generate code but debugging complex, real world issues still requires human reasoning.

Future developers must excel at:

Root cause analysis
Reading logs and system metrics
Understanding runtime behavior
Thinking critically under uncertainty

Problem solving remains one of the most future proof developer skills.

6. Adaptability & Continuous Learning

Technology cycles are shrinking. Frameworks rise and fade quickly. AI tools evolve monthly.

The developers who thrive are those who:

Learn continuously
Experiment with new tools
Stay curious
Adapt without ego

In an AI driven environment, rigidity is risk. Adaptability is leverage.

7. Ethical & Security Awareness

AI introduces new risks privacy concerns, biased outputs, insecure code generation.

Future developers need awareness of:

Secure coding practices
Data protection principles
Ethical AI usage
Responsible deployment

Technical power without responsibility creates fragile systems. Ethics and security are no longer optional knowledge areas.

8. Collaboration Across Disciplines

Modern software development is cross functional.

Developers increasingly collaborate with:

Designers
Product managers
Data scientists
Security teams

Understanding how these roles think improves alignment and reduces friction. Collaboration is no longer a "soft skill" it’s a productivity multiplier.

9. Automation & Workflow Optimization

The best developers optimize their time.

This includes:

Automating repetitive tasks
Setting up monitoring and alerts
Streamlining CI/CD pipelines
Using AI and scripts to reduce friction

Efficiency compounds over time. Developers who master workflow automation gain an edge that others can’t easily replicate.

10. Strategic Thinking About Your Career

In an AI augmented world, career growth requires intentional positioning.

Ask yourself:

What problems am I uniquely good at solving?
Where do I add value beyond code generation?
How can I combine technical depth with strategic thinking?

Developers who think long term will stay relevant even as tools evolve.

Final Thoughts: Coding Is the Foundation, Not the Ceiling

Coding will always matter. But in the coming years, the developers who stand out won’t be those who write the most lines of code they’ll be the ones who think clearly, communicate effectively, design intelligently, and adapt quickly.

The future belongs to developers who combine:

Technical depth
Systems thinking
Communication excellence
Product awareness
AI collaboration skills

Master these, and you won’t just survive in an AI augmented world you’ll lead in it.

If this article resonated with you, share it with another developer thinking about their future. And if you’re serious about growing beyond code, stay tuned because the next decade of software development is just getting started.

SIPHON: The Telephony-First Framework for Calling AI

Wed, 28 Jan 2026 17:36:40 +0000

Building an AI that can chat via text is now a solved problem. Building an AI that can handle a real phone call in production is still a nightmare of fragmented infrastructure.

Developers typically face a "plumbing" crisis: they must manually stitch together SIP trunks, manage real-time media buffers, handle signal interruptions, and wire up multiple AI providers—all while trying to keep latency low enough for a human conversation.

SIPHON was built to end the plumbing. It is an open-source Python framework that provides a unified, telephony-first abstraction for building and operating Calling AI agents.

The Problem: The Telephony Gap

Traditional IVR systems and contact center platforms were never designed for the era of Large Language Models (LLMs). When developers try to build modern calling agents, they encounter three primary friction points:

Complexity: Each project requires re-implementing SIP trunk provisioning, room orchestration, and VAD (Voice Activity Detection) tuning.
Vendor Lock-in: Most "Voice AI" platforms tie you to a single stack, making it impossible to swap LLM or TTS providers as technology evolves.
Operation Hurdles: Features like call recording, metadata persistence, and transcription handling are often treated as afterthoughts rather than first-class features.

The Solution: A Unified Calling Abstraction

SIPHON sits between the telephony world and the AI world, providing a coherent framework for developers to build production-ready agents in ~30 lines of code.

How it Works: The SIPHON Architecture

Unlike generic voice frameworks, SIPHON is built on top of LiveKit, leveraging its real-time media and SIP layer to ensure high reliability.

The diagram illustrates how SIPHON orchestrates the entire call lifecycle:

PSTN/SIP Provider ↔ LiveKit SIP Domain (Real-time media)
LiveKit Rooms ↔ SIPHON Agent Worker (Orchestration)
SIPHON Worker ↔ AI Providers (OpenAI, Deepgram, Cartesia, etc.)

The framework is divided into two core modules:

siphon.telephony: Handles inbound Dispatch rules and outbound Call initiation, allowing you to bind phone numbers to agents programmatically.
siphon.agent: The runner that manages the LiveKit Agent worker, entrypoint orchestration, and the dynamic construction of AI components.

Key Pillars of SIPHON

1. Production-Ready at Scale

SIPHON is not a "toy" framework. It is designed for horizontal scalability; you can run your agent on one server or a thousand, and the architecture automatically balances the load.

2. Sub-500ms Latency

By utilizing WebRTC for real-time media interactions, SIPHON ensures voice interactions feel natural. It manages audio packet loss and interruptions to maintain a human-like flow.

3. Total Vendor Flexibility

Through its plugin architecture, SIPHON is agnostic to your AI stack. You can swap between OpenAI, Gemini, Deepgram, or ElevenLabs with minimal code changes.

4. Integrated Data Persistence

Recording, transcription, and metadata persistence are enabled via simple environment flags. Whether you need to save to S3, Postgres, or Redis, SIPHON handles the storage logic for you.

Getting Started

SIPHON is now open-source under the Apache 2.0 license.

Developers can install the framework and spin up a functioning agent worker in minutes:

pip install siphon-ai

Whether you are building an AI receptionist, an outbound notification system, or a contact-center triage bot, SIPHON provides the infrastructure to get you to production faster.

Stop building the plumbing. Start building the agent.

Read the Documentation | ⭐ Star us on GitHub

A BLACKDWARF Initiative.

We Open-Sourced Our AI Calling Framework (So You Don't Waste 2-3 Months)

Wed, 21 Jan 2026 11:09:10 +0000

Three months.

That’s how long many teams spend building telephony infrastructure before writing a single line of actual conversation logic for an AI voice agent.

Not because the AI was hard.
Because telephony is brutal.

Today, we’re open-sourcing the solution so you don’t have to go through the same pain.

The Hidden Problem with AI Calling Agents

Building an AI calling agent sounds straightforward:

Use an LLM
Add speech-to-text
Add text-to-speech
Connect it to a phone number

In reality, that’s where most teams hit a wall.

To make real phone calls, you end up dealing with:

SIP trunks & PSTN providers
Low-latency, bidirectional audio
Real-time orchestration of STT, LLM, and TTS
Call state, interruptions, transfers
Scaling, monitoring, recordings, persistence

The result?
Most teams spend weeks or months on infrastructure before they ever touch the conversation itself.

We did too. And eventually asked:

“Why is building voice AI still this hard?”

Introducing Siphon

Siphon is an open-source Python framework that handles the telephony complexity for you, so you can focus on building great conversations.

Here’s what a complete AI receptionist looks like with Siphon:

from siphon.agent import Agent
from siphon.plugins import openai, cartesia, deepgram

agent = Agent(
    agent_name="receptionist",
    llm=openai.LLM(model="gpt-4"),
    tts=cartesia.TTS(voice="helpful-assistant"),
    stt=deepgram.STT(model="nova-2"),
    system_instructions="""
    You are a friendly receptionist for Acme Corp.
    Help callers schedule appointments or route them correctly.
    """
)

if __name__ == "__main__":
    agent.start()

Run this, and your agent can answer real phone calls via any SIP provider (Twilio, Telnyx, etc.).

What Siphon Handles for You

SIP & PSTN connectivity
Works with any SIP provider, no FreeSWITCH pain.
⚡ Real-time audio pipeline
Built on LiveKit with streaming audio and sub-500ms voice-to-voice latency.
AI orchestration
Plug-and-play support for LLMs, STT, and TTS.

Swap providers with a single line:

llm=anthropic.LLM(model="claude-3-5-sonnet")

Production-ready by default
Auto-scaling, call recordings, transcripts, state handling, and observability.

Quick Start

Install:

pip install siphon-ai

Create an agent:

from siphon.agent import Agent
from siphon.plugins import openai, cartesia, deepgram

agent = Agent(
    agent_name="my_first_agent",
    llm=openai.LLM(),
    tts=cartesia.TTS(),
    stt=deepgram.STT(),
    system_instructions="You are a helpful assistant.",
)

agent.start()

That’s it.
Your agent is live and answering phone calls.

(Full setup, outbound calling, and advanced examples are in the docs.)

Why We Open-Sourced It

We could’ve kept Siphon proprietary or turned it into a closed SaaS.

But we believe voice AI shouldn’t be locked behind massive infrastructure effort.

Siphon is:

Apache 2.0 licensed
Provider-agnostic
Fully self-hostable
No vendor lock-in

Use it commercially, modify it, or build on top of it.

What You Can Build

Customer support agents
Appointment scheduling
Sales qualification
Surveys & feedback collection
Healthcare intake systems

If it involves phone calls and conversations, Siphon handles the hard parts.

Get Involved

⭐ GitHub: https://github.com/blackdwarftech/siphon
Docs: https://siphon.blackdwarf.in/docs
Issues & feature requests welcome
PRs encouraged

We’re building Siphon in public and would love community feedback.

If you’ve ever thought

“I wish building AI calling agents was simpler”

— give Siphon a try.

Built by BLACKDWARF
Mission: Democratize complex technologies for developers.

The OS of the Future: Will It Be Chat Based?

Wed, 21 Jan 2026 05:07:59 +0000

Every major shift in computing eventually forces the same question:

What becomes the primary interface?

With AI everywhere and chat interfaces dominating attention, it’s tempting to assume the answer is obvious: the operating system of the future will be conversational.

Type.
Ask.
Respond.

Clean. Simple. Familiar.

But after watching how AI systems behave in real workflows, not demos, the conclusion is more nuanced:

Chat will be part of the future OS.
It will not be the OS.

Why Chat Feels Like the Natural Successor

Chat works because it lowers friction.

It allows users to:

express intent loosely
avoid learning interfaces
bypass menus and configuration
get immediate feedback

As a bootstrap interface, chat is incredibly powerful.

It’s why AI adoption exploded so quickly.

But adoption is not the same as durability.

The Limits of Chat as a Primary Operating Layer

Chat breaks down the moment work becomes:

multi-step
repetitive
stateful
collaborative
safety-critical

Real operating systems must handle:

persistent context
background processes
permissions
concurrency
recoverability
predictability

Chat, by itself, is none of these things.

It’s a request-response interface, not an execution environment.

Operating Systems Are About Control, Not Conversation

Historically, operating systems succeeded not because they were expressive but because they were stable and boring.

They:

abstracted complexity
enforced boundaries
handled failure quietly
made the right behavior the default

Chat is expressive. Operating systems are restrictive.

That tension matters.

An OS that relies purely on chat would:

reintroduce ambiguity
make outcomes prompt-dependent
push responsibility back onto users
increase cognitive load over time

That’s the opposite of what an OS is supposed to do.

The Future OS Looks More Like a Coordinator Than a Chatbot

The OS of the future will likely have:

background AI operators running continuously
systems that observe context without being asked
intent captured implicitly, not typed explicitly
workflows triggered by state changes, not commands
escalation paths instead of conversations
visibility instead of verbosity

Chat becomes:

a control surface
a clarification layer
a debugging tool

Not the core.

Why Chat Will Remain Important but Secondary

Chat excels at:

exploration
explanation
clarification
exceptions
onboarding

It fails at:

routine execution
reliability
governance
scale

That means chat survives but moves to the edges.

Just like command lines survived GUIs.

Still powerful. No longer dominant.

The Real OS Is Being Built Below the Interface

The most important layers of the future OS won’t be visible.

They will handle:

memory and context
intent resolution
decision routing
tool orchestration
policy enforcement
auditability
recovery

This is infrastructure, not UX.

And it’s where the real competition is happening.

Why This Matters for Builders and Leaders

If you’re building products today and betting everything on chat UX, you’re likely optimising for the wrong horizon.

The defensible advantage won’t be:

better chat prompts
smoother chat UI
faster chat responses

It will be:

better intent models
stronger system boundaries
safer execution layers
clearer defaults
quieter reliability

That’s how operating systems win.

The Real Takeaway

Chat is not the future OS. It’s the training wheels.

Useful. Approachable. Transitional.

The OS of the future will feel less like a conversation and more like an environment that:

understands what you’re trying to do
acts without being asked repeatedly
intervenes only when necessary
makes good behavior automatic

In other words:

The future OS won’t talk to you all the time.

It will quietly work for you.

And that’s how you’ll know it’s mature!

Build or Buy: The Agent Platform Decision Developers Face in 2026

Thu, 15 Jan 2026 03:44:18 +0000

You need an agent to handle code reviews. Or automate testing. Or manage deployments. Or debug production issues.

The question comes up immediately: do we build it or use a platform?

The honest answer is uncomfortable: it depends on your team, your constraints, and what you're trying to accomplish.

Elite developers building custom agents get better results for their specific use cases. But most teams ship faster and maintain easier with platforms.

Here's how to decide which path makes sense for your situation.

The 10x Developer Pattern

There's a pattern emerging among developers who get exceptional results with AI agents. They're not waiting for perfect platforms. They're building modular, specialized agents for their exact workflows.

One AI architect described it clearly: "The 10x developers are building these modular, swappable architectures today. They create specialized bots for different tasks—research, analysis, visualization—then build orchestration layers that let them work together."

This approach works because these developers understand their workflows intimately. They know exactly what bottlenecks exist. They can design agents that solve their specific problems.

The agents they build aren't general-purpose. They're laser-focused on particular tasks in particular contexts. That specificity is what makes them powerful.

But this approach requires significant investment. You need to understand agent architecture. You need to build orchestration logic. You need to maintain everything as AI capabilities evolve.

For teams with those capabilities and unique requirements, building custom agents delivers better results than any platform.

When Building Makes Sense

Build custom agents when you have:

Unique workflows that platforms don't support. If your development process is highly specialized—custom tooling, proprietary systems, unusual constraints—platforms built for common patterns won't fit well.

Specific security or compliance requirements. If you can't send code or data to external services, or you need specific audit capabilities, building gives you full control.

Integration needs platforms don't handle. If you need agents that work with internal systems platforms don't support, custom building makes sense.

Engineering capacity to maintain agents. Building is the easy part. Maintaining as models improve, platforms evolve, and requirements change is harder. Only build if you can maintain.

Clear ROI from customization. If the benefit of perfectly tailored agents significantly outweighs platform costs plus your engineering time, build.

The key insight: building is about control and specificity. You get exactly what you need. But you pay for it in engineering time.

When Platforms Make Sense

Use platforms when you have:

Common workflows that platforms handle well. If you're doing standard code completion, testing, documentation, or debugging, platforms are optimized for these patterns.

Need to ship quickly. Platforms get you results in hours or days, not weeks or months. If speed to value matters more than perfect fit, use platforms.

Limited engineering capacity for agent maintenance. Platforms handle model updates, capability improvements, and integration maintenance. You focus on using agents, not maintaining them.

Standard security requirements. If you can use external services with standard security practices, platforms work fine.

Uncertain requirements. If you're still figuring out what you need, platforms let you experiment without big upfront investment.

The pattern: platforms trade some flexibility for speed, ease of use, and lower maintenance burden. For most teams, that's the right tradeoff.

Platform Capabilities That Matter

If you're evaluating platforms, focus on capabilities that actually impact results:

Response speed. Cursor 2.0's Composer model completes most tasks in under 30 seconds. That matters. When AI takes several minutes to respond, it breaks your flow. Fast feedback keeps you productive.

Codebase understanding. Asimov from Reflection AI is designed specifically for deep codebase comprehension. It ingests entire codebases, architecture docs, GitHub threads, and chat history to understand context. For large, complex projects, this depth of understanding matters more than raw generation speed.

Multi-agent support. Some platforms let you run multiple agents in parallel on different tasks. This matters when you're working on several problems simultaneously or when having multiple agents attempt the same task improves results.

Code execution and testing. Platforms that can actually run code and test changes deliver better results than those that just generate suggestions. Being able to verify that code works before suggesting it reduces iteration cycles.

Integration with your tools. Check what your platform integrates with natively. GitHub? GitLab? Your internal systems? The fewer custom integrations you need to build, the faster you ship.

Comparing Real Options

Here's how current platforms compare on key capabilities:

GitHub Copilot coding agent handles task delegation well. You describe what you want, it works in the background, creates draft pull requests. Good for defined tasks you can hand off. Integrates deeply with GitHub workflows.

Cursor 2.0 focuses on speed and multi-agent workflows. The Composer model is fast. The parallel agent capability lets you try multiple approaches simultaneously. Good for rapid iteration on code tasks.

Asimov excels at understanding large, complex codebases. It's built specifically for the research phase of development—understanding existing code before making changes. In blind tests with open source maintainers, it beat other coding products 60-80% of the time on complex questions.

Shadow is open source with MIT licensing. It creates isolated execution environments where agents can work autonomously on GitHub repositories. Good if you need full control and don't mind managing infrastructure.

Each platform optimizes for different use cases. The best choice depends on what you're trying to accomplish.

The Cost Calculation

Cost isn't just subscription fees. It's subscription fees plus engineering time plus opportunity cost.

Platform costs are straightforward. GitHub Copilot, Cursor, and similar platforms cost $20-40 per user per month. Multiply by your team size. That's your direct cost.

Build costs are trickier. How much engineering time to build the initial agent? How much ongoing maintenance? What's that time worth?

If it takes two engineers two weeks to build a custom agent, that's roughly $10,000-20,000 in engineering cost depending on salaries. Then add maintenance time. And opportunity cost—what else could those engineers have built?

Compare that to a year of platform subscriptions. For a 10-person team using Cursor at $30/month, you're looking at $3,600 annually.

The math gets interesting when you factor in benefits. If your custom agent delivers 10% better results because it's perfectly tailored to your workflow, does that 10% improvement justify the engineering investment?

Sometimes yes. Often no.

Integration Points That Matter

Whether you build or buy, certain integration points determine success:

Version control integration. How do agents access your repository? Create branches? Submit pull requests? This needs to be seamless.

CI/CD integration. Can agents trigger builds and tests? See results? This matters for agents that verify their work.

Observability integration. For agents handling production issues, they need access to logs, metrics, and traces. How does this work?

Internal tool integration. Your team probably uses internal tools that platforms don't know about. How do you handle this?

Data access. What data can agents access? What's off limits? How do you enforce boundaries?

Platforms handle common integrations well. Custom agents let you integrate with anything but require you to build those integrations.

The Hybrid Approach

You don't have to choose one path exclusively. Many teams use platforms for common tasks and build custom agents for specialized needs.

Use GitHub Copilot for general code completion and pull request reviews. Build a custom agent for your specific deployment workflow that platforms don't understand.

Use Cursor for rapid prototyping. Build custom agents that integrate with your internal monitoring systems.

Use Asimov for codebase research. Build custom agents for your compliance reporting that needs to work with proprietary systems.

The hybrid approach lets you get platform benefits for commodity tasks while maintaining control where it matters.

What's Changing Fast

The platform landscape is evolving quickly. GitHub Copilot added background task delegation this year. Cursor launched multi-agent capabilities. Asimov launched focused specifically on codebase comprehension.

If you build custom agents, you control the pace of change. You upgrade when you're ready. But you might miss capabilities platforms add.

If you use platforms, you get new capabilities automatically. But you're dependent on platform direction and timing.

This tradeoff matters for teams in rapidly changing environments. Can you afford to wait for platforms to add capabilities you need? Or do you need control over your roadmap?

The Build Decision Checklist

Before deciding to build, honestly answer these questions:

Do we have engineers with agent architecture experience? Building agents is different from building applications. Do you have the skills?

Can we maintain this long-term? Models improve. Best practices evolve. Can you keep your custom agents current?

Is our use case truly unique? Or are we overestimating how special our needs are? Many "unique" workflows turn out to be common with slight variations.

Have we tried platforms and found them insufficient? Or are we building because building is more fun than configuring?

Will the team actually use custom agents? Sometimes custom-built tools don't get adopted because they lack polish or documentation.

If you answer yes to all of these, building might make sense. If you're uncertain on any, start with platforms.

The Platform Selection Checklist

If you're going with a platform, evaluate:

Does it handle our primary use cases well? Test it with real tasks your team does daily.

How fast is the feedback loop? Slow responses kill productivity.

What's the codebase size limit? Some platforms struggle with large repositories.

Can it integrate with our tools? Check GitHub, GitLab, whatever you use.

What's the pricing model? Per-user, per-usage, or hybrid? Which makes sense for your team size and usage patterns?

What data leaves our environment? Understand exactly what gets sent to platform providers.

How good is the support? When things break, how quickly can you get help?

Test platforms with real work before committing. Most offer trials. Use them.

Start With Platforms, Build When Needed

The practical advice for most teams: start with platforms.

They get you results quickly. They're easier to adopt across a team. They handle maintenance. And they're improving fast.

If you hit real limitations—not imagined limitations, real ones that platform support can't solve—then consider building custom agents for those specific use cases.

The elite developers building custom agents? Many of them spent years using platforms first. They understand what works and what doesn't. They build custom solutions to fill specific gaps platforms don't address.

You don't need to start where they ended up. You can reach the same place by starting with platforms and building strategically when you hit real constraints.

Building Is Glamorous, Platforms Deliver Value

There's something appealing about building your own agents. Custom architecture. Perfect fit for your needs. Full control.

But there's also something valuable about solving problems quickly with tools that already exist.

The question isn't which is better in the abstract. It's which is better for your team, your constraints, your timeline, and your requirements.

Most teams get more value from platforms. Some teams genuinely need custom solutions. A few teams benefit from both.

The key is being honest about which category you're in.

If you're not sure, start with platforms. You can always build custom agents later when you have clear evidence you need them.

But if you build first and regret it, you've spent weeks or months of engineering time with nothing to show for it.

Start fast. Build selectively. Ship constantly.

That's how you make real progress with agents in 2026.

Building Production Voice AI: What 95% Order Containment Actually Takes

Tue, 13 Jan 2026 18:05:32 +0000

Most voice AI demos look great. Then you ship to production and discover the system can't handle background noise, interrupts users mid-sentence, or adds latency that kills the experience.

Deepgram's recent acquisition of OfOne, a platform that achieved 95%+ order containment in actual drive-thru environments, offers insight into what it takes to build voice AI that works in the real world. Not in controlled demos. In production, where people order food with screaming kids in the back seat and truck engines idling.

Here's what their engineering team learned, and what it means for anyone building with voice AI.

The Acoustics Problem Nobody Talks About

Drive-thru environments are especially hostile to speech recognition. Car engines, wind noise, HVAC systems, multiple voices bleeding into the same microphone, and customers speaking with wildly different accents and speeds. Most legacy speech systems break down because they were never designed for unpredictable, overlapping, multi-source audio.

The solution isn't better microphones or noise cancellation. It's training models specifically on drive-thru acoustics and continuously adapting them using real operational data. Deepgram's approach couples domain-adapted models with a runtime that hot-swaps them as conditions change.

The system automatically routes audio to the most appropriate model for current conditions while keeping latency low across thousands of concurrent sessions. Generic ASR models trained on clean audio simply can't handle this level of acoustic chaos.

Why Interruptions Are Harder Than You Think

Traditional speech systems treat turn-taking as a separate problem layered on top of recognition. They rely on rules like "if there's silence for X milliseconds, the user is done talking." This works fine for dictation. It fails completely in conversation.

People pause mid-sentence. They think out loud. They restart ideas or trail off before finishing. A silence-based system can't tell the difference between "I want a..." (brief pause while thinking) and "I want a hamburger" (done speaking). The result is either premature interruption or awkward delays.

Flux, Deepgram's conversational speech model, makes turn-taking part of the speech recognition itself. As it transcribes, it evaluates conversational intent using both acoustic signals and language context. Is this a brief pause or the end of a thought? Is the speaker likely to continue or genuinely handing over the turn?

This lets the system prepare a response early when it detects the speaker might be finished, but immediately resume listening if they continue. Only when Flux is confident the turn has actually ended does it finalize the transcript.

The technical challenge is that mistakes are costly in both directions. Interrupt too early and you break trust instantly. Wait too long and the interaction feels sluggish and unnatural.

The Latency Tax of Multi-Provider Systems

Deepgram's Voice Agent API targets sub-500 millisecond end-to-end latency, including perception, LLM reasoning, and speech generation. Real-time voice demands perception in under 200 milliseconds and similarly fast time-to-first-audio-byte on generation.

Building with separate STT, LLM, and TTS providers introduces network hops, buffering delays, and pipeline fragmentation that typically add 1-3 seconds per turn. That's the difference between conversation that feels natural and conversation that makes users interrupt or give up.

Running the entire pipeline—streaming recognition, turn detection, TTS, and state management—within one runtime optimized for real-time workloads eliminates most of that overhead. This isn't about marginal improvements. It's about whether your voice interface is usable or not.

Implementation Reality Check

Most teams can get a proof of concept running within hours using the cloud API. The friction usually appears not in integrating Deepgram, but in surrounding application logic.

Teams often underestimate what's required to manage conversational state, handle interruptions, or orchestrate backend actions triggered by voice. The ones that struggle are typically trying to adapt existing chatbot or IVR codebases to real-time, turn-based audio. Those architectures assume synchronous, text-only interactions.

The adjustment isn't about the speech technology. It's about redesigning workflow to account for streaming audio, real-time decision-making, and fallbacks. Once teams make that shift, adoption accelerates quickly.

When Self-Hosting Makes Sense

Deepgram cloud typically delivers the lowest latency because it runs on optimized GPU clusters. Self-hosted deployments are architecturally identical, but may introduce additional network or hardware constraints.

Customers choose to self-host for compliance, data sovereignty, or isolation requirements—not for performance. It makes sense when audio must stay on-premises, when strict regional data governance applies, or when private VPC isolation is required at scale.

Because the Enterprise Runtime automatically distributes and manages models, self-hosting still benefits from the same adaptivity and resource efficiency as the cloud. Just within a controlled customer environment.

Migration from Existing Providers

Teams using basic STT APIs can typically switch by replacing a single API call and adjusting streaming logic. Deepgram supports open-source models like Whisper in the same runtime, allowing incremental migration—running legacy models during transition while adopting Deepgram models for high-value use cases.

Significant refactoring only occurs when moving from batch or request-response APIs to fully real-time streaming agents. But that refactor is required regardless of provider. Deepgram tends to reduce complexity because consolidating perception, turn logic, and generation into one platform eliminates large chunks of glue code and multi-provider orchestration.

The Domain Adaptation Lesson

Generic ASR models don't hold up in noisy, time-compressed environments where accuracy directly affects revenue. Drive-thru performance validated that domain-specific adaptation isn't optional—it's essential.

This applies equally in healthcare, customer support, and logistics. Models need tuning to specific terminology, acoustic conditions, and conversational patterns for each domain.

Another key insight: even high-accuracy systems need edge case handling. Deepgram's architecture allows seamless human intervention without collapsing the session. In drive-throughs, back-of-house staff can listen and make real-time corrections, just as they do today. Similar hybrid-supervision models are extending into clinical transcription, appointment scheduling, and contact centers.

Common Failure Modes

The most common production failures involve overlapping speech, inconsistent turn-taking, unexpected background noise, and user corrections ("actually, change that"). Traditional ASR models are brittle in these scenarios because they assume clear, single-speaker audio.

Another common failure is latency creep. As teams layer multiple providers, latency quietly inflates until the system feels unresponsive. Running entirely through a single streaming session under one real-time runtime prevents this.

Scalability failures like traffic spikes, concurrency bursts, inconsistent workloads are handled automatically by model hot-swapping and load distribution algorithms.

What This Means for Developers

Voice AI is moving from demos to production. The technical challenges aren't about recognition accuracy in clean audio anymore. They're about handling acoustic chaos, managing natural conversation flow, and maintaining sub-500ms latency under real-world conditions.

The gap between systems that work in demos and systems that work in production is domain-specific adaptation, conversational awareness, and architectural integration. Building with separate providers for each component introduces latency and complexity that breaks the user experience.

Teams shipping production voice AI need to think about acoustics, turn-taking, and latency from the start. Not as problems to solve later.

Agents Aren't Apps: Why Your UI Strategy Just Changed

Wed, 31 Dec 2025 16:22:53 +0000

You've spent years building interfaces. Forms with validation. Dashboards with charts. Navigation menus that make sense. Responsive layouts that work on every device.

That skillset is becoming less relevant.

Not because the work wasn't good. But because the fundamental assumption behind it just changed.

The assumption was this: humans navigate software by clicking through menus, filling out forms, and reading screens.

That assumption is breaking down fast.

The Interface Is Moving

Traditional applications put a user interface between humans and business logic. You open the CRM. You navigate to the customer record. You click edit. You change a field. You save.

Every action requires you to know where things are and how to get there.

Agents eliminate most of that. You tell the agent what you want. It figures out where to find the information, what to change, and how to execute the task.

The interface isn't a collection of screens anymore. It's a conversation.

This changes what developers build.

Dynamic Interfaces Generated at Runtime

Some agents still need visual interfaces. But these interfaces don't look like traditional applications.

Instead of pre-built forms with fixed fields, agents generate interfaces on demand based on what's needed for the specific task.

Need to approve a purchase order? The agent creates a form showing relevant vendor history, budget impact, and comparison to similar purchases. Different context, different form. Same agent.

Traditional development means building every possible screen in advance. Agent-based development means building systems that can generate appropriate interfaces based on context.

The shift is fundamental. You're not designing screens anymore. You're designing the logic that determines what interfaces should exist.

Headless Agents: No UI at All

Some agents don't need interfaces. They just make decisions and take actions.

A fraud detection agent monitors transactions, applies rules, and flags suspicious activity. No one interacts with it directly. No dashboard. No forms. Just decisions happening in the background.

An inventory management agent tracks stock levels, predicts demand, and triggers reorders when thresholds are hit. It doesn't need a UI. It needs good decision logic and reliable integrations.

This pattern is spreading. Agents handle routine decisions autonomously. Humans only get involved when something requires judgment that the agent can't provide.

For developers, this means building systems where the primary user is another system, not a person.

Why CRM and ERP Interfaces Are Becoming Obsolete

Consider how people actually use CRM systems today. They don't enjoy navigating through Salesforce. They do it because that's where the customer data lives.

Agents change this. Instead of opening Salesforce, finding the account, and reading through notes, you ask: "What's the status of the Acme deal?"

The agent accesses Salesforce, finds the account, reads the notes, checks recent emails, reviews the opportunity stage, and tells you what you need to know.

The Salesforce interface still exists. But you're not using it. The agent is.

This pattern applies across enterprise applications. ERP systems. HR platforms. Project management tools. The interfaces were built for human navigation. But humans increasingly interact through agents instead.

The underlying systems still matter. The data models matter. The business logic matters. But the interfaces? They're becoming legacy artifacts.

What This Means for Frontend Developers

If you build user interfaces, this creates an uncomfortable question: what do you build now?

The answer isn't that frontend development disappears. It's that it changes focus.

Instead of building comprehensive interfaces that expose every feature, you build targeted interfaces for specific contexts where visual interaction adds value.

Instead of designing navigation systems, you design conversation flows.

Instead of optimizing for ease of finding features, you optimize for clarity when agents need human input.

The skills that matter shift from information architecture and navigation design to conversation design and context-aware interface generation.

Building for Agent Consumption

When agents become the primary consumers of your APIs and data, different things matter.

Traditional APIs often assume a human will interpret the response. Documentation explains what fields mean. Error messages describe what went wrong. The API design prioritizes flexibility for different human use cases.

Agent-first APIs need different characteristics. Clear, consistent structure. Predictable error handling. Good semantic descriptions that agents can parse. Support for bulk operations and batch processing.

The difference shows up in details. A human-focused API might return a customer record with 50 fields. An agent-focused API returns the same data but includes metadata describing what each field represents, its valid values, and its business meaning.

Agents can work with either. But they work better with APIs designed for programmatic consumption at scale.

The New Skill: Designing Conversations

The interface design skill that matters now is conversation design.

How do you structure a conversation between a human and an agent to accomplish a goal? What information needs to be exchanged? When should the agent ask for clarification versus making assumptions? How do you handle ambiguity?

These questions aren't new. But they're becoming central to interface design in ways they weren't before.

A good form makes data entry clear and prevents errors. A good conversation does the same thing but through natural language exchange instead of structured fields.

The underlying principles transfer. But the implementation is completely different.

What Still Needs Traditional Interfaces

Some things still work better with traditional interfaces. Data visualization. Complex spatial relationships. Reviewing large amounts of information quickly. Creative work that benefits from direct manipulation.

Agents handle extraction, summarization, and decision-making well. They don't handle visual pattern recognition or creative layout well.

The future probably isn't all-agent or all-traditional. It's knowing which interface makes sense for which task.

But the default is shifting. Ten years ago, the default was "build an interface for it." Now the default is becoming "let the agent handle it, unless there's a specific reason humans need direct visual access."

The Purchase Order Example

Here's how this plays out in practice.

Traditional system: You log into the procurement platform. Navigate to purchase orders. Click "create new." Fill out vendor, items, quantities, delivery date, budget code. Click through approval workflow. Submit.

Agent-based system: You tell the agent "Order 50 laptops from Dell, standard spec, for the Q1 new hires." The agent finds the standard spec, gets Dell pricing, checks budget availability, generates the PO, routes it to the right approver, and confirms when it's done.

No interface. No navigation. No form filling.

The agent might generate a visual summary for the approver showing cost comparison and delivery timeline. But that's dynamic, context-specific, and temporary. Not a permanent interface someone had to build.

The Transition Challenge

The difficult part isn't technical. It's organizational.

Your company has invested years building comprehensive interfaces. Those interfaces represent thousands of hours of design, development, and refinement. They work. People know how to use them.

Now agents are making those interfaces less necessary. But you can't just shut them down. People still use them. Some tasks still need them. And building the agent layer takes time.

The transition period is messy. You're maintaining legacy interfaces while building agent capabilities. You're supporting both patterns simultaneously. And you're trying to figure out which features need interface rebuilds versus agent implementations.

There's no clean answer. But the direction is clear.

Stop Building Forms

The provocative version of this argument: if you're still building forms, you're building the wrong thing.

The nuanced version: forms made sense when humans needed to navigate complex data entry. But if an agent can gather the information through conversation and validation logic, the form is unnecessary overhead.

Not every form disappears overnight. But the default assumption should shift from "we need a form for this" to "can an agent handle this workflow?"

That shift changes what developers build and how they think about interface design.

The Skills That Transfer

Good interface design was always about understanding user goals and removing friction. That principle doesn't change.

What changes is the implementation. You're removing friction through conversation instead of navigation. You're designing for context-aware generation instead of comprehensive coverage. You're building for agent interpretation instead of human comprehension.

The core skill, understanding what users need and making it easy to accomplish, transfers directly.

The implementation techniques? Those need updating.

What Developers Should Do Now

Start building for agent consumption. Even if your organization isn't deploying agents yet, your APIs and data structures should work well for programmatic access at scale.

Learn conversation design. Understand how to structure natural language interactions that accomplish goals efficiently.

Experiment with agent-based interfaces. Build a simple agent that handles a workflow your team currently does through forms. See where it works well and where it breaks down.

Pay attention to which interfaces in your applications are becoming less used because people found agent-based alternatives. That tells you where the shift is happening.

The interface revolution isn't coming. It's here. And it's changing what developers build, how they build it, and what skills matter.

If you're still thinking in terms of screens and navigation, you're already behind.

Build an AI Chatbot for Course Creators on WordPress

Thu, 11 Dec 2025 09:56:51 +0000

In this article we will build an AI chatbot. Before writing code, we decide what this chatbot must do. Based on who we are helping and what results they expect we would decide how the chatbot would function.
For this article we will take the example of a course creator who needs an AI chatbot before and after a student buys.

Results that matter for a course creator

Raise course completion from about 20% toward 40% or higher.
Let the bot answer about 70% of common questions so the creator gains back 20-30 hours each month.
Turn more trials into paid seats by keeping prospects in chat with previews and reminders.
Get 80% of buyers to start a lesson within the first day so they stay engaged.
Keep human escalations under 20% so staff can focus on students who truly need help.

Now, based on the above results we would need to decide the AI chatbot behaviour and pick features which serve those results. For our example of a course creator we can select the features below.

Feature	Why this helps
Bubble Widget	Sits quietly in a corner with a timed preview line so visitors can ask about lessons without losing their place. Good for pre-sale work and quick nudges.
Popup Widget	Opens as a modal when someone finishes checkout or stalls on a module, making it easy to push onboarding steps or rescue stuck students.
File Search & RAG	Feeds lesson transcripts, worksheets, and FAQ docs into the bot so every reply references real material instead of generic text.

Build it in five short steps

1. Create and add the system instructions

We will use Predictable Dialogs which has an open source chat widget, into which we would add the system instructions that explain tone, steps, and rules.

2. Upload course files for File Search & RAG

Next we will upload lesson plans, transcripts, homework keys, policy docs, and sample answers. Keep each file clean with headings. Break long docs into 100-200 token chunks with about 20 token overlap so the bot keeps context. Ask test questions that reference tricky spots and confirm the bot cites the right snippets. Keep adding or fixing files until answers stay accurate.

Use the web embed script and choose the bubble variant. This version stays on every page without blocking content. You can capture user info, theme the button, and show a preview message. Here is a starter snippet:

<script type="module">
  import Agent from 'https://cdn.jsdelivr.net/npm/@agent-embed/js@latest/dist/web.js'
  Agent.initBubble({
    agentName: "course-companion",
    user: {
      user_id: window?.USER_ID ?? "anon",
      user_segments: ["prospect"],
    },
    previewMessage: {
      message: "Need a study plan?",
      autoShowDelay: 4000,
    },
    theme: {
      placement: 'right',
      button: { backgroundColor: "#4C3AFF", iconColor: "#FFFFFF" },
      previewMessage: { backgroundColor: "#4C3AFF", textColor: "#FFFFFF" }
    }
  });
</script>

To add this to WordPress you have two simple paths:

Site Editor: go to Appearance → Editor → Pages, add a page or template block, insert a Custom HTML block, and paste the script.
WPCode plugin: install WPCode, go to Code Snippets → Add New → HTML Snippet, paste the script, toggle Activate, and save. This lets you load the widget on every page.

Keep the preview short. Trigger Agent.open() or Agent.showPreviewMessage() when someone hits a pricing page or watches a lesson preview by attaching those calls to your WordPress buttons.

Use the popup version on checkout pages, onboarding flows, or inside the LMS when someone seems stuck. The modal takes over the middle of the screen, so use it only when the student must do something next.

<script type="module">
  import Agent from 'https://cdn.jsdelivr.net/npm/@agent-embed/js@latest/dist/web.js'
  Agent.initPopup({
    agentName: "course-coach",
    autoShowDelay: 0,
    defaultOpen: true,
    user: {
      user_id: lessonProgress.userId,
      user_segments: ["purchased", lessonProgress.currentModule]
    },
    initialPrompt: `The learner is stuck on module ${lessonProgress.currentModule}.`,
    onClose: () => analytics.track("Module Popup Closed")
  });
</script>

To show this inside WordPress, paste the popup script into the exact template or block that renders your checkout or lesson page. If you need it site-wide, add it through WPCode but wrap the call in a condition (for example, check the current page slug in a small inline script) so it only opens where it makes sense. Control width so it fits phones. Toggle it with Agent.open(), Agent.close(), or Agent.toggle() when WordPress detects a stalled learner (for example, after a custom block notices no quiz submission).

5. Test, monitor, improve

Ask the bot for edge cases, like grading rules or refund deadlines, and see if it cites the right file chunk. Watch engagement logs to see if the preview timing or popup triggers are annoying people. Adjust the scripts until questions fall under the 20% escalation goal. Re-upload files whenever you add modules so the index stays current.

Wrap up

When you start with helping a course creator support and convert students, you only need three features: Bubble Widget, Popup Widget, and File Search & RAG. Build the agent, load the files, drop in both widgets through the WordPress Site Editor or WPCode, and keep testing. You get faster responses for students, fewer repetitive tickets for the creator, and better odds that everyone finishes the course.

Preparing Students for Modern Software Development: Toolchain

Fri, 05 Dec 2025 11:52:58 +0000

In the software engineering classes I teach (undergraduate and graduate) I'm working to help students gain hands-on exposure to essential tools necessary for real-world software development. While languages, frameworks, and tools constantly change, the toolchain that supports development evolves more gradually—and mastering it can improve students’ readiness to contribute to software projects in internship or industry roles. A list of tool categories I've considered is below, but I'm curious what other essential tools or tool categories should students understand to be industry-ready for modern software development and beyond?

IDEs
Version Control
Static analysis
Debuggers/logging tools
Testing frameworks
CI/CD
AI coding assistants

Are there other things missing, tools you wish new grads knew about before joining your team, or specific tools that are essential within these categories? I'm open to suggestions!

How I've built an app to track my open-source project growth

Tue, 11 Nov 2025 12:13:34 +0000

Hey all!

I've been building open-source tools for a while, mostly focused on AI, automation, and developer productivity.
As I started sharing my projects across Reddit, Twitter, and other developer communities, I often encouraged people who liked my work to ⭐ the repos.

Over time, I noticed I was constantly checking my GitHub analytics manually... and thinking "How's my project doing today?" or "Did that post bring in any new stars?"

So, I decided to scratch my own itch and built TrendForge Labs, an Android app that helps developers like me track GitHub repository growth over time.

What TrendForge Labs Does

It lets you:

Monitor GitHub repositories for star count changes
Track daily and historical star growth
Add any public repository to your watchlist
View repository details including description and language
Use home screen widgets for quick star count access
Store all data locally for maximum privacy

It uses the GitHub API to fetch repository data and trends, making it easy to see how your projects evolve and compare engagement over time.

Why I Built It

I wanted something simple, private, and visual to track my open-source growth.
There are analytics dashboards out there, but most are web-based, require logins, or don't focus on the "stars as milestones" aspect.

TrendForge Labs is fully local, with no logins, no ads, and no external tracking.
Just your data, on your device.

The Takeaway

Building it reminded me how important it is to solve your own problems first. It makes the process so much more meaningful.

If you're an indie dev, an open-source maintainer, or someone just starting out trying to make your project more visible and track its growth, you'll probably find TrendForge Labs handy.
You can find it on Google Play. It's free to try for 7 days, which I figured is enough time for users to test it and see if it’s something they’d want to keep using afterward.

If you're also into open-source tools, you might enjoy checking out some of my projects that inspired this app:

Happy hacking and keep building awesome stuff!

SAP spent 50 years building proprietary development tools. That strategy ended this week in Berlin.

Wed, 05 Nov 2025 15:11:40 +0000

SAP Abandons Proprietary Developer Tools. Here's What That Actually Means.

The Shift Everyone Missed

SAP TechEd 2025 opened with Muhammad Alam, SAP's board member for Product and Engineering, making an unusual promise: developers can now "build, extend, and automate using the tools they love most."

Not SAP's tools. The tools developers already use.

It's a complete reversal of SAP's historical approach. For decades, working with SAP meant learning SAP's proprietary environments, SAP's frameworks, and SAP's way of doing things. That created a moat around SAP's business but also created a developer experience problem.

Bharat Sandhu, SVP and CMO of SAP's Business Technology Platform, addressed it directly in an interview: "The biggest misconception developers have about SAP BTP is that it's not open."

The technical implementations announced at TechEd demonstrate that SAP is backing this up with actual infrastructure.

What Changed Under the Hood

SAP announced three significant technical capabilities that fundamentally change how developers can work with SAP:

Model Context Protocol (MCP) Servers for SAP Frameworks

SAP now provides local MCP servers for its Cloud Application Programming Model, SAP Fiori elements, SAPUI5, and the mobile development kit. These are available now.

What this means: Developers using AI code assistants like Cursor can access SAP development frameworks directly in their preferred environment. They don't need to switch to SAP's tools.

An ABAP-based MCP server is planned for H1 2026, which will expose ABAP Cloud development capabilities to coding agents.

Sandhu emphasized the importance: "Model-driven tooling, like SAP Cloud Application Programming Model, SAP Fiori elements, SAPUI5, and SAP's mobile development kit, increases developer productivity and supports consistency across SAP Build projects."

MCP Gateway in SAP Integration Suite

The MCP Gateway (general availability planned Q1 2026) enables customers to expose custom APIs and integration flows that can be dynamically consumed by AI agents.

The practical value: "It provides a unique capability for customers to enrich custom agents built in Joule Studio or extend Joule Agents by integrating data from legacy SAP systems and third-party ERP, CRM, and HR vendors, composed as MCP tools for smooth agentic consumption," according to one SAP technical lead during the experience center tour.

This addresses a real problem. Enterprises don't just have SAP data. They have decades of data in various systems. The MCP Gateway enables agents to work across the entire landscape with standardized access, centralized governance, and simplified discoverability.

VS Code Extension Pack

SAP Build capabilities now work directly in Visual Studio Code. Individual extensions are available now. The full extension pack will be published on the Open VSX Registry for other development environments in Q2 2026.

Sandhu noted that SAP's own IDE is "built on VS and a VS Code extension," acknowledging that the underlying technology already comes from Microsoft's open-source project.

Why This Matters: The Developer Scarcity Problem

This isn't about being nice to developers. SAP is responding to a crisis.

In the fireside chat with Alex Kantrowitz, Muhammad Alam shared a customer example: "We have a customer who says we have a backlog that if I had to do with my existing capacity would take me 20 years to deliver."

Another data point from the same conversation: "40,000 workers with enough backlog for 200,000."

The math is brutal. Enterprises can't hire their way out of this problem. The only solution is making existing developers dramatically more productive.

Alam framed it clearly: "AI is going to be about acceleration. How do you ensure they have the right tools to deliver innovation faster?"

Alam added, "We saw metrics showing 7x to 12x value with AI in sprints as learning increases."

The Business Logic Behind Open Development

Brenda Bown, CMO of SAP Business AI Marketing, said that customers asking "why SAP AI vs. building our own with ChatGPT" receive three answers: trust, governance, and the "breadth and depth of the data."

The open development strategy supports this positioning. SAP provides the business context and data semantics. Developers use whatever tools they want to build upon it.

It's a different kind of moat. Instead of trapping developers in proprietary tools, SAP is betting that the value is in the data layer, not the development environment layer.

When asked how much SAP BTP development actually happens in external tools versus SAP's native environments, Sandhu acknowledged it's early: "Too early" to have meaningful usage statistics.

The infrastructure is being built to support developer choice. Adoption patterns will emerge over the next few quarters.

Two Paths to Agent Development

The open development strategy creates two distinct paths for building AI agents:

Path 1: Joule Studio (Low-Code)

Joule Studio (general availability: December 2025) enables developers to create and deploy custom AI agents with assistance from Joule itself. New features coming in H1 2026:

Support for system-triggered agents (not just user-initiated)
Extensibility of SAP-delivered Joule Agents
Centralized enterprise-grade agent monitoring
Support for Agent2Agent protocol

This path is designed to enable the rapid development of building agents while leveraging SAP semantics and maintaining alignment with SAP data.

Path 2: Pro-Code Frameworks on SAP BTP

SAP BTP provides comprehensive support for popular open-source frameworks, including Crew.AI and LangGraph. The platform provides:

End-to-end identity and authorization
Governance and integration capabilities
Access to the AI Foundation for the latest AI models
SAP HANA Cloud for agent memory and secure tool execution
SAP Integration Suite for smooth integration with applications

Sandhu was clear about which path most customers are choosing: when asked if customers building custom agents with pro-code tools are deploying to SAP BTP or running in their own infrastructure, he said, "Mostly to BTP."

The Partner Impact

The open development shift is already affecting SAP's partner ecosystem, and not always in a positive way.

When asked about partners' biggest complaints, Sandhu said: "Used to charge for dev tools, now for free. More help on training and enablement."

Making development tools free eliminates a revenue stream for some partners. They're asking for more training resources to help them add value in other ways.

SAP's response: a new free SAP Build test, demo, and development license specifically for partners. This lets partners experiment, build demos, and develop solutions without purchasing licenses.

The partner ecosystem is also building agents. Sandhu said there will be "40 by the end of the year" partner-built agents available, in addition to SAP's own Joule Agents.

What's Available Today vs. What's Roadmap

This matters for developers planning projects now:

Available Today:

Local MCP servers for SAP frameworks
Individual VS Code extensions for SAP Build
Support for Cursor and other code assistants with SAP frameworks
Pro-code agent development with LangGraph and similar frameworks

Q1 2026:

MCP Gateway in Integration Suite
ABAP-based MCP server
Enhanced monitoring for custom agents

Q2 2026:

Full SAP BTP extension pack on Open VSX Registry
ABAP support in the extension pack
Additional agent development capabilities

When asked what customers can do today if they want to start building agents this week, Sandhu said, "Go build. Everything will be more generally available in a couple of weeks."

That "couple of weeks" qualifier is important. Some capabilities are available now. Others are imminent. Developers need to verify specific features before committing to project timelines.

The Critical Technical Requirement

One point came up repeatedly across interviews: understanding SAP's data semantics.

Sandhu emphasized this as the most common integration mistake: "Don't take data out without the semantic understanding."

This is the real value SAP is protecting. You can use whatever development tools you want. You can deploy agents as you see fit. But if you want SAP's business context—the relationships, the business meaning, the validated transformations—you need to work with SAP's semantic layer.

That semantic layer lives in SAP Business Data Cloud and SAP HANA Cloud. Those are not optional if you want agents that understand SAP business processes.

What Developers Should Actually Do

Based on the announcements and interviews, here's the practical path:

If you're building applications: Use VS Code with SAP's extension pack. Work in your preferred environment while maintaining access to SAP frameworks and business context.

If you're building agents for common use cases: Start with SAP's Joule Agents. 40+ are available across finance, HR, supply chain, and other functions. Extend them using Joule Studio when you need company-specific modifications.

If you're building custom agents: Use pro-code frameworks on SAP BTP. You get access to SAP's governance, security, and data semantics while maintaining full control over agent logic.

In all cases: Understand SAP's data products and business semantics before building. The compute platform is flexible. The semantic layer is not.

The Real Test

Muhammad Alam closed the keynote with a direct challenge: "SAP's announcements today give developers the tools they need to deliver at the speed of AI."

The test of whether SAP's open development strategy is effective will be simple: do developers choose to use these tools, or do they remain in proprietary SAP environments because the open options do not work well enough?

That evidence will emerge over the next two quarters as these capabilities move from announcement to production use. Developers will vote with their toolchain choices.

For SAP, the bet is clear: giving developers choice while maintaining control over data semantics creates a more sustainable platform than forcing them into proprietary environments.

For developers, the practical question is whether this actually makes building on SAP easier or if it's just more complexity to navigate.

Recommended Hashtags:

Twitter: #SAPTechEd #DeveloperTools #OpenSource #SAPBTP #AgenticAI

LinkedIn: #SAPTechEd #EnterpriseDevelopment #DeveloperExperience #OpenDevelopment #AIAgents

AI vs. Human: The Battle of Who’s Dumber

Mon, 06 Oct 2025 15:40:13 +0000

AI vs. Human: The Battle of Who’s Dumber

Let’s be honest — AI was supposed to take over the world by now. But instead of world domination, it’s out here writing LinkedIn posts that sound like inspirational soup.

And humans? We’re no better. We keep giving it prompts like:

"Write viral blog fast now."

AI: "Sure thing, boss. Here's a haiku about email etiquette."

So yeah. The apocalypse is delayed.

Round 1: The Dumb Prompts

Humans keep asking AI for miracles using caveman instructions. It's like yelling at Siri through a fan.

Example:

Human: "Be funny."

AI: "Knock knock."

If your AI sounds like your uncle at family dinner, the problem isn’t the machine — it’s your prompt.

That’s where The AI Alchemist comes in.

They don’t just fix prompts — they upgrade your entire AI IQ. It’s the difference between saying "Draw dog" and getting Picasso to paint your golden retriever riding a unicycle.

Round 2: The Overconfidence

Humans: "AI can never replace me."Also humans: Use AI to spell-check their own name.

Meanwhile, AI confidently predicts 47 wrong stock prices and still calls itself "intelligent."

Basically, both sides are bluffing.

Round 3: The Plot Twist

AI isn’t here to replace humans. It’s here to remind us how bad we are at giving instructions.And The AI Alchemist? It’s like Google Translate for your brain’s chaos.

You type confusion.It gives clarity.Your AI finally stops crying in binary.

The Grand Finale

So who’s dumber — AI or humans?Yes.

But at least one of us can get smarter.Hint: it’s you.

Visit The AI Alchemist and evolve your prompts before your AI starts unionizing.

Because if the future is written in code, your prompt is the pen.Might as well write something smart.

The Future of AI Automation in the Military: Warfare by 2030

Sat, 04 Oct 2025 14:13:56 +0000

The Future of AI Automation in the Military: Warfare by 2030

By 2030, AI will transform warfare, with autonomous drones, robotic sentinels, and AI-driven strategies dominating battlefields. Current examples, like Ukraine’s AI-assisted drone strikes (80% accuracy) and the U.S. DOD’s generative AI for mission planning, show the shift to human-AI hybrid operations. Technologies like drone swarms, digital twins, and AI-optimized logistics will enable multidomain dominance, favoring mass-produced unmanned systems over costly manned platforms. In a U.S.-China scenario, AI could use decoys and remote drone grids to outmaneuver foes.
Yet, risks abound: Israel’s Lavender AI exposed ethical pitfalls, with high civilian costs sparking “human-in-the-loop” debates. Legal frameworks must evolve to govern lethal AI, while soldiers face psychological strain trusting fallible machines. By 2040, wars may hinge on algorithmic speed and deception, but human oversight remains vital. The U.S. must scale production, boost AI literacy, and balance ethics to stay ahead in this AI arms race, ensuring the human spirit endures in an automated age.

Salesforce shifts developer focus from building data pipelines to orchestrating AI agents at scale.

Thu, 02 Oct 2025 13:11:07 +0000

Salesforce Targets Data Fragmentation With New Platform Tools for AI Developers

Salesforce is expanding its platform architecture with new tools designed to help developers build and manage AI systems that work with unified data structures.

The company announced updates to Data Cloud, MuleSoft, Tableau, and embedded security features. The changes address a common problem: most enterprise AI projects fail because data quality is poor, governance is inconsistent, and systems don't connect properly.

According to a RAND study cited by Salesforce, more than 80% of AI projects fail to deliver value. The company's response focuses on giving developers better tools to manage metadata, govern AI agents, and standardize how business terms are defined across systems.

What Developers Get

The platform updates include five main components that change how developers work with enterprise data and AI.

Data Cloud Context Indexing helps AI agents understand unstructured content like contracts, diagrams, and tables. The new indexing pipeline interprets this content through business rules, making it easier to extract specific information from large, disconnected datasets.

For example, a field engineer could upload a technical schematic and have an AI agent walk through a troubleshooting process step by step. What used to take hours can now happen in minutes.

Data Cloud Clean Rooms are now generally available. They let companies share and analyze data without exposing raw information. The feature uses zero-copy connectivity, which means you don't duplicate datasets. This reduces security risks, cuts storage costs, and helps with compliance.

Banks are already using this to compare transaction patterns and detect fraud faster. They can spot fraud rings in hours instead of weeks without exposing customer records to each other.

Tableau Semantics is a new semantic layer that connects to Data Cloud. It translates raw data into business language that both humans and AI can understand. Salesforce is releasing a Customer 360 Semantic Data Model that unifies data and metadata across different Salesforce clouds.

The bigger news here is that Tableau is working with industry partners to create a universal semantic interchange. This could standardize how different platforms define business terms.

If your marketing team defines "annual contract value" differently than your sales team, that inconsistency flows into every report and every AI model. Tableau Semantics aims to fix that by enforcing one definition across all systems.

MuleSoft Agent Fabric addresses what Salesforce calls "agent sprawl." As companies build more AI agents across different teams and platforms, coordination becomes a problem. Different agents do redundant work, create compliance gaps, and don't share information.

Agent Fabric gives you a single registry to manage every AI agent, no matter where it was built. A retailer could have separate agents for inventory tracking, price updates, and fraud detection that now work together. Price adjustments happen automatically, and fraud checks run in real time.

Embedded AI Security and Compliance adds security monitoring across the platform. The updates include integrations with security vendors to identify threats and manage compliance proactively.

Why This Matters for Developers

These updates shift what developers do day-to-day. Instead of building custom data pipelines that break when source systems change, you're working with a unified data foundation. Instead of writing integration code between every system, you're orchestrating agents that already have access to standardized data.

The semantic layer is particularly important. When AI agents pull from the same business definitions, their outputs become more consistent and easier to explain. That matters when you need to show why a model made a specific recommendation.

The Agent Fabric addresses a real problem that's emerging as companies deploy more AI. Without a way to register and manage agents centrally, you end up with duplicated work and security blind spots. Having one place to see what every agent does and how they interact helps you avoid those issues.

Clean Rooms solve the collaboration problem when working with external partners. You can build applications that analyze shared datasets without ever moving sensitive information. That opens up use cases that weren't possible before due to privacy and compliance concerns.

The Bigger Picture

Salesforce is positioning these tools as the foundation for what it calls the "Agentic Enterprise"—where humans and AI agents work together across every workflow. The company's approach focuses on three principles: ensuring AI outputs use unified business data, embedding security and compliance into every workflow, and keeping systems open to avoid vendor lock-in.

Two enterprise customers highlighted in the announcement show how this works in practice. AAA Washington is using the unified data foundation to create a complete view of their members, improving roadside assistance, insurance, and travel services. UChicago Medicine emphasized that healthcare AI must be built on trust, with reliable data ensuring accurate patient interactions.

For developers building enterprise AI systems, these updates provide infrastructure that wasn't available before. You get standardized semantics, unified data access, centralized agent management, and built-in security—all designed to work together.

The announcements come ahead of Dreamforce, which runs October 14-16 in San Francisco. More details about implementation and availability will surface during the event.

Theory Ventures has more engineers than investors. Here's why that matters for dev tools.

Mon, 29 Sep 2025 23:19:19 +0000

Why Theory Ventures Built a Developer Relations Team—And What It Means for Developers

Most venture capital firms treat developers as an afterthought. They chase enterprise deals, court C-suite executives, and make investment decisions based on spreadsheets and market projections. Theory Ventures does the opposite.

The $680M AI and data fund runs more software engineers than investors—four technologists to three investors. And they're not just for show. These engineers build agents, run hackathons, and debug tool calls alongside the developers at their portfolio companies.

"We believe a deep technical understanding helps us invest better," says Tomasz Tunguz, Theory's founder and a veteran of enterprise software investing. "We're playing around with the technology and using it in deployment. That gives us a sense for where the market is going."

This isn't marketing. Theory's head of AI was hired with a specific mandate: reimagine a venture capital firm running 1,000 agents every day. The team deploys MCPs, uses GEPA and DSP, and hosts quarterly internal hackathons. They live in the same environment you do.

Developers Don't Pull Punches

Tunguz knows developer feedback differs from traditional enterprise customer feedback. "Brutally honest," he says. "Developers pull no punches."

You can't sell developers on buzzwords or polished demos. They want to know which keyboard shortcuts you use and whether you've wrestled with Python environment problems. They spot fake expertise instantly.

"Being able to walk the walk is really important," Tunguz explains. "If we aim to invest in developer tooling and AI systems, we want to learn alongside developers implementing internally, just the way they implement internally."

Theory measures their developer relations success through engagement metrics—events hosted, positive feedback, community involvement. Like GitHub stars, these indicators sit a degree or two away from financial performance. But they matter because attention has become the scarcest resource in tech.

"With AI synthesizing everything, the most important thing to differentiate and attract attention is being genuine," Tunguz says.

What Developers Are Actually Struggling With

Theory's portfolio companies give them direct insight into what's actually hard about building with AI. Tool calling tops the list.

"Figuring out why an AI decides to call which tool when and why it doesn't consistently select to use that tool; that's one of the most challenging tasks developers face," Tunguz says.

The architecture question compounds the problem. Should a three-part tool run as a hardcoded script, or should the AI make intermediate decisions? When accuracy drops to 75-80% across three steps, end-to-end reliability falls below 60%.

Code generation works brilliantly now. Tunguz can define a task, let an agent work for two or three hours, and get successful results. The whole job has shifted to architecture. "It's not a line of code that I'll be writing maybe ever again," he says.

The second big shift: developers don't leave their IDE anymore. No more tab-switching to Stack Overflow. Everything happens in a single flow state, with context-aware help right in the terminal.

How Investment Criteria Is Changing

AI moves faster than any market Tunguz has seen. "You wake up and the world has changed. There's some new academic paper, some new architecture, some Chinese company that has distilled an American model."

The fastest way to lose money in venture capital used to be investing in an IDE. Nobody except IntelliJ ever made money on one. Now agentic coding companies are the fastest-growing investments Theory tracks.

"The IDE may be less valuable than it once was because most of the software is being automated anyway," Tunguz observes. Cloud Code recognized this early by focusing on the terminal instead of panels and intermediate state views.

The biggest pattern Tunguz sees in successful AI startups: AI provisioning the product directly. When Databricks acquired Neon, 75% of new Neon instances were being generated by AI. An application fires up a Postgres instance on Superbase or Neon automatically. No human involved.

Developers Are More Important Than Ever

AI hasn't diminished the developer's role in enterprise buying decisions. It's amplified it.

Contract sizes are increasing. Budget decisions now span both software and labor costs. "Should we hire this AI agent instead of hiring 10 new software engineers?" Tunguz asks. "The developer is the person best equipped to determine whether the agent can perform that level of work."

Theory invests in tools that grow from communities. Heroku grew from Rails. Supabase from TypeScript. Understanding the momentum behind these communities helps predict how broadly a tool will be adopted.

The next 18 months will bring opportunities in AI site reliability engineering, security automation and review, and education for software engineers and marketing engineers. But the biggest opportunity: staff-level software engineers that are actually AI.

"We're not there yet," Tunguz admits. "Junior developer work from an AI? You can get there. Staff level or senior architects? Still a ways to go."

Theory Ventures proves that a VC firm can walk the walk with developers. They're building with the same tools, hitting the same problems, and staying brutally honest about what works and what doesn't.

That's the kind of investor developers deserve.

Build AI Workflows Visually, Fully Local & Private with Agentic Signal

Wed, 20 Aug 2025 17:19:22 +0000

I just launched Agentic Signal — a visual AI workflow builder that integrates tightly with Ollama. Everything runs locally and privately, so there’s no cloud dependency.

Key Features

Visual drag-and-drop workflow creation
Full streaming support with local LLMs (Ollama)
Tool calling and external service integration (email, calendar, cloud storage, browser automation)
Conversation memory and structured outputs (JSON schema validation)
Model management right from the UI

Tech Stack

React, TypeScript, Vite, Deno, GraphQL Yoga, React Flow, Material-UI (MUI), Playwright, Docusaurus, JSONata, Ajv, Zod, Bun, Chart.js, SCSS, OAuth 2.0, Google APIs