Thirteen applications since mid-August. Thirteen polite silences.

Every one had a tailored CV. Every one had a cover letter mapped line by line to the job description. By the rules hiring used to run on, that candidate did everything right.

If your inbox looks the same, so did you.

You're findable. Findable is not chosen. The rules are the problem — and sitting still won't fix them. The rest of this piece is what to do instead, in order, starting today.

Your résumé is priced at zero. Here's why.

A résumé was never proof. It was a proxy. "Ten years at X" stood in for "can do the work." A degree stood in for "learned the theory."

Proxies only hold while they're expensive to counterfeit. Both broke the moment a plausible CV for any role became a forty-second task. Every candidate generates one now. Every candidate looks perfect on paper. Hiring managers know it — so they discount the document to zero and hunt for the one thing a prompt can't fake: something you built, in public, with a trail.

I spent this month taking notes while hiring managers explained why they picked the person they picked. Not one mentioned a degree, a certificate, or a years count. All of them described something the candidate had built or fixed.

Your résumé still does one job: it gets you past the ATS filter. That's all "findable" means. Treating the filter as the decision is the mistake.

Action 1 (today, 30 minutes): Audit your last 10 applications. If all you sent was a CV and a cover letter, you sent nothing a prompt couldn't produce. Stop tweaking the document. Start building the evidence.

The three probes behind every AI interview question

Every interview question about AI is a wrapper. Unwrap it and you find one of three probes:

• Experiment like a scientist — hypothesis, test, accept the result, move fast. Sounds like: "How would you automate this?"
• Stay close to the work — you can name which step of the workflow is broken, and which steps AI can actually improve. Sounds like: "Walk me through a process you rebuilt with AI. What didn't work?"
• Stay curious — you ask the customer the right questions before building anything. Depth, not breadth. Sounds like: "What did the customer actually need, and how did you find out?"

What a fail sounds like, and what a pass sounds like:

• Experiment. Fail: names a model and a prompt. Pass: "I don't know yet — here's how I'd find out, and how fast."
• Proximity. Fail: "I've used AI to improve workflows." Pass: names the step that breaks, then the step you actually automated — and why they weren't the same one.
• Curiosity. Fail: proposes the chatbot. Pass: went and asked the customer where the process loses them, before building anything.

Notice what isn't probed: knowing the most models. Fluency is table stakes, and it's spreading so fast it stops being a differentiator before you finish listing it.

Action 2 (this week): Write your three answers out loud. One experiment, one broken workflow step with names and numbers, one customer question you asked before building. If any of them still sounds like the "fail" column, that's your drill list.

Build a portfolio of process — the five artefacts that get you chosen

Chosen candidates don't show up with a better résumé. They show up with a portfolio of process. Five artefacts kept coming up in my notes:

1. One workflow you rebuilt with AI. Manual before, AI after, named and scoped. Yours — not a tutorial's.
2. A public write-up of it. A post, a blog, a repo README. Anywhere a hiring manager finds it before the interview.
3. A failure log. The automations that didn't work, and why. The most under-supplied artefact in hiring right now — and the most reliable signal of a scientist's mindset.
4. A technical deep-dive. Not "I use Claude Code." How the agent loop works. What your MCP server exposes. Where the tokens go.
5. A day in the life with agents. Which agents, which tasks, what you still do by hand and why. Video is best — it proves communication skill in the same footage.

The same pattern runs under all five: you walked into a process, found the broken step, fixed it with AI, and explained it to the team. That is the job now, whatever the title says.

Action 3 (this month, one artefact per week):

• Week 1: pick one workflow from your current or last job and rebuild a piece of it with AI. Small is fine. Real is required.
• Week 2: publish the write-up. A failure log is the most under-supplied artefact in hiring right now — so include what broke.
• Week 3: write the deep-dive. If you can't explain where the tokens go, learn it, then write it.
• Week 4: record one video walkthrough. Post it. Posting is how you prove the knowledge in your head exists outside it.

Interviews changed on both sides of the table

Candidates moved first. They record every interview, feed the transcript to an LLM, and ask where they were vague and what a stronger answer would have sounded like. Then they drill the weak answers before the next round. If you aren't doing this, the person you're competing with is.

Interviewers went the other way from what most candidates expect: deeper, not shallower. The coding round is less about syntax and more about one question — "show me how you'd do this with AI, and where you'd stop trusting it."

The strongest answer in my notes ran like this:

"This is my domain. Here's the workflow, here's the step I automated, here's the agent that does it, here's what I'd change next, and here's how I'd hand it to the team."

Now read the CV-bullet version: "Experienced with LLMs and agentic workflows."

One of these earns a second call.

Action 4 (every interview, from the next one on): Record it (where legal), transcribe it, and run one prompt: where was I vague, and what would a stronger answer have sounded like? Drill the weak spots before the next round. Fifteen minutes per interview. Your competition is already doing it.

The uncomfortable part

AI is opening roles faster than most people expected. For a lot of people it's the social elevator they've been waiting on — a way to skip the credential queue and be judged on the work itself.

Good news, with one catch: the elevator only stops for people who put the work where it can be seen.

So here's the sequence. Stop rewriting the CV. Build one workflow. Publish the write-up — failures included. Record your interviews and drill the weak answers. Four actions, and not one of them is "apply to more jobs."

Findable is the ATS. Chosen is the evidence.

Which artefact are you shipping first?

There's a new buzzword rolling through the AI world, and it landed with all the subtlety of a brick through a window: graph engineering. It's the top rung of what people are now calling a "scope ladder" — prompt, context, harness, loop, graph. Five labels since 2022, each one a bigger box for the same question: how do I get a useful result out of a model?

I've been a professional engineer for over twenty years. I've scheduled ETL pipelines in banks, queued jobs through Laravel at 3am in Amman, and watched trend after trend arrive dressed as a revolution when it was really a reorg. So let me save you six months: most of graph engineering is Airflow with a new coat of paint. But one part of it is genuinely real, it maps embarrassingly well to the queues you already run, and it's the only thing worth your time. Let me show you which is which.

First, the ladder is mostly one idea wearing five hats

Every label in that ladder exists because the one below it hit a wall. That's not a conspiracy — it's just how the industry works.

• Prompt → context: because perfect wording can't supply facts the model doesn't have. No sentence you write gets a model to know the date of your last production deploy.
• Context → harness: because a model that can only read can't change anything. It needed hands — tools, a filesystem — and a mirror: test output, compiler errors it could argue with.
• Harness → loop: because one pass through the tools rarely lands the job. Quality came from iteration count, not prompt cleverness. The people winning weren't writing better prompts; they were letting the agent fail and retry.
• Loop → graph: because one loop can't parallelise, can't specialise, can't independently check its own work. One context, one responsibility — and some jobs need an organisation, not a single worker.

Rungs two, three, and four — context, harness, loop — are so entangled that working engineers use the words interchangeably. Only two boundaries hold weight: the shift from instruction to information (01→02), and the shift from one worker to an organisation (04→05).

That last one is graph engineering. The rest of the ladder is the same idea in five different coats.

So what's actually new in graph engineering?

At rung five, the question stops being "how do I get one model to do a thing" and becomes "how do many loops wire together?" One word: topology. The scope is the whole system — several rung-04 loops, deterministic functions, validators, tools, and humans, all wired together.

The levers are nodes, typed edges, shared state, parallel branches, verifiers, handoffs, stop conditions, budgets. And here's my contrarian bit: none of that structure is new. DAG schedulers and workflow engines have been drawing these graphs for a decade. Airflow has been orchestrating dependencies since 2015. If all you want is to draw boxes and arrows and run them on a schedule, you could have done that when most LLM developers were still in high school.

The only truly new thing — the entire delta, the whole novelty worth your attention — is that the nodes now interpret their tasks instead of following fixed rules.

That's it. That's the whole revolution. And it's a big one, because it changes every implicit assumption you had. When a node is deterministic, you can trust it, unit test it, predict its cost. When a node is a model, it will occasionally lie to you — confidently, politely — and take as long and cost as much as it likes. Which means state, vetoes, and budgets stop being implied and have to become explicit. That's the real engineering. Everything else is paint.

Two things called the same name

Before you build anything, you need to know the term is split. "Graph engineering" means two genuinely different things, and a lot of the confusion in the hype is people using the same word for both:

• Meaning A — Orchestration graph. Nodes are units of work, edges are permitted transitions. This is control flow. Ecosystem: LangGraph, Mastra, Temporal. This one sits genuinely above loop engineering. My favourite one-liner for it: loops are subroutines, graphs are programs.
• Meaning B — Knowledge graph / GraphRAG. Nodes are entities, edges are typed relationships — caused, owns, wrote. This is data and retrieval. Ecosystem: Neo4j, GraphRAG pipelines. It's a smarter way to fill one context window. My favourite one-liner there: vector search finds things that sound like your question; a graph finds things connected to your answer.

The disambiguation question is brutally simple: are you routing work, or retrieving knowledge? A is control flow, B is data. They do compose — a node in graph A can retrieve by traversing graph B — but if you don't know which one you're building, you will build the wrong thing.

Do you even need a graph? Be honest

Here's the most useful thing I can hand you, and it's three questions:

1. Does the work have two or more sub-tasks that could run in parallel, or need different specialised context?
2. Do you need an independent check on the output — something other than what produced it?
3. Is there a point where a human must approve before work continues?

Two or more yeses? Build the graph. Zero or one? Stay on a single loop. A single well-guarded loop is cheaper, easier to debug, and good enough for most tasks. Reaching for a graph too early is the single most common way to turn a working agent into an unobservable mess. I've watched teams install LangGraph and instantly lose the ability to explain what their own system did on any given run.

And here's my strong opinion, stated plainly: don't install a graph framework yet.

A graph is a plain data structure plus a fifty-line runner. Build that first. You'll understand the failure modes from the inside, and you'll know exactly what a framework would actually buy you. There are genuine reasons to adopt LangGraph, Mastra, or Temporal later — durable checkpointing, human-in-the-loop pauses that survive days, time-travel replay, a visual trace UI. Those are real features. They are not reasons: "this is how everyone does it," or wanting the word graph in your architecture diagram, which I promise you a VP will not read as deeply as you think.

The five ways agent graphs die in the first month

If you do build one, the first thirty days will throw five traps at you:

1. The verifier shares the drafter's model and context. It rubber-stamps its own work — a model that wrote a thing will nod approvingly at that same thing. Give the verifier fresh context and an explicit checklist, or make it deterministic code.
2. Edges decided by free text. "I think we should retry" is not an edge. Return a validated enum; route anything unrecognised to escalate.
3. No step budget. A two-node cycle with no cap is an unbounded invoice. Every graph needs a global ceiling, not just per-node retries.
4. Every node is an agent. Threshold checks and enum routing belong in code. LLM nodes are for ambiguity only.
5. Unlogged runs. Without a per-node trace you can't answer "why did it do that?" — and that question arrives, without fail, on day three, from your boss.

The discipline that saves you from all five, in one line: an agent that runs out of budget escalates. It does not fail quietly.

Not every node should be an agent

Listen, this is the part too many architecture diagrams get wrong. The model is not the star of every scene. The split is not "use AI everywhere" — it's about where ambiguity lives.

• If it's deterministic, plain code wins. Invoice approval thresholds, plan-active checks, routing on a known enum — anything you can unit test is code, full stop.
• If there's ambiguity, an LLM earns its place. "Is this email a refund request?" Summarise, draft, translate. Planning under open conditions. Interpreting messy human input. That's model territory.

And here's the budget angle nobody puts in the blog posts: each LLM node multiplies your cost per run by roughly its retry ceiling. A node that retries five times isn't one model call — it's up to five, plus the verifier, plus the retries on that. The code/LLM split isn't just architecture; it's the difference between pennies per run and a bill that lands like a licence renewal on a Friday.

Here's the kicker: you've already built this

Now the part that should land hardest if you're a Laravel developer. Read this mapping and tell me it doesn't make you a little uncomfortable — because I already know the answer, I built this exact thing years ago:

• a node = a queued Job class (ClassifyTicket, DraftReply)
• a typed edge = a PHP enum the job returns, validated before dispatch
• shared state = an agent_runs row
• a trace = agent_run_steps rows: node, tokens, latency, cost
• a step budget = a steps_remaining column, decremented atomically
• a retry cap = $tries and $backoff
• a verifier = a Job allowed to re-dispatch its own predecessor
• a parallel branch = Bus::batch([...])
• a join node = the batch's then() callback
• a terminal state = a status enum: done, escalated, failed
• a human checkpoint = awaiting_approval, resumed by a controller action

Read that table again, slowly. You already know rung 05. The wiring is Laravel queues. The orchestration, the retries, the state, the escalations, the sits-awaiting-a-human — it's all there. Graph engineering isn't new. It's the architecture you've been building for twenty years, where the only thing that changed is the workers.

And that changed worker is the entire problem. Your old queue workers were deterministic — they did the same thing every time and failed predictably. Your new workers are non-deterministic and, occasionally, they will lie to you. Which is exactly why every edge now needs an explicit guard: a verifier, a hard attempt cap, a stop condition. That's not buzzword territory. That's just good engineering with the stakes raised, because the component in the middle of your pipeline has an opinion.

Not a rebrand. A rebrand plus one hard truth

So let me land this the way I started it. Most of graph engineering — the boxes, the arrows, the DAG you could draw in Airflow when Trump was still in his first term — is exactly what we've always drawn. A rebrand. New paint, same skeleton, and a lot of people charging consulting fees to draw it for you.

The one delta is real, and it's not the graph at all — it's the nodes that interpret their tasks. That single change forces state, vetoes, and budgets to become explicit instead of implied, and that's where the genuine engineering work of the next decade is going to happen. The engineering lives in the edges, not the node count. Always has.

So my advice: don't chase the graph framework — chasing the word graph in your diagram is how money disappears. Build the plain data structure. Build the fifty-line runner. Give each node a guard. Log everything. And for the love of your own sanity, leave an escalate edge — every graph needs a door marked give this to a human.

Because here's the provocation I want to leave you with: the AI field is not discovering orchestration. It's rediscovering it, badly, and selling it back to you as new. The question isn't "should I adopt graph engineering?" The question is whether you'll notice you've known the answer since your first queue worker. The only thing new under the sun is that the workers now have opinions. Tell me — how are you planning to verify theirs?

I've watched the same pattern for 20 years. Developer learns React. Developer learns Next.js. Developer learns the next abstraction layer. Salary plateaus anyway.

The ceiling isn't technical. It's architectural. It's the gap between "I write code" and "I own outcomes."

At Alrajhi, I see this daily. Two engineers, same stack (Laravel, Next.js, React Native), same years of experience. One makes $60K. The other makes $78K-plus. The difference? Seven specific capabilities that have nothing to do with syntax.

Skill 1: Production Incident Ownership

Most developers run from production fires. The $18K premium goes to the ones who run toward them.

I'm not talking about on-call rotation theater. I mean true ownership: the 3AM alert, the corrupted transaction state, the AI agent that's hallucinating payment authorizations. You stay until root cause. You write the post-mortem that actually changes system design.

In our banking infra, we had a Laravel queue processor that would silently fail on specific Arabic character encodings. Three teams knew about it. One engineer — now our platform lead — spent a weekend tracing through Horizon, MySQL binary logs, and downstream React Native sync states. Fixed it permanently.

That's worth $18K. The skill isn't debugging. It's consequence absorption.

Skill 2: Cross-System Mental Models

Framework expertise has a half-life. Laravel 11 looks different from Laravel 5. But the physics of distributed systems? That compounds.

The engineers who break salary ceilings can hold three system layers simultaneously:

• The Next.js frontend's hydration boundary
• The Laravel API's queue concurrency and connection pool
• The React Native bridge's async storage and offline conflict resolution

And they see how changes in one create tsunamis in others.

In MENA fintech, this matters more than Silicon Valley. Our users have intermittent connectivity. Our regulators demand audit trails that cross mobile, web, and core banking. The engineer who can trace a transaction from biometric auth in Riyadh to ledger commit in Jordan — that's architectural thinking. That's premium pricing.

Skill 3: AI Agent Orchestration (Not Just Prompting)

