标签：#EV

In my first post, I wrote about why I spent my first week writing zero business logic and instead built rig - our lightweight, POSIX-compliant local provisioning tool. It was my way of rejecting "wiki-ops" and applying Infrastructure-as-Code (IaC) discipline to our local environments so that a hardware failure means minutes of downtime, not a week. But as I transitioned into Week Two, I was hit by a different kind of operational reality check. For years, I had been building a comprehensive repository of system architecture, design decisions, and guidelines on Confluence. It was my digital home. So, knowing I would be creating a startup, I set to work writing my documentation in my spare time in preparation. But during a brief hiatus of inactivity, the space was silently, unceremoniously deleted. It was gone. Late nights of ideas, patterns, templates, and reference materials vanished into the cloud ether. That loss was a violent reminder of a lesson I thought I'd fully mastered: if your documentation doesn't live alongside your code, you don't truly own it. Relying on third-party SaaS wikis to store the soul of your system architecture is just another form of "click-ops". It creates an artificial separation between the craftsmen writing the logic and the documentation that defines it. But rather than mourning my lost Confluence space, I treated it as a catalyst. I decided that our young startup would not have a bloated, detached corporate wiki. Instead, we would treat Documentation as a Contract - a unified, git-backed human-and-machine contract that serves as the precise, zero-maintenance boundary for our AI systems. Here is how losing my documentation led to a new architectural philosophy, and how we built a zero-overhead, "Anti-AI AI Strategy" that uses GitLab CI/CD and Google Workspace to run a secure, managed RAG pipeline. The Anti-AI Strategy: Why We Refuse to Let AI Write Our Code Walk into almost any tech startup today, and you’ll find developers blindly feed

Tuesday, 10:47 AM. Fourteen developers open their IDE extensions at once, and the shared AI server starts returning timeouts. Nobody planned for the morning spike. The free tier was announced on Monday, the team adopted it by Tuesday, and the first capacity incident happened before lunch. This article is a 30-minute load-test workflow for teams that just received access to a free hosted AI server. The goal is not to benchmark model quality. The goal is to find the concurrency ceiling before your team does — the hard way. The Free Server Is a Shared Resource Now MonkeyCode is an open-source AI coding project that offers free models and a free server. The offer is attractive for the same reason it is dangerous: it removes the two usual adoption barriers — API billing and self-hosting operations — and turns the server into a shared team resource overnight. Disclosure: This article was prepared as part of MonkeyCode's product outreach. A shared resource without a measured ceiling behaves like a shared database without connection pooling. It works in the demo, degrades under load, and fails at the worst possible moment: the morning standup, the release freeze, the day before the demo. The failure mode is not what most teams expect. It is not the token quota. It is latency collapse. Requests queue, timeouts cascade, and the IDE extension retries, which adds more load. The server does not die; it just becomes unusable. The Math: Little's Law for AI Requests Before writing any test code, define the model. Little's Law states that the average number of requests in a system equals the arrival rate multiplied by the average service time: L = λ × W L — average requests in the system (concurrency) λ — arrival rate, requests per second W — average service time per request, in seconds For an AI server, W is dominated by model inference time. A single code-generation request can take 10 to 40 seconds on a shared free server, depending on the model and the prompt length. That change

In remote software demos, the biggest problem is not always the product itself. Sometimes the audience simply doesn’t know where to look. A button may be visible. A setting may already be on screen. The presenter may be explaining everything correctly. But if attention isn’t directed clearly, people can still get lost. After doing a lot of screen sharing and software demos, I kept noticing the same small UX problems. 1. The cursor is visible, but not necessarily noticeable When you're presenting your own screen, you always know where your pointer is. The audience doesn’t. On a large monitor, a compressed video call, or a busy application UI, the pointer can easily disappear visually even though it is technically visible. This becomes especially obvious when you say something like: “If you look over here…” You know exactly what “here” means. The audience may need another second or two to find it. That delay sounds minor, but during a demo it can happen again and again. A presenter moves on to the next step while part of the audience is still trying to locate the previous one. 2. Moving the pointer is not the same as directing attention A common workaround is to move the mouse around whatever you want people to notice. I’ve done this many times myself. Circle the button with the cursor. Move back and forth over a chart. Quickly point between two settings. It works, but it also adds visual noise. Eventually I realized there are really two different actions happening: Navigation — using the mouse to operate the software. Attention — telling the audience where to look. During a demo, those aren’t always the same thing. Sometimes I don’t want to click anything or change the interface. I just want to say: Look here. 3. Highlighting something can interrupt the demo There are plenty of powerful screen annotation tools available. They make sense when you want to draw arrows, write notes, add shapes, or explain something in detail. But during a live product demo, switching int

