The Lab

Accelerating engineering throughput via AI agent orchestration increases code volume, but it introduces severe financial exposure when vulnerabilities reach production. Remediating security flaws downstream inflates application TCO and creates unbudgeted OPEX driven by emergency patching and rework. Generating code faster without embedded security validation at the source merely accelerates technical debt and operational risk. To eliminate this bottleneck and enforce a strict Shift-Left posture, I engineered and integrated the `owasp-security-verification` skill into my AI-Augmented SDLC orchestration suite. This component executes automated audits on agent-generated code and architecture against OWASP Top 10 (2025) and ASVS 5.0 standards. Furthermore, it addresses emerging threat vectors specific to Generative AI and multi-agent systems (OWASP LLM Top 10 and Agentic Security), guaranteeing that workloads deployed to Serverless or containerized environments adhere to rigorous authentication, cryptography, and input validation controls. The true return on investment in AI-driven development is not raw output volume; it is minimizing the Verification Tax required to audit agentic code before it impacts cloud unit economics. In your AI delivery pipeline, are you validating security posture directly within the architectural prompt, or paying the remediation penalty on your monthly cloud invoice?

In July of this year (2026), Babel, the catalog, search and sales app for the Le Tiende bookstore, designed with an explicit cost target of US$0, ran up an AWS bill of US$94.44. DynamoDB accounted for US$90.34 of it (96%); Lambda, which is the actual application, cost US$0.00028 for the entire month. It all traced back to just one line in serverless.yml: "provisioned capacity 25/25 on every table (AWS always-free tier, US$0 cost target, never on-demand)". An agent wrote it, I approved it in a PR, and it was wrong where it mattered: the free 25 RCU and 25 WCU apply per account, not per table. Eight tables, two stages and two secondary indexes added up to 18 blocks of 25/25. That meant US$8.42 a day, flat and identical for 11 days, to store only 43 test records. The real damage wasn't the mistake itself but the "never on-demand", which locked the assumption in place and ruled out the right fix before anyone could propose it. Fixing it took one command, update-table --billing-mode PAY_PER_REQUEST across all 16 tables without losing a single record, plus an IaC change that same day. What took longer was understanding why nobody saw it coming. There was a US$4 budget, but the fixed Route 53 floor (about US$3.58) maxed it out on the first of every month, so its alert fired every time and meant nothing. I wrote the case up as a warning for agents and humans (in Spanish), now required reading before anyone builds infrastructure for a Le Tiende project. Three of its rules: no price gets written down without checking it that day (otherwise it is flagged SIN VERIFICAR, "unverified"), budgets are set above the account's fixed cost floor, and anything billed by the hour rather than by usage is a standing liability. What a model knows about cloud pricing is out of date by design, and the confidence with which it calls something free has no bearing on whether it still is. But the model didn't pay the bill. Whoever approved the PR without asking where that number came from did. Reviewing the code isn't enough; you also have to audit the assumptions hiding in the comments. How many cost claims in your IaC did you personally verify, and how many did you inherit from an agent with enough authority?

On August 3rd I published an 80/20 here: AI handled 80 % of raw execution volume, I handled the 20 % of architecture. This month I re-ran the analysis over the same file, 237 rows and 107.7 hours, and it came back 6/94. Not because the Pareto split is false, but because my CSV could never prove it. The rows marked as AI were session wall-clock: while the agent worked, I was reading, approving and course-correcting, and all that supervision sat hidden inside the time credited to the machine. I was measuring who executed the task, not what it cost me to review it. The verification tax was structurally invisible in the schema. If your AI productivity dashboard has a single time column, it very likely carries the same blind spot. To close that gap I released ai-effort-tracking under an Apache 2.0 license. The finding that made it possible is almost mundane: the tax was already on disk. It's the interval between the agent finishing its answer and me sending the next prompt, and the transcript has been recording it all along. With hooks it stops being an estimate and becomes a measurement, with a threshold that reclassifies long gaps as absence rather than review, so a session that spends the night waiting doesn't inflate the metric. The skill also separates the billing regime, because under a subscription the marginal cost of a token is zero and under an API it's real. And it normalises cache accounting across providers: Anthropic, OpenAI and DeepSeek count it three incompatible ways, and getting it wrong throws no error, it just inflates cost by 3.23×. When no verified rate exists, cost stays `null` instead of being estimated. Correcting one of your own published figures costs more than publishing it, but a number that can't survive its own audit isn't telemetry, it's an anecdote with decimals. What I know now is that in AI-augmented development the expensive question isn't how much the agent produces. It's what it costs me to trust what it produced. Did you measure your 80/20, or did you assume it?

As the old adage goes, "the shoemaker's children go barefoot." A similar dynamic plays out in solution architecture: internal infrastructure keeps getting pushed aside for client-facing priorities. The real bottleneck is rarely technical capability—it's managing resource allocation and opportunity cost when the internal stakeholder is the one being served. For the complete overhaul of my website, I deployed a structured engineering framework integrated with AI-driven development. That strategy let me accelerate delivery and optimize OPEX without sacrificing architectural consistency. The full implementation process and technical artifacts live in the development log and the project repository, and I'd point especially to the Google Stitch integration process, where enforcing design system governance took fine-tuned prompt orchestration. Building custom solutions for yourself demands strict operational governance to keep scope creep in check. What framework do you rely on across discovery, design, and deployment to stay focused and actually ship your own engineering initiatives?

The software industry seems obsessed with "AI programming" hype, yet hardly any engineering leadership actually quantifies its real impact with empirical telemetry. Anecdotal productivity gains are a shaky foundation—one that inflates OPEX and leaves developer idle time unchecked. Skip a line-by-line audit of resource allocation across the Software Development Life Cycle (SDLC), and you're deploying AI tools on blind faith rather than operational efficiency. To set clear benchmarks, I put a minute-by-minute tracking specification into operation (instrucciones-tracking.md), logging task stages, human-versus-AI execution, and hardware interface constraints. The data is decisive: AI handles 80% of raw execution volume across `Specs`, `Backend`, `Frontend`, and `Cloud` tasks—a steady 80/20 ratio. Just 10.4 hours spent purely on upstream business-rule specifications unlocked over 16 hours of asynchronous, mobile-driven validation. Shift human effort from syntax generation to strategic architecture, and staff productivity rises while the Total Cost of Ownership (TCO) per feature delivered comes down. AI-augmented engineering isn't about replacing the developer—it turns the Senior Engineer into an Executive Orchestration Director. Are you actually capturing concrete SDLC unit metrics, or paying for AI seats without tracking what they yield on your bottom line?

Deploy autonomous CLI agents without strict operational boundaries and you're setting up a disastrous domino effect: cascading dependency failures, unchecked token bleed, runaway API billing overhead. Too many teams bolt agentic workflows on as isolated scripts, missing that unrestricted model execution inflates transaction costs and puts budget viability directly at risk. AI infrastructure without deterministic limits isn't scaling — it's compounding engineering debt. To solve this operational bottleneck—inspired by this article—I built and released project-docs-bootstrap under an Apache 2.0 license: a native, 3-file local state orchestration framework structured as a skill. Rather than bolting on heavy external specifications that add technical friction, this architecture enforces deterministic limits directly in the file system. Restricting execution through "Plan Mode" cuts down infinite loops, slashes API operating expenses (OPEX), and keeps the repository stable, protecting your Total Cost of Ownership (TCO). LLMs behave a lot like teenagers: they need clear parameters and guardrails, because leaving them alone at the mall with an uncapped credit card never ends well. Are you actively governing your agentic workflows, or letting autonomous CLI tools run up an open, unmonitored corporate credit card?