Everyone's playing with ChatGPT wrappers. Few are building agent systems that survive enterprise reality.

Our AI agents at Alrajhi handle KYC document verification, fraud scoring, and customer service escalation. The $18K difference isn't who writes better prompts. It's who understands:

• Failure modes: What happens when the LLM hallucifies a regulatory threshold?
• Observability: How do you trace an agent decision through to audit requirements?
• Human-in-the-loop design: Where does friction actually help vs. hurt?

I built a Laravel-based agent orchestrator that routes between GPT-4, Claude, and local models based on latency, cost, and confidence thresholds. The hard part wasn't the API calls. It was the circuit breakers, the fallback chains, the rollback mechanisms.

That's infrastructure thinking. That's the premium.

Skill 4: Regulatory Translation

In emerging markets, compliance isn't overhead. It's competitive moat.

Saudi SAMA regulations. Jordanian CBJ requirements. UAE DFSA frameworks. The engineer who can read a 200-page circular and translate it into system constraints — database schemas, API rate limits, retention policies — becomes irreplaceable.

I once spent three weeks mapping SAMA's "customer due diligence" requirements to our Laravel models. Sounds boring. But that mapping became the foundation for our AI agent training data, our React Native offline sync logic, and our Next.js admin dashboards.

Regulatory fluency is domain expertise with teeth.

Skill 5: Migration Physics

Greenfield projects are rare. Brownfield resurrection is the real work.

The $18K skill is migration architecture: moving live systems without breaking the money pipe.

We recently migrated a core Laravel 8 monolith to a modular Laravel 11 structure with event sourcing. The technical patterns are documented. The hard part was:

• Hot migration: Dual-write periods, verification scripts, rollback windows
• Stakeholder gravity: Convincing risk committees that "zero downtime" is achievable
• Team momentum: Keeping 40 engineers productive while the ground shifts

Migration physics is about headroom — the space you create for others to work while you rebuild the floor.

Skill 6: Cost-to-Complexity Arbitrage

Cloud bills are the new performance optimization. But most engineers optimize locally.

The ceiling-breaker sees cost architecture: which systems need GPUs, which can run on spot instances, where caching actually pays off vs. where it's premature optimization.

I cut our AI inference costs 40% by moving from synchronous OpenAI calls to async Laravel queues with local model fallbacks. The React Native app got faster (less waiting on network). The Next.js dashboard got richer (more budget for complex queries). The agents got more reliable (rate limit protection).

Cost optimization is system design with economic constraints.

Skill 7: The Documentation of Decisions

Not code comments. Not wiki pages. Decision records that survive turnover.

Every $18K premium engineer I know maintains ADRs (Architecture Decision Records) that capture:

• What we considered
• What we rejected and why
• The consequences we're accepting
• The conditions that would make us reconsider

In Jordan's tight talent market, this is survival infrastructure. When your senior Laravel engineer moves to Dubai, the decision context doesn't leave with them.

I have 200+ ADRs in our repo. Some from 2019. I still reference them when new engineers ask "why not GraphQL?" or "why not serverless?" The answers are contextual, not absolute. Documented context preserves institutional velocity.

The MENA Multiplier

Here's what the generic "7 skills" articles miss: geography changes the value function.

In MENA fintech, these skills compound:

• Regulatory translation × emerging market complexity = rare expertise
• Migration physics × legacy core banking = high-stakes differentiation
• AI agent orchestration × Arabic NLP gaps = genuine innovation opportunity

We're not implementing Silicon Valley playbooks. We're building on sand that shifts — regulatory, infrastructural, cultural.

The $18K premium isn't about being 20% better at React. It's about being the person who can navigate uncertainty while shipping systems that move money.

The Real Ceiling

After 20 years, here's my contrarian take: salary ceilings are consent structures.

Most developers accept the frame they're given. "Senior" means 5 years. "Staff" means 10 years. The ceiling is imaginary until someone breaks it.

The seven skills above aren't about climbing a ladder. They're about making the ladder irrelevant. When you can own production, translate regulation, orchestrate AI, and document decisions that outlast your tenure, you stop competing on years-of-experience.

You compete on risk absorption.

And banks — especially in MENA, especially in fintech — will pay for risk absorption. Because the alternative is systems that fail in ways that make headlines.

What I'm Building Now

At Alrajhi, we're pushing these skills into our hiring and promotion frameworks. Not buzzwords. Specific demonstrations: incident post-mortems, migration plans, agent observability dashboards, ADR portfolios.

The engineers who show up with these? We fight to keep them. The ones who don't? We invest until they do, or we make hard decisions.

Your move: which of these seven are you actually demonstrating, not just claiming? And what's the one production system you're avoiding ownership of because the consequences feel too heavy?

I used to write prompts like I used to write Laravel controllers in 2014 — verbose, defensive, convinced that more lines meant more control.

Hundreds of tokens setting context. Chain-of-thought examples. Five-shot demonstrations. Personality frameworks. Temperature lectures. I was building prompt cathedrals when I needed sledgehammers.

Then I watched our AI agent handling KYC verification at Alrajhi Bank choke on its own instructions. 400-token prompt. 8-second latency. Context window bleeding. The agent was spending more energy parsing my prose than reasoning about the customer.

That's when I started cutting. Ruthlessly.

Gravity as a Feature

Here's what 20 years of system architecture taught me: constraint creates clarity. Not the other way around.

In Laravel, we learned this with Eloquent. In Next.js, we learned it with server components. In banking infrastructure, we learned it when every millisecond of latency costs real money and regulatory scrutiny.

My current prompt for our fraud-detection agent:

"Flag transaction. Explain in Arabic. Confidence 0-1. No speculation."

Twelve words. The agent doesn't wander. The agent doesn't hallucinate policy interpretations. The agent does one thing with defined boundaries.

The MENA Reality Check

Let me be direct about where I'm sitting. Jordan. Three hours from Riyadh. Building for a market where "enterprise AI" still means most vendors are selling snake oil wrapped in English-language documentation.

Our users don't need AI that sounds like a McKinsey deck. They need decisions. Fast. In Arabic. With audit trails.

The friction of verbose prompts isn't just latency. It's translation debt. English-heavy prompting creates a middle layer of cultural misalignment. Our agents were answering questions nobody asked because the prompts assumed Western banking contexts.

Twelve Arabic words — or twelve English words that map cleanly — cuts through that. No abstraction tsunami. No context collapse.

What I Actually Built

Our stack at Alrajhi: Laravel for core banking APIs, Next.js for internal dashboards, React Native for customer-facing apps. The AI layer sits between, orchestrating agents for credit scoring, document verification, compliance checks.

I rebuilt our three heaviest agents last quarter with the 12-word constraint.

Before: 340-token average prompt, 4.2s response time, 12% hallucination rate on edge cases.

After: 89-token average prompt, 1.8s response time, 3% hallucination rate.

The hallucinations didn't drop because the model got smarter. They dropped because I stopped confusing it.

The Mechanics of Collapse

How do you actually do this? Not by being clever. By being mechanical.

1. One Domain Verb

"Flag." "Extract." "Compare." "Route." Not "analyze and determine whether there might be indicators suggesting." That's not precision. That's throat-clearing.

2. One Output Format

"JSON with keys: decision, confidence, reasoning." Not "please provide your response in a structured format that includes." The model knows JSON. Name the schema and move on.

3. One Constraint Boundary

"No speculation" is doing heavy lifting. It creates a wall. The agent hits it and stops. Without that wall, it keeps generating — confident-sounding nonsense about patterns it half-perceives.

4. One Localization Anchor

"Explain in Arabic." Not optional. Not "if relevant." Our regulators read Arabic. Our customers read Arabic. The default English bias of most LLMs is a compliance risk I'm not taking.

The Infrastructure Angle

From an infra + UX lens, this matters more than it looks.

Short prompts mean smaller context windows. Smaller context windows mean:

• Cheaper inference — we're seeing 40% cost reduction on our OpenAI bill
• Faster caching — similar prompts hit Redis more often
• Cleaner observability — I can actually read the prompts in our logs without scrolling
• Easier A/B testing — swapping 12 words is surgical; swapping 400 is archaeology

In Next.js terms: it's the difference between server components that ship minimal JS and a bloated bundle that ships everything just in case. The browser — or the LLM — pays for your indecision.