How I Built a Wedding Planning Suite with Supabase in 3 Months Quick Answer: I built a full wedding planning platform in 90 days using Supabase as the backend (PostgreSQL database, real-time subscriptions, Row Level Security, and OAuth auth), Next.js 14 for the frontend, and a few carefully chosen npm packages for specific features like QR code scanning. The key was leveraging Supabase's managed services to avoid building auth, websockets, and file storage from scratch. Introduction Three months ago, I had an idea: what if couples could plan their entire wedding through one cohesive platform? Not a static checklist app, but a living, breathing system where vendors, guests, budgets, and timelines all talked to each other in real time. I'm a solo developer with a day job. I didn't have a team of backend engineers to build authentication, real-time sync, or file storage infrastructure. I needed a stack that would let me ship fast without shipping broken. Enter Supabase. I'd heard the "Firebase alternative" pitch before, but what I discovered was something far more powerful for developers who actually want to own their data and their SQL. This is the story of how I built WedPlanner—a full wedding planning suite—with Supabase, Next.js, and a few other tools. No VC funding. No offshore team. Just me, a tight deadline, and a PostgreSQL database that never let me down. Why Supabase? The Architecture Decision That Made Everything Possible When you're building alone, every architectural decision compounds. Pick the wrong database, and you'll spend weeks fighting migrations. Pick the wrong auth solution, and you'll ship with security holes you don't even know about. I evaluated Firebase, PlanetScale, Clerk, and rolling my own PostgreSQL on RDS. Here's why Supabase won: PostgreSQL, not a proprietary document store. Wedding data is relational. A guest belongs to a wedding. A vendor has multiple bookings. A budget category has many line items. Trying to model this in Firestore's

Background The site edit modal kept accumulating fields — site name, category, SSH connection details, WordPress install location — until editing anything meant scrolling up and down a single long form to find the right field. To clean this up, we split it into three tabs: "Registration info," "SSH," and "WordPress info." That change broke form submission itself, in a way that was hard to spot at first. What tabbing broke The tab implementation itself is straightforward. Each tab's fields live in a <div class="site-tab-content" data-tab="..."> , and CSS toggles which one is visible. .site-tab-content { display : none ; } .site-tab-content.active { display : block ; } An inactive tab is hidden with display: none . Nothing unusual so far, and visually it worked fine. The problem showed up when a required field sat in a tab that was not currently active, and the user left it empty while saving from a different tab. Clicking the save button did nothing . No error message appeared. The form just looked stuck. Root cause: a browser cannot report an error on a field it cannot show HTML5 form validation works by having the browser automatically block the submit event whenever a constrained field (like required ) fails, then focusing that field and showing its standard validation bubble (equivalent to calling reportValidity() ). Note: reportValidity() is a method from the HTML5 Constraint Validation API. It checks whether a form element's value satisfies its constraints (required, pattern, etc.) and, if not, displays the browser's standard error bubble. But when the failing field sits inside a tab hidden with display: none , the browser has nowhere to anchor that error bubble. It still faithfully blocks the submit — but it cannot visualize the error, so it simply stops without any visible feedback. From the user's side, this looks exactly like a button that does not respond. Before tabbing, every field lived on the same screen, so this never surfaced. Introducing tabs — a UI

