Adding an AGENTS.md file can increase a coding agent’s cost without improving its success rate. A study from @ETH_en and @logic_star_ai tested this across hundreds of software maintenance tasks. The researchers evaluated four agent/model combinations on 300 SWE-bench Lite tasks and another 138 tasks from 12 Python repositories. They compared runs without a context file against runs with generated or developer-written instructions, where available. Generated files increased average inference costs by 20% on SWE-bench and 23% on the second benchmark, without a statistically significant improvement in task success. Developer-written files performed better than generated ones, but their improvement over having no file was also not statistically significant. The agents generally followed the instructions. They explored more files and ran more tests. Those actions consumed additional resources without producing a clear improvement in the benchmark results. There are limits to that conclusion. Success meant passing the evaluation tests. The study does not establish whether the instructions improved security, maintainability, or human review effort. A statistically nonsignificant result also does not prove that two approaches are equivalent. In a separate experiment with existing documentation removed, generated context files helped, suggesting their usefulness depends partly on what information is already available. For a team using coding agents, a practical next step is to evaluate changes to repository instructions against recurring failures. Suppose an agent keeps breaking retry behavior in a billing service. An instruction explaining where an idempotency key must be preserved, with a reference to the relevant contract test, gives the team a specific behavior to evaluate. General advice such as “follow good architecture” is harder to assess. Run representative tasks with and without the proposed instruction, keeping the model and environment fixed. Repeat the runs to account for variation. Compare passing tests, unrelated edits, violations of architectural constraints, reviewer effort, and cost. These are suggested checks for your workflow, rather than outcomes established by this paper. Instructions also need maintenance. Commands change, modules move, and constraints evolve. Assign an owner to the file and remove obsolete guidance. Where possible, enforce requirements through tests or dependency checks as well. The study gives teams a reason to test their agent instructions rather than assume that adding more context improves results. Paper: arxiv.org/html/2602.11988v3

When people talk about platforms, the conversation almost always goes to infrastructure: clusters, pipelines, observability, developer portals. That matters. But as AI moves into business processes, the platform layer that carries the most weight is a different one: business components. Insurance is a good example. An insurer sells auto, home, life, and commercial coverage. Through several channels: brokers, app, website, partners. And behind all of it sits a small set of capabilities: quoting, underwriting, premium calculation, policy issuance, endorsements, billing, claims. At most insurers, these capabilities have been built several times. One quoting engine for the broker portal. Another for the app. Another for the partner selling embedded insurance. Each with slightly different rules, maintained by a different team. For people, this was already expensive. Launching a new product or channel takes months. A regulatory change has to be made in several places. For agents, it's a risk problem. An agent serving a broker that needs to recalculate a premium after an endorsement will look for the rule somewhere. If there are three implementations, it will pick one, or try to reconstruct the rule from whatever it finds. When it gets it wrong, the error becomes a policy issued at the wrong price or a claim paid outside policy terms. When premium calculation, endorsements, and claims adjustment exist as platform components, the agent doesn't need to understand the rule. It calls the capability. The rule lives in one place, has an owner, has a version, and keeps a record of who called what. This reduces how much context an agent has to absorb to act safely. And it gives the insurer control over what each agent can do: a service agent can look up a policy and open a claim, but can't approve a payout above a certain amount without a human. Business components become the vocabulary agents use to operate the insurer. Companies with that vocabulary well defined will put agents into production faster and with less risk. The hardest part is still organizational. Deciding who owns each capability. And accepting that some products and channels will give up a bit of autonomy so the company gains speed and safety.

Eu acho que não é IA não. Muito realista pra ser IA. Mas não sei, na dúvida

You can automate the entire process and still build the wrong product. Delivering faster doesn’t mean we’re solving the right problem. That’s what I explore in my latest article: medium.com/@dsbraz/you-can-a…