What I Cut (And Don't Miss)

Gone: "You are a helpful assistant." The model already knows this. It's either true and redundant, or false and ignored.

Gone: "Think step by step." Chain-of-thought doesn't need an invitation. The model reasons or it doesn't. The instruction adds tokens, not capability.

Gone: Examples in the prompt. We moved to fine-tuned adapters. One-time cost, permanent behavior. Prompt examples are runtime tax.

Gone: Temperature settings in prose. "Be creative but accurate" is meaningless. We set temperature=0 in the API call and describe the task. The model doesn't need to be told its own hyperparameters.

The React Native Parallel

Our mobile team felt this immediately. They were building a chat interface for our AI agents and drowning in loading states.

Four-second prompts meant four-second spinners. In Jordan's mobile networks — where 3G still exists and patience is a currency — that's abandonment.

Collapsing to 12-word prompts cut perceived latency more than any optimization we tried. The physics are simple: less data over the wire, faster token generation, earlier streaming starts.

They didn't change the UI. I changed the gravity underneath it.

When Long Still Lives

I'm not a fundamentalist. Some problems need walls of text.

Legal contract analysis. Multi-party negotiation. Creative writing where voice matters. Our credit policy agent still carries 200 tokens of regulatory framework because the complexity is real.

But I audit it monthly. I cut 10% every time. The framework creeps. Gravity wins by default.

The difference: intentional complexity versus accumulated cruft. Most long prompts I see are the latter. Written once, never reviewed, cargo-culted across systems.

The Enterprise Trap

Here's what frustrates me about banking AI discourse. Vendors selling "enterprise solutions" with prompt templates that read like terms of service. Layer upon layer of "safety" that just creates ambiguity.

Our procurement team loves these. Boxes checked. Compliance theater complete.

My engineering team hates them. We can't see what the agent actually does. We can't debug failures. We can't optimize.

Twelve-word prompts are un-auditable in the best way. They're so simple that review is instant. No hidden logic. No emergent behavior from prompt interactions.

In emerging markets, this matters double. We don't have the headcount to maintain prompt engineering teams. We need systems that stay comprehensible when the person who built them is on vacation or has left.

The Fine-Tuning Pivot

The real unlock came when we stopped trying to prompt our way to behavior and started training for it.

Laravel's ecosystem taught me this. You don't write 500 lines of validation logic. You write a FormRequest. You declare rules. The framework handles the rest.

We fine-tuned a small model on our 12-word patterns. Now the "prompt" is often just the verb and the data. The behavior lives in weights, not tokens.

Cost: $2,400 for the fine-tuning run. Benefit: 60% inference cost reduction, sub-second responses, behavior that's testable rather than promptable.

This is the direction. Prompts as interface, not implementation. The shorter the interface, the cleaner the contract.

What I'm Watching

Claude's 3.5 Sonnet. Google's Flash. OpenAI's 4o-mini. The race to fast, cheap, capable is compressing the prompt window whether we like it or not.

Models are getting better at implied instruction. They're learning that "flag transaction" in a banking context carries assumptions about what matters. The prompt can shrink because the context is richer.

This is the tsunami coming. Developers still writing 500-token prompts are building on sand. The models don't need your scaffolding anymore. They need your intent, cleanly stated.

The Question

I cut my prompts to 12 words because I was forced to — by latency, by cost, by Arabic localization, by regulatory scrutiny in a market that doesn't forgive slowness.

What's forcing you?

Or are you still building cathedrals nobody asked for, waiting for the gravity you refuse to see?

Building AI agents for banking in Amman. Laravel, Next.js, React Native. Twenty years of watching complexity collapse. Always looking for the 12-word version.

Three months ago, I watched a Laravel queue worker I'd written get replaced by an AI agent that wrote its own retry logic.

Not because the agent was better. Because I spent six hours in a meeting arguing whether our Next.js admin panel should show agent confidence scores or raw token probabilities. While the agent kept shipping.

That's when it hit me: I'm not fighting AI for my job. I'm fighting to stay technical while becoming a manager I never asked to be.

The Friction of "Vibe Coding"

You've seen the demos. Cursor, Claude Code, Lovable — type a prompt, get a deployable branch. The MENA startup ecosystem is drowning in founders who think they've eliminated engineering.

They're wrong. But so are we.

The friction didn't disappear. It moved up the stack. Now I spend my mornings at Alrajhi Bank reviewing agent-generated React Native modules not for syntax errors — those are gone — but for:

• Regulatory compliance: Does this KYC flow satisfy SAMA's sandbox requirements?
• Audit trails: Can we prove why the agent chose this biometric vendor?
• Failure modes: When the LLM hallucinates a Saudi IBAN format, who's on-call?

The code is cheap. The context is expensive.

From Artisan to Air Traffic Controller

Twenty years ago, I measured productivity in commits. Now I measure it in decision velocity.

My team runs 12 autonomous agents across our banking infrastructure. Each agent has:

• A budget ceiling (inference tokens + API calls)
• A risk profile (can it touch prod? customer data? core banking APIs?)
• An escalation ladder (when does it wake a human?)

Sound familiar? That's management. I'm running a distributed team where half the "engineers" are stochastic and need constant performance reviews.

The Laravel applications I maintain now serve as governance layers — not business logic executors. My Next.js frontends are observability dashboards for agent behavior. The actual "work" happens in headless loops I can't step through with a debugger.

The MENA Reality Check

Jordan's tech scene taught me something Silicon Valley misses: infrastructure constraints breed better managers.

When your GPU cluster lives in Frankfurt because AWS Riyadh doesn't have the capacity, you learn to optimize for latency of decision-making, not lines of code. When your mobile banking app needs to function on 3-year-old Android devices with intermittent connectivity, you can't afford agent experiments that "mostly work."

I see Egyptian fintechs, Emirati neobanks, Saudi payment rails — all converging on the same pattern. The engineers who thrive aren't the ones prompting hardest. They're the ones who architect the guardrails.

What "Managing" Actually Means Now

Let me be specific about what changed in my daily work:

Budget ownership: Every agent invocation is a line item. I negotiate with finance whether our fraud detection agent gets GPT-4 or Claude 3.5 Sonnet based on latency/cost trade-offs. That's resource allocation.

Stakeholder translation: Business wants "AI personalization." I translate that into: agent prompt templates, A/B test frameworks, fallback rules when personalization violates SAMA guidelines. That's requirements management.

Team health: My human engineers are burning out faster because the cognitive load shifted. They're not debugging code — they're debugging intent alignment between agents. That's people management.

Risk posture: When an agent suggests a database migration based on schema inference, I'm the one who says no. Not because it's wrong. Because I can't prove it's right to an auditor. That's governance.

The Stack Becomes the Org Chart

Here's what hurts: the tools I love are becoming management interfaces.

Laravel used to be about elegant Eloquent relationships. Now it's about authorization policies for agent actions — can this service account trigger a wire transfer? Should it?

Next.js used to be about SSR performance. Now it's about streaming agent responses — how do we render confidence intervals in real-time without freezing the UI?

React Native used to be about bridge modules and native performance. Now it's about offline-first agent synchronization — how do we queue agent tasks when the user loses signal in rural Jordan?

The architecture diagrams I draw look less like layered cakes and more like organizational charts — with humans, agents, and legacy systems as nodes, and trust boundaries as the edges.

The Headroom Problem

There's a ceiling on how much complexity one human can orchestrate. I used to think that ceiling was cognitive — how much code can I understand?

Now I know it's attentional. How many agent contexts can I hold simultaneously while remaining accountable for outcomes?

At Alrajhi, we're experimenting with meta-agents — systems that manage other agents. This should solve the scaling problem. Instead, it created a recursive management burden: who manages the meta-agent? Who reviews its reviews?

The answer, so far, is me. And every engineer I know in similar roles.

What We Lose, What We Keep

I miss the gravity of production deploys. The certainty that I wrote the logic, I understood the edge cases, I could explain the failure mode to a regulator at 3 AM.

Now I ship systems I can only characterize statistically. "This agent performs 94% accuracy on our test suite" — that's not engineering. That's quality assurance for a black box.

But here's what I gained: leverage at a different scale. One engineer with good agent orchestration can cover what used to require a squad. In emerging markets where technical talent is scarce and expensive, that's not optional. That's survival.

The Contrarian Take

Everyone says "learn to prompt better." I say: learn to manage better.

Prompt engineering is a local maximum. The engineers who will own the next decade are building:

• Evaluation frameworks (how do you know your agent improved?)
• Fallback architectures (what happens when the LLM provider changes their model?)
• Audit infrastructure (how do you reconstruct a decision for compliance?)

These aren't coding skills. They're organizational design skills applied to software.

The Jordanian Perspective

In Amman, we have a phrase: "El-maktaba elly ma feeha ketaab, ma feeha 3alam" — the library without books has no flags. Meaning: you need substance to signal status.

The global AI discourse is obsessed with flags — demos, benchmarks, hype. In MENA fintech, we're obsessed with substance — provable correctness, regulatory defensibility, operational resilience.

That makes us conservative. That also makes us better prepared for the actual future, where AI isn't a magic wand but a risk vector requiring constant supervision.

Your New Job Description

If you're still reading, you're probably wondering: what should I actually do?

Stop optimizing for code output. Start optimizing for system comprehension.

• Can you explain why an agent made a decision to a non-technical stakeholder?
• Can you design a circuit breaker that fails safely when agents disagree?
• Can you price the cost of an AI feature in tokens, latency, and cognitive load?

These are management questions. They're also engineering questions now.

The Tsunami Isn't Coming. It's Here.

I didn't choose to become a manager. The architecture of modern systems — especially in regulated industries like banking — made it inevitable.

The developers who resist this shift will find themselves squeezed between "vibe coders" who ship faster and cheaper, and "AI engineers" who actually understand the systems underneath. There's no middle ground anymore.

Your choice isn't whether to manage. It's whether to manage well — with explicit frameworks, measurable outcomes, and honest accounting of where human judgment adds value.

Or to manage poorly — by pretending you're still just "coding" while the complexity tsunami washes over you.

The Real Question

Twenty years in, I've learned that disruption doesn't replace expertise. It relocates it.

The expertise that mattered in 2005 was algorithmic. In 2015, it was architectural. In 2025, it's orchestrational — the ability to compose reliable systems from unreliable components, human and artificial.

So here's my provocation: When was the last time you wrote code that no agent could have generated — not because of complexity, but because of accountability?

If you can't answer that, you're already a manager. The only question is whether you're getting paid like one.

Every AI agent demo looks perfect.

Clean transcripts. Happy paths. Customers who speak in complete sentences and never interrupt themselves. I've sat through fifty of these pitches at Alrajhi Bank. The gap between demo and production is a canyon.

Here's what actually happens when your banking AI agent hits real users in Riyadh, Amman, or Cairo: code-switching between Arabic dialects, background noise from busy streets, customers who don't know their own account types, edge cases that break your intent classification in ways you couldn't imagine.

Your synthetic training data? It's architectural fiction.

Why I Started Recording Everything

Two years ago we built our first voice agent for balance inquiries and transfers. Standard stuff. Laravel backend, Next.js admin panel, React Native for the mobile interface.

We trained on 10,000 synthetic conversations. Beautiful dataset. Grammatically perfect. Covered every feature flag in our spec.

Week one in production: 34% containment rate. The agent couldn't handle a customer who said "habibi I need my money" instead of "transfer funds." Couldn't parse the Jordanian dialect "shu" as a question marker. Crashed on overlapping speech when someone's kid grabbed the phone.

We were flying blind. No recordings, no telemetry, just logs saying "intent_classification_failed."

That failure taught me something I've applied to every AI project since: the conversation is the infrastructure. Not the model. Not the prompt engineering. The raw, messy, recorded reality of how humans actually talk to machines.

What "Recording Everything" Actually Means

I'm not talking about compliance recording for legal teams. That's table stakes in banking.

I mean engineering-grade capture:

• Full audio streams with speaker diarization (who spoke when)
• Real-time transcriptions with confidence scores per word
• Latency metrics for every turn in the conversation
• Context state snapshots at each decision point
• Model outputs with their probability distributions
• Fallback triggers and the exact user utterance that caused them

In our Laravel backend, we built a pipeline that treats every call as a structured event stream. Audio chunks flow through Redis streams, get processed by Whisper for transcription, then land in ClickHouse for analysis. The React Native client uploads compressed audio with session metadata. Our Next.js dashboard lets engineers replay conversations with full context reconstruction.

This isn't Big Brother surveillance. It's observability for conversational systems.

The MENA Reality Check

Working from Jordan, I see how Western AI assumptions crumble in emerging markets.

Your average Saudi customer might start a conversation in formal Arabic, switch to Najdi dialect when frustrated, drop English technical terms, then code-mix with Urdu if they're South Asian. Try training your standard OpenAI or Anthropic model on that without real recordings.

Network conditions matter too. Our React Native app sees call quality ranging from pristine 5G in Riyadh financial district to degraded audio on 3G in rural Jordan. Without recorded samples across this spectrum, your noise robustness is theoretical.

And don't get me started on cultural friction patterns. In some MENA markets, customers repeat security information slowly because they don't trust the system understood. In others, they speak fast to test if the agent is actually listening. These behaviors don't appear in synthetic data. They only emerge when you have walls of real calls to analyze.

How We Use Recordings to Build Better Agents

Our current workflow at Alrajhi looks like this:

Week 1-2: Shadow Mode

New agent runs alongside human agents. We record everything but don't automate responses. The AI generates replies, we compare against what humans actually said, measure divergence. This catches intent misclassification before customers see it.

Week 3-4: Graduated Rollout

We enable the agent for 5% of traffic, but with aggressive escalation triggers. Every escalation gets tagged with the audio snippet that caused it. Our Laravel pipeline automatically surfaces clusters: "agent failed on balance inquiries over 1M SAR," "confusion between 'transfer' and 'payment' verbs."

Month 2+: Continuous Mining

We run weekly jobs that:

• Extract high-entropy utterances (low confidence, multiple intent matches)
• Find conversation patterns that led to human takeover
• Identify successful repair sequences (where agent recovered from misunderstanding)
• Build synthetic training data from real patterns, not imagined ones

This last point matters. We don't use raw recordings for training (privacy, compliance, PII). We use them to understand what to synthesize. The recordings tell us where our synthetic data was wrong.

The Technical Architecture

For engineers who want specifics, here's our stack:

Ingestion Layer

• Twilio/Media Streams for telephony audio
• React Native SDK with custom audio compression (Opus, 24kbps)
• Laravel queue workers for stream routing

Processing Pipeline

• Whisper v3 for transcription with fine-tuned Arabic dialect support
• Speaker diarization via pyannote.audio
• Real-time intent classification with our own fine-tuned BERT variant

Storage & Retrieval

• Audio: S3 with lifecycle policies (30 days hot, 1 year glacier)
• Metadata: ClickHouse for fast analytical queries
• Search: Elasticsearch for transcript full-text + phonetic matching

Analysis Tools

• Next.js dashboard with conversation replay
• Jupyter notebooks for pattern mining
• Automated alerting on containment rate drops

The whole system adds about 200ms latency to calls, which is acceptable for banking use cases. For high-frequency trading or real-time payments, we'd need edge deployment. Trade-offs everywhere.

What You'll Actually Find

After six months of recording, here's what we discovered about our "simple" balance inquiry agent:

• 23% of calls included at least one non-task utterance (greeting, complaint about previous service, small talk)
• Edge case explosion: 147 distinct ways customers asked for "recent transactions," none appearing in our original training set
• Recovery patterns: The most successful agent recoveries used acknowledgment phrases specific to Saudi Arabic politeness norms, which our synthetic data completely missed
• Silent failures: 8% of calls where the agent gave technically correct but practically wrong answers (customer asked for "last transfer," agent gave last incoming transfer, customer wanted last outgoing)

These aren't bugs you find in testing. They're gravity. They're the weight of real usage pulling your system toward its actual shape.

The Privacy Engineering Problem

I know what you're thinking. Banking. Recordings. Compliance nightmare.

Yes. And it's solvable.

We built PII detection directly into the Laravel pipeline. Audio streams get scanned for credit card numbers, account numbers, national IDs before storage. Transcripts are redacted automatically. Access controls are granular: engineers can see patterns, not individual calls, unless specifically authorized for debugging.

In Jordan and Saudi Arabia, regulatory frameworks are evolving fast. We work with legal teams to ensure consent flows are clear. The React Native app explicitly asks for recording permission with specific use case explanations, not blanket "improve our service" language.

The alternative — not recording, not knowing — is worse. You ship blind. You discover failures through customer complaints and regulatory fines rather than engineering analysis.

Before You Ship That Agent

If you're building AI agents for enterprise — especially in regulated industries, especially in complex linguistic environments — here's my checklist:

1. Recording infrastructure first. Not after. First. Before you train your model, before you write your prompts, you need the pipeline to capture reality.

2. Synthetic data is a starting point, not a substitute. Use it to bootstrap. Replace it with distributions derived from real recordings as fast as possible.

3. Measure containment, but also measure confidence calibration. An agent that escalates appropriately is better than one that's confidently wrong.

4. Build for dialect, noise, and interruption from day one. These aren't edge cases. They're the center of mass in emerging markets.

5. Create feedback loops where engineers hear the failures. Not dashboards. Actual audio. The emotional weight of a frustrated customer teaches more than any metric.

The Real Question

Most teams building AI agents are optimizing for demo day. Clean transcripts, happy paths, metrics that look good in pitch decks.

The teams that survive production are optimizing for friction visibility. They want to see where the system grinds against reality. They build recording infrastructure not despite the complexity, but because it reveals truth.

We're about to deploy our third-generation agent at Alrajhi. It handles complex multi-turn conversations, integrates with our core banking systems through Laravel APIs, serves customers across three countries. The difference between this generation and our first attempt isn't better models or bigger training sets.

It's 400,000 recorded conversations showing us exactly where we were wrong.

So here's my question for you: What's your plan for capturing reality? Or are you still building in the clean room, hoping the world will cooperate with your assumptions?

Three agentic AI vendors pitched us last quarter. Every pitch had the same shape. A fast demo, perfect context, and a price that assumed compute was free.

Then you ask about throughput. About audit trails. About what a hallucinated compliance decision costs at two in the morning while the transaction pipeline is already saturated.

What are the five agents, and what is each one allowed to decide?

Five agents run in production. None of them decide anything by themselves. Each produces a draft, a score or a suggestion, and a person signs it.

That last column is the design. Everything else is implementation detail.

How do you generate API contracts from documentation that lies?

By treating the documentation as a hint and the response samples as the truth. We integrate with more than 40 third-party APIs: card networks, local switches, government identity services. Their documentation includes PDFs scanned in 2019, Swagger files that disagree with the endpoint, and services that return HTTP 200 with an HTML error page in the body.

The agent runs inside a GitHub Actions workflow rather than a chat window. It pulls the current spec or scrapes whatever passes for documentation, generates strict TypeScript from real response samples, writes Laravel FormRequest classes with validation extracted from the field descriptions, and opens a pull request whose description is the breaking-change analysis.

The win was not speed. It was that the mobile team stopped shipping type errors into production.

What does a regulator's audit request actually require?

Ninety days of transaction history, delivered inside 48 hours, with an evidence chain a person can follow back to the query that produced each number. That used to take four engineers three days. It now takes one agent and one compliance officer.

The agent has read-only views onto our transaction warehouse, ClickHouse underneath, and retrieval over our internal compliance playbook, vectorised in Postgres with pgvector. The output is a Markdown report with the SQL embedded, so the officer can rerun any figure rather than trust it.

Embedding the query next to the answer is the part worth copying. A number a reviewer cannot reproduce is a number that fails the audit, whatever produced it.

Why does data residency force inference onto your own hardware?

Because the transaction data cannot leave. That single constraint decides the model, the hardware and the budget, before anyone discusses quality.

So we serve an open-weight model on hardware we own, with vLLM in front of it. It is slower than a hosted frontier model and it costs more GPUs. It is also the only version of this that a regulator will accept.

Latency makes the same argument from a different direction. Regional fibre to Frankfurt runs around 60 ms on a good day, before the model has read a token. Hosted AI services are priced and designed around a latency budget that assumes you are next door to the datacentre. For anything a customer waits on, local inference is not a preference.

How do you stop shipping App Store rejections?

By testing against your own rejection history rather than against a generic checklist. Guideline 4.2, Minimum Functionality, is subjective, and it is applied unevenly across reviewers in our region. A rejection costs a launch window, not an afternoon.

The agent runs Maestro and Detox flows in CI. The judgement sits on top: it reads previous rejection reasons from the App Store Connect API, generates cases that target those specific patterns, flags screens that read as a wrapped web page, and produces a submission confidence score.

Apple did not get faster. We stopped submitting broken builds. The agent catches broken deep links, missing loading states and Arabic text truncating in right-to-left layouts. It cannot fix an app that is genuinely a wrapped website, and no agent can.

Should an agent remediate an incident on its own?

No. Not in a bank. Auto-remediation is a liability position, not an engineering one, so this agent is decision support for whoever is awake at three in the morning.

A PagerDuty webhook lands in a Laravel queue worker. The agent gathers recent deploys, database metrics and error logs, retrieves over our incident runbooks, and posts one Slack thread: likely root cause, a suggested rollback command, and the closest previous incidents.

During an annual bulk-payment run, card processing spiked 400%. The agent named the pattern correctly, bulk payment plus third-party processor throttling, and surfaced a manual failover procedure we had documented and never automated.

It also suggested a failover that would have broken our active-active architecture contract. A person caught it. That is the whole argument for keeping the last column of the table above empty.

What does a code review agent catch that generic tools miss?

The patterns that are only dangerous in your codebase. We tried the general-purpose review tools and they were too noisy to keep, because banking code has failure modes that a tool trained on public repositories does not recognise.

Ours takes PHPStan output as structured input and adds rules extracted from our own past incidents.

Only the last two are really about banking. The first two are the same mistakes I write about in what yabasha.dev actually runs, at a scale where nobody gets fined for them.

What does "no code" actually cost by month six?

The pitch deck said no code. Here is the inventory six months in.

The timeout row is the one that bit hardest, and I wrote up the general version of that failure in building production AI agents that actually work. A queued job whose timeout is shorter than the model call it makes does not fail loudly. It writes nothing.

Where do these agents still get it wrong?

In four places, consistently. I list them because the failures shaped the design more than the successes did.

The third one is current work. I am testing whether agents can negotiate schema mappings across reconciliation vendors better than people do, on the theory that agents do not get bored and do not assume an equivalence is obvious. They converge fast. They also converge on mappings that pass every type check and are wrong about the business.

Why is every agent a queue worker rather than an API endpoint?

Because it lets us change the model without shipping a mobile release. Every agent in this stack is Laravel-side. The React Native app and the Next.js frontend call ordinary APIs, and the model is an implementation detail behind them rather than part of the interface.

This is the same shape I use at a far smaller scale on my own site, described in how I built an AI agent for my portfolio, and the cost argument for it is in cutting LLM API costs 60%.

What is different about building this in MENA?

Three constraints that changed the architecture rather than the roadmap.

The third constraint is the one that decided the most. A design only your two best people can operate is not a production design.

What would I check before trusting an agent in a regulated system?

Work from the audit backwards. If a reviewer cannot reproduce the number, nothing else on this list matters.

• Every agent output a person signs is reproducible from the query or evidence embedded beside it.
• No agent executes anything. It drafts, scores or suggests, and a person acts.
• Anything touching money carries an explicit human-verification gate.
• The data-residency constraint is settled before the model shortlist, not after.
• Every model call runs behind a queue, so timeouts and retries belong to the queue rather than the caller.
• Model swaps are benchmarked against your own evaluation set before they reach production.
• The failure list is written down, and each entry has a named guard.

Measured with

Figures as stated in the original post, written from four years working remotely with an enterprise bank in the region. The bank is not named, and operational detail that would describe its security posture has been generalised.

• Laravel backend, Next.js web, React Native mobile
• More than 40 third-party API integrations
• Open-weight model served with vLLM on owned hardware; ClickHouse warehouse; Postgres with pgvector
• Regulator audit shape: 90 days of history inside 48 hours
• App Store submission to approval: 14 days before, 4 days after
• Six months of production agents at the time of writing

Questions: @bayyash

Same chair, same Ctrl+S, wildly different output. Last week I spent 4 hours debugging a Laravel queue that swallowed 2,000 card-transaction jobs. Yesterday I spent 4 hours debugging Henry (our Slack AI) who swallowed 2,000 card-transaction descriptions. Same dopamine hit when the log turns green, different muscle memory.

Google VP Josh Woodward says "everyone is becoming a manager". Cute. In our Amman office we’ve skipped the ceremony and jumped straight to the messy part: directing agents that can spin 10,000 lines of boilerplate before I finish my Turkish coffee.

The org chart is now a wiring diagram

Three months ago I drew this on the whiteboard for our RBI compliance meeting:

Bashar (Staff Engineer)
├── Henry-Draft (slack bot, Node 20)
├── Henry-Security (OpenAI gpt-4-turbo)
├── Henry-OnCall (PagerDuty webhook glue)
└── Bashar-HandsOn (me, 40 % headroom)

CFO stared at it like I’d committed tax fraud. Then I showed the numbers: Henry-Draft wrote 62 % of last sprint’s API specs. Henry-Security caught a PCI regex that would have cost us SAR 450k in fines. I still typed the final git push, but only after three agents debated variable naming like junior devs fighting over tabs vs spaces.

Taste is the new latency

Prompt engineering? Dead end. The compounding skill is taste — knowing when to let Henry hallucinate a JSON schema vs when to lock him in a straitjacket of Zod validation. Last Tuesday he spat out a transaction categorizer that classified “shawarma” as “charitable donation”. Funny until the regulator asks why Alrajhi’s risk engine thinks kebab shops are NGOs.

Same problem we had with offshore teams in 2012: garbage in, gospel out. Except now the offshore team is a 200-token context window and it never sleeps.

The trick is teaching taste at scale. We built a tiny Next.js app — internal codename TasteLinter — that scores each agent output on three axes:

1. Compliance (does it violate SAMA circular 12/2024?)
2. Risk (could this query expose PII?)
3. Aesthetics (is the generated Laravel resource route actually RESTful?)

Fail any axis and the PR auto-blocks. Henry hates it. Our auditors love it. Same friction, new surface.

Voice is not the interface — narrative is

Woodward talks about Gemini Spark making voice the interface. That’s surface glitter. The real shift is narrative compression. I can say “build a refund flow that handles partial capture, partial void, and triggers an SMS to the cardholder in Arabic” and Henry spins a 120-line Laravel job, a React Native screen, and an SNS template. But if I misplace one adjective the whole thing compiles into a money-losing disaster.

Voice lowers the floor. Judgment raises the ceiling. There’s still no autocomplete for consequences.

Middle management without the salary bump

Here’s the dirty secret from 23 years of banking tech: middle management was always 80 % translation work. Translate business into Jira. Translate Jira into code. Translate code into outage reports. Agents just made the translation layer thinner.

I now spend my mornings curating instead of coding. Example: Henry generated a fraud-detection heuristic that looked brilliant until I realized it used customer email domain as a signal. In Jordan that flags every user with a .edu.jo address as high-risk — basically every university student in the country. One line of YAML, infinite reputational damage.

So I curate. I downgrade false positives the way I used to review pull requests. I leave comments like “use IFSC code, not email TLD” and Henry learns. The diff still shows my GitHub avatar, but the patch is 90 % machine-authored.

The gravity well of legacy

Nothing exposes the myth of “everyone is a manager” faster than a 2008 COBOL module sitting between your agents and the core banking switch. You can orchestrate Henry, Claude, and a fleet of GPT-4s, but if the mainframe only speaks 370-ASCII over MQ, you’re still stuck hand-rolling hex dumps at 2 a.m.

Legacy is the new middle management. It doesn’t report to you, but it approves all your vacation requests.

Promotion letter pending

HR hasn’t updated my title yet. Officially I’m Staff Software Engineer. Unofficially I manage:

• 3 AI agents (Henry variants)
• 2 offshore contractors (humans, for now)
• 1 legacy queue system (written in Java 6, immortal)
• 1 human intern (who thinks git rebase is dark magic)

Same paycheck, 4x the surface area for failure.

Your move

Look at your last week’s calendar. How many reviews were code vs agent behavior? If the ratio tips past 50 %, congratulations — you’re management. The org chart just didn’t send the memo.

So here’s my question: when performance-review season arrives, do we file the agents under direct reports or tools? Because right now they’re both, and the ambiguity is where the next outage hides.

#aiManagement #mideastFintech #agentOps

I started writing code in 2005. Not in a garage with a startup dream — in a bank, where "move fast" meant deploying quarterly and "break things" meant losing millions.

Twenty-one years later, I'm building AI agents that reason, plan, and execute autonomously. The journey between those two points wasn't a straight line. It was a series of controlled explosions.

The Banking Years (2005–2012)

Seven years in banking taught me one thing: systems that fail cost real money. Not theoretical money. Not VC money. Money that someone's pension depends on.

I learned to build for fault tolerance before it was trendy. Every line of code carried weight. Every deployment was a commitment. You don't unlearn that.

Banking gave me discipline. It also gave me a deep skepticism of anything labeled "revolutionary." I've seen too many "game-changing" architectures that couldn't survive a Monday morning traffic spike.

Humanitarian Tech (2012–2018)

Then I went where most engineers don't: humanitarian operations.

Imagine building systems where the users are field workers in disaster zones, connectivity is intermittent at best, and the data you process determines whether food reaches 10,000 people or 100,000.

This is where I learned about constraints as architecture. When your network drops every 30 minutes, you design differently. When your users speak five languages and have limited tech literacy, you simplify differently. When the stakes are measured in human lives, you QA differently.

Humanitarian tech taught me that the best technology is invisible. It works. It doesn't ask for attention. It just does its job while the real work happens.

eCommerce & Operations (2018–2022)

eCommerce seems simple until you're handling inventory across multiple warehouses, processing thousands of orders a day, and your payment integration fails at 2 AM on Black Friday.

This phase taught me operational thinking. Not just building software — building systems that run operations. The difference is enormous.

An engineer builds a feature. An operations-minded engineer builds a feature that degrades gracefully, reports its own failures, and doesn't wake anyone up at 3 AM unless it actually matters.

The AI Pivot (2022–Now)

When I saw what was happening with large language models, I didn't see a shiny new toy. I saw a force multiplier for everything I'd built over 17 years.

Banking discipline + humanitarian constraints + operational thinking = the perfect foundation for production AI.

Here's what most people get wrong about AI engineering: it's not about the model. It's about the system around the model.

Anyone can call an API and get a response. The hard part is:

• Grounding outputs in real data (RAG)
• Building agents that don't hallucinate themselves into oblivion
• Creating fallback chains when the model gets it wrong
• Observing, measuring, and improving — not just deploying and praying

That's what I do now. I build AI systems that work in production. Not demos. Not proof-of-concepts. Systems that handle real data, real users, and real consequences.

What 20 Years Actually Teaches You

Here's the thing nobody tells you about a long career: the domains change, the principles don't.

• Build for failure, not just success
• Constraints are design inputs, not obstacles
• If it can't degrade gracefully, it's not production-ready
• The best architecture is the one nobody notices

These principles hold whether you're processing bank transactions, coordinating disaster relief, or deploying AI agents.

What I'm Building Now

Today I'm focused on Cortex (YabashaOS) — an AI operating system that brings structure to agent workflows. Alongside that: FinTrack for financial intelligence, AutomotiveAI for the automotive sector, and Jopal for document management.

Twenty years of banking, humanitarian work, eCommerce, and operations — all converging into AI systems that actually ship.

If you're building AI and wondering why your demo works but your production system doesn't, maybe you need someone who's spent two decades learning that the hard way.

That's what I bring to the table. Not just AI knowledge. Systems thinking forged in the trenches.

What's the one principle from your career that carried you through every domain change? I'd genuinely like to know.

I wrote a LinkedIn post last Monday in six minutes. It used to take forty.

Nothing got smarter. I stopped opening a blank chat and re-explaining who I am, what I am building, what I sound like and which words I will not use. I wrote that down once, in files, and the chat starts from there.

Is this about Claude Projects or Claude Code?

Projects. They are different products and the setup below does not transfer.

Claude Code is a coding agent that runs in your terminal and your editor, reads your repository, and edits files. Its configuration lives in CLAUDE.md and skill files inside the repo.

Projects are workspaces on claude.ai. Each one holds its own instructions and its own uploaded files, and every chat inside it starts with all of them loaded. That is what this post configures. If you came here for the terminal tool, this is not the post you want.

What does the two hours actually consist of?

Seven steps. Each one produces a file or a setting, and none of them is prompting.

That is 115 minutes. The two hours in the title is not a round-up for effect, which I only noticed while adding this table.

Why does a Project beat a good prompt?

Because the prompt has to be retyped and the Project does not. Three things make the difference.

Separate workspaces keep contexts from bleeding. A newsletter Project and a client-email Project do not share files, so neither inherits the other's tone.

Instruction adherence is the part I actually evaluate. If I write "never use the word leverage" and the model uses it anyway, the rules file is decoration. That is the test I would run before committing two hours to any tool, rather than taking anyone's word for which one holds up.

File memory removes the re-upload. Drop a folder of documents into a Project and every reply is written with them in scope.

Projects need a paid plan. The current figure is on the pricing page, and I am deliberately not printing a number here that will be wrong by the time you read it.

How do you write the about-me file without writing it?

Get interviewed. Writing about yourself in the abstract produces a CV. Being asked one question at a time produces the messy detail that is actually useful.

Open a chat in the Project and ask for a 30-minute interview, one question at a time, going deep before moving on. Cover who you are, what you are building now, your goals for the next twelve months, what you are afraid of, what you already tried that failed, who your audience is, what they are sceptical of, and what is off-limits in public.

One instruction matters more than the rest: never invent facts about me, only use what I tell you.

How do you capture a voice you cannot describe?

By handing over work instead of adjectives. Paste in three things you wrote that sounded most like you and that landed with real people. A post that worked. An email to a friend. A caption that got a real reply.

Then ask for analysis rather than praise: what you would never say, what you reach for when you are excited, what changes when you are admitting a failure, whether you use emoji, your sentence-length pattern.

The follow-up questions are where the file gets sharp. Words you hate. Phrases you refuse. The adjective you would never pick. Those are the things three samples cannot show and you can answer in a minute.

What do the anti-AI writing rules actually stop?

The tics. Every model has a house style, and it leaks into your drafts unless you name the pattern and ban it.

Build this file from your own drafts rather than from a list someone else wrote. Read three pieces the model produced for you, mark every phrase that made you wince, and that is the file. It takes ten minutes and it is the single highest-yield item on the list.

What goes in the Project instructions?

Standing rules, not a task. This field runs before every chat in the Project, so it should hold only what is true every time.

Write it as a job description for someone who needs to know your standards: what you want, what you never want, how output should be formatted, and what context to always assume. The same discipline applies as to a system prompt in code, which I wrote about in building production AI agents that actually work: short, role-based, and specific about the failure you are preventing.

Add one line at the top that states your goal for the year. A number, not a mood.

Why must templates live in the matching Project?

Because context that does not apply is noise, and noise costs you the thing you came for. A pitch-email template sitting in your newsletter Project pulls drafts toward a register you did not ask for.

That last row is the step most people skip. Uploading your real numbers is what turns "should I post this?" from a guess into a comparison against your own baseline.

What does the prompt actually look like afterwards?

Twelve words. "Write a LinkedIn post about yesterday's podcast" is enough, because voice, audience, format, banned words and call-to-action style are already loaded.

Shorter prompts are also cheaper, which matters at volume rather than at this scale. The general version of that argument, with measured numbers behind it, is in cutting LLM API costs 60%.

What is the step that actually compounds?

Closing the feedback loop. Everything above gets you a workspace that knows you as of today. It does not get better unless your corrections find their way back into the files.

The habit is small and easy to skip: when you edit something, say what you cut and why. "I removed the second paragraph, it read as motivational. I rewrote the close, it had no call to action." Two sentences, once, instead of the same edit every week.

I run the same pattern on this site in code rather than in a chat, described in how I built an AI agent for my portfolio. The mechanism differs. The principle does not.

What does this setup not fix?

Four things, and knowing them in advance saves you the disappointment.

That third row is the one I hold on to in client work too. The human stays in the loop for the same reason a regulated system keeps one, which I wrote about in what actually works in enterprise banking: the value is in the draft, and the accountability stays with a person.

Where should you start?

With the one thing you write every week and resent writing. Build that Project, in that order, and stop.

The failure mode is building seven Projects on a Saturday and using none of them. One Project, used daily for a fortnight, teaches you what belongs in the files. Seven Projects teach you nothing, because you never find out which context was doing the work.

Two hours is the whole investment. The question is not whether it works. It is which week you actually spend them.

Checked on 2026-09-21

• Step times as published, summing to 115 minutes
• Prompt length and drafting times as published: 800 words to 12, 40 minutes to 6
• Pricing linked rather than quoted, because a figure printed here will age
• Granola, Otter and Wispr Flow all resolve and all produce transcripts
• Claude Code and Claude Projects are separate products; this post configures Projects

Questions: @bayyash

Last week I caught myself typing the same context into Claude for the third time in one day. Who I am, what I'm building, what my voice sounds like. Three separate chats, three identical walls of text. That's when it hit me — I was using AI like a search engine instead of building it like a teammate.

Here's the thing most people miss: AI tools are useless without organized knowledge underneath them. You can prompt all day, but if your data lives in six different apps and your voice lives in your head, every output starts from zero.

I spent the last month building a five-level AI system. Not theoretical. Not "excited to share." A system that actually runs my content pipeline, audits my channels, and scores my podcast guests in under 10 minutes.

Here's exactly what I did — and what I'd change.

Level 1: Stop Typing, Start Talking

Allie Miller told me something that changed how I work: the best prompting is complaining to your AI. Voice gives the model 10x more context than typing. You naturally explain the background, mention edge cases, give examples — without thinking about it.

I use WisprFlow because it handles both Russian and English. For longer recordings — conference talks, interviews — I use Trint. Every podcast episode gets transcribed automatically.

If you're still typing prompts, that's the first thing I'd change this week.

The Part Everyone Skips: Context Files

Every AI tool I use has access to a small set of files about me. They don't change often, but they transform every output from generic to personal.

• Voice profile — how I write, what I sound like, what I hate
• Fact dossier — my background, companies, what I won't talk about publicly
• Anti-AI writing guide — patterns I refuse to publish in my voice
• Channel descriptions — who my audience is, what the cadence is

The move: I asked Claude to interview me for 30 minutes. One question at a time. It built a draft voice profile from my answers. My team cleaned it up. Now anyone on my team can write a post that sounds like me — not because they're good at imitation, but because the context does the work.

Action this week: Ask Claude to interview you for 30 minutes. Save the output. Use it across every project.

The Database That Lives Outside Any One Tool

Here's the mistake I made three times: locking all my data inside one AI platform. Tools change every three months. Today I love Claude. Tomorrow Codex ships something that makes me switch.

So my entire knowledge layer lives in an external Notion database. Organized by channel — YouTube, Newsletter, Podcast, Instagram, LinkedIn. Each one has performance data, transcripts, tone of voice, branding, a decisions log.

Every podcast episode gets its own page. When the transcript lands, the whole team gets a notification. That single trigger kicks off clip selection, newsletter drafting, social posts — all from one source.

Level 2: Build AI on Top of Your Knowledge

I use Claude Projects — one per platform. YouTube, Newsletter, Podcast, Instagram, LinkedIn. Each project is built on the context files and channel data I just described.

My team is testing Claude Cowork, the desktop version. It doesn't just read files — it opens them, edits documents, runs scripts on your machine. We have a master folder for YouTube production with subfolders for titles, thumbnails, scripting, distribution, and guest research. Each subfolder has its own instructions file.

The results are far more accurate on the first try.

The Guest Evaluation System That Changed Everything

When my team wants to vet a podcast guest, they paste a name into the Silicon Valley Girl Claude project. The project scores guests across 8 categories: Results, AI/Business factor, Personal story, Fame fit, Zeitgeist, Bridge factor, PR/Media presence, and Thought leadership.

Each one weighted. Each one benchmarked against our actual Notion data on how past episodes performed.

A list of 10 guests used to take 2-3 days. Now it takes under 10 minutes.

That's 8-12 hours back per week for the team. And we make better booking decisions because every guest gets scored against the same rubric.

Level 3: Scheduled Agents That Run Without You

This is where it gets real. Six agents running on timers for Silicon Valley Girl.

• Monday 9am: Trending content research — 10 video ideas drop into a doc. By the time the team opens their laptops, the ideas are ready.
• Monday 10am: Weekly AI/tech/business news summary. Before our Monday standup, we already know what's worth talking about.
• Monday 12pm: Full channel health audit covering 12 months. What's working, what's slipping, what to double down on.
• Daily 12pm: Media mention scanner. When something good comes up, we know about it the same morning.
• Wednesday 12pm: Guest follow-up agent. Reads our declined-guests list, scores each one, finds strong news hooks from the past 7 days, and recommends who to re-approach.

None of these agents replace anyone. They remove the part of the job that didn't need a human in the first place.

Level 4: Vibe Code Your Own Tools

Luis von Ahn, CEO of Duolingo, told me on the podcast that at Duolingo, every person has built their own dashboard. I loved that. So my team and I built one.

I did not write the code. I described what I wanted in Claude chat. Claude turned it into a technical prompt. Claude Code wrote and edited the actual files on my Mac. Eight to ten weeks between March and May.

The dashboard pulls from YouTube, Instagram, Threads, LinkedIn, X, and Beehiiv. A Python cron job monitors every video from the moment it publishes.

Three trigger moments:

• Day 4: If click-through drops below 4% with 20,000+ impressions — early packaging signal.
• Day 7: If views below 12K, or 30-second retention below 50%.
• Day 14: If total views below the 30K KPI, the team gets a message.

When a trigger fires, the system sends metrics to Claude and asks for a diagnostic. The output lands in our team channel. Costs fractions of a cent per video.

AI Search Visibility

Here's what most people don't think about yet: traffic is shifting from Google to chatbots. People ask ChatGPT, Perplexity, and Google AI Overview for podcast recommendations, tool recommendations, expert recommendations.

When I tested earlier this year, my podcast didn't show up at all. Zero visibility in AI search.

So we rebuilt the podcast site, created a Wikipedia page, updated descriptions on every platform. We track against 11 competitors with 50 prompts daily.

The honest before-and-after:

• Before: SVG only appeared in branded prompts ("who is Marina Mogilko?")
• Today: SVG appears in 6-8 prompts that don't mention my name at all

Is that a lot? No. Is it more than zero? Yes. And every one of those positions is a slot we didn't have a month ago.

Level 5: Close the Loop

This is where almost no one is. It's also the level I'm still building.

Every call we run — strategy, 1:1s, planning, guest prep — gets recorded with Granola. The notes end up in clean transcripts. The problem: those notes sit in Granola. They don't get into the Claude project that runs the rest of my business.

So when I ask Claude "what did we decide about the editorial calendar last week?" — it has no idea.

What we're working on: when a meeting wraps, the transcript and next-step list should move straight into the right Claude project. YouTube into the YouTube project. Podcast into the podcast project.

This is the gap I've been thinking about for months. Almost no founder has solved it yet.

The Uncomfortable Truth

Everyone wants to skip to Level 5. Nobody wants to spend 2 hours on Level 1.

But here's what I've learned after rebuilding this system three times: the boring foundation is the only thing that makes the exciting stuff work. Voice inputs are useless without organized data. Scheduled agents are useless without context files. Custom dashboards are useless without a clean knowledge layer.

The 2 hours you spend on Level 1 is the highest-leverage time investment you'll make this year.

Question I'm sitting with right now: Are you using AI like a search engine — or building it like a teammate that knows you?

I have been building software for over twenty years. For the past several, that work has centered on production AI systems — the kind that handle real traffic, real data, and real failure modes. This post is a straight inventory of what I actually ship, how I architect it, and what breaks when you move beyond tutorials.

RAG Systems That Survive Contact with Reality

Retrieval-Augmented Generation is the backbone of most production AI products I build. But a RAG pipeline that works on a demo PDF is not the same as one that ingests ten thousand heterogeneous documents with mixed Arabic and English content, tables, headers, and inconsistent formatting.

Chunking Is Not a Solved Problem

The default "split every 1000 characters" approach fails the moment your source material has structure. I use recursive character splitting as a baseline, but the real work happens in semantic chunking — splitting at natural boundaries like section headers, paragraph breaks, and logical transitions. For structured documents, I preserve metadata (page numbers, section titles, source filenames) and attach it to every chunk so the retrieval layer can filter and rank with context.

For Arabic content, chunking gets harder. Arabic morphology is rich, sentence boundaries are not always obvious, and mixed Arabic-English documents create embedding drift if you are not careful. I typically chunk Arabic text slightly smaller than English equivalents to preserve semantic coherence across the embedding model's context window.

Embeddings and Vector Stores

I have shipped systems on both Pinecone and pgvector. Pinecone wins when you need managed scaling and hybrid search out of the box. pgvector wins when your retrieval layer is already tightly coupled to PostgreSQL, when you need transactional consistency between your application data and your vectors, or when you are optimizing for cost at scale.

My default embedding stack is text-embedding-3-large for English and multilingual content, with fallback to text-embedding-3-small for high-volume, lower-precision use cases. For Arabic-specific deployments, I evaluate Arabic-specific embedding models against a held-out test set before committing — generic multilingual models are better than they used to be, but they are not always the right tool.

Retrieval Patterns Beyond Naive Similarity Search

Cosine similarity on a single embedding is rarely enough. I run hybrid search — combining dense vector similarity with sparse BM25 keyword matching — and then re-rank with a cross-encoder or a lightweight reranking model. The dense retrieval gets you recall; the re-ranker gets you precision. Without the second step, you get plausible-sounding but irrelevant chunks at the top of your context window.

I also implement query expansion and hypothetical document embedding (HyDE) where appropriate: generate a synthetic answer to the user's question, embed that, and retrieve against it. It costs an extra LLM call, but the retrieval quality improvement is measurable.

AI Agents: Tool-Calling, Guardrails, and Observability

Agents are not magic. They are loops — a language model, a set of tools, and a control structure that decides what to call next. The hard part is making that loop reliable enough to expose to users.

Tool-Calling Patterns

I build agents with explicit tool schemas, not free-form prompting. Every tool has a typed input schema, a clear description, and a deterministic output. The LLM generates structured JSON to invoke tools, and I validate that JSON against the schema before execution. If the model hallucinates a parameter or sends malformed JSON, the validation layer catches it and returns a structured error back to the agent loop.

Tools fall into three categories in my systems: data retrieval (search, database queries), action execution (send email, create ticket, update record), and computation (math, formatting, validation). I never give an agent unrestricted write access without human confirmation — the blast radius is too large.

Guardrails and Fallback Chains

Every agent has input guardrails: PII detection, prompt injection filtering, and topic boundary checks. Every agent has output guardrails: format validation, safety checks, and confidence thresholds. If the model's output confidence is below a threshold, or if validation fails, the system falls back to a simpler chain or escalates to a human.

I implement fallback chains as explicit state machines, not implicit prompt engineering. If the primary model fails, the system tries a smaller model with a narrower prompt. If that fails, it returns a graceful degradation message and logs the incident for review.

Observability with Langfuse

You cannot debug what you cannot see. I instrument every agent trace with Langfuse: input prompts, tool calls, latencies, token counts, and error states. This is not optional in production. When a user reports a bad result, I need to reconstruct the exact chain of thought, see which tool was called with what parameters, and identify where the logic diverged from the intended path.

Langfuse also gives me cost attribution per trace, which matters when you are running multiple models and need to know which user workflows are expensive.

Full-Stack Production: Laravel 12, Next.js 16, and React Native

AI does not exist in a vacuum. It sits inside applications that have authentication, billing, permissions, mobile clients, and deployment pipelines. I build the full stack, not just the model layer.

Laravel 12 + Next.js 16 Monorepo

My default backend is Laravel 12. It handles queues, scheduling, database migrations, API authentication, and event broadcasting without ceremony. For the frontend, I use Next.js 16 with the App Router, server components for initial data fetching, and client components for interactive AI chat interfaces.

The monorepo structure keeps the API contracts tight. Laravel exposes typed API resources; Next.js consumes them with generated TypeScript types. When the backend schema changes, the frontend build breaks immediately — which is exactly what I want.

React Native for Mobile

When the product needs a mobile presence, I ship React Native apps that share business logic with the web frontend. The AI chat interface, streaming responses, and tool-call UIs are implemented once and adapted to mobile constraints. Push notifications for async agent completions are handled through Laravel's notification channels.

Production vs. Tutorial AI: What Actually Breaks

Tutorials show you the happy path. Production is the other 90% of the work.

Cost

LLM costs scale linearly with traffic and super-linearly with context window size. A naive RAG system that dumps 8,000 tokens of retrieved context into every request will bankrupt you at scale. I implement aggressive context compression, selective retrieval (only fetch what you need), and model routing: use the cheapest model that can handle the task, and escalate to expensive models only when necessary.

Latency

Users will not wait five seconds for a chat response. I optimize latency at every layer: faster embedding models, cached retrieval results, streaming responses to the client, and pre-computed summaries for common queries. For high-latency operations — like multi-step agent workflows — I switch to an async pattern: acknowledge the request, process in the background, and notify the user when complete.

Hallucinations

Hallucinations do not go away with better prompting. You need grounding: every generated claim must be traceable to a retrieved source. I implement citation requirements in the prompt, parse citations from the model output, and verify that cited chunks actually exist in the retrieval set. If the model cannot cite a source, the answer is flagged for review.

Architecture Patterns

Here is a simplified view of a production RAG + Agent system I have shipped:

┌─────────────────┐     ┌──────────────────┐     ┌─────────────────┐
│   Next.js 16    │────▶│   Laravel 12     │────▶│  Vector Store   │
│   (Frontend)    │     │   (API / Queue)  │     │  (pgvector)     │
└─────────────────┘     └──────────────────┘     └─────────────────┘
                               │
                               ▼
                        ┌──────────────────┐
                        │   AI Agent Loop  │
                        │  (Tool Calling)  │
                        └──────────────────┘
                               │
              ┌────────────────┼────────────────┐
              ▼                ▼                ▼
        ┌──────────┐    ┌──────────┐    ┌──────────┐
        │  Search  │    │  Action  │    │  LLM API │
        │  (RAG)   │    │  Tools   │    │ (Router) │
        └──────────┘    └──────────┘    └──────────┘

The LLM API layer routes between models based on task complexity: small model for classification and routing, large model for generation and reasoning. Every call is traced, every cost is logged, every failure triggers a fallback.

Cost Optimization Strategies

Model routing is the single biggest lever. I classify incoming requests by complexity and route them to the appropriate model tier. Simple queries hit a fast, cheap model. Complex reasoning escalates to a larger model. This alone can reduce costs by 60-70% without measurable quality loss.

Caching is the second lever. Embedding results, retrieval sets, and common LLM responses are cached with TTLs appropriate to the data freshness requirements. For batch workloads — like nightly document ingestion — I use batching APIs where available to cut per-request overhead.

The MENA Context: Arabic NLP and Regional Scaling

Building AI for the Middle East and North Africa introduces constraints that Western-centric tutorials ignore. Arabic NLP requires handling diacritics, dialectal variation, and right-to-left UI flows. Compliance requirements vary by country: data residency, content moderation standards, and regulatory approval for AI-generated outputs.

I design systems with regional modularity from the start: embedding models that handle Arabic well, UI components that support RTL layouts, and deployment architectures that can pin data to specific geographic regions when required. Scaling in MENA also means optimizing for mobile-first usage and variable network conditions — lightweight APIs, aggressive caching, and offline-capable mobile features.

Evaluation Loops: Automated Quality Checks

Shipping AI features without evaluation is reckless. I run automated quality checks on every deployment: retrieval accuracy (did we fetch the right chunks?), answer relevance (does the generated response address the question?), citation correctness (are the sources real and relevant?), and safety (no PII leaks, no policy violations).

These checks run against a held-out evaluation dataset that grows over time. When a new failure mode appears in production, I add an example to the eval set and fix the system. The eval suite runs in CI before every deploy. If scores regress, the deploy is blocked.

What This Means for Your Project

If you are building AI products, the gap between prototype and production is wider than it looks. I bridge that gap — architecting systems that retrieve accurately, reason reliably, scale affordably, and fail gracefully. Whether you need a RAG pipeline for internal documents, an agent that interacts with your existing APIs, or a full-stack product with mobile and web clients, the patterns above are how I ship.

If you want to talk architecture, model selection, or regional deployment strategy, get in touch.

I started shipping code in 2005. Back then, deploying felt like launching a physical rocket. You prayed to the server gods and watched the logs.

Over two decades, I’ve built systems for banks, humanitarian organizations, and eCommerce giants. I’ve seen the pendulum swing from monoliths to microservices, from on-prem to cloud, from logic to machine learning.

But nothing prepared us for the current wave.

The Reframe

The last 20 years were about writing instructions. The next 20 are about building protocols.

We used to tell computers exactly how to do a job. Now, we tell them what the job is, and we build the guardrails to keep them from burning the house down while they do it.

That's not just a paradigm shift. That's a tsunami that rearranges the coastline of software engineering.

Real Failures, Real Lessons

In the banking sector, a missed decimal point meant a financial crisis. In the humanitarian sector, downtime meant someone didn't get help. The stakes trained me to be paranoid.

Now, as an AI Engineer, that paranoia is my biggest asset.

Everyone is racing to build agents. Most of them are just function calls with a LinkedIn profile. They lack memory, they lack context, and they lack safety.

Building an AI agent isn't about connecting an API key to a chat interface. It's about grounding. It's about permissions. It's about operational safety.

The Next Era

We are no longer just programmers. We are system architects for non-human intelligence.

If you are still trying to control every execution path with an if/else statement, you are fighting gravity.

Stop writing scripts. Start designing systems. The era of the prompt is over. Are you ready for the era of the protocol?

Most writing about AI agents argues about prompts. Almost none of it is about the thing that actually takes agents down, which is the plumbing around the model call.

Here is a failure from my own site. It is small, it is boring, and it is exactly the shape of the ones that hurt.

What actually broke on my own system?

A queued job that calls a language model wrote nothing, three times, and left no error a caller could see. The job was GeneratePostSeoJob, which asks a model to write SEO fields for a blog post.

The cause was two timeouts that disagreed. Laravel Horizon gives a worker 60 seconds. The service that makes the model call allows a single request 120. Neither number was wrong on its own. Together they guaranteed that any post long enough to take the model past a minute would be killed mid-request.

The production failed_jobs table recorded it plainly: Illuminate\Queue\TimeoutExceededException: App\Jobs\GeneratePostSeoJob has timed out, at 10:24:47 on 19 September 2026. The fix landed at 10:47:39 the same morning.

Why is a mismatched timeout worse than a crash?

Because a crash tells you. This did not.

The worker killed the request while the model was still answering. No response arrived, so no parsing failed, no validation tripped, and no handler ran. The job simply stopped. Horizon retried it twice more, hit the same wall twice more, and only then wrote one TimeoutExceededException with no mention of the model, the post, or the 120-second call it interrupted.

The rule I wrote into the code as a comment, so the next person cannot miss it: any queued job that reaches the model must declare a $timeout larger than the model call's own ceiling. Both model-calling jobs in this repo now sit at 150 against a 120-second call.

How do you size the timeout for a job that calls a model?

Work outwards from the slowest thing, not inwards from the platform's ceiling. The model call is the innermost budget. Every layer wrapping it needs headroom, and the outermost layer is usually a platform limit you do not control.

An earlier version of this post claimed Convex actions time out at 30 seconds and budgeted 25 seconds against it. That is wrong, and I have corrected it. The documented limits are 30 minutes and 10 minutes. The lesson survives the correction, which is that you should never guess a platform limit. Read it, write it down next to your own budget, and make the gap between them deliberate.

What should an agent do when the model returns nothing usable?

Fall back, every time, on a path that cannot itself call the model. Three different failures collapse into the same answer in my own pipeline, and none of them raise to the caller.

The model returns null, the response does not decode as JSON, or processing it throws. In all three cases PostAiService::analyzeContent() logs and returns fallbackAnalysis(), a heuristic that reads the post and produces a summary without any model at all.

That is the part most agent tutorials skip. A fallback that calls a cheaper model is still a fallback that can fail. Somewhere at the bottom of the ladder there has to be a rung made of plain code.

Decide the ladder before the incident. During one you will pick whichever rung is nearest, and that is how a system ends up with no rung 4.

How do you force a model to return a shape you can trust?

Ask for a schema and refuse anything else. In TypeScript that is generateObject from the Vercel AI SDK with a Zod schema, so the SDK retries or fails on invalid output instead of handing you a broken object.

const ToolCallSchema = z.object({
  tool: z.enum(['search_orders', 'create_ticket', 'escalate']),
  params: z.record(z.unknown()),
  confidence: z.number().min(0).max(1),
});

A schema is necessary and not sufficient. Valid JSON can still be wrong, and the interesting checks are the ones your schema cannot express.

My own pipeline has one worth copying. The model is asked for a summary of at most 60 words and overshoots that budget often enough to matter. The frontend truncates on sentence boundaries, so an overshooting summary loses its final clause, which is the part carrying the outcome and therefore the part worth quoting. So the same word clamp the heuristic fallback uses is applied to the model's output too.

Which retries help, and which ones just cost money?

Retry the failures that are about the network and the provider. Never retry the ones that are about your own request, because they will fail identically and bill you for the privilege.

That last row is the one I learned the hard way. Horizon retried my job twice after the first kill. All three attempts burned the same model call and none of them could have finished.

What should every model call record?

Input tokens, output tokens, the model name, the duration, and whether it succeeded. Without those five you are guessing, and Langfuse gives you all of them as a distributed trace across a multi-step agent run.

The reason to trace rather than log is that agent steps are separate model calls. One user request becomes intent classification, then tool selection, then response synthesis. A log line per step tells you each step happened. A trace tells you which step spent the time and which step spent the money.

Cost attribution is the payoff. Tag every trace with the feature that triggered it and you can answer questions about a feature's unit economics rather than about a bill. I built the same instinct into a client's retrieval system, and the measured result is in cutting LLM API costs 60%. Caching moved four times more money than model routing did, and I only know that because every call was traced first.

How do you know an agent got better rather than just different?

You run evals, and you accept that this is the least mature part of the stack. Three kinds are worth having, and I am describing what I recommend rather than a suite I can point you at.

Deterministic checks answer whether the output matched the schema and carried the required fields. A model-as-judge grades outputs against written criteria using a cheap model, which is imprecise but catches large regressions. Human spot-checks on a small sample of real traffic catch what both of the others miss, which is usually tone and context.

What breaks first when an agent meets real users?

Not the prompt. This is the order I now expect, with what each one looks like from outside.

Four of those six cost nothing but attention. The expensive ones are the fallback ladder and the eval dataset, and both are cheaper than the incident that teaches you to build them.

How does this fit a Laravel or Next.js codebase?

The same way any other unreliable dependency does. The model call is an HTTP request to somebody else's machine, and it deserves the treatment you already give those.

On this site the model work runs as queued jobs behind Horizon, which is the same queue that pushes cache purges to the frontend. I wrote that protocol up in the cache handshake, and the surrounding architecture, including what has no retry at all and why, in what yabasha.dev actually runs.

The constraints get sharper the more regulated the client. What survives contact with a bank's review is a narrower set than what survives a demo, and I wrote about that gap in what actually works in enterprise banking.

What does the Composable AI Stack actually give you?

Less than an earlier version of this post claimed. I read the repository row by row before republishing, and three of its eight claims were aspirational. Here is what is in the tree today.

The import path in the older table was wrong too. The generated template uses the @acme scope, so it is runWithGuardrails from @acme/ai, not from a @yabasha/cas subpath. The CLI on npm is @yabasha/cas; the packages it scaffolds are not.

bun add -g @yabasha/cas
cas init my-agent-system

What would I check before calling an agent production-ready?

Start at the outside and work in. The prompt is the last thing on this list for a reason.

• Every layer that wraps a model call declares a timeout, and each one is larger than the layer inside it.
• The platform's own execution limit is written down next to your budget, read from the vendor's docs rather than remembered.
• Every model output passes a schema, and then passes a business rule the schema cannot express.
• The fallback ladder ends in code that cannot call a model.
• Retries fire on 429 and 5xx, and nowhere else.
• Every call records tokens, model, duration and outcome, and every trace carries the feature that caused it.
• A graded dataset exists, and something runs against it before you ship.

Measured with

Numbers read from this repository and from production on 2026-09-21.

• Laravel 12 on PHP 8.4, Horizon on Redis, one VPS
• config/horizon.php: tries 3, timeout 60, memory 128
• OpenRouterService::HTTP_TIMEOUT_SECONDS 120; both model-calling jobs declare $timeout 150
• The incident: TimeoutExceededException on GeneratePostSeoJob, 2026-09-19 10:24:47, fixed 10:47:39
• Convex execution limits quoted from the vendor's limits page, fetched 2026-09-21
• @yabasha/cas 0.2.0 on the npm registry; composable-ai-stack public, last pushed 2026-05-12, cloned and read on 2026-09-21

Questions: @bayyash

The invoice was $4,200 for one week of LLM calls. The system was live, the users were active, and a rewrite was not on the table. The brief was narrow. Make it cheaper without making it worse.

Six weeks and two sprints later the same week cost $1,680.

What did this RAG system cost before and after?

Week 0 billed $4,200. Week 6 billed $1,680, a 60% reduction, with no database migration and no downtime. Cost per query fell from $0.08 to $0.032. Every number in this table was recorded on the same dashboard, six weeks apart.

Latency fell alongside cost, which surprised me. It should not have. A call that never reaches the model returns in milliseconds, and a call carrying 1,200 tokens of context finishes sooner than one carrying 8,000.

What was the system, and where was the money going?

A retrieval system answering questions against a client's internal knowledge base. Next.js on the front, Convex as the backend, Qdrant for vectors, OpenAI for inference. It demoed well and held up for the first hundred users.

Four things were wrong at once, and none of them were visible.

Vector search returned 10 chunks per query, each over 800 tokens. The system prompt had grown to roughly 420 tokens of assistant boilerplate. There was no cache, so the same question cost full price every time it was asked. There was no routing, so a yes-or-no lookup paid the same rate as a multi-step reasoning task.

Which five changes produced the cut, and what did each one save?

Five changes, applied in order, each one resting on the visibility the previous one created. These are the shares I attributed at the time.

Those five shares add to 65%, and the invoice moved 60%. They do not add, they stack. Change 2 only ever runs on the calls change 1 failed to catch, so its 15% is 15% of a smaller number by the time it lands. I am quoting the attributions as I recorded them. The 60% is the invoice, and the invoice is the number I trust.

How does a semantic cache cut LLM spend?

By never calling the model. An incoming query is embedded, the embedding is hashed, and the hash is looked up in Redis. A hit returns the stored answer. A miss calls the model, then writes the answer back under a SETEX with a seven-day expiry.

// packages/ai/cache.ts
const CACHE_TTL = 60 * 60 * 24 * 7;

export async function getCachedResponse(
  embedding: number[]
): Promise<string | null> {
  return redis.get(`rag:cache:${hashEmbedding(embedding)}`);
}

The similarity threshold is 0.92 cosine. Above that, two phrasings of the same question are treated as one question. Below it, they are not. I set the target hit rate at 40% and it settled at 62%.

That is the trade I took, and it is only safe because the knowledge base changed slowly. Event-driven invalidation is the harder half of the same problem, and I wrote up how I do it for this site's own cache in the cache handshake. Different cache, different system, same question. When do you evict?

What did prompt and context compression actually remove?

Two things: the system prompt, and the retrieved context around it. The prompt went from roughly 420 tokens of politeness instructions to 47 tokens that say what the model must do.

Answer based on context. Say "I don't know" if context lacks info. Be concise.

The context was the larger win. Ten chunks at 800-plus tokens each meant 8,000 tokens of retrieval before the user's own question was added.

Read your rendered prompts, not your templates. The template looks lean. The string that reaches the model is the one you are paying for, and it is usually full of things nobody chose.

Why does dropping low-relevance chunks improve answers?

Because low-scoring context does not sit there harmlessly. It competes. Qdrant exposes a score_threshold on search, so a chunk below 0.78 cosine is never returned rather than returned and then trimmed. Average relevance across the surviving chunks went from 0.65 to 0.89.

Hallucinations dropped when the noisy chunks stopped arriving. That was not the goal. The goal was tokens, and the quality improvement came free, which is the opposite of how cost work usually goes.

The pipeline also carries a max_context_tokens ceiling. If query plus context exceeds it, the oldest chunks are truncated first. It has never been the binding constraint since the floor went in, which is the point of a backstop.

When is a cheaper model the right model?

When the query does not need reasoning. A definition lookup and a multi-step analysis were paying the same rate, and a query classifier fixed that. Classification runs on a cheap embedding compared against labelled examples, so the routing decision costs close to nothing.

Roughly 40% of queries ended up on the cheap path. Routing was worth about 8% of total spend, which is smaller than it feels like it should be, and that is worth saying out loud. Caching moves four times more money than routing does.

The cost is a slight quality dip on edge cases where the classifier guesses wrong. I accepted that because it is measured, not assumed. Check current rates on the OpenAI pricing page before copying this table. The relative gap between tiers is what makes routing pay, and that gap moves.

Why cap output tokens on every call?

Because output tokens bill at the same rate as input tokens, and nothing about an uncapped response is predictable. One query returned 2,400 tokens because a user typed "tell me everything about". Nobody chose that cost.

Every call now carries a maxTokens value from that table. When the model stops early, the user gets a "Continue?" button rather than a truncated paragraph, so the cap is visible in the product instead of hidden in the response.

This was the smallest of the five changes, worth about 3%. It is also the one I would ship first in a new system, because it costs an afternoon and it removes an entire class of surprise from the bill.

What do you need to see before you change anything?

Cost per query, per call, with the model name attached. I spent the first day instrumenting and changed nothing, and that day paid for itself several times over. Langfuse carried the tracing.

Each call records input tokens, output tokens, total cost, model, latency, cache hit or miss, user and session id, query classification, and the rendered prompt. The rendered prompt matters more than it sounds. It is the only way to tell whether compression actually shipped.

The dashboard refreshes every five minutes and shows cost per query, cache hit rate, the split across models, and latency at p50, p95 and p99.

The same instinct drives the agent work I wrote up in building production AI agents that actually work. An agent you cannot trace is an agent you cannot debug or bill for.

What did not work?

Three attempts, all rolled back. I am listing them because the failures shaped the final design more than the wins did.

The third one is the one I would have shipped if nobody had asked who sits at those desks. It was technically sound and completely wrong for the deployment, which is the kind of mistake you only avoid by knowing the client's floor plan. I wrote about how much of that context matters in what actually works in enterprise banking.

How do you keep every LLM call on one path?

One wrapper, no exceptions. Every model call in the system goes through a single function, so caching, routing, guardrails and cost tracking cannot be skipped by a new feature written in a hurry.

// packages/ai/index.ts
export async function generateRAGResponse(
  query: string,
  context: Chunk[]
): Promise<AIResponse> {
  const embedding = await embed(query);

  const cached = await getCachedResponse(embedding);
  if (cached) return cached;

  const modelConfig = await routeQuery(query);
  const prompt = buildCompressedPrompt(query, context);
  const validated = await applyInputGuardrails(prompt);

  const response = await callLLM({ ...modelConfig, prompt: validated });

  await trackCost(response.usage, modelConfig.model);
  await cacheResponse(embedding, response.text);

  return response;
}

The module splits into cache, router, guardrails, cost tracker and shared types. None of that is clever. Its whole value is that there is one place to change a threshold and one place to read a bill. I use the same shape at much smaller scale on my own site, described in how I built an AI agent for my portfolio.

What would I do differently?

Instrument on day one of the build, not day one of the cleanup. The $4,200 week was not caused by a bad decision. It was caused by six good decisions nobody could see the price of.

Two smaller lessons held up. The "no rewrite" constraint forced better thinking than an open brief would have, because every idea had to survive the question of what it touched. And the boring change won. A Redis cache is not novel and it moved more money than the three clever experiments combined.

The system still runs. Spend flattened while usage kept climbing, and there have been no more surprise invoices.

Measured with

• Stack: Next.js, Convex, Qdrant, OpenAI, Redis, Langfuse
• Figures recorded week 0 and week 6 of the optimisation, two sprints apart
• Client system, not yabasha.dev. Figures are from that engagement's dashboard

Questions: @bayyash · Code: composable-ai-stack

On January 6th, 2026, Adam Wathan, founder of Tailwind CSS, did something unprecedented: he publicly confessed that his company was dying not from competition, but from success. Seventy-five percent of his engineering team—three out of four engineers—were laid off. Revenue had cratered by 80%. The framework powering over 617,000 live websites, including Shopify, GitHub, and NASA's Jet Propulsion Laboratory, had become a victim of its own popularity. (leanware.co)

The killer? AI coding assistants that had absorbed Tailwind's documentation into their models, serving answers directly inside VS Code and Cursor without ever sending a developer to tailwindcss.com. No doc visits. No discovery funnel. No conversions to Tailwind UI. No revenue. (dev.to)

This isn't a story about CSS. It's a diagnostic X-ray of how AI is rewiring developer behavior at the neurological level—and vaporizing the economic foundations of software development in the process.

The Moment I Realized I Was Part of the Problem

Last Tuesday, I caught myself doing something I'd been doing for months without noticing: I stopped opening documentation. Completely.

My AI assistant answered my Tailwind question before I could even type "tailwindcss.com" into my browser. It was convenient. It was fast. It was exactly the behavior that nuked Tailwind's business model. I had become a data point in their collapse, a perfect exemplar of the 40% traffic drop they'd seen since early 2023. (businessinsider.com)

But the real gut-punch came three hours later.

I was reviewing a critical payments module my assistant had generated in 90 seconds. The code looked perfect—clean abstractions, proper error handling, even helpful comments. But my verification pipeline screamed bloody murder. Buried in an async function was a timezone edge case that would have double-charged users in daylight saving transitions.

I caught it. But only because I'd built a verification-first pipeline that treated AI-generated code as radioactive ☢️ until proven safe.

That's when the proverb clicked: "When the winds of change blow, some people build walls, others build windmills."

The winds aren't blowing anymore. This is the hurricane. And I'm definitely in the windmill camp.

The Three Shocks Reshaping Our Reality

Tailwind's collapse isn't an isolated tragedy. It's the first visible symptom of a systemic shockwave that’s hitting every knowledge-based industry simultaneously. For software engineers, it manifests in three interlocking crises:

1. The Economic Shock: The Death of the Attention Funnel

Tailwind's business model was simple and proven: give away the framework (MIT license), monetize through documentation traffic that converts to paid products like Tailwind UI and Catalyst. It's the same playbook used by countless open-source companies, devtools startups, and even enterprise software vendors who rely on educational content to drive sales.

AI has broken this funnel irreparably.

When developers ask ChatGPT, Cursor, or GitHub Copilot "how do I implement a responsive grid in Tailwind?", the AI doesn't send them to the docs. It serves the answer directly. The developer gets what they need. The framework gets usage. The company gets nothing. (chyshkala.com)

This is the counterintuitive nightmare: increased usage correlates with decreased revenue. As Wathan lamented, "Right now there's just no correlation between making Tailwind easier to use and making development of the framework more sustainable." (businessinsider.com)

Every tool that monetizes through developer attention—from API docs to video courses to Stack Overflow—is now at existential risk. The meteor has struck. We're waiting for the dust to settle.

2. The Career Shock: The Great Engineering Restructuring

The layoffs keep coming. Not because AI has replaced entire engineering teams, but because companies are frantically restructuring around AI-augmented workflows and haven't found the new equilibrium yet.

The math is brutal: if AI generates 70% of initial code, do you need 70% fewer engineers? Or do you need different engineers—ones who can verify, constrain, and operate AI systems at scale?

The answer is emerging in real-time. Wathan's team went from four engineers to one. Not because Tailwind CSS became obsolete, but because the way developers use it changed. The company had "six months left" before payroll became impossible. (leanware.co)

This creates a terrifying paradox for individual engineers: your productivity is rising while your job security is falling. The developers who thrive won't be the ones who type the fastest or know the most syntax. They'll be the ones who can specify constraints clearly, design verification systems, and ship AI-assisted code with higher confidence than traditional code.

The competitive moat has shifted from coding speed to engineering judgment.

3. The Execution Shock: The Silent Bug Multiplier

Remember that payments bug I almost shipped? It's not an edge case. It's the new normal.

AI generates code that looks correct but harbors subtle, catastrophic failures. I've seen it produce:

• SQL queries with N+1 bombs hidden behind elegant async sugar
• Security checks that validate token shape but not cryptographic signature
• Database migrations that pass in dev but lock entire production tables for hours
• API integrations that don't handle rate limits because the training data never showed them failing

The tragedy is this: you ship 3x faster, but you debug 5x slower because you don't own the mental model. You didn't write it line by line. You can't trace the reasoning. The AI's "thought process" is invisible, compressed into a black box that outputs confidently wrong answers.

This is the fundamental asymmetry breaking traditional software delivery. Velocity accelerates exponentially. Confidence collapses linearly. And the cost of being wrong hasn't changed—but the speed of being wrong has accelerated 100x.

Building Windmills: The Verification-First Revolution

The old workflow—write code, review, ship—assumes humans generate every line. That assumption is dead.

The new architecture treats AI as a first-class actor in your engineering system, but one that must earn trust through evidence, not authority. I call it verification-first engineering: a system where AI generates at infinite speed, but production access is gated by observable proof of correctness.

Here's how it works:

The AI-Native Architecture Stack

1. Prompt Assembly Layer Version-control your prompts like code. A prompt isn't a chat message—it's a function with inputs, outputs, and invariants. Use templates, validate parameters, test edge cases. Tools like LangChain Hub or simple JSON schemas work. The key is treating prompts as formal specifications that encode business rules, not vague requests.

2. AI Orchestrator A thin abstraction layer (AWS Bedrock, Azure OpenAI, or a custom proxy) that:

• Routes prompts to appropriate models based on cost/risk
• Enforces token budgets and timeout limits
• Handles fallback logic when models hallucinate
• Logs every input/output for auditability

This is your circuit breaker. It prevents AI from becoming a single point of failure.

3. Verification Pipeline Every AI-generated diff must pass through escalating gates:

• Static analysis: Type checks, linters, security scanners (Semgrep)
• Unit & property tests: Verify logic, fuzz edge cases (pytest-hypothesis)
• Integration tests: Confirm contracts with real services
• Load testing: Catch N+1 queries and performance regressions
• Staged rollout: Feature flags → canary → production with traffic shadowing

4. Observability Layer Tag AI-generated code paths in your telemetry (span.set_attribute("ai_generated", True)). Measure:

• Defect escape rate
• Time to detect failures in AI paths
• Cost per feature vs. traditional development
• Revert rate

This is the CI/CD pipeline for AI cognition. It moves the bottleneck from generation (which AI owns) to verification (which you own).

The Mindset Fix: From Coder to Engineer-Supervisor

I tell my team: "The AI is typing. You're still responsible."

This isn't about controlling AI. It's about owning outcomes. You don't get credit for lines written. You get credit for defects prevented, incidents resolved, and systems sustained.

The developers who thrive will master four new skills:

1. Constraint specification: Writing prompts that encode invariants and business rules
2. Behavior verification: Designing tests that catch AI hallucinations
3. Safe shipping: Architecting rollouts that contain AI mistakes
4. Reality observation: Debugging systems where 30% of code came from a black box

This is the new moat. Non-developers using AI can't do this. Junior developers using AI without mentorship will ship disasters. Senior developers who master verification will become 10x engineers—not because they type more, but because they ship safer.

The Trust Decision Matrix: When to Believe Your AI

Verification-first engineering sounds expensive. It is. But not everywhere equally. The key is matching verification rigor to risk level.

Here's the non-obvious heuristic I use daily:

The rule: The more context AI lacks (business rules, production constraints, legacy quirks), the more guardrails you need. Verification cost scales with the unknowns.

This matrix becomes your compass. It tells you when to let AI ship freely and when to slow down for deep verification.

From Theory to Practice: What Changed When I Made the Shift

I implemented this verification-first approach across three client projects at my consultancy. The results redefined what's possible:

• Shipped 2.3x faster: AI cut initial dev time by 70%, but verification added only 30% overhead. Net win: 2.3x velocity.
• Escaped defect rate dropped 40%: Property tests caught edge cases I'd have missed reviewing code line-by-line.
• Code review transformed: Reviewers focused on intent and risk instead of syntax. The conversation moved from "this variable name is wrong" to "what happens if this AI-generated payment call fails?"
• Incident frequency stayed flat: Despite 3x more deployments, we didn't see incident spikes. Feature flags contained blast radius.
• Career leverage: In client interviews, I don't lead with "I code fast." I lead with: "I ship AI-assisted code with lower risk than traditional code." That's a differentiator in a world where everyone's using AI but most are doing it recklessly.

The workflow shift is fundamental:

• Old: Write code → Review → Ship
• New: Prompt → Generate → Verify → Constrain → Observe → Ship → Verify again

AI accelerates the middle. Engineering discipline protects the edges.

The New Reality: Assumptions for AIxc World

As of January 2026, I'm operating under these assumptions. If they shift, I'll adapt my guardrails. The principle remains: verify first, ship second.

1. AI models will keep improving at coding tasks, but remain unreliable on context-heavy decisions. The gap between "write a function" and "understand our business" won't close soon.
2. Doc-driven monetization is dying. Tailwind is the canary in the coal mine for every devtools company. Expect consolidation, sponsorship models (like Google AI Studio and Vercel stepping in for Tailwind), and direct-to-AI licensing deals.
3. Regulatory pressure around AI liability is rising. Owning outcomes becomes a legal necessity, not just a best practice. Verification paper trails will be your defense.
4. Economic constraints demand smaller teams ship bigger systems. Efficiency isn't a competitive advantage anymore—it's survival. The companies that figure out verification-first workflows will outcompete those that don't.

Your Verification-First Blueprint: 15 Steps to AI-Native Engineering

This isn't theory. Here's the exact checklist I use on every project:

1. Version-control your prompts in the same repo as your code
2. Run static analysis (type checkers, linters, security scanners) on every AI-generated diff
3. Write property tests for functions with clear invariants; use pytest-hypothesis or similar
4. Flag AI-generated code paths in your telemetry (span.set_attribute("ai_generated", True))
5. Require feature flags for any AI-generated feature touching production data
6. Shadow-deploy AI changes to compare behavior against existing code before traffic cutover
7. Log prompt inputs/outputs for debugging (but scrub secrets)
8. Set token budgets and timeouts in your AI orchestrator to prevent runaway costs
9. Review AI code for failure modes, not style: What happens if this API call fails? What if data is malformed?
10. Build a rollback plan before merging AI-generated migrations or infrastructure changes
11. Measure AI-specific metrics: time-to-first-output, defect rate, revert rate, cost per feature
12. Document the why: If AI generated it, write a comment explaining the business rule it implements
13. Train your team on prompt injection attacks and AI-specific security risks
14. Use canned prompts for common tasks to reduce variance and improve reproducibility
15. Schedule regular "AI debt" reviews: Refactor AI-generated code that has drifted from your evolving standards

This checklist is your windmill. Each step converts AI's chaotic energy into reliable, sustainable power.

The Only Viable Response

The Tailwind drama and Anthropic headlines aren't warnings to panic. They're signals to level up.

AI won't replace software engineers in 2026, but it will create a bifurcation:

• Downward: Engineers who treat AI as autocomplete, skip verification, and ship AI-generated code like they wrote it themselves. They'll move fast and break things—then get broken by incidents and layoffs.
• Upward: Engineers who treat AI as a junior teammate with infinite stamina. They'll build verification pipelines, specify constraints, observe production, and own outcomes. They'll ship faster with higher confidence.

The game has changed. The player on the other side is hidden, but the rules are clear: Generate fast, verify faster, and own the outcome. The engineers who win will be the ones who build systems so robust that AI becomes a force multiplier, not a liability.

My advice? Don't fear the AI that writes code. Fear the day your competitors verify theirs better than you do.

The meteor struck Tailwind. It's headed for every knowledge-based industry next. Build walls, and you'll be buried. Build windmills, and you'll harness the hurricane.

The Work Is Just Beginning

If you're building AI-assisted products and want to harden your verification pipeline, I share deeper dives, real implementation templates, and war stories from the trenches at yabasha.dev/blog. Based in Amman, Jordan, I work with small teams and solo founders who want to ship fast without breaking things.

The winds aren't coming. They're here. Let's build something that doesn't explode.

For Your Team: Building AI-Native Development

Give engineers their choice of AI harnesses. Every engineer should have access to coding agents with their preferred models and interfaces: Claude Code, Cursor, Devin, leveraging both closed and open models. Hearing that Meta engineers are forced to use Llama 4? That's a self-imposed limitation. Opus 4.5 is the baseline now.

Tool access is non-negotiable. Give your agents complete access to all dev tooling: Linear, GitHub, Datadog, Sentry, and any internal tools. If your agents are held back by lack of context, that's your failure, not theirs.

Invest in codebase-specific agent documentation. Stop complaining that agents "don't do X well." If that's your issue, try better prompting, agents.md, linting, and code rules. Tell them exactly how you want things done. Every manual edit you make is an opportunity for agent.md improvement.

Build robust background agent infrastructure. Get a full development stack running in VMs or sandboxes. Yes, it's hard to set up, but it pays dividends when engineers can run multiple agents in parallel. Code review will be your next bottleneck—get ahead of it.

Solve security properly. Stop being risk-averse and do what it takes to unblock tool access. Security theater that prevents AI adoption is an unforced error.

For Your Product: Shipping AI-Powered Features

Always use the latest generation models. Move features off last-gen models immediately unless robust evals prove otherwise. This requires updating every 1-2 weeks. As jaredpalmer noted, GitHub Copilot mobile still offers code review with GPT-4.1 and Sonnet 3.5. You're leaving money on the table by staying on Sonnet 4 or GPT-4o.

Use embedding semantic search everywhere. Any general embedding model will outperform Levenshtein distance and fuzzy heuristics. This is table stakes.

Leave no form unfilled. Use structured outputs and available user context for best-effort pre-filling. Reduce friction ruthlessly.

Allow unstructured inputs on all surfaces. Forms are dead. Every product surface must accept freeform text and documents.

Custom fine-tuning is dead. Stop wasting 8 weeks on fine-tuning. The frontier moves too fast, costs are dropping too quickly, and better prompting gets you 90% of the way there. This will only become more true as instruction-following improves.

Build evals for rapid model-upgrade decisions. They don't need to be perfect—just good enough to compare models on a Pareto cost vs. performance plot. Most decisions become obvious.

Empower all engineers to build with AI. Build primitives to call models from any codebase: structured output endpoints, semantic similarity APIs, sandboxed code execution. Make AI a first-class building block.

What else belongs in this quick note? The frontier is moving—don't let unforced errors hold you back.

I published a version of this post in January 2026. Rereading it this week, I found it described PostgreSQL, Sentry, Vercel Pro and Laravel Cloud. This site runs none of them. It also walked through an app/Events/ContentInvalidated.php that has never existed here, and a queue job with five retries and exponential backoff that, in the real repo, has no retries at all.

So this is the honest version. Every file path, version number and behaviour below comes from the running code.

What does yabasha.dev actually run?

One repository, three workspaces, built by Turborepo over Bun workspaces.

The root package.json declares workspaces: ["apps/*", "packages/*"] and pins packageManager: "bun@1.3.0". turbo.json defines four tasks. dev is marked persistent and uncached. build, lint and typecheck each declare dependsOn: ["^build"] style ordering so packages/ui compiles before apps/web consumes it.

There is no Kubernetes, no edge network and no second cloud account. One box runs everything.

Why one repo instead of two?

Because the two apps share a contract that changes often, and nothing else enforces it.

When I add a field to a Laravel API resource, the TypeScript type in apps/web/src/lib/api.ts that reads it has to change in the same breath. In two repositories that is two pull requests, and the window between them is where a production 500 lives. In one repository it is one commit, and CI either passes on both apps or fails.

That is the whole argument. It is not about tooling elegance.

The cost is real and worth naming. A monorepo makes it easy to reach across the boundary when you should not. packages/ui may not import from apps/web, and nothing but review enforces that.

How do the two apps talk to each other?

Not the way most Laravel and Next.js guides describe. There is no Sanctum cookie handshake between the frontend and the API, because the frontend never acts as a logged-in user.

The shape of those endpoints follows the conventions I wrote up in building RESTful APIs with Laravel. What changed since then is the authentication, which is where most of the thinking went.

A ManageToken is generated once, shown once, and stored as a SHA-256 hash. The plaintext is never written to the database. Each token carries a subset of 15 abilities from the TokenAbility enum, from posts.write through newsletter.subscribe, and every use writes an audit row.

The AuthenticateManageOrSanctum middleware has one rule worth stating plainly. A bearer token must resolve to an active ManageToken or the request gets a 401. There is no anonymous fallback, so a revoked token fails closed rather than quietly downgrading to public access.

How does a published post reach the frontend?

PostObserver::saved() dispatches RevalidateFrontendJob, which POSTs a cache tag and a URL list to /api/revalidate on the Next.js side with an X-Revalidate-Token header. The route calls revalidateTag() and pings IndexNow.

I wrote that protocol up in detail, including the version I would build where staleness costs money, in the Cache Handshake. Two details from it matter here.

The route accepts 12 tag names and rejects everything else. A typo does not purge a different tag, it purges nothing, and the 400 is only reported. Separately, the urls array in the request body does not purge anything. It feeds the IndexNow ping only. The tag is what clears the cache.

Behind all of it sits time-based revalidation, set per fetch in apps/web/src/lib/api.ts:

What happens when a cache purge fails?

Nothing retries. This is the part the old version of this post got most wrong.

RevalidateFrontendJob sets no $tries and no $backoff. It wraps an Http::timeout(8) call in a try/catch, and on failure it calls report() and returns. The job is marked complete. Horizon shows no failure, because there was none.

That is a deliberate trade for a portfolio, and I would not ship it to a client. The honest framing is that time-based ISR does the work and the purge is an optimisation that usually fires. If you need the acknowledged, retried version, it is in the Cache Handshake post linked above.

One consequence catches me every time. GeneratePostSeoJob writes with updateQuietly(), which skips the observer, so regenerating SEO fields fires no purge at all. The page catches up on its own timer. A curl immediately after still shows the old value.

Why does the test suite run on SQLite when production runs MySQL?

Because it was fast to set up, and I have not fixed it.

apps/backend/phpunit.xml pins DB_CONNECTION=sqlite and DB_DATABASE=:memory:. The CI job installs pdo_sqlite only. The suite is healthy by its own measure. As of today it runs 478 passing tests and 1 skipped, through Pest 4.

But every MySQL-specific behaviour in this codebase is untested everywhere it runs. A correlated subquery that SQLite tolerates and MySQL rejects would pass CI and fail in production. I know of no such bug today. I also have no test that would find one.

I have no plan to fix it this quarter, which is the useful admission. Naming an untested surface is worth more than pretending it is covered.

What does a deploy look like?

Two commands and one trap.

The Laravel side runs composer install --no-dev, which has bitten me. A class that only reaches the tree through a require-dev package passes CI, where dev dependencies are installed, and fatals on the server, where they are not. That is a whole category of bug with no test that can catch it, because the code runs in the one place the suite never does.

The Next.js side runs a production build and then:

pm2 restart portfolio-yabasha --update-env

--update-env is not optional. A plain pm2 restart inherits PM2's cached environment and silently ignores every value you just changed in .env.local. I have debugged the same "my new env var does nothing" problem more than once before remembering.

The box also needed 4 GB of swap added before next build would finish. Without it the build is OOM-killed with no useful message.

What would I change?

The pattern in that table is the honest one. Every gap is a deliberate trade against a failure I have not been hit by yet, and I would make a different call for a client system.

Related

I use this stack to run an AI pipeline over my own content, which I describe in how I built an AI agent for my portfolio. The Laravel queue concepts above come straight from the Horizon documentation, and the caching model on the Next.js side is the one described in the revalidateTag reference.

Tested with

Versions read from composer.json and package.json on 2026-09-19.

• Laravel 12.69, PHP 8.4
• Laravel Horizon 5.48, Sanctum 4.3
• Filament 4
• Next.js 16.3, React 19.2
• Bun 1.3.0, Turborepo 2.10
• MySQL in production, SQLite in the test suite

I spend weeks architecting client systems with care. For my own portfolio I was invalidating cache like a junior developer: php artisan cache:clear on a cron job, and hope. The irony wasn't lost on me.

Yabasha.dev is a Laravel 12 API with a Filament admin behind a Next.js 16 frontend on ISR. Making the two talk without me playing telephone operator every time I published turned into two answers, not one: the simple version this site runs, and the Cache Handshake — the version I'd ship where a stale page costs money.

Why did my Laravel + Next.js cache go stale for hours?

A cron job running cache:clear invalidates on a schedule, not on a change. When the schedule missed a publish, the old page served until the next tick. Then the first webhook I wrote had the opposite problem — it fired instantly and nobody checked whether it landed. Four failure modes, one root cause: no signal from the system that knows to the system that renders.

I was spending more time verifying cache state than writing. Not engineering — wishful thinking.

What is ISR in Next.js 16, and why can't Laravel see inside it?

Incremental Static Regeneration serves a statically rendered page and regenerates it either on a timer (revalidate: 180) or on demand, when code inside the Next.js runtime calls revalidatePath() or revalidateTag(). The cache lives in Next.js. Laravel has no native way in — the only door is an HTTP route you write yourself.

That door is the design problem. Next.js's revalidateTag documentation explains how to purge a tag; it says nothing about the caller being another service on another box that may be down, mid-deploy, or sending the same request twice. Time-based revalidation papers over that with a window. For a portfolio that publishes twice a month a 3-minute window is fine. For the same architecture under a client's newsroom it isn't — and this site exists to demonstrate the architecture I sell, not the shortcut.

ISR, SSR or SSG for a CMS-backed site?

ISR, when content changes on a human schedule and reads dwarf writes. The table is the argument:

On-demand ISR moves the whole problem into one phrase: if the signal is reliable. Everything below is about how reliable it has to be. For the layer above this — how the Laravel 12 API, Filament 4 and the Next.js 16 app sit in one Bun monorepo — see Laravel 12 + Next.js 16 Monorepo Architecture: A Production Blueprint.

How does yabasha.dev invalidate Next.js ISR from Laravel today?

yabasha.dev invalidates Next.js ISR with one queued job. PostObserver::saved() dispatches RevalidateFrontendJob when a published post changes; the job POSTs { tag: "posts", urls: [...] } to /api/revalidate with an X-Revalidate-Token header and an 8-second timeout. Next.js verifies the token, calls revalidateTag("posts"), and pings IndexNow with the URLs. Laravel Horizon retries a failed job up to 3 times. That's the whole system.

The URL list is the dependency graph, built where the change happens:

// app/Observers/PostObserver.php
protected function dispatchFrontendRevalidation(Post $post): void
{
    $urls = ['/blog', '/feed.xml', '/sitemap.xml', '/blog/'.$post->slug];

    if ($post->wasChanged('slug')) {
        $urls[] = '/blog/'.$post->getOriginal('slug');
    }

    RevalidateFrontendJob::dispatch('posts', array_values(array_unique($urls)));
}

// app/Jobs/RevalidateFrontendJob.php
public function handle(): void
{
    $token = config('services.frontend.revalidation_token');
    if (empty($token)) {
        return; // dormant in environments without a frontend
    }

    $response = Http::timeout(8)
        ->withHeaders(['X-Revalidate-Token' => $token])
        ->acceptJson()->asJson()
        ->post(rtrim(config('app.frontend_url'), '/').'/api/revalidate', [
            'tag'  => $this->tag,
            'urls' => $this->urls,
        ]);

    if (! $response->successful()) {
        report(new \RuntimeException("Frontend revalidate failed: HTTP {$response->status()}"));
    }
}

// apps/web/src/app/api/revalidate/route.ts (trimmed)
const token = request.headers.get("x-revalidate-token");
if (!verifyPasswordTiming(token, env.REVALIDATION_TOKEN)) {
  return NextResponse.json({ message: "Invalid token" }, { status: 401 });
}

if (!ALLOWED_TAGS.has(tag)) {
  return NextResponse.json({ message: `Tag '${tag}' is not allowed` }, { status: 400 });
}

revalidateTag(tag, "max");
after(() => pingIndexNow(parsed.urls)); // Bing, Yandex, Seznam, Naver, Yep

return NextResponse.json({ revalidated: true, tag, now: Date.now() });

Every fetch in lib/api.ts carries tags: ["posts"] and a time-based revalidate of 180 seconds on a post and 300 on the listing. Purging the tag makes the next request regenerate; the timer is the safety net if the purge never arrives. The same fetch layer feeds the assistant in How I Built an AI Agent for my Portfolio using Laravel & Next.js, so a stale cache would mean a stale answer.

How do you secure the Next.js revalidation endpoint?

Secure /api/revalidate with a secret in a header, compared in constant time, plus an allowlist of what the caller may purge. On yabasha.dev the token travels as X-Revalidate-Token; verifyPasswordTiming() compares it without leaking length or prefix through timing; a request that puts ?secret= in the query string gets a 410, because query strings land in access logs. The tag must be one of 12 allowed names, and the URL list is capped at 50 entries that must start with /.

That's a static shared secret, and I'll name the weakness: it lives in two .env files and rotates only when a human remembers. It is adequate here because the worst a leaked token can do is force a cache regeneration — expensive, not dangerous. The Handshake below replaces it with a short-lived signed JWT, which is the right call the moment the endpoint can do anything more than purge.

The anti-pattern to avoid is the one I started with: if (secret === process.env.SECRET). It's timing-leaky, it's usually in a query string, and it has no allowlist, so a leaked token purges everything.

What happens when revalidation fails today?

When the webhook fails on yabasha.dev, Horizon retries the job up to 3 times, the failure is reported to the log, and the 180-second time-based revalidation on the post fetch quietly repairs the page on the next tick. There is no acknowledgement and no callback. Laravel never learns whether Next.js regenerated anything — it learns only whether the HTTP call returned 2xx.

For this site the cost column is acceptable: nobody loses money because a blog post is three minutes late. Read that column again for a bank's rate page or a newsroom's homepage, and the simple version stops being a shortcut and starts being a liability. That's the line where the Handshake begins.

When is the simple version not enough — and what does the Cache Handshake add?

The Cache Handshake treats invalidation as a two-phase commit with Redis as referee. Laravel writes the intent to a Redis list with a unique revalidation_id; a worker POSTs to Next.js with a signed JWT; Next.js regenerates and calls Laravel back with the same id; only that callback marks the record completed. Failures re-queue up to 3 times, and a circuit breaker opens after 10 failures for 300 seconds so a dead deploy isn't hammered.

This is a design, not what the portfolio runs — the portfolio doesn't need it. It's what I'd ship where staleness has a price. The pieces:

// app/Listeners/QueueRevalidation.php — write the intent, never call Next.js directly
Redis::rpush('revalidation:queue', json_encode([
    'revalidation_id' => $event->revalidationId,
    'slug'            => $event->post->slug,
    'dependencies'    => ['blog?category='.$event->post->category->slug, 'blog', ''],
]));

Redis::hmset("revalidation:{$event->revalidationId}:status", [
    'state' => 'pending', 'attempts' => 0, 'created_at' => now()->timestamp,
]);

// app/Jobs/ProcessRevalidation.php — signed request, bounded retries
$token = JWT::encode(['sub' => $id, 'exp' => now()->addMinutes(5)->timestamp], $secret, 'HS256');

$response = Http::withToken($token)->post("{$nextjs}/api/revalidate", $payload);

if ($response->failed()) {
    $attempts < 3
        ? Redis::rpush('revalidation:queue', $raw)                 // re-queue
        : Redis::hset("revalidation:{$id}:status", 'state', 'failed');
    return;
}

Redis::hset("revalidation:{$id}:status", 'state', 'acknowledged');

// app/api/revalidate/route.ts — regenerate, then close the loop
revalidatePath(`/blog/${slug}`);
await Promise.all(dependencies.map((p: string) => revalidatePath(`/${p}`)));

await fetch(`${process.env.LARAVEL_URL}/api/revalidation/complete`, {
  method: "POST",
  headers: { Authorization: `Bearer ${process.env.REVALIDATION_SECRET}` },
  body: JSON.stringify({ revalidation_id }),
});

// app/Services/RevalidationStrategy.php — not all paths deserve the same budget
return match (true) {
    $path === ''                    => ['workers' => 5, 'timeout' => 10, 'retry' => 5], // homepage
    str_starts_with($path, 'blog/') => ['workers' => 2, 'timeout' => 30, 'retry' => 3],
    default                         => ['workers' => 1, 'timeout' => 60, 'retry' => 2],
};

Is there example code?

The live version is four files in the yabasha.dev monorepo: apps/backend/app/Observers/PostObserver.php (builds the URL list), apps/backend/app/Jobs/RevalidateFrontendJob.php (the call), apps/web/src/app/api/revalidate/route.ts (token check, allowlist, revalidateTag, IndexNow) and apps/web/src/lib/api.ts (the tagged fetches). The Handshake snippets above are the design in full; the Laravel side is an event, a listener, a job and a strategy class, and the Next.js side is one route plus one callback.

What did fixing this actually change?

The workflow now: write in Filament, publish, Laravel dispatches the job, Next.js purges the tag, the next visitor gets the new page, and Bing already knows. I don't think about caching.

The catch

The Handshake is more machinery than a portfolio needs — that's both the point and the warning. Ship the simple version until a stale page costs something, and know exactly which four properties you're missing when it does: acknowledgement, bounded retries, a breaker, and priority. It's the same discipline as the agent work in Building Production AI Agents That Work: What Failed First: the demo and the production version differ in what happens when the call fails, not in what happens when it succeeds.

So the question isn't whether your webhook works. It's this: when it fails at 03:00 during a deploy, who finds out first — you, or your reader? 🎯

Building the same stack for a client? That's the architecture on /services/laravel-nextjs.

I published a version of this in early 2026 describing a five-step agent: fetch the draft, generate metadata, run an SEO pass on a second model, validate, publish. It had a benchmark table pricing five models per task, a cost ledger, and a Filament widget showing thirty days of spend.

Almost none of that is in the repository. There is no FetchDraftJob, no GenerateMetadataJob, no AiCall model, no agent_runs table and no spend widget. I described the system I meant to build.

Here is the real thing.

What actually triggers the agent?

Saving a post. There is no review status, no queue button and no cron. An Eloquent observer runs after every save, checks seven columns, and dispatches one job if any of them is empty.

If every one of those is populated, nothing happens. That single condition is the whole scheduler, and it means the agent is idempotent by accident rather than by design: refill the columns and it stops firing.

What does the job actually do?

One model call. GeneratePostSeoJob hands the title and body to PostAiService::analyzeContent(), which builds one prompt, sends one chat request through OpenRouter, and parses one JSON response covering all the fields above.

Five classes, one call. The earlier version of this post split that into five queued steps because five steps sound like an agent. They are not free: each boundary is a place the run can die halfway with some columns written and some not.

Why is there only one active model?

Because choosing per task means maintaining a routing table, and the routing table was the first thing I deleted. AiModel::active()->first() returns one row, and that row's request_id is the model for every call on the site.

The catalogue itself is synced from OpenRouter and stores more than the id.

Those price columns are the vendor's published rates, not what I spent. Nothing in this repo records the cost of a call. A post that claimed an average cost per post was quoting a number no table holds.

If you want the version with real cost attribution, it is the client system in cutting LLM API costs 60%, where every call was traced before anything was optimised.

What happens when the active model disappears?

OpenRouter retires models, and the failover for that is the one piece of real agent machinery here. It is one level deep and it fires on unavailability, not on a retry count.

OpenRouterService::chat() sends the request with the active model. If the response fails and the error means the model is gone, it deactivates that row, notifies the admin, and resends with the environment fallback model. If that also fails, it logs and returns null.

That is smaller than what I described before, and it covers the failure that has actually happened to me.

What runs when the model returns nothing usable?

A heuristic that calls no model at all. Three different failures collapse into the same path, and none of them reach the caller as an exception.

fallbackAnalysis() reads the post and produces a summary, an excerpt and a description by truncation and sentence splitting. It is unglamorous and it always answers.

There is a second fallback underneath that one. If the model answers but omits meta_description, the job calls Post::deriveDescription(), which takes the excerpt, or the body if there is no excerpt. That is why a good excerpt is the best insurance in the whole pipeline.

Why is the model's output clamped before it is saved?

Because the model overshoots the word budget often enough to lose the sentence worth quoting. ai_summary_short is capped at 60 words. The frontend truncates on sentence boundaries, so an over-long summary loses its final clause, and the final clause is usually the one carrying the outcome.

So the same clamp the heuristic uses is applied to the model's answer too. It is a two-line fix for a failure that is otherwise invisible: the field is populated, the type is right, and the most citable sentence is missing.

How long is the job allowed to take?

Longer than the call it makes, which sounds obvious and was not. A single OpenRouter request is allowed 120 seconds. Horizon gives a worker 60.

For a while the job declared no timeout of its own, so it inherited 60 and any post long enough to take the model past a minute was killed mid-request. It wrote nothing and produced no useful error. I wrote that failure up properly in building production AI agents that actually work; the short version is that the job now declares 150 and the comment above it says why.

The retries are Horizon's, not the job's. The published version of this post gave the job $tries = 3 and a three-step backoff array. It has neither.

How does the published page find out?

Through a second job, not through this one. PostObserver also dispatches RevalidateFrontendJob, which posts a cache tag to the Next.js side, and the route calls revalidateTag.

There is a catch worth knowing if you build this. The SEO job writes quietly, without firing the observer again, so regenerating metadata purges nothing. The page waits out its own timer instead. A curl immediately after a run still shows the old value, and I have talked myself into believing a column was dropped on exactly that evidence.

The full protocol, including the acknowledged version I would build if staleness cost money, is in the cache handshake.

What does the admin side actually look like?

Filament 4, with five widgets, none of which are about AI spend.

The real controls are artisan commands rather than admin pages: posts:regenerate-summary for one post's TL;DR, posts:apply-revision to write a whole post from a markdown file, and posts:publish-scheduled, which the scheduler runs every minute.

Which versions is this running on?

Read from the lockfiles on 2026-09-21, because the published version of this post was wrong about two of them.

What is still missing?

Four things, and I am listing them because the previous version of this post claimed three of them were already built.

The architecture around all of this is described in what yabasha.dev actually runs, including the parts I would not ship to a client.

What would I tell someone starting this?

Build the trigger and one call. Nothing else, at first.

The instinct is to design the pipeline, because a pipeline is the interesting part. But a five-step pipeline has four places to die halfway, and on a personal site there is no traffic to justify that risk. One observer, one job, one model and a plain-code fallback covers the whole job of labelling your own writing.

The second mistake is never automating anything. That one I did avoid.

Read from the tree on 2026-09-21

• apps/web/package.json, apps/backend/composer.json for every version above
• PostObserver, GeneratePostSeoJob, PostAiService, OpenRouterService, AiModel
• config/horizon.php for the worker timeout and retry count
• routes/console.php for the scheduled commands
• app/Filament/Widgets/ for the widget list

The repository is private, so none of this is a link you can follow. The earlier version of this post said the pipeline was open source and invited readers to go and read it. That was wrong, and it is the correction I most wanted to make.

Questions: @bayyash