Last month I shared how I built 143 free online tools that run 100% in your browser — no signup, no uploads, no watermarks. That post got a great response (and a lot of "how is this free?" comments — answer: it stays free because files never touch a server, so there are no processing costs). Today's update: every single tool now has a full guide series. What's new 144 how-to articles — one per tool — live at toolfyra.vercel.app/blog : Step-by-step guides — every input explained, common pitfalls, pro tips Real competitor comparison tables (we scraped and analyzed who ranks for what, and where their tools annoy users with account walls) FAQ sections with schema markup so answers surface directly in search and AI assistants Unique generated illustrations per article Smart related-tools clusters — finish one task, the next tool is one click away Why guides for calculator tools? Because "how to use a calculator" is what people actually search for. Tools win clicks; guides win trust and rankings . Each article is built from real search-engine data: live SERP results, keyword expansions, and competitor FAQ analysis — zero guesswork. The engineering side (for the dev readers) Every tool is a single HTML page with vanilla JS — calculators run client-side, file tools use Canvas/FileReader APIs The blog is generated (Python build script): schema.org BlogPosting + FAQPage + BreadcrumbList, per-post OG images as optimized SVGs, canonical URLs, sitemap + IndexNow pings on every deploy New site-wide: instant search (type "pdf" → live results dropdown, keyboard-first: / to focus, ↑↓ to navigate), a Tools dropdown with 11 categories, and a mobile hamburger panel — all vanilla JS, no dependencies Privacy by architecture: there is literally no upload endpoint to breach What's next More waves of content (FAQ, mistakes-to-avoid, and comparison articles for every tool) A batch of new tools from our demand-research pipeline (we score thousands of real search phrases before writing a line

Introduction: The Systemic Failure in Application Security Onboarding Consider the scenario of a junior Application Security Engineer tasked with securing a 2-billion-line codebase, written in unfamiliar languages, within a one-month deadline. This is not a theoretical exercise but the lived experience of a recent graduate in India, whose public appeal for assistance reveals profound deficiencies in how organizations integrate and support junior AppSec talent. The pressure is unrelenting, the tools are insufficient, and the expectations are disconnected from practical realities. This case is not an isolated incident but a symptom of a broader organizational failure to address the complexities of application security in high-stakes environments. The engineer’s experience underscores a critical misalignment: the exponential growth in codebase complexity has outstripped the resources and guidance provided to those responsible for securing them. Absent a senior AppSec mentor, with limited proficiency in critical languages such as Laravel/PHP and C#, and equipped only with rudimentary tools like grep and Codex, the engineer is forced to navigate an environment rife with unseen risks. The consequences are twofold: individual inefficiency and self-doubt, compounded by organizational exposure to unmitigated security threats. The causal pathway is unambiguous: massive codebases + unrealistic deadlines + subpar tools + absent mentorship → overwhelmed engineers → cursory reviews → undetected vulnerabilities → systemic security compromise. The risks extend beyond individual burnout to include data breaches, financial liabilities, and reputational damage. This is not an edge case but a predictable outcome of organizational neglect. The urgency is undeniable. As software systems increase in complexity and cyber threats proliferate, the demand for competent, adequately supported AppSec professionals has never been more critical. Yet, organizations persist in failing to bridge the

Grand Theft Auto VI is nigh. Here’s what the developer revealed about its highly anticipated game.