You told the AI to “fix until there are no more bugs.” It found bugs in code that already passed the tests. And it made things worse more often than it made them better. Wang-Lin, Isopoussu, and Mahon (2026) ran LLMs in a blind bug-fix loop: the model only sees the current code, “fixes” it, and repeats until it says the code is clean — with no history of prior edits. With Gemini 2.5 Flash-Lite and atomic edits, the rate of damaging correct code was ~29%, versus ~6% for actually repairing broken code. In many runs the loop became a “pseudo-bug” cycle: the same change gets added and removed forever. Takeaway: “keep asking the AI until it’s clean” is not a stopping rule. It’s an edit trigger. If the tests already pass, the next “fix” needs evidence — not the model’s confidence. Have you seen an AI invent a bug in code that was already fine? Comment “yes” or “not yet.” Paper: If It’s Not Buggy, Don’t Fix It (Wang-Lin, Isopoussu, Mahon, 2026) arxiv.org/abs/2609.10123

Before I raise autonomy, I ask 5 questions. If two lack a good answer, autonomy doesn’t go up — the harness does. 1. Exactly which decision is being delegated? (If the answer is “the whole flow,” you haven’t decomposed.) 2. What’s the minimum evidence that authorizes action? (Without that, the agent acts on verbal confidence.) 3. Is the mistake reversible in minutes? (If not, max autonomy = propose, not execute.) 4. Which metric kills autonomous mode? (Reopen, chargeback, P1, false close — pick one and automate the kill switch.) 5. Who is on the hook in 15 minutes when it breaks? (No name and channel = hope, not operations.) Short ladder: L0: suggest only L1: execute reversible L2: execute with automatic verification L3: execute with budget/limit + alert L4: rare — and always with a named owner Raising a level without clearing the 5 is autonomy theater. What level are most of your agents actually on — not on the slide?

I’ve been working with software for more than 25 years, and I’ve seen a few waves that promised to change everything. With agents, the change is real. The cost of turning intent into code has dropped dramatically. But at the same time, I have the feeling that we’re starting to test ideas the industry has already tested before: separating those who think from those who implement, assuming a good specification solves the problem, and treating code generation as if it were the main bottleneck. The technology has changed a lot. The problems, not so much. I wrote about this in the article: medium.com/@dsbraz/the-techn…

“We want a more autonomous agent.” I hear this weekly. Sounds like progress. Often it’s just the urge to remove humans without redesigning the system. Autonomy without criteria isn’t maturity. It’s blast radius with a nice UI. Teams raise temperature, unlock more tools, remove the approve step — and call it evolution. Until the quiet failure: wrong email, ticket closed without root cause, sensitive data in the wrong place. The useful question isn’t “can the agent do it alone?” It’s “in what decision envelope can it operate without becoming an incident?” This week: 5 posts on calibrating real autonomy — not demo talk. If you’ve raised agent autonomy in production: what broke first?

Closing the week: The demo→production gap is rarely “we need a better model.” It’s an incomplete harness — tools, context, verification, blast radius, human loop. Swapping LLMs is easy to explain in a meeting. Building the surroundings is the real work. One takeaway: stop asking “which model?” and start asking “which harness axis is weak?” Curious: which axis broke you first when you shipped an agent — tools, context, verification, blast radius, or the human loop? Reply. I want to see the pattern.

Before I agentize a workflow, I run 4 checks. If two fail, it’s not agent time — it’s harness design time. 1. Verification cost Can you cheaply tell if the answer is right? If not, high autonomy is expensive risk. 2. Reversibility Can you undo the mistake? If not, the agent doesn’t “ship” alone — it proposes. 3. Decomposition Does the task break into stable steps with clear tools? If it’s a blob, you’ll drown in infinite prompting. 4. Failure owner When it breaks (and it will), who responds how fast? Without that, you don’t have a product — you have a public experiment. Strong model + weak 4 = pretty demo. Average model + strong 4 = operations. Which check does your team skip most?

Real case (no client names): agent that “worked” in the playground and failed in the real channel. In the demo, context fit a clean window. In production, history was messy — incomplete ticket, flaky tool timeouts, a business rule buried in a PDF nobody indexed. The team wanted a bigger model. The real issue: weak verification + unstable tool plane. What unblocked it wasn’t a smarter LLM. It was: - explicit failure when a tool dies (instead of hallucinating) - human check on irreversible actions - minimum necessary context, not the full conversation dump Same “intelligence.” Different system. If you’re mid-diagnosis: are you measuring model quality — or environment quality?