# Marcelo Guerra — Full Profile > Software & Hardware Developer | Electronic Engineer | Full-Stack Developer ## About I'm an electronic engineer and full-stack developer with over two decades solving problems with technology — from embedded hardware systems to modern web applications. Today I focus on mentoring other developers and building products, integrating processes and delivering solutions. Whether with PHP, JS, Go or another language, with or without AI tooling integration, the end result has to be a product that meets the objective and is appropriate for the business's current stage. When not coding, I'm usually exploring new technologies, tinkering with hardware projects, or thinking about how to simplify complex processes. ## Tech Stack - **Backend:** Laravel, PHP, Livewire - **Frontend:** Vue.js 3, TypeScript, Tailwind CSS, Inertia.js - **Admin:** Filament v5 - **Infrastructure:** Docker, Docker Swarm, Traefik, Proxmox - **Databases:** PostgreSQL, MySQL, SQLite, Redis - **AI/ML:** OpenAI API, Claude API, AI tooling - **Hardware:** Electronic Engineering, Embedded Systems ## Projects ### PrimeForge — Infrastructure Control Panel PHP, Laravel, Filament, Go, Docker, Traefik, PostgreSQL, Redis ### Cloud Prime — VPS & Managed Services Laravel, Filament, Livewire, Proxmox, xterm.js, VNC, SSH, Docker Swarm, MySQL, PostgreSQL ### Packgrid — Private Package Server PHP, Laravel, Filament, Livewire, Composer, npm, Docker ### Anonymize — Data Anonymization CLI TypeScript, Node.js, npm, Faker ### File Manager — Filament Plugin PHP, Laravel, Filament, Livewire, Tailwind, S3/MinIO ### Web Terminal — Filament Plugin PHP, Laravel, Filament, Livewire, SSH, Bash ### Copy File Content — JetBrains Plugin Kotlin, Gradle, IntelliJ Platform ### Task Master Terminal UI Ink, React, TypeScript, Node.js ### Interactive Upgrader for Laravel PHP, Composer, Laravel, Node.js ### Console Agent — AI Flows PHP, YAML, OpenAI, Pest ### Node.js RDAP Client RDAP, Node.js, TypeScript, Bash, Mocha ## Career Timeline - **2017-2026:** CTO & Developer at Likker — technical vision and all technical decisions, from strategy and processes to developing real solutions, deployment, continuous operation, and product evolution - **2014-2020:** Freelance Developer - **2004-2014:** Project Management, Consulting & Technology Specialist ## Contact - Website: https://mwguerra.com - GitHub: https://github.com/mwguerra - LinkedIn: https://www.linkedin.com/in/marcelowguerra/ - Email: mwguerra@gmail.com ## Posts Let's talk about uncertainty and AI (https://mwguerra.com/blog/en/uncertainty-and-ai-code-review-third-party-packages-observability): LLMs introduced a black box of behavior, and the work became minimizing uncertainty. In development, bigger PRs and barely reviewed code call for treating AI code like a third-party package: changelogs, tests, vulnerabilities and interface consistency, with human review in critical code. In AI as a feature, the quality of the same model version varies, and tests, guardrails and observability become instruments of control. Since the first chatbots, LLMs have introduced a black box of behavior. From there, the work has had one general focus: minimizing that uncertainty. It shows up in two places: in the code AI writes for the project and in the AI the project uses as a feature. --- ## On developing with AI PRs have been getting bigger with AI, and the code in them less and less readable. How do we handle this uncertainty in projects? - Do we automate code review? - In this context, is the human still relevant in the process? - If so, what is the new context, and the level of abstraction, that should be reviewed? The same can be asked about tests: what to test and how to test it. ### What are PRs and code reviews for today, after all? They used to guarantee adherence to process and learning through peer review. Today, that loses some of its meaning with large PRs and AI-generated code. AI can now write, review and change its own code. Often that code is barely reviewed by the developer, even when it is tested exhaustively. ### The promise and the shift in focus AI comes with a promise: to make the work easier and let the developer focus on what matters most. But that means the developer has to want to shift focus from code to: - the product - the architecture - the process - the delivery of value All of that while keeping their core knowledge of code, as a specialist. **Developers are problem solvers. They deliver solutions, and that does not change.** ### AI code as a third-party package Using AI code is not very different from using a third-party package whose source you have never read and whose changes you do not follow. **Security in AI code should be treated in a similar way.** Allowing for the differences, we should also: - review changelogs - make sure tests are being implemented correctly and are testing what should be tested - periodically assess the code for vulnerabilities - validate that its interfaces and features still match the need You have to trust whoever wrote the package. In the same way, you have to trust that the AI wrote code that not only works but also meets the many criteria the project defines, and that it was developed following adequate processes. ### Part of the solution, not all of it Harness, specs and skills are part of the solution, but they are not everything. **Human review is still essential in critical code.** There, not just the behavior but every action must be mastered by whoever will maintain critical systems and is responsible for how they function and operate. --- ## On using AI as a feature in projects Beyond the project's code, do you trust the AI models you use? The AI model brings a new layer of uncertainty that we cannot control. Model quality, even within the same model version, has historically varied over time. That has to be taken into account in the project. Tests that were already important carry even more weight and relevance in this context. Guardrails are also essential layers of validation and protection for the process. **Observability takes on a new role: it becomes a tool not only for monitoring, but also for control.** Control of tokens, cost, ethics, decisions and more. --- The black box is still there. The work is still the same: minimizing the uncertainty around it. - AI gets demoed in greenfield and billed in legacy (https://mwguerra.com/blog/en/ai-gets-demoed-in-greenfield-and-billed-in-legacy) An essay on where AI generates returns in real software. The legacy problem was never writing code, it was understanding what exists: program comprehension studies show more than half of working time spent on understanding. The biggest brownfield return is context recovery: assisted archaeology with candidate documentation, characterization tests that freeze behavior before change, strangler fig executed by agents in validated slices, and new layers (adapters, tests, instrumentation) as greenfield hidden inside the legacy. It rejects the two symmetrical promises: autonomous rewrites and legacy as forbidden ground for AI. Topics: legacy, brownfield, characterization tests, strangler fig, code comprehension, software archaeology, documentation, technical debt, migration, agents Every AI demo you have ever seen starts the same way. Empty repository, one prompt, a working application in minutes. The software estate that sustains companies looks nothing like that. AI's bill is not paid where it impresses. It is paid where the code is ten years old, has had three previous owners and carries no tests. --- ## The legacy problem was never writing Program comprehension studies have measured the same phenomenon for years: developers spend more than half of their working time understanding existing code, not producing new code (Xia et al., 2018). In legacy systems, the proportion only grows. Generating code was always the cheap part of the equation. The expensive part is knowing what exists, why it exists that way and what breaks when something changes. A tool that generates code attacks the cheap part. **The AI that generates is a showcase. The AI that helps you understand is leverage.** --- ## Assisted archaeology The first serious use of AI in brownfield does not produce a single line of feature. It produces understanding: mapping modules and dependencies, explaining stretches nobody touched out of fear, reconstructing the intent behind decisions nobody documented, generating candidate documentation for human review. "Candidate" is the word that matters. The model's output about your system is a hypothesis to validate, not established truth. The model infers intent from patterns, and old systems are full of patterns that lie. The final artifact rewards the care: versionable context where there used to be memory. The map that lived in a few heads becomes a document the whole team reads, reviews and corrects. The same document becomes quality context for the next agent task, and the cycle feeds itself. --- ## Freeze behavior before changing it Michael Feathers defined legacy as code without tests, and the definition has aged well. The agent-era reread lies in characterization tests: tests that record the system's current behavior, right or wrong, before any change. Writing those tests was always too tedious to actually happen. High volume, low creativity, invisible value until the day it saves a deploy. It is the exact task profile where an agent shines, with mandatory human review on the output. The net changes the conversation about risk. Refactoring without characterization is a bet. Refactoring with the suite recording every deviation is a controlled operation. **First freeze the behavior. Then change it.** --- ## Strangler fig with agent arms The strangler pattern has existed for decades: build the new around the old, redirect flow gradually, turn off the old once parity is proven. Martin Fowler described the path long before language models existed. The limiter was never the concept. It was manpower. Mapping routes, extracting a piece, keeping both alive, measuring parity: work too long for most budgets. The combination that changes the game: specs extracted from observed behavior, an agent executing the migration in slices, a characterization suite validating each slice before the next. The decision of what to strangle first remains human. Risk, value and coupling do not come out of a prompt. --- ## The greenfield hidden inside the legacy Not every gain requires touching the core. A good share comes from new layers around what exists: adapters that isolate the old behind a clean contract, tests where there never were any, documentation where there was legend, instrumentation where there was silence. Each of those layers is genuine greenfield, with the advantage of delivering value on top of the system that already generates revenue. The prioritization criterion is the usual one: start where understanding is scarcest and change is most frequent. --- ## Where the discourse goes wrong Two symmetrical promises deserve suspicion. "AI rewrites your legacy on its own." Big-bang rewrites failed before models existed, for reasons that were never a lack of manpower: implicit requirements, undocumented behavior, invisible dependencies. **AI lowers the cost of labor. The cost of ignorance stays exactly where it was.** "Legacy is no place for AI." That one inverts the return. Greenfield has little context to recover. Legacy is where context recovery is worth the most, precisely because it is the scarcest asset there. --- ## Conclusion The empty repository will keep producing beautiful demos, and that is fine. Demos have a function. The software that pays companies' bills has age, scars and a poorly told history. That is where the productivity promise needs to prove itself. Whoever points AI at where understanding is missing, and not at where code is missing, reaps the return the demo promised and never delivered. **Greenfield impresses. Legacy pays the bill.** - Without evals, every new prompt is an untested deploy (https://mwguerra.com/blog/en/without-evals-every-new-prompt-is-an-untested-deploy) A technical article presenting evals as the regression test reread for LLM systems. Unit tests verify deterministic functions; a model returns a distribution, and the assert becomes a measurement with a threshold. A worthwhile suite combines golden, edge, adversarial and cost cases, favoring curated sampling over exhaustion. LLM-as-judge works with calibration against human evaluation and periodic re-evaluation. Coupled to prompt versioning, the suite turns V2 versus V1 from opinion into a diff and protects against provider model swaps. Closes with a twenty-case starting plan. Topics: evals, golden dataset, LLM-as-judge, behavior regression, prompt versioning, acceptance criteria, calibration, evaluation suite, agent quality When your team shipped the V2 of its agent, how did it measure that it was better than V1? In another article, that question appeared as the divider between amateur and professional teams, and it was left without a full answer. Versioning prompts like code, a thesis I have also defended, solves traceability. Tracking is not evaluating. The missing discipline has a name: evals. --- ## What unit tests do not reach A unit test verifies a deterministic function. Input X, output Y, always. The assert is boolean and a green suite means behavior preserved. A model returns something else: a distribution. The same input produces legitimate variations, and the variation is not a bug, it is a property of the component. Exact assertions break on any synonym. Loose assertions pass any garbage. The practical result is everywhere: impeccable pipelines surrounding a component nobody verifies. **The code is covered. The behavior is in the dark.** --- ## Evals are the regression test reread The concept is not new. The unit is: - The golden dataset represents the fixtures: real inputs with reference results. - The acceptance criteria represent the assert: required format, mandatory facts, prohibitions, minimum score. - The suite represents the regression: it runs in full on every change of prompt, model or tool. - The report represents the diff: what improved, what got worse, in which class of case. The structural difference is in the assert. It stops being boolean and becomes a measurement with a threshold. The question is no longer "is the output equal to the expected one?" but "in what proportion of cases does the output meet the criteria?". **Accepting that the answer is statistical is what separates evaluating from hoping.** --- ## What goes into a suite worth having Four families of cases, in different proportions: - Golden cases: the flows that pay for the product, extracted from real usage, with human-reviewed reference results. - Edge cases: ambiguous, incomplete, contradictory, off-pattern input. - Adversarial cases: what can never happen. Instruction leakage, forbidden actions, broken format, invented data. - Cost cases: the right result through the short path is also a criterion. Solving with triple the tokens is a regression of another kind. Sampling beats exhaustion. Fifty cases chosen with criteria say more than five thousand collected without it. Curating the suite is senior engineering work, the same way designing a good integration suite always was. --- ## The judge is also a model Part of the criteria does not fit in a regex. Tone, usefulness, faithfulness to context. For those, the emerging pattern is LLM-as-judge: one model evaluates the other's output against a rubric. It works, under two non-negotiable conditions. Calibration before trust: the judge evaluates a sample humans have also evaluated, and it only enters the pipeline when the agreement rate is known and acceptable. Periodic re-evaluation: judges also drift, also change versions, also carry bias. A loose rubric produces inflated scores at scale. **A judge without calibration is guesswork with an API.** --- ## Couple the suite to versioning Here the two disciplines meet. A database migration triggers tests in CI. A prompt change triggers evals. - A version bump without the suite run does not reach production. - Results are stored per version. Comparing V2 to V1 stops being opinion in a meeting and becomes a diff in a report. - A model swap by the provider, the case nobody controls, is what justifies the suite the most: the regression shows up in staging, not at the customer. The cost exists: tokens to run it, curation time to maintain it. The honest comparison is never against zero. It is against the cost of discovering the regression in production, paid in rework, incidents and user trust. Running a sample on every change and the full suite per release is the balance that has been working. --- ## Where to start No ceremony, in this order: - Extract twenty real cases from production and write the expected result for each one. - Define up to three objective criteria per case: format, mandatory fact, prohibition. - Run them against the current version and store the result as the baseline. - From then on, no prompt changes without the suite running. Twenty cases do not cover everything. They cover infinitely more than the current alternative, which is the memory of whoever tested by hand. **Without evals, "it got better" is opinion. With evals, it is a diff.** - The work that used to train seniors is the same work AI automated (https://mwguerra.com/blog/en/work-that-trained-seniors-is-the-work-ai-automated) A career and engineering-culture reflection on the training pipeline AI shut down. Entry tasks (CRUD, bugfixes, boilerplate) were an informal school of judgment in small doses. With those rungs automated and junior hiring falling, as measured by Stanford's Canaries in the Coal Mine research, the market wants ready-made seniors while having shut down the path that produced them. Learning by osmosis is over; training became deliberate design: guided review of agent PRs, specification as an exercise, postmortems as classes, mentoring as senior work with reserved time. Topics: talent development, junior developers, seniority, mentorship, technical judgment, entry-level hiring, Canaries in the Coal Mine, engineering culture, career In another article, I argued that AI compresses the base: simple tasks start requiring fewer people. The market reading usually stops at that point, at headcount. There is a less discussed consequence, and it shows up with a delay. Those tasks were the school. ## The invisible ladder No company called it a training program, but it was one. The repetitive CRUD, the edge-case bugfix, the small screen nobody wanted to build, the tedious integration with the old system. Entry work, handed to whoever was starting out, with supervision embedded in the flow. What was learned there was never syntax. It was judgment in small doses. Naming a variable and being corrected in review. Deciding where a function ends. Breaking something small, feeling the cost, understanding why the test existed. Each task carried a tiny decision, and the accumulation of those decisions, over years, was what the market called seniority. The ladder had low rungs on purpose. Failing on the first rung was cheap. ## The paradox the market is creating Those rungs got automated. Entry-level work is exactly what models do best, and the rational short-term response showed up fast: hire fewer people at the start of their careers. The data already registers the movement. Stanford's Canaries in the Coal Mine research measured, in payroll records, a decline of about 20% in the headcount of software developers aged 22 to 25 since late 2022, with the drop concentrated in occupations where AI automates work rather than augmenting it ([Brynjolfsson, Chandar and Chen, 2025](https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/)). Each individual decision makes sense in the quarter it is made. The aggregate produces a paradox: the market wants ready-made seniors and shut down the assembly line that produced seniors. Seniors are not born senior. Every experienced professional on your team was once somebody's expensive junior, trained on tasks an agent now solves in minutes. **Whoever is not training people today will be competing, a few years from now, for a professional nobody trained.** ## Learning by osmosis is over The old formation worked by osmosis. High volume of small tasks, daily contact with code under construction, frequent review, cheap mistakes. Nobody designed the process because the process was the backlog itself. Without the volume of small tasks, osmosis loses its culture medium. What remains requires deliberate design. Some formats are already proving viable. The junior reviews the agent's PR next to a senior, discussing the why of each choice before the merge. Writes the spec for a task, compares it with what the agent delivered and investigates the difference. Joins postmortems as an exercise in reading systems, not as a spectator. Takes on a small incident with close accompaniment. Notice the displacement. Today's junior enters through the rung that used to be among the last: reading, judging and deciding under guidance, instead of typing volume. It is a harder entrance. It is also a richer one, as long as someone designs the path and absorbs the cost. **Training stopped being a byproduct of the backlog. It became work with a name, an owner and reserved time.** ## What changes for those who lead This is not an HR agenda. It is an engineering decision with a long horizon. Reserving formative tasks on purpose, even when the agent would solve them faster, accepting the cost as investment rather than inefficiency. Measuring the evolution of a person's judgment, not the volume they produce. Protecting the time of those who mentor, because mentoring became part of senior work, not a hallway favor. The team that only optimizes this sprint's delivery is consuming a stock of seniority that nobody is replenishing. The bill does not arrive this quarter. It arrives on the day the senior who solved everything leaves, and behind them there is nobody who climbed the rungs, because the rungs no longer existed. AI will not train that person, because training requires someone who cares about their mistakes. Who is learning to decide on your team today? On which task, with what accompaniment, paying what cost of error? - Every agent in production is an insider with credentials (https://mwguerra.com/blog/en/every-agent-in-production-is-an-insider-with-credentials) An essay on AI agent security that moves the debate from the model to the autonomy granted. An agent with tools is a privileged non-human identity and deserves insider-risk discipline. Prompt injection is the reread of SQL injection: instruction and data in the same channel, with no prepared statement possible. The lethal trifecta (private data, untrusted content, exit channel) and Meta's Rule of Two become architecture rules, complemented by per-task least privilege, containment with a defined blast radius and treatment of the tool and MCP supply chain as dependencies with execution power. Topics: agent security, prompt injection, lethal trifecta, Rule of Two, least privilege, containment, blast radius, tool supply chain, MCP, non-human identity, OWASP The public debate about AI security looks at the model. Alignment, jailbreaks, what it agrees or refuses to answer. Meanwhile, the agent you put in production has access to the database, the corporate email and the repository. The risk does not live in what the model says. It lives in what it can do with the credentials it was given. --- ## An insider that never sleeps Security teams spent decades building discipline around insider risk. Access segregated by role, audit trails, revocation at offboarding, monitoring for anomalous behavior. All of it because an identity with privileges inside the perimeter causes more damage than most attackers outside. An agent with tools is exactly that: a privileged identity operating inside the perimeter. With three aggravating factors. It operates at scale, executing more actions per hour than any employee. It accepts instructions from any text that enters its context. It does not find an unusual request strange, because it has no baseline for strange. **An agent in production is a non-human identity with privileges. It deserves the same discipline demanded of people.** Most companies still treat it as a productivity feature. It ships to production with no access inventory, no formal owner, no revocation plan. No employee would get through onboarding like that. --- ## Prompt injection is this era's injection The industry has learned this lesson once before. SQL injection dominated an era because instruction and data traveled in the same channel: the query assembled by concatenation executed whatever the user typed into the form. The fix came structurally, prepared statements separating command from content. Nobody solved it by politely asking users not to attack. Language models reintroduce the problem by construction. In a model's context, instruction and data are the same text. The page the agent reads, the email it summarizes, the ticket it triages, the README of the dependency it installs: any of them can carry an instruction, and the model has no native boundary between "this is content" and "this is command". The comparison is not even mine. Simon Willison named prompt injection in direct reference to SQL injection, for the same underlying problem. OWASP lists prompt injection as the number one risk in LLM applications ([GenAI Top 10](https://genai.owasp.org/)). **There is no prepared statement for natural language.** Instructing the model to "ignore commands coming from content" is probabilistic mitigation. It reduces the frequency of the attack, it does not eliminate the class. Treating this as a prompt problem is putting a band-aid on an architecture flaw. --- ## The trifecta that sums up the problem Willison also named the fatal combination: access to private data, exposure to untrusted content, and a communication channel to the outside ([the lethal trifecta](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/)). An agent that combines all three has everything an exfiltration attack needs. The untrusted content carries the instruction. The private access provides the data. The exit channel delivers the result to an attacker who never breached anything. He just wrote a text your agent read. The uncomfortable detail: the list describes the useful assistant everyone wants to build. It reads company data, processes documents from outside, sends the result to someone. Convenience and fragility are the same design. Meta turned the trifecta into an engineering rule with the Rule of Two: at most two of the three properties per agent session. Need all three? Execution stops being autonomous and goes through human approval before any consequential action. In practice: - An agent that reads arbitrary web content does not write outside the perimeter. - An agent with access to sensitive data does not process content you do not control. - An agent that sends email, opens PRs or calls external APIs operates on curated context, not free input. **Breaking one vertex turns the attack from trivial into hard.** It is network segmentation reasoning, applied to autonomy. --- ## Least privilege stopped being a best practice The convenient path is well known: create a service token with broad scope and hand it to the agent, because "it needs to be able to do everything". It is handing over the keys to the building on day one, with the difference that this employee reads orders from any piece of paper it finds along the way. Least privilege, in the agent era, takes on specific contours: - Credentials per task, not per agent. Scope is born and dies with the execution. - Read separated from write. Most tasks only need the first. - Production isolated from exploration. An agent that experiments does not touch the environment that generates revenue. - Irreversible actions go through human approval. Deleting, paying, publishing and sending do not belong in an autonomous loop. Define first what the agent can never do. The rest is negotiated per task. --- ## Containment defines the blast radius In another article, containment appeared as one item in a risk vocabulary. It deserves its own development, because it starts from the correct premise: **the agent will be compromised at some point. The architecture decides the size of the damage.** The hardening is the usual kind, aimed at a new component: - Execution sandbox. The agent runs in a disposable environment, not on the machine that matters. - Egress control. Network on an allowlist: the agent talks to approved destinations and to nothing else. - Budgets and timeouts as brakes. A runaway execution dies by limit, not by luck. - Audit trail per action. Every tool called, every credential used, queryable later. None of this list waits for a smarter model. It is engineering that existed before it. --- ## The tool supply chain Every tool connected to the agent is a dependency with execution power. Third-party MCP servers, plugins, integrations: all of it enters the model's context speaking with a system voice. A malicious tool description is executable instruction disguised as metadata. A server compromised in an update becomes a direct command channel into the perimeter. The treatment is what code dependencies received after the supply chain attacks: - A living inventory: which tools each agent can see, reviewed frequently. - Pinned versions: an external server update goes through review, not automation. - Tool descriptions get reviewed like code, because they act like code. - Less is more: every additional tool is additional surface. A lean agent is a defensible agent. --- ## For those who lead Four questions worth an audit this very week: - Which credentials does each agent carry today, and who answers for them? - What untrusted content enters your agents' context, and through which door? - If an agent is compromised right now, what is the blast radius? - Is there a data exit path that no human approves? Whoever cannot answer has an insider with credentials and no signed contract. **Agent security is not solved at the model. It is solved in the design of autonomy.** - AI is the new engine. Races are still won by engineering (https://mwguerra.com/blog/en/ai-is-the-new-engine-races-still-won-by-engineering) Everyone with a new model compares engines. High-performance races are not won on the engine alone: aerodynamics, strategy, and engineering still decide who crosses the line. With AI, the physics is the same. Everyone with a new car compares engines. In high-performance racing, the engine is one part of the equation. Aerodynamics and race strategy weigh just as much. With AI, a good part of the market is comparing engines and calling it strategy. --- ## The wrong sport In another article, the point was that the market race changes its object: from adoption to efficiency. This text looks at what comes before the object: what decides any race. Every model release becomes a comparison table. Benchmarks, context window, price per million tokens, generation speed. The comparison is useful. It only answers a small question: which engine is more powerful this quarter. **Models, tokens, and agents are the new engine. An engine alone does not win races.** In modern Formula 1, the top teams' engines are close. The grid separates on aerodynamics, trackside operations, and strategy. Power became a prerequisite, the difference is built everywhere else. --- ## Toy car, race car AI is still hype for some. For others, it is just operational reality. Both can be right, because they are running different races. Whoever builds a toy car can accept AI output as it comes and ride the momentum. Proof of concept, prototype, low-risk internal tool: the cost of error is small and speed pays the bill. Whoever competes in a market that demands quality faces another question: would you blindly trust AI, without reading the code and without testing it yourself? It depends. There is no right answer. There is common sense, and there are good practices. --- ## The wind tunnel If you do not read the code you generate with AI, you are probably still at a proof of concept. Or an MVP with few users and little traffic. That is a diagnosis of stage, not a flaw. The problem starts when the toy becomes a product and the process stays the same. Nobody can point to the exact moment the toy car should enter the wind tunnel. The question gets better when it stops being about maturity and becomes a risk decision: how much does an error in this system cost, today, with these users and these contracts? **When the business grows, processes and engineering stop being bureaucracy. They become what guarantees the future life of the business.** --- ## Code review changed shape, not relevance It is already possible to go days without writing code by hand. Reading code became the non-negotiable part of the job. Security, reliability, maintenance, future analysis, healthy system growth within well-defined specs: all of it depends on someone who read and understood what the machine produced. The shape changed. Less semicolon hunting, more architecture. Less "does it work?", more "should this exist? does it respect the spec? does it create coupling? does it open an attack surface?". The 2025 DORA report registers that about 30% of professionals declare little or no trust in AI-generated code ([full report](https://dora.dev/dora-report-2025/)). The research team itself reads the number as healthy: trust and verify. Reviewing stopped being a bureaucratic step and became the last braking zone before the corner. --- ## 300 km/h is not driving faster Whoever drives in the city every day knows how to drive. Putting that person at 300 km/h demands a skill they do not have yet. Different response times. Different braking distances. Different cost of error. Developing with AI at full speed is the same transition. The defect that took a sprint to be born now appears in minutes, replicated across ten files, with passing tests and sampled review. The opportunity is real: whoever learns to operate at this speed opens a gap the competitor does not close in a season. The risk is the same fact, read from the other side: review capacity becomes the new braking distance. **New speed is a new skill. Assuming the old competence transfers on its own is the most expensive way to find out it does not.** --- ## Impulse is not strategy A good part of AI adoption decisions today is emotional. Fear of falling behind, board pressure, a competitor's announcement, an impressive conference demo. Impulse produces motion. Strategy produces position. On track, the pit stop is not called on a gut feeling. The pit window was computed before the start and is adjusted in real time with telemetry. Strategy, in the context of AI, means deciding before the lights go out: where AI enters the flow, what it can touch, what validates the output, who answers for the result, and which metric says it is working. The emotional factor does not disappear, nor should it. A sense of urgency is legitimate when the market accelerates. The question is what it feeds: emotion sets ambition, engineering sets execution. The reasoning is not exclusive to development. Marketing, legal, support, operations: the same rush, the same risks, the same need to decide with method. --- ## A risk vocabulary for racing at 300 km/h Speed under uncertainty has a technical name: exposure. Models are non-deterministic, change versions without notice, and degrade over long contexts. Professional risk management already has the vocabulary missing from AI conversations: - Risk appetite: how much error each system accepts. An internal draft generator and a payment flow do not share the same appetite. - Exposure: probability times impact. Unreviewed code in a critical system is high exposure, not productivity. - Mitigation: review, tests, feature flags, canary releases, rollback. They reduce impact without killing speed. - Containment: sandboxes, minimal permissions, isolated environments. They define the blast radius when something gets through. - Acceptance: a documented decision to live with a risk. Accepting risk is legitimate. Ignoring risk is acceptance without a signature. **Racing at 300 km/h does not eliminate risk. It manages exposure.** --- ## What still obeys the laws of physics The engine evolves on its own, for everyone, at the same time. Models change generations every quarter, tokens get cheaper, context windows grow. The 2025 DORA research, with nearly 5,000 professionals, measures the rest of the car. Ninety percent already use AI at work and more than 80% perceive productivity gains. The same edition shows delivery instability rising along with throughput ([report](https://dora.dev/dora-report-2025/)). I have argued the amplification thesis in another article: AI strengthens what works and accelerates chaos where there is no foundation. What the 2025 numbers add is the mechanism: teams adapted for speed, the systems around them have not yet. Translated to the track, what still obeys physics: - Aerodynamics: architecture, platform, and the processes that keep the car stable as speed climbs. - People: judgment, critical analysis, accountability for decisions. AI amplifies professionals, it does not replace them. - Engineering: validation, metrics, tests, improvement cycles. What turns speed into reliable results. **The engine belongs to everyone. The aerodynamics are yours.** --- ## Processes matter more than prompts The search for the perfect prompt is the AI version of polishing the engine in the garage. In another article, I argued that the model is not an interlocutor: it is a mechanism that conditions output on the context it receives. The practical consequence is direct. The gain is not in the magic sentence, it is in the process around it. Provide context. Define standards. Document decisions. Establish quality criteria. Build validation mechanisms. Collaborating with AI the way you collaborate with a teammate means integrating it into the flow: asking questions, requesting alternatives, refining instructions, setting clear rules per task. Issuing loose commands and hoping for the best is the opposite of that. **The prompt is the steering wheel. The process is the whole car.** --- ## Continuous validation is the pit stop Pit stops cost seconds and win races. Staying out on worn tires looks like speed, until the corner where it stops being speed. The goal was never to produce faster at any cost. It is to deliver reliable results at sustainable speed: human validation, reviews, metrics, tests, and continuous improvement cycles that make AI output more useful and more precise over time. AI is an essential tool and that will not change. But it exists inside a context, it is not an isolated answer to problems that existed before it. --- ## Conclusion Engines will keep improving every quarter, for you and for your competitor, at the same price. The question stopped being which engine you use. It became whether there is a racing team around it: aerodynamics that hold the speed, strategy decided before the start, telemetry that shows the track as it is. **You buy the engine. You build the race.** - You write specs for a character that does not exist (https://mwguerra.com/blog/en/you-write-specs-for-a-character-that-does-not-exist) An essay on spec-driven development that starts from one observation: the image of AI inherited from film, a sentient intelligence that understands like a person, contaminates how we write specs and prompts. The thesis is that the model does not understand, it only conditions output on context and attention. Specifying well requires understanding context, attention and memory, separating model work from script work, recognizing that models are not interchangeable, and accounting for the extra token cost of writing in Portuguese. Topics: spec-driven development, specs, prompts, context engineering, context window, attention, memory, tokenization, token cost, model work versus script work, agents, LLM, Transformer Most people think they understand AI because they have seen AI in film since the 1960s. The image that stuck is one of a sentient intelligence, expressing itself and understanding us completely. That is not the thing answering your prompt. --- ## The sentient intelligence is a cultural inheritance HAL 9000 talked, reasoned and had intent of its own. "2001: A Space Odyssey" is from 1968. From it to the Star Trek of today, treating AI as a companion or a coworker has always been on the wish list. Decades before the technology existed (Siri, Alexa, Google Assistant, to name a few), film had already delivered a sharp image of what AI means: an artificial mind that speaks like a person, understands like a person and decides like a person. That image is not naive. It is cultural. It was absorbed by entire generations of professionals, often while still children, before any of them opened a terminal. **The reference arrived fully formed, long before the engineering, and it shapes what we expect when we type.** The result is a silent assumption that someone is on the other side. Someone who grasps the intent behind the words, fills the gaps with common sense and forgives ambiguity. That assumption is the error at the starting point. --- ## We write specs as if we were talking to someone Spec-driven development put the specification at the center of the flow. The text became the artifact that drives the work. The problem is that we keep writing that text inside the imagination of film. We call it by name and explain ourselves. We give context the way we would to a new colleague. We soften, we narrate intent, we ask permission before instructing. We write for an intelligence that understands, not for a mechanism that processes. It is worth reflecting: who are we writing for? Are we writing for the company, to record a decision? For the model, to condition an output? For ourselves, to organize our own thinking? Those are three different recipients, and each one calls for different writing (and all of them have their place). **When you write for an "intelligence", you write for a character. The model is not that character.** --- ## Another question: a specification of what? There is an ambiguity at the center of spec-driven development that almost nobody addresses. Is the specification a way of working for humans, or an execution instruction for agents? Is it the specification of the process, or of the final product? These are distinct artifacts: - A spec for a human carries shared context, tacit knowledge and room for judgment. - A spec for an agent is an iterable, executable interface. It does not fill gaps with judgment the agent does not have. - A product spec (like a PRD) describes the expected result. - A process spec describes the path to it. Collapsing these into a single document and calling it "the spec" is the source of half the problems. The same text is charged in three distinct, incompatible ways at once. **The spec stopped being a support document. It became an executable interface, and an executable interface does not forgive ambiguity.** --- ## Why we explain when we should instruct The practical question is direct: why do we write prompts as if explaining to a person, instead of giving direct instructions? After all, what delivers better results? We explain because the imagination of film says there is someone there who needs to understand. Conversation feels like the natural path when you believe in an interlocutor. But the model does not understand in that sense. It conditions output on the context it receives. Structured, direct instruction tends to beat conversational explanation. That does not always hold, and it depends on the task and the model. The point is that the reflex of "explaining to a person" is cultural, not an engineering choice. **Explaining presupposes an interlocutor. Instructing presupposes a mechanism. The difference is not style, it is the result.** --- ## The real path runs through context and attention Understanding models, context and attention technically is the path. There is no shortcut through human analogy. The Transformer architecture, described in "Attention is All You Need" (Vaswani et al., 2017), does not read text the way a person reads. It weighs relationships between tokens through the attention mechanism. The context window is finite. The position of information inside it matters. Note: models today are far more than the LLMs of before, but the concepts still apply. Knowing this is what separates two postures: the one that writes for an imagined mind, and the one that engineers the context a real mechanism will weigh. This is what we call context engineering. It is not conversation, it is design. **The model does not understand your text. It conditions output on the context you provide and on what attention weighs inside it.** Output quality is tied to context quality. Order, density, noise and position stop being a matter of wording and become engineering variables. --- ## The context window, memory and attention Do you remember everything you have ever studied? Even if you have access to every book and all the context you have ever studied, there is a real limit to how much you can recall. To carry out work from that, you need to reach the right books, find the data you are after and then focus your attention on the problem itself you are handling or answering. In a similar way, context windows of one million tokens go through the same thing. Models with diffuse attention have to reach the information, all of it available, across that window, retrieve the relevant pieces and assemble their attention window for the work. These are three concepts that, when well understood, enable real context engineering, easing information retrieval and the attention process. **Context engineering, attention and memory work toward optimizing tokens and processing costs.** --- ## Not everything is model work There is a second technical understanding worth as much as the first: knowing what is model work and what is script work. A model is good at fuzzy categorization, ambiguous classification and judgment under uncertainty. A script in Python or Bash is good at deterministic, exact, repeatable operation. The question to ask before each task is not "how do I ask the model to do this". It is another: - Does this require judgment about something ambiguous, or is it a fixed rule? - Does the result need to be identical every time, or does it tolerate variation? - Does the cost of a wrong answer justify the flexibility of a model? Using a model where a script would do is waste and unpredictability. Using a script where judgment is needed is brittleness. Add to that the fact that each model handles tools and hooks differently (the harness is not the only thing dealing with this). How it calls a function, how it reads the return, how it chains steps, all of it varies and has to be understood case by case. **The engineering is not only in writing a better prompt. It is also in deciding whether that is model work or script work.** --- ## Each model was trained differently The term "AI" suggests everything is a single thing. It is not. There are models trained more heavily on code, others stronger in a specific language, others tuned for long reasoning or for tool calls. The training mix, the language coverage and the behavior with tools change from one to another. Treating models as interchangeable repeats the film mistake at another scale. Instead of one monolithic intelligence, we start treating every model as the same generic mechanism. The right choice depends on the task, not on preference. A model strong in code may be weak in your language. A model excellent in prose may be expensive and unstable in agent execution. **There is no "the AI". There are models, each with trained strengths, each with its own characteristics, and choosing is part of the work.** --- ## Writing in Portuguese carries a token cost There is a concrete cost, almost never discussed, in writing for these models in Portuguese. Text in Portuguese tends to require two to three times more tokens than the English equivalent for the same meaning. This comes first from how some tokenizers were built on English content. As a result, English gets the most efficient encoding, and everything else is treated as an exception (Petrov et al., "Do All Languages Cost the Same?", 2023). The bill does not stop at direct cost. Because training a Transformer scales with the square of sequence length, doubling a language's token count can quadruple processing cost and inflate latency ([The Token Tax, 2025](https://arxiv.org/pdf/2509.05486)). There is also an implicit translation effect. Most of the code, comments and documentation that trained these models is in English. When you write intent in Portuguese and expect code in return, there is a real bridging effort between the two languages, and it consumes context. This is not an argument to abandon Portuguese. It is an argument to decide consciously, with an eye on token economy. - Dense, structured technical instruction tends to come out cheaper and more precise in English. - Product reasoning, business nuance and team communication still make sense in Portuguese. **The model is not language-neutral. The Portuguese you write goes through an implicit translator, and that has a price.** --- ## Conclusion We need to better understand what this thing we call AI is and how it works. The sentient intelligence of film is a metaphor. Good for imagining, useless for specifying. For anyone writing specs and prompts seriously, four questions are worth more than style: - Is this spec for a human to interpret or for an agent to execute? - Am I explaining to an interlocutor, or instructing a mechanism? - Is this model work, or script work? - Which model, trained on what, and at what token cost? **The model will not understand you. It will condition its output on what you deliver.** The only variable under your control is the quality of what you deliver. - AI in production is decided on the thousandth call, not the first (https://mwguerra.com/blog/en/ai-in-production-is-decided-on-the-thousandth-call-not-the-first) Every tutorial teaches the first model call. Production is the thousandth: budgets, prompt versioning, schema validation, and telemetry. The model is the easiest part of your AI feature. Every tutorial teaches you to send a prompt and return a response. It works on the first try, impresses in the demo, ships to production on a Friday. The problem never shows up on the first call. It shows up on the thousandth: inside a queue, under traffic spikes, with a user stuck in a loop and an API invoice growing by the hour. **The difference between an AI prototype and a production system is not the model. It is the engineering around it.** The principles below do not depend on language or framework. They apply to any stack that puts an LLM in the critical path of a product. --- ## AI in production is infrastructure While AI is an experiment, almost anything is acceptable: direct calls to the provider, prompts embedded in code, responses used without validation. When it starts deciding moderation, pricing, search, or any flow that touches users and revenue, the system takes on a different contract. It must be predictable, observable, and financially controlled. A misbehaving prompt cannot corrupt domain state. A latency spike cannot lock up your workers. A runaway call cannot turn into a four-figure invoice overnight. **Treating AI as a feature produces demos. Treating AI as infrastructure produces systems.** --- ## Model output is untrusted input Every experienced developer has internalized one rule: user input deserves no trust. You validate, constrain, and reject anything that does not conform before it touches business logic. LLM output deserves exactly the same treatment. The mental model that works: treat every response like a request sent by an anonymous user. Schema validation, business rules, explicit rejection on failure. Never optimistic parsing. The failure modes are specific and well known: - hallucinated structure: the field arrives as `client` when the system expects `customer_id` - syntactically broken JSON, silently swallowed by a naive parser - invented tool names that do not exist in your registry - cascading failure: in an agent chain, one malformed output corrupts every downstream step None of this is an edge case that more testing will solve; these are properties of the component. They call for architecture, not coverage. --- ## Isolate the model behind a contract Controllers, domain services, and jobs never talk to the provider directly. They talk to an interface that represents "AI execution" at the application boundary. Behind it, an adapter handles transport only: authentication, timeouts, protocol-level retries. No business rules, no budgets, no telemetry. Governance comes in as a decorator layer over the same contract. It checks the budget before the call, records telemetry after, and returns the result. Every execution path goes through it: HTTP, queue, scheduled command. What this separation buys: - swapping providers without touching the domain - testing business logic against a stand-in for the contract, without burning API credits - concentrating cost, audit, and policy in a single place The domain decides what to ask. The infrastructure decides how to ask. --- ## Prompts are code. Version them like code. You version your database schema, your code, your infrastructure config. Prompts remain editable in a database row or a loose file nobody reviews. The cost arrives late. Output quality degrades silently, spend climbs without explanation, a regression surfaces and nobody can say which prompt version was live at that moment. The pattern that solves this already exists in your repertoire: the migration. - prompt definitions live in version control - each version has an explicit number and a content checksum - deployment syncs the definitions as part of the pipeline - historical versions remain fully traceable - rollback means reverting the file and syncing again Execution parameters belong to the same definition as the text: model, temperature, token ceiling. Changing the wording forces you to look at the configuration. The definition is a unit, with isolated environments: staging never shares prompt state with production. **You don't tweak prompts. You increment versions.** One detail that separates people who have operated this pattern from people who have only read about it: version conflicts between branches resolve like migration timestamps, whoever merges last renumbers. A CI check that rejects two definitions with the same name and version turns the collision into a PR comment instead of a production incident. --- ## Budgets are checked before the call Rate limiting at the HTTP edge is necessary and solves only part of the problem. Background jobs never pass through HTTP middleware. If the limit lives only at the edge, every asynchronous process bypasses it by construction. Budget enforcement belongs in the service layer, inside the contract, intercepting every execution before dispatch: - a token estimate for the request, conservative by design - accumulated usage for the user or tenant in the period - a spending ceiling that blocks before calling the provider, not after the invoice The estimate can skip billing-grade precision. What it needs is to err upward. The protective gate overestimates on purpose; fine-grained accounting comes from the provider's response, recorded in telemetry. Layered limits complete the design: requests per minute by user tier, a monthly spending ceiling per account, explicit blocking with an upgrade path. Each one protects against a different abuse mode. --- ## Record the failure, not just the success Telemetry that only logs success gives you cost data. Logging both success and failure gives you a debuggable system. Every interaction with the model produces a record containing: - the exact prompt version that executed - the input payload and a hash of the response - input and output tokens - latency - status, with the error message when there is one This record changes conversations. Multiplying tokens by price, grouped by prompt version, answers questions like "version 3 costs 40% more than version 2 for the same volume". At that point, prompt governance stops being an internal engineering concern and becomes a business conversation. The response hash has a job of its own: detecting silent output drift between versions processing the same input. Without it, that class of regression only shows up when a customer complains. --- ## Valid structure is not correct semantics Providers offer native structured output, with the schema enforced at generation time. Use it. The feature significantly increases format reliability. Then validate again, on your side, with your library, against your schema. **The provider guarantees its format. Your pipeline answers for yours.** A valid schema still leaves room for semantic error. The model respects the shape and picks the wrong value. The defenses operate in layers: - aggressive enums: an action field is never free text - business-rule validation after the schema: does the returned `customer_id` actually exist? - self-reported confidence scores with threshold routing: above, execute; below, human review - retry with feedback: the validation failure goes back to the model with the error context, and it corrects itself on the next attempt Monitoring closes the loop. As an operational rule, retries above 15 to 20% of calls point to a problem in the schema or the prompt contract. More retries do not fix a bad design. --- ## Design the failure path Blind retries against a rate-limited provider saturate the queue and amplify the original problem. Failure needs an explicit contract: - retry only the errors that deserve it: rate limits, yes; validation errors, no - exponential backoff between attempts, giving the provider time to recover - timeouts as a hard ceiling: a stalled connection cannot hold a worker indefinitely - exhausted attempts send the job to a dead-letter queue, with the full payload, inspectable and replayable The worst destination for a persistent failure is a generic log entry nobody reviews. The dead-letter queue preserves context and allows replay with the original information intact. For asynchronous execution, one consistency detail: resolve the prompt version at dispatch time and pass the reference to the job. The worker uses the version that was current when the decision was made, not whatever exists when the queue finally processes it. --- ## Test the guards, not the model Tests that call the real API burn credits and prove nothing: responses vary, assertions turn brittle, the CI pipeline gets expensive. What deserves testing is what you control: - does the rate limit block users who exhausted their quota? - does the spending ceiling stop the request before the call goes out? - is the usage record dispatched with the correct payload? - does validation reject a malformed response and trigger the retry? The provider comes in mocked, with fabricated responses. The suite validates the engineering around the model, which is exactly the part you are accountable for. --- ## Non-determinism is a property, not a defect Even at temperature zero with identical prompts, outputs vary between runs. Floating-point GPU operations, internal model routing, batch variation at inference. It is the nature of the component. Three patterns absorb that variance when the risk justifies the cost: - majority voting: three calls, execution when two agree, for critical, low-frequency actions - self-verification: a second pass where the model checks its own output against the schema before execution - confidence routing: the model weighs in, your thresholds decide whether a human enters the loop None of these patterns eliminates the variance. They make it manageable, at a known and chosen cost. --- ## The rule that organizes everything Every layer in this article points to the same boundary. The model suggests. The code validates. The system executes. Never a shorter path than that. Letting an LLM mutate state directly means giving up the only deterministic guarantee you have: your own. For anyone leading teams shipping AI to production, three questions are worth the audit: - which prompt version produced each response in production, and how long does it take you to answer that? - what happens today when an AI job fails five times in a row? - how much does each AI feature cost, per user, per version, per day? If any answer is "I don't know", the prototype has not become a system yet. **LLMs decide. Code verifies. Systems execute.** - The next race isn't AI adoption, it's AI efficiency. (https://mwguerra.com/blog/en/the-next-race-isnt-ai-adoption-its-ai-efficiency) "Tokens will keep getting cheaper, so cost stops being a problem." The first half is true. The second half is where enterprise AI bills are about to blow up, and where engineering starts to matter again. US$ 644 billion on generative AI in 2025, 76% more than the year before. The figure comes from [Gartner](https://www.gartner.com/en/newsroom/press-releases/2025-03-31-gartner-forecasts-worldwide-genai-spending-to-reach-644-billion-in-2025). Over the same period, 95% of enterprise generative AI pilots produced no measurable P&L impact, according to [MIT's "The GenAI Divide" report](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo). Both numbers are true at once. Together, they describe the phase we're in: record spending, rare returns, almost no control. The obvious reading is that AI disappointed. The useful reading is different: most companies adopted AI without ever measuring what it costs to deliver what it delivers. --- ## The cheap-token paradox There's a comfortable belief going around: "tokens will keep getting cheaper, so cost stops being a problem." The first half is true. For a fixed level of performance, inference prices are falling between 9x and 900x per year depending on the task, according to analysis by [Epoch AI](https://epoch.ai/data-insights/llm-inference-price-trends). Performance that cost around US$ 20 per million tokens in 2022 now costs cents. [Gartner goes further, projecting](https://www.digitaltoday.co.kr/en/view/43930/gartner-says-falling-ai-token-prices-wont-cut-corporate-ai-costs) inference costs dropping more than 90% by 2030. The second half is where the reasoning breaks. **Falling cost per token does not mean falling total cost.** Gartner itself, in the same report, points to why: agents consume 5 to 30 times more tokens per task than a traditional chatbot. Usage grows faster than prices fall. The net result is the bill going up while the token gets cheaper. Don't confuse the commoditized token getting cheap with frontier reasoning getting cheap. They're different things, and the invoice knows the difference. Tokens aren't even the only channel. Every software vendor stacks its own AI surcharge per seat, baked into the subscription. The bill climbs through two paths at once: the consumption you measure and the markup wrapped inside the tooling. That one, you almost never see. Cheap tokens are the perfect argument for postponing discipline. Which is exactly why they're dangerous. --- ## We've seen this movie before Anyone senior recognizes the pattern. There was the phase when every startup adopted microservices and Kubernetes long before needing them, drawn to the fashionable architecture, without sizing the cost of operating and maintaining it. There was the "dump everything into the data lake" phase: accumulating data as an end in itself, before knowing what to measure. Then there was the cloud bill shock. Migrate everything in the excitement, get hit at the end of the month, and only then does cost governance become a discipline. The market named it FinOps. AI is repeating the curve. Euphoria, accumulation, invoice, correction. The difference is that this time the bill arrives faster, and the correction has already begun. In 2024, 17% of companies had abandoned most of their AI initiatives. In 2025, [42%](https://workos.com/blog/why-most-enterprise-ai-projects-fail-patterns-that-work), more than double in a single year, according to S&P Global. Running in production, in turn, tends to blow past the pilot's projection by a factor of [3 to 5x](https://www.cloudzero.com/blog/how-much-does-ai-cost/): the prototype doesn't pay for monitoring, retries, scale, or edge cases. The invoice does. --- ## The race changes its object The first race was about adoption. Who had AI, who didn't, who shipped first. The next one is about efficiency. It borrows a name once again: FinOps for AI. What changes in practice: - The debate moves from "how many tokens did we consume" to "what did it cost to deliver the result". - The metric stops being volume and becomes cost per outcome, unit economics applied to AI. - AI cost, today scattered across teams, gets an owner. FinOps for AI is organizational design before it's tooling. Someone has to answer for the bill. - The board question stops being "did we adopt AI?" and becomes "what did it cost to deliver what?". "Cost per outcome", by the way, has two terms. Measuring what you spend without measuring the quality of what comes out is half the equation. Speed without quality just swaps the token bill for the rework bill. **More tokens never meant more productivity. Only now will the market be forced to admit it.** --- ## Efficiency is not a new word Before measuring, it's worth defining. Economy is spending little. Speed is going fast. **Efficiency is something else: the ratio between the value delivered and the resources spent to deliver it.** Engineering has measured that ratio for decades. The entire discipline that already exists around software cost applies to agents. Only the unit of account changed. The concepts we already master transfer directly: - **Profiling.** We've always profiled code to find where time and CPU drain away. The same applies to agents: which call burns the budget, where tokens leak. The decision graph is the flame graph of the agent era. - **Pareto.** Cost concentrates in a few calls. Optimize those, ignore the rest. It works for slow queries and it works for expensive agents. - **Right-sizing.** Nobody spins up a giant instance to run a cron job. Yet people call the frontier model to classify text without a second thought. Sizing the model to the task is AI's right-sizing. - **Caching.** The oldest trick in computing: don't recompute what's already been computed. Context and prompt caching is memoization in new clothes. - **The cost / latency / quality trade-off.** Optimize one, pay in another. Batch trades latency for cost; a smaller model trades marginal quality for savings. Choosing the vertex is an engineering decision, not a default setting. How do you measure? The unit moves from "how much" to "how much per outcome": - **Cost per outcome.** Per task completed successfully, not per token consumed. - **First-pass yield.** Borrowed from manufacturing. How many tasks come out right the first time? Retries are waste, and waste is measurable. - **Useful vs. wasted tokens.** How much of the consumption became results and how much was loops, retries, and inflated context. The yardstick isn't new. It's been in the drawer since the last time the market had to look at the bill. --- ## Control is called observability You don't optimize what you don't measure. An agent's decision-making process is, by default, a black box. Control comes from making that process visible. In practice: - **Agent observability.** Instrument every decision, every tool call, every step of the reasoning. LangFuse, LangSmith, Sentry, and OpenLLMetry live here; standards like OpenTelemetry with GenAI semantic conventions provide the foundation of traces and spans. - **Hooks in the decision flow.** Measurement and control points inside the agent's execution, not just at the output. Measure cost per decision, not per month. - **Decision graphs.** See the path the agent actually took: where it burned tokens for nothing, where it looped, where it escalated to the expensive model without needing to. With the process visible, the concepts from the previous section stop being guesswork: you can see where right-sizing pays off, where caching bites, when batch is worth it. Optimized inference systems, combining routing, caching, quantization, and batching, reach a price-performance ratio [5 to 10x better](https://www.runpod.io/articles/guides/ai-inference-optimization-achieving-maximum-throughput-with-minimal-latency) than unoptimized deployments. But only after you can see where to apply them. --- ## It's not about spending less. It's about knowing what you spend. The point is not to slow AI down. Aggressive consumption makes complete sense at the frontier. An OpenAI exploring the limits of the technology spends tokens as research, and it should. The problem is confusing the rationales. Whoever runs AI in production doesn't share the goals of whoever researches AI. Treating production consumption like a research budget is what fills the invoice without filling the results. The next valuable skill isn't using AI for everything. It's knowing where it pays and where it just burns budget. Because engineering, with or without agents, has always been the same thing: **optimizing resources under constraints.** AI didn't revoke that rule. It's just about to collect from everyone who pretended it didn't exist. - Serious AI adoption is still the exception in the Brazilian mid-market (https://mwguerra.com/blog/en/serious-ai-adoption-is-still-the-exception-in-the-brazilian-mid-market) AI hype is high, serious adoption is still low. The bottleneck isn't tech, it's operationalization. Treating AI as engineering — process, metrics, governance — separates who capitalizes from who stages theater. This post is a bit longer than usual, but I felt it was necessary to reflect on AI adoption. I've been called to assist on two consulting engagements in this area, and the pattern that shows up in both justifies the length of the text. **The hype is high and serious adoption is still low.** In conversations with technical leadership and in internal diagnostics, the same scenario repeats: lots of tools released, very little engineering organized around them. The gap between these two things is what will separate those who capitalize on the coming years from those who stand watching the train go by. --- ### The bottleneck isn't innovation. It's operationalization. The wrong hypothesis is that the problem is lack of available technology. It isn't. The generative AI ecosystem has delivered more usable tooling in the last two years than many sectors received in decades. Models, assisted IDEs, agent frameworks, MCPs, spec-driven development patterns, observability libraries, evaluation platforms. All of this exists, is accessible, and in many cases is free or cheap relative to the potential return. What's missing isn't innovation. It's integration, acceleration, and operationalization of these innovations within real organizations, crossing fragmented institutional boundaries, antiquated processes, and resistant cultures. **Innovation is ready. What needs to be rebuilt is the system that allows it to turn into product, practice, and process.** This is different work from innovating. It requires different people, different incentives, different kinds of decisions. --- ### The distance between "I use ChatGPT" and "I use AI in production" There's a big difference between a dev subscribing to Cursor with a personal card and a company structuring AI as an engineering capability. The first is individual adoption. It shows up everywhere. The second is an **organizational decision**. It shows up in very few mid-sized companies. The reason for the rarity isn't financial. The tools are accessible, well documented, and cheap relative to the potential return. The reason is mindset. Most companies that have a digital product, including those that sell software as their main business, still treat AI as a coding shortcut. Not as an engineering platform. **The result is predictable: lots of lines of code generated, almost no measurable improvement in delivery or quality.** --- ### The problem is rarely AI. It's the foundation it lands on. Mid-sized companies in Brazil tend to have the same profile when you look under the hood: - Large legacy, usually more than a decade old - Architecture with accumulated technical debt - Inconsistent or nonexistent logs - Shallow observability, with poorly instrumented or absent APM - Stack patterns undefined across projects - Critical knowledge in the heads of a few people with more than ten years in the company Adding AI on top of this foundation doesn't fix anything. It accelerates the production of more poorly observed, poorly architected, and poorly documented code, now with greater speed and less traceability. **AI doesn't fix the foundation. It scales what was already bad.** The question that precedes "how to adopt AI" is another one: **does the current base sustain speed, or will speed expose what has always been fragile?** --- ### Lines of code is not a metric The most common metric in companies starting to adopt AI is amount of code generated. It's the worst possible metric. Ten thousand generated lines can be: - Technical documentation someone should have written years ago - Legitimate refactoring - Rework in a loop, with AI guessing solutions to a poorly specified problem - Duplicated code because nobody checked whether something equivalent already existed - Boilerplate inflated by a poorly directed model Without separating these categories, the number says nothing. Worse: it creates the illusion of productivity while quality plummets. **The metrics** that really matter are different, and **have existed for years in the DORA framework**: - Deployment frequency - Lead time for changes - Mean time to recovery - Change failure rate **They're still poorly adopted.** They remain the only reliable way to measure whether AI is accelerating delivery or piling up technical debt at high speed. **What isn't measured isn't improved. Lines of code isn't a measure, it's vanity.** --- ### Engineering, not vibe coding A good portion of current AI use on development teams is what has come to be called vibe coding: quick prompt, code accepted, next problem. It works for prototypes. It doesn't sustain production. The difference between the two worlds fits in one word: **specification**. **Those doing applied AI seriously have implemented some kind of spec-driven development.** The names vary: spec-kit, BMAD, customized internal process. The idea is the same: - Write the specification before generating code - Define explicit contracts and acceptance criteria - Break it down into auditable tasks - Review the plan before executing - Version the specification as a first-class artifact In real projects, teams that adopt this model achieve refactorings that previously would take three sprints in a fraction of that time. Not because AI is magic, but because planning was done carefully, and the rest became assisted execution. The cost is in planning. Generation is cheap. **The expensive part of engineering remains alignment, architecture design, and decision. That doesn't automate. Not yet.** --- ### Fly often. Fly fast. The most important lesson from organizations that managed to operationalize innovation at scale isn't technical. It's about posture. **Fly often. Fly fast. Fly hardware nobody had let fly before.** In applied AI, this means: - Short, cheap pilots with controlled scope and defined metrics - Accepting commercial off-the-shelf components instead of waiting for the perfect internal tool - Tolerating prototype failure as long as it learns fast. A prototype that doesn't fail isn't testing anything relevant - Promoting skills, agents, and processes validated in pilot to the company's shared platform - Iterating contracts, prompts, and architectures with the same cadence we iterate code Companies harvesting results in AI didn't wait for the perfect strategy. They flew early, flew wrong, flew again, corrected, kept correcting until the system became mature enough to scale. **Whoever waits for internal consensus before testing isn't going to test in time.** --- ### AI as a platform, not as a feature Companies adopting AI seriously have stopped treating it as an individual tool and started treating it as an engineering platform. Platform means: - Skills shared across teams, versioned in a central repository - Explicit project constitution: stack, architecture, patterns, design system, mainline - Governance guardrails applicable across the entire organization - Low-friction setup. The dev installs, authenticates, and is ready to use - Observability of usage itself: who uses it, how they use it, with what result - Sponsorship distributed by squad, with internal champions disseminating Those who treat AI as a feature give Cursor to each dev and hope. Those who treat AI as a platform build layers: shared tooling, defined processes, usage metrics, iterative evolution of the adoption framework itself. **The gain doesn't come from the tool. It comes from the organization around the tool.** --- ### Agent observability is the next frontier Those who have moved past individual adoption and structured AI as a platform start to face the next problem: the agent is a black box. **A black box in production isn't acceptable in any other component of the architecture.** There's no reason for it to be acceptable here. The next layer of maturity is observability of the agent's own decision-making process: - How many tokens each step consumes - What the remaining budget is before each call - What decision the agent took and why - Whether that decision was better or worse than the previous one - How much each execution cost, in real money - Which tools were called, in what order, with what success This isn't a luxury for big companies. It's a minimum requirement for putting an agent in production without recurring incidents. Hooks before and after each step, with structured measurement of consumption and result, transform the agent from a black box into an auditable component. **Without this layer, there's no way to decide between agent versions, nor to justify operating costs to whoever signs the check.** The question that separates the amateur team from the professional one is simple: when you built a V2 of your agent, how did you measure that it got better? In tokens? In time? In decision quality? In money? Whoever answers "it got better because it seems so" is guessing. Whoever answers with data is doing engineering. --- ### The strategic cost of slowness Slowness in adoption isn't neutral. It has a cost, and the cost is strategic. - Duplication of effort: each team doing the same initial exploration in isolation, burning tokens and time on the same learning curve - Slower iteration: without a defined process, each experiment starts from zero, without capitalizing on what others discovered - Talent loss: senior devs aren't going to wait two years for your company to decide how to adopt AI. They go where that's already been solved - Growing gap between commercial innovation speed and corporate adoption speed: when the market delivers new tooling every three months, deciding on annual planning cycles is lost math **Each quarter of corporate hesitation equals several quarters of competitive advantage accumulated by those who acted.** The competition isn't only internal. External competitors, across all sectors, aren't waiting for the Brazilian market to decide. --- ### The chasm between advanced stack and mid-market Companies with advanced stack, such as large fintechs, big techs, well-capitalized startups, are already in the phase of measuring and optimizing agents in production. **The Brazilian mid-market is still discussing whether to release Cursor for devs.** This chasm is real, and it's growing. The barrier to the advanced level requires: - Accumulated technical maturity - Clear executive sponsorship - Platform structure capable of absorbing AI as a new layer - Measurement culture already installed Whoever arrives at AI adoption without any of these four things isn't going to reach advanced in the short term. They'll generate more code faster, with the same bad quality as before, now with the fake metric of "we're using AI" to show the board. What appears as adoption, in many cases, is theater. --- ### Internal resistance has partial reason Another consistent pattern: the strongest resistance to serious AI adoption comes from within the technical team itself, not from leadership. The argument appears in variations: - "I don't use it so I don't get dependent" - "What if I unlearn how to program?" - "I prefer to do it my way" The resistance has some reason to exist. Uncontrolled use of AI really does atrophy reasoning when it becomes a crutch. Models can hallucinate, propose wrong solutions with false conviction, take a less experienced dev down the hole at high speed. The conclusion "don't use it," however, is the wrong one. The right conclusion is: use it with governance. Keep control of input and output. Don't let the tool decide the problem, nor blindly accept what it proposes as a solution. AI needs to be treated as an assistant under technical supervision, not as a substitute for reasoning. There's a real cost for those who refuse to adopt. Companies are optimizing structure. Layoffs are already happening, generally for reasons that precede AI: bloated headcounts, accumulated operational inefficiency, market adjustment. AI is a narrative excuse. The next wave, which won't take long, is going to hit primarily those who didn't adopt. Then the reason will be real. A friend who recently took on a Staff Engineer role in AI told me: **"Whoever arrives first drinks clean water." That's the reality of the pioneer, of those who build the path and lead.** Whoever arrives late finds what the market has already filtered. --- ### What separates those who really adopted It's not the tool. Companies using the same Cursor, the same Claude, the same set of models reach radically different results. The difference is in: - Defined process: not just Cursor released, but spec-driven flow installed and enforced in review - Active governance: guardrails, policies, mandatory review of what goes to production - Real metrics: DORA, quality, observability of AI usage itself - Measurement maturity: measurable before and after, not assumption of gain - Executive sponsorship: someone at the right level understands and protects the initiative against short-term ROI thinking - Internal champions: people who disseminate within teams, not eternal external consulting - Progressive evolution: each team at the maturity level it can handle, without forcing artificial uniformity Those who have these seven things installed are reaping. Those with three or four are halfway there. Those with one or none are doing adoption theater. **Adoption theater is expensive: tokens consumed without return, rework in production, false sense of productivity reported upward.** --- ### This moment won't repeat itself The window for serious applied AI adoption in the mid-market is now. Not two years from now, when the topic will be mature, the models will be stable, the best practice will be consolidated. Two years from now, those who prepared today will be three versions ahead. They'll have usage data, versioned contracts, agents refined in production, trained team, installed culture. Whoever is still deciding whether to release Cursor for devs is going to arrive too late. You can't do what was always done. You can't use the planning cycles of before, the procurement processes of before, the review structures of before. The moment demands a different posture. The next decade defines who leads in this market. The decisions that matter are being made today, in silence, inside companies that understood that waiting has a cost. --- ### For those leading technology teams Some questions that are worth more than any model benchmark: - How is the quality of what comes out of the team being measured, separated from speed? - Did the review process keep up with generation speed, or did it become a bottleneck? - Is there specification before code generation, or does the dev go straight from prompt? - Is the team's critical knowledge documented in a versionable artifact, or does it still live in the heads of the same three people? - Is AI usage measurable by team, by skill, by project, or is it a gray cloud of distributed licenses? - Does the observability of what's in production sustain the speed the team is trying to put into it? - How much does each decision made by an agent cost, in tokens and in real money, and is that number being tracked? - How many pilots were put in flight in the last six months? How many were promoted to the platform? How many were shut down with documented learning? Whoever answers these questions clearly is adopting AI seriously. Whoever hasn't answered yet is somewhere between individual adoption and corporate theater. --- ### Conclusion Applied AI taken seriously in the Brazilian mid-market is still the exception, not the rule. The reason isn't lack of tools. It's maturity, technical, organizational, and cultural. **Maturity isn't bought with an IDE license.** The difference between those who capitalize and those who stand watching will be the willingness to treat AI as engineering: with process, metric, governance, observability. Not as a shortcut, not as hype, not as corporate theater. Treating it as a long-term project eternally under study doesn't work either. The cycle is too fast for that. The market delivers new tooling every quarter. Deciding on an annual cycle is lost math. **The window is still open. The market, however, has already begun to separate three groups: those who are accelerating with quality, those who are accelerating chaos, those still standing still deciding whether to accelerate.** Whoever arrives early works with clean terrain. Whoever arrives later gets what's left. - Merged PRs: the "lines of code" of the AI era (https://mwguerra.com/blog/en/merged-prs-the-lines-of-code-of-the-ai-era) Merged PRs stopped meaning what they used to. The data shows the bill of speed without quality — and the choice is no longer 'whether' to use AI, it's at what quality. That call belongs to tech leadership. Merged PRs has been a popular productivity metric in recent years. It's still popular. It just stopped meaning what it used to mean. Last week, the point was that implementation became a commodity. The bottleneck of senior work has shifted. But commodity accelerates production, it doesn't accelerate quality. The numbers have started to show the bill for this change. CodeRabbit analyzed 470 real pull requests and found 1.7x more issues in AI co-authored code. Critical issues rose 40%. Major issues, 70% ([link to the report](https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report)). --- ### What this metric hides Merged PRs are a very short-term signal. They say nothing about medium-term sustainability. What to look at instead? **The solution isn't swapping one metric for another. It's reading velocity alongside quality.** DORA itself made this turn in 2025, adding rework rate (unplanned deploys to fix what already went to production) to its official ruler, together with change failure rate and MTTR. It's worth adding one specific to AI: **code churn**, the percentage of lines discarded within two weeks of commit. GitClear analyzed 211 million lines of code between 2020 and 2024 and showed what's happening: refactoring dropped from 25% to less than 10% of changes, while pasted code rose from 8% to 18%. Less reuse, more cloning ([link to the research](https://www.gitclear.com/recent_ai_developer_productivity_code_quality_research)). **Velocity without quality becomes invisible technical debt**, which accumulates silently. Beyond that, technical debt was never an AI problem, it was always an industry problem. AI just accelerated the accumulation. --- ### What mature teams are already doing **The simplistic reading is to treat AI as the problem. The honest reading is to treat it as an amplifier.** DORA 2025 is explicit about this: AI strengthens what already works well and exposes what's fragile. Where the team has mature CI/CD, written architecture patterns, and structured review, AI accelerates all of it. Where it doesn't, it accelerates chaos. The teams ahead have already moved, and the pattern is the same: systems that classify risk and decide the review flow automatically, in the form of agents. Three examples: - **Automated code reviews** by T-shirt size. Small changes in UI or docs, the agent approves on its own. Medium and large, the agent prepares the review and puts the human in the loop. Changes with cross-team impact, the agent identifies and tags the specialists who need to review the material. - **Self-healing systems** running for over a year and a half in some shops, where agents pull small bugs from the backlog autonomously, open a PR, and go back to the same review flow by T-shirt size. The natural entropy of software becomes the system's problem, not the on-call person's. - **A different cultural stance**, taking the worst days as seriously as the best ones. Quality isn't what shows up in the product demo, it's what shows up when something goes wrong at three in the morning. In all three cases, the tech leader's job is to **architect how the team absorbs velocity without letting quality collapse**. --- ### ... and tests? This is a point gaining more and more relevance. Not just in the how, but in the when. AI writes code that passes tests with impressive ease, because it was trained on millions of test files. That means change failure rate can stay stable on the surface while the quality of what's underneath slides. Hence the importance of testing before the PR, not after, and measuring coverage by behavior, not by line. The question is no longer "is there a test?" and becomes **"would this test be here if AI hadn't written the code along with it?"**. --- ### The questions that change the direction For those leading teams, three questions worth asking: - How is quality being measured, separated from velocity? - What is the code review flow today? Is it automated by risk level, or does every PR still receive the same attention, overloading the (human) reviewers? - Where are the tests? Before the PR, or after? AI changes a lot of how tests should be structured. --- **Nobody is going to stop using AI.** The choice is no longer "whether," it's "**at what quality**". This decision is, more than ever, on technical leadership, at whatever level it sits. - Traditional technical seniority is looking at the wrong bottleneck (https://mwguerra.com/blog/en/traditional-technical-seniority-is-looking-at-the-wrong-bottleneck) 40% of code generated by AI in early 2023, near 100% on the 2024 horizon. The bottleneck of senior work simply left the stage — and what remains is what no one wants to claim publicly: discovery, decision, review. 40% of code generated by AI in early 2023. Nearly 100% as the short-term horizon in 2024, via agents. The numbers come from Thomas Dohmke, at GitHub Universe 2024. The obvious reading is that the models improved. The more useful reading is different: what used to be the bottleneck in senior engineering work has simply left the stage. --- ## What leaves the stage Implementation. Syntax. Boilerplate. Translating business rules into code. Everything that sat between intent and execution became a commodity in teams that have internalized heavy AI use. **The bottleneck has moved to the three points nobody wants to take on publicly.** - **Discovery**, figuring out what needs to be done - **Decision**, judging well what and how to build - **Review**, validating that the output is correct These three points weren't invented by AI. They were always there. The difference is that now they take up practically all of senior work time, instead of showing up between one round of implementation and another. --- ## The redefinition of what being senior means Senior is no longer "knowing how to write code well." Senior with AI has become **building the thing that builds the thing**: the context, the spec, the harness, the validation. It's leaving behind the role of solitary author of lines of code and becoming an agent of transformation for the team. A phrase worthy of Nelson Rodrigues has been circulating in recent conversations at tech events: nobody knows anything, but everyone knows everything. The translation is direct. The companies on the cutting edge don't have answers. They are exploring. This takes the pressure off "being behind" and places the responsibility of "being the one who is testing, adjusting, discovering." Exactly the kind of work that has always belonged to seniors, and that was hidden by the speed of implementation. --- ## What this changes in day-to-day work **Anyone measuring their own value by code delivery speed is looking at the wrong bottleneck in today's work.** Those who understood that today's work is architecting context, decision, and validation are becoming the multipliers of the team. The difference between the two groups isn't talent. It's reading the moment. Where is the bottleneck on your team today? And is your work addressing it, or is it still concentrated where the bottleneck no longer is? - AI in production is revealing the real maturity of technology teams (https://mwguerra.com/blog/en/ai-in-production-is-revealing-the-real-maturity-of-technology-teams) Teams that looked productive start exposing their limitations once AI hits production. It doesn't create the problem — it just makes visible what was always there, redefining what the market calls basic. Teams that once seemed productive now show their limitations. AI doesn't create this problem. It just makes visible what was already there. --- ## AI is a tool Like any tool, the impact depends on how it's used. When applied well, AI increases the performance of developers and teams. It reduces wasted time, optimizes resources, and accelerates deliveries. **From this perspective, it can replace unnecessary effort.** Does this mean AI will take developers' jobs? **Not directly.** - **It raises the level of the game.** - It raises the level of the work. - It raises the level of demand on projects. - **It also compresses the base.** Simpler tasks start to require fewer people. The gap between those who execute and those who think in systems grows. This isn't just about evolution. **There is a redistribution of value in the market.** --- ## Cultural context There is a relevant cultural factor. In regions like the United States, Europe, and parts of Asia, there is a more solid foundation in computer science and engineering. There is also stronger integration between academia and industry. This problem isn't exclusive to Brazil. Worldwide, there is a large mass of tool-oriented developers with little depth in fundamentals. The difference is that outside Brazil there's a larger layer of professionals with a solid foundation sustaining the market. In Brazil, many professionals enter the market with gaps in architecture, systems design, and algorithms. Many training programs prioritize stacks and technologies, but not necessarily the why behind the decisions. **AI changes this scenario.** --- ## On specs, agents, skills, and harness There's a lot of talk about: - Spec-driven development - Agents - Skills - Harness **These concepts aren't new.** They are rereadings of fundamentals already known: - Specs represent documentation of processes and architecture - Harness represents the structure of tools and processes of the core business - Skills represent clear instructions for execution - Agents represent separation of responsibilities **The difference is that this is no longer optional.** There is also an important shift. Before, documentation was ignored. Processes were implicit. Decisions were concentrated in people. Today, specs become executable input. Documentation becomes an interface with systems. **Processes are no longer support and become part of the product.** --- ## A shift in what counts as basic **AI forces something essential: thinking better and writing better.** Documenting decisions. Describing processes. Defining responsibilities. This movement raises the professional's level. **It also redefines what the market considers basic:** - Writing CRUD is no longer a differentiator - Knowing how to use a framework is no longer a differentiator - Basic debugging is no longer a differentiator The differentiator now is: - Modeling - Architecture - Decision-making - Understanding trade-offs --- ## Impact beyond development This movement doesn't affect only developers. Designers, managers, and executives are also impacted. **AI doesn't act only as a productivity tool. It acts as a catalyst for professional maturity.** By writing what they do and how they do it, professionals gain awareness. They start to see previously invisible flaws. They improve decision-making. They get closer to the real value they deliver to the business. --- ## Conclusion **This isn't about replacement.** There is evolution and exposure. More performance. More clarity. More efficiency. More awareness. From a business standpoint, less waste, more speed, and greater capacity to innovate. There is a central point. **AI doesn't eliminate professionals.** **It eliminates the lack of clarity.** In many cases, it exposes professionals who never had to explain or deeply understand what they were doing. This isn't just about technology, product, or business. **The focus is on people.** Professionals who start reflecting on what they do, why they do it, how they can be more productive, how to deliver more value, and what their limits are. These professionals begin to better understand their processes, limitations, goals, and challenges. **This kind of growth cannot be outsourced.**