The JVM ecosystem offers a wide range of powerful frameworks, each with its own strengths and capabilities. In a modern distributed architecture, however, applications are not always built using the same framework. Services developed with frameworks such as Quarkus, Micronaut, and Spring Boot may need to communicate seamlessly as part of the same system. This guide demonstrates how RabbitMQ can enable cross-framework asynchronous communication between JVM applications. We will build two applications using different frameworks: a Quarkus application that publishes LeaveRequest messages and a Micronaut application that consumes and processes them. The first application, built with Quarkus, publishes a LeaveRequest object as a message to RabbitMQ. The second application, built with Micronaut, receives the LeaveRequest message and processes it according to the application's business logic. By the end of this guide, you will have a practical understanding of how two applications built with different Java frameworks can communicate asynchronously using RabbitMQ. Lets begin the journey To ensure that both applications use a consistent message contract, create a separate Gradle project named common. This project will contain the shared LeaveRequest model and can be referenced as a dependency by both the Quarkus and Micronaut applications. @Introspected @Serdeable public record LeaveRequest ( String personName , String personRole , String facilityName , String wardName , String shiftName , String leaveReason , String recipientName , String recipientEmail , String recipient , String subject ) {} The dependency on the common project will be dependencies { annotationProcessor ( "io.micronaut:micronaut-inject-java:5.1.12" ) implementation ( "io.micronaut.serde:micronaut-serde-jackson:3.1.1" ) } The @Introspected and @Serdeable annotations enable Micronaut to generate the metadata required for efficient introspection and serialization. Connecting Quarkus to RabbitMQ To connect th

Hey everyone! 👋 Finding reliable, free public APIs for side projects or learning is always a hassle because many listed APIs eventually go down or become paid. To solve this, I created Awesome Free APIs Live — an open-source, curated collection of 50+ free public APIs across AI, developer tools, security, and open data. ⚙️ How It Works Daily Health Checks: Powered by GitHub Actions , an automated script tests endpoints daily and updates live status badges. Zero Dead Links: Broken endpoints are flagged automatically so developers don't waste time debugging dead services. Categorized & Searchable: Clean, categorized UI hosted on GitHub Pages. ### 🔗 Links 🌐 Live Directory: shilpshakti.github.io/awesome-free-apis-live ⭐ GitHub Repository: github.com/ShilpShakti/awesome-free-apis-live Contributions are very welcome! If you know of any great free APIs, feel free to open a PR or check out the open issues on GitHub.

What is ZeroDroid? ZeroDroid is an open-source Android toolkit that exposes the radios, sensors and connected-device capabilities already present in a phone. GitHub: https://github.com/theabhishekchandra/ZeroDroid What problems does it address? The app contains 29 tools across five areas: Wireless: Wi-Fi, BLE, NFC, Bluetooth Classic and peer-to-peer connections RF and signals: IR, UWB, SDR-device detection and ultrasonic analysis Sensors: GPS/GNSS, QR analysis, device sensors and magnetic anomalies Network: USB inspection, cell-tower information and wardriving Security: tracker scanning, hidden-camera indicators, rogue-AP detection, network scanning and deauthentication indicators Architecture ZeroDroid uses Kotlin, Jetpack Compose, Material 3, MVVM, StateFlow, Hilt and Room. Services are lazy-loaded, and scanning begins only when the user starts a tool. Important limitations A smartphone cannot guarantee that it has found every camera, tracker, bug or network threat. Several detections are heuristic and may produce false positives or miss threats. Hardware availability also differs between Android devices. The project is intended only for education, defensive security and testing devices or networks you own or are authorized to assess. Feedback wanted I am looking for: Compatibility reports from different Android phones Feedback about permission handling False-positive reports Contributions, tests and documentation improvements Repository: https://github.com/theabhishekchandra/ZeroDroid

When testing opinionated Linux distributions, the ultimate benchmark isn't how smoothly they run on a workstation with 16 cores and a high-end GPU—it's how gracefully they perform on budget, resource-constrained hardware. Enter Omarchy , the "omakase" Arch-based distribution created by David Heinemeier Hansson (DHH) . Built around the Hyprland tiling window manager and explicitly tailored for modern developer productivity, Omarchy proves that a curated desktop environment doesn't require a heavy computing footprint. Running Omarchy 4.0.0 on an entry-level laptop built around an Intel Celeron N4020 CPU demonstrates how deliberate software curation turns modest hardware into a fast, highly capable development machine. 💻 Hardware & System Overview Below is the environment breakdown from our test run: Category Specification / Details Hardware / PC Model ASUS C204M Processor Intel® Celeron® N4020 (2 cores / 2 threads) @ 2.80 GHz Graphics Integrated Intel UHD Graphics 600 Display 11" Built-in Display (1366x768 @ 60 Hz) RAM Utilization 2.69 GiB / 3.68 GiB (~73% load) Storage / Root 15.66 GiB / 27.10 GiB (~58% used) on Btrfs OS & Kernel Omarchy 4.0.0-1 (Linux Kernel 7.1.8-arch1-3) Compositor Hyprland 0.56.2 (Wayland) 🚀 The Developer Experience: What Makes Omarchy Special Omarchy isn't just an Arch installer with custom dots; it's an opinionated operating system designed to eliminate setup friction and let you write code immediately. 1. Zero-Friction Language Setup via Menus Setting up language runtimes on a fresh Linux install often involves hunting down version managers (like asdf , nvm , or pyenv ), configuring shell initialization scripts, and managing system paths. Omarchy streamlines this entirely. Through its integrated menu system, installing a programming language or developer stack is as simple as launching the system menu, picking a language (Node.js, Ruby, Python, Go, Rust), and hitting Enter. The system automatically installs the necessary version managers, conf

Claire McDonough is stepping down on October 30 to pursue a new opportunity, the company said in a filing on Thursday.

Indexar o código fora do repo: como economizar tokens sem jogar o projeto no contexto Pessoal, o agent precisava achar um símbolo. Trabalho de um minuto. Na prática, ele abria arquivo atrás de arquivo, colava dump de teste no papo e a janela sumia. Às vezes a fatura também. Não era o modelo burro. Era eu pagando o monorepo inteiro pra responder a pergunta errada. A pergunta mudou. Deixei de ser “qual tool faz o agent entender o repo?” e virei: o que é memória de domínio, e o que é só custo de ler código nesta sessão? Tem um segundo motivo, e ele não é economia. Um índice de símbolos é um mapa do seu sistema : quem chama o quê, onde está o fluxo crítico. Se esse mapa mora no git, no cache de CI ou num serviço que o agent também escreve, o blast radius não é só token. É superfície. Duas contas, um prompt Memória de domínio é política. O que pode ser lembrado, por qual porta se entra, o que é canônico. Notas, contratos, “onde a gente decide X”. Indexer de código não resolve isso. Code-read barato é custo de sessão. Achar caller e símbolo sem despejar o working tree no prompt. Isso não deveria virar a sua base de conhecimento. Eu misturava. O indexer virava KB. O vault virava grep sem porta. Os dois falhavam, e a sessão inchava igual. Economizar token aqui não é trocar de modelo da semana. É separar camada. E decidir onde o mapa vive . O que eu mudei na mesa O mapa de símbolos saiu do working tree. Cache local, fora do repo , fora do git. Reindex é operação de máquina, não de PR. O agent consulta o índice; não precisa reler o monorepo pra “quem chama essa função?”. Quatro perguntas que eu faço antes de indexar um repo (vale colar no README do setup): O índice vive na minha máquina ou sai dela (cloud, CI, cache compartilhado)? Entra em contexto de agent que também tem tool de escrita ? Como eu apago e revogo? Quem mais lê isso? Índice ≠ fonte de verdade versionada. Least privilege no que entra no contexto continua valendo. Depois, parei de mandar firehose de CLI cru. tes

Last week, it came to light Cursor had mostly finished migrating from SolidJS to React . This migration happened about seven months ago. But it became a central focus of discussion following the Solid 2.0 RC release . Then yesterday, a week later, it came to my attention that the Anthropic docs example command for their large-scale migration feature is: I admit that my gut reaction was not great. Out of all the examples they could have chosen... Years of my work became a canonical example of the thing you migrate away from — in the same week we shipped the biggest release in the project's history — stung in a way I won't pretend it didn't. My second reaction was to assume that, like the other trickle-down posts I'd seen this week, this rode the same week-old news cycle. Then I checked the Internet Archive and realized this has been there since at least April 2026 . Four months before the Cursor story broke. At this point, the whole public footprint was a mention of an experiment sandwiched between bigger updates in a Cursor blog post posted in January. The kind of thing that no one outside the industry would even really pick up on. No reasoning, no benchmarks, no argument. Stop to think about what that means. I should be careful here because I can't prove anyone at Anthropic ever read that Cursor post. Nobody can. Maybe a docs writer saw the experiment. Maybe Claude drafted its own example. But think it through. Either it traveled from a buried line in one company's release notes into another company's official docs, or it needed no origin at all. It was already assumed before any public migration existed. Our industry has quietly started broadcasting conclusions where it used to transmit arguments. We couldn't have picked a worse time, because — as I'll get to — arguments are the only source that still matters. Why This Matters More Than It Used To It would be fair to ask, hasn't it always been like this? Teams cargo cult large players. Netflix or Facebook uses thi

Every hackathon has the same 90-second moment of dread: someone hands you a codebase you've never seen, and you have to make sense of it before the clock runs out. File trees don't help. grep doesn't help. You waste the first 30–60 minutes reading the wrong files, missing a hidden dependency, and stepping straight into a production trap nobody warned you about. In other words: before writing code, you spend half your time trying to figure out where the hell the code is. The idea wasn't "AI that writes your code." It was "AI that tells you where to look before you write it." For InnovaHack Chapter-1, my team built Waypoint — a dev onboarding platform. Point it at any GitHub repo or a local folder, describe a task like "Add a new global configuration flag to app.set()", and instead of you reading the whole codebase to figure out where that even goes, it hands you a Mission Brief : exactly which files you'll touch, the traps waiting in them, what to learn first, and the order to do it in. Waypoint made the Top 50 — one of the 50 chosen to advance to Round 2. Here's how it actually works under the hood, what it took to build, what's next for it — and since I don't believe in only posting the highlight reel, what happened after we placed that made us walk away from the next round. The problem: the cold-start tax Every time a developer joins a new codebase, or picks up an unfamiliar task in one they already know, there's a tax paid in wrong files read, missed dependencies, and traps hit blind. For me, that moment came when I wanted to contribute to Forem — the open-source project that actually powers DEV. I didn't know a line of Ruby on Rails, and between learning the language, understanding the framework, and preparing for interviews, I didn't have the time to read an entire unfamiliar codebase just to figure out where one feature belonged. I never ended up making that contribution. But the problem stuck with me. It's also a pattern for our team more broadly: we delibera

We build GPTree with several coding agents working the same repository at once: Claude Code, Codex, and Cursor, each in its own git worktree. The failure that finally made us build tooling for it was small and completely silent. One session was told to replace PaymentService with a Stripe-specific implementation. Another was told to add PayPal support to PaymentService . Different worktrees. Different files. Zero textual conflict. Git merged both branches cleanly, and the second change now depended on an extension point the first had deleted. Nothing in the toolchain had an opinion about it at any moment. Git compares diffs. It cannot compare plans. Worktrees isolate files, not plans Worktrees became the standard answer to parallel agents for a good reason: two sessions editing one checkout will overwrite each other's files and poison each other's context. Isolated checkouts fix that completely. But three failure modes survive file isolation, because they were never about files: Destructive versus additive. One agent removes or replaces a thing another agent is building on. The example above. Merges clean, breaks the design. Duplicate work. Two agents solve the same problem from different angles because nothing assigned ownership. You pay twice and then pay again to reconcile. Contract drift. One agent changes an API, a schema, or a config contract while another codes against the old shape. Compiles, runs, disagrees at runtime. A shared task list helps with the second one, if every agent reads it, every time. Nothing in that setup catches the first or third, because the collision is between intentions, and intentions live in prompts, not in any file a tool can watch. Declare the work before doing it Foremerge is the internal tool we built for this, open-sourced this week. It is a coordination protocol that sits above Git: agents declare what they are about to do, before they do it, in a form precise enough to check. A declaration is an intent with one or more semant

Originally published at parvejshah.com/blog/why-browser-agents-fail-in-production-without-semantic-layers by Parvej Shah . The Fragility of Machine Vision in Modern DOMs Maybe the next evolution of frontend engineering isn't just designing interfaces for humans. It is designing interfaces that machines can reliably understand too. Browser agents don't always fail because the AI model is bad. Often, the web page itself is fundamentally hostile to machine parsers. Modern single-page applications (SPAs) render deeply nested <div> trees with ephemeral, auto-generated class names (such as Tailwind or CSS-in-JS hashes). While this provides fluid visual rendering for human users, it strips away semantic meaning for automated agents. graph TD A[AI Browser Agent] -->|Fragile Visual OCR / Coordinate Guessing| B[Opaque Div Hierarchy] B -->|Frontend Code Deploy / CSS Hash Shift| C[Broken Automation & Flaky Selectors] A -->|Direct Deterministic Query| D[Semantic Schema & data-agent Attributes] D -->|Refactor-Proof Contract| E[Deterministic Task Execution] Moving Beyond Ephemeral Selectors We already treat accessibility (a11y) as a non-negotiable contract between the frontend and assistive technologies through ARIA attributes. Why not extend that exact engineering rigor to AI agents? Imagine components exposing explicit, stable machine intent: // The machine contract: deterministic, testable, refactor-proof < button data - agent = " checkout-submit-button " data - agent - action = " complete-transaction " className = " btn-primary " > Confirm & Pay < /button > With explicit semantic attributes: Zero Layout Guesswork: The agent does not need to guess which button to click based on pixel coordinates or fragile CSS selectors. Deterministic Interaction Paths: Continuous integration (CI) test suites can validate machine contracts alongside accessibility audits. Reduced Latency & Token Costs: Vision-language models (VLMs) introduce non-deterministic latency and high token costs when in

₹85,000 per month. That was the AI API bill sitting in my client's inbox when they called me in a mild panic last quarter. They run a mid-sized e-commerce operation in Pune — about 4,000 orders a day — and had integrated AI into customer support, product descriptions, and internal reporting. The AI was working beautifully. The invoice was not. Three weeks later, their monthly bill was ₹12,400. Same tasks. Same quality. No corners cut. Here's exactly what changed. The real problem: every task was using the most expensive model When I audited their setup, the issue was obvious within five minutes. Every single API call — whether it was classifying a customer complaint into one of 8 categories or generating a 2,000-word product description — was hitting the same premium model. It's the most common mistake I see with businesses adopting AI: they pick one model during the proof-of-concept phase and never revisit that decision as they scale. You wouldn't hire a senior chartered accountant to do data entry. But that's essentially what was happening — a top-tier reasoning model answering "Is this complaint about shipping or billing?" Fix 1: Model routing — the single biggest cost lever Model routing means sending each task to the cheapest model that can handle it at acceptable quality. I categorised their ~47 distinct API call types into three tiers. 68% of calls moved to the lightweight tier, 20% to mid-tier, only 12% stayed on premium. That single change dropped the bill from ₹85K to roughly ₹38K — no quality loss, verified with two weeks of A/B testing on customer satisfaction scores before switching fully. Fix 2: Prompt caching — stop paying for the same context twice Their support bot sent the same 1,200-token system prompt with every call — policies, tone, catalogue context, all identical across thousands of daily calls. Caching processes it once and references it cheaply on subsequent calls within the window. At ~6,000 support interactions a day, this alone saved ₹8,

Originally published at parvejshah.com/blog/why-browser-agents-fail-in-production-without-semantic-layers-test by Parvej Shah . The Semantic Contract Modern web applications optimize DOM trees for human eyes with nested divs... graph TD A[Vision Model] -->|Fragile OCR| B[DOM Tree] C[Semantic Layer] -->|Deterministic Contract| B const button = document . querySelector ( " [data-agent=submit] " ); Parvej Shah is a Lead Full-Stack Web Developer & Platform Architect based in Dhaka, Bangladesh. Explore full architecture case studies and production code at parvejshah.com .