DEV Community: Aria Kovac

Beyond Chatbots: A Decision Workflow for Getting Everyone to Kickoff

Aria Kovac — Tue, 01 Sep 2026 07:06:44 +0000

Most match-day plans do not fail because people are lazy.

They fail because the group chat is trying to use a chatbot answer where it actually needs a decision workflow.

That difference matters for World Cup-scale football days in New York and New Jersey. The 2026 tournament has already concluded, but its New York/New Jersey match days are still a useful retrospective case study. FIFA scheduled the final for New York/New Jersey on July 19, 2026, and NJ Transit’s 2026 World Cup guidance described eight MetLife Stadium match days, including World Cup-specific rail rules between Penn Station New York and Secaucus Junction in the four hours before kickoff.

Those details are not decoration. They are the whole problem.

A fan leaving Queens is not solving the same route as a friend leaving Brooklyn. Someone coming from Manhattan may care about Penn Station timing. Someone already on the New Jersey side may not want to backtrack into the city just because the group chat picked a familiar meeting point. And after the match, the plan changes again, because everybody leaving together at the same time is usually the least realistic version of events.

A normal chatbot can answer a question like, "How do we get to the stadium?"

A better match-day assistant should help a group decide.

The Wrong Object: One Perfect Recommendation

The weak version of AI planning gives one confident answer:

"Leave early, meet near the stadium, and take transit."

That is not wrong. It is just not enough.

It ignores where people start. It ignores who can leave work early. It ignores who hates transfers, who needs food first, who has the tickets, and who will be impossible to reach once the cell network gets noisy.

I see the same shape in support work all the time. The failure is not always bad information. Sometimes the failure is that the information never became an assignable action.

For match day, the useful object is not a recommendation. It is a small decision packet:

Context. Options. Reason. Action.

That is it. Not model architecture. Not a giant itinerary. Just enough structure to move a group from "what should we do?" to "we are doing this."

The iMessage Version

Here is the kind of flow I would want in a group chat before kickoff:

Context: Four people. One in Astoria, one in Bushwick, one near Harlem, one in Jersey City. In this example, kickoff is at 6:00 PM. Two people can leave early. Nobody wants to drive. The group wants food before entering the stadium, but not a long sit-down dinner.

Option 1: Everyone meets near Penn Station New York, then travels together toward Secaucus and the stadium.

Option 2: Split by side of the river. The NYC group meets near Penn Station. The Jersey City person meets the group closer to Secaucus. Food happens before the final stadium leg, not near each person's apartment.

Option 3: Skip the pre-stadium meet-up. Everyone enters separately, then meets at a fixed section or landmark inside after security.

Reason: Option 2 gives the group one shared checkpoint without forcing the New Jersey person to travel backward into Manhattan. It also avoids making the latest person control everyone else's arrival.

Action: Pick Option 2. NYC group leaves first. Jersey City person confirms arrival separately. If anyone misses the checkpoint, they switch to Option 3 instead of restarting the whole plan.

That is the level of structure I want from city AI. For this kind of local decision, Karpo for everyday city decisions makes more sense than a generic chatbot because the useful input is not just a question. It starts with mood, neighborhood, budget, and who is coming with you, then turns that context into places, events, and plans.

Not an official event guide. Not a tournament partner. Just a better way to turn local constraints into a plan people can actually follow.

Before Kickoff: Solve Convergence

Before kickoff, the main problem is not the stadium. It is convergence.

Where does the group become a group?

For NYC football fans, that question has layers. A plan that sounds simple from Manhattan may be annoying from Queens. A plan that looks fast on a map may fail once you add event-day transit rules, transfer anxiety, bag checks, weather, and the one friend who always sends "almost there" from twenty minutes away.

I would keep pre-match decisions narrow:

Pick one shared checkpoint.

Pick one fallback checkpoint.

Pick a latest arrival time.

Decide who carries the tickets or confirms the ticket transfer.

Decide whether food is before transit, near the checkpoint, or after entry.

Everything else is noise.

If an AI tool gives seven restaurant choices, three transit routes, and a motivational paragraph, it has not helped yet. It has created more surface area for disagreement.

The best output is usually two to four options with trade-offs.

During the Match: Plan for Drift

During the match, the plan should become smaller, not larger.

People lose signal. Someone goes for water. Someone is late. Someone's phone battery drops to nine percent. Someone wants to stay in the seat while everyone else wants to move.

A good decision workflow handles that without drama:

If separated before kickoff, meet at the section.

If separated during the match, do not move unless there is a clear reason.

If signal fails, use the last agreed checkpoint.

If the group needs to split, name the next reconnection time.

This is not glamorous AI. It is just coordination under stress. But that is exactly where generic chatbots feel thin. They can suggest. They cannot always commit the group to a next step.

After the Match: Do Not Pretend Everyone Leaves Together

The after-match plan deserves its own decision.

People often plan the arrival carefully and then treat the exit as an afterthought. That is backwards. The exit has more fatigue, less patience, weaker phone batteries, and heavier crowd pressure.

NJ Transit’s 2026 World Cup match-day guidance treated post-match travel as its own operating window, with targeted service adjustments after matches. That is the kind of planning fact a match-day assistant should respect. Even if you are not using those exact past dates, the principle holds for any major match day: post-event travel is a different decision from pre-event travel.

I would give the group three exit options before the match starts:

Option A: Leave together immediately.

Option B: Wait out the first rush at a nearby safe, agreed location.

Option C: Split by destination and stop pretending one route serves everyone.

Then pick the default before kickoff.

The point is not to predict the entire evening. The point is to remove one tired argument from the end of it.

What Developers Should Notice

The useful product lesson here is not "add AI to event planning."

It is that some consumer AI tasks should not be shaped like Q&A.

A match-day group does not need an answer. It needs a decision object with ownership, timing, fallbacks, and local constraints.

For a city decision tool, I would rather see:

Two to four realistic options.

A short reason for each.

A clear default.

A fallback if the group misses the plan.

A source-of-truth warning when event details, transit schedules, or venue policies may have changed.

That last part matters. Any AI product touching live city plans should know when to stop being confident. Match times, service advisories, bag policies, street closures, and weather can change. A good assistant should push users toward current official sources when the details are operational.

The Real Shift

The future of everyday AI is not just better chat.

It is better small decisions.

Where should we meet? Who goes first? Which option works for the person coming from the farthest borough? What happens if the train is delayed? What do we do after the match, when everyone is tired and nobody wants to reopen the discussion?

That is where city AI can become useful without pretending to be magic.

World Cup-scale match days make the problem obvious, but the pattern is ordinary. Concerts, playoff games, airport pickups, late dinners, weekend plans, visiting friends, bad weather, different budgets, different neighborhoods.

A chatbot gives an answer.

A decision workflow gets the group moving.

On a crowded match day, that difference is not theoretical. It is whether everyone makes it to kickoff still speaking to each other.

Final Gate

Item	Result	Evidence
Risk lowered	pass	“It starts with mood, neighborhood, budget, and who is coming with you...”
Event timing corrected	pass	“The 2026 tournament has already concluded...”
NJ Transit boundary narrowed	pass	“World Cup-specific rail rules between Penn Station New York and Secaucus Junction...”
No official affiliation claim	pass	“Not an official event guide. Not a tournament partner.”
Assigned anchor used once	pass	“Karpo for everyday city decisions”

Natural’s $30M Raise Shows Why Agentic Payments Are the Missing Runtime for AI Agents

Aria Kovac — Tue, 21 Jul 2026 09:02:11 +0000

I do not worry much when an AI agent writes a bad draft. I worry when it can hire a vendor, agree to a price, and then has no safe way to pay.

That is the real signal behind Natural’s new funding round. On July 20, 2026, Natural announced a \$30 million Series A led by Kirsten Green at Forerunner, bringing its total funding to over \$40 million. The company says it is building the foundational payments stack for AI agents, with live products including wallets, vaults, pay, request, transfer, and connect.

The obvious headline is “Natural wants to take on Stripe.”

The more useful developer framing is this: once agents move from recommending actions to executing them, payments become a runtime problem.

Today’s payment systems assume a human is somewhere nearby. A person enters card details. A person approves a bank transfer. A person knows why the invoice exists. A person can explain the dispute later.

Agent workflows break that assumption.

Imagine a logistics agent that finds a freight vendor, compares quotes, negotiates timing, and prepares a shipment. The moment money needs to move, the agent has to stop and ask a human to finish the transaction. That is not a small UX issue. It is the boundary between automation and actual economic agency.

A payment tool for agents cannot just be a checkout button with a prettier API. It needs policy, identity, observability, and failure handling.

Screenshot from Natural

If I were designing an agentic payment flow, I would want the payment layer to answer seven questions before funds move:

Who authorized this agent to spend?
What budget, rail, merchant, and category limits apply?
Is the counterparty an agent, a business, or a human?
What evidence connects the payment to the original task?
Does this payment require human approval?
What happens if the agent made the wrong decision?
Can support, finance, or compliance reconstruct the transaction later?

That last point is where my support-engineering brain gets loud.

A bad agentic payment system does not only create fraud risk. It creates explanation debt. Someone will eventually ask why an agent paid a vendor, why it chose that amount, why it skipped another option, or why a refund request should be accepted. If the payment layer cannot show the trace, the problem becomes a human investigation.

Natural’s own product language points in this direction. Its Pay page says Natural handles orchestration, ledgering, routing, compliance, risk, and disputes. Its earlier agentic payments memo talks about controllable wallets, transaction-level rules, authorization tools, and observability.

Those are exactly the boring primitives that make autonomous systems survivable.

Stripe is not ignoring the same problem. Stripe’s agentic commerce docs describe flows where agents help buyers browse products, manage carts, and complete purchases. The docs also reference protocols such as UCP, ACP, MPP, and x402 across different seller and agent flows. Stripe has also written about Shared Payment Tokens, where agents can initiate payments with scoped credentials instead of exposing the underlying payment method.

That tells me this is not one startup’s narrative. It is an infrastructure race.

There are also stablecoin-focused players such as Skyfire, which describes itself as identity and payments infrastructure for AI agents. The stablecoin angle makes sense for some machine-speed payments, especially API access, global settlement, and microtransactions. But I would be careful about assuming stablecoins solve the whole problem. Enterprises still care about bank rails, reconciliation, compliance workflows, and accounting systems that do not disappear because an agent can hold a wallet.

So the question is not simply Natural vs Stripe.

Screenshot from Stripe

The question is what kind of payment primitive agent developers will actually use.

For small agent workflows, maybe a scoped card token is enough. For marketplace agents, maybe the hard problem is merchant onboarding. For business operations agents, ACH and bank-account workflows may matter more. For agent-to-agent API markets, wallets and real-time settlement may be cleaner.

The dangerous mistake would be treating payments as the final step after the agent is already built.

Payments should be designed as part of the agent architecture:

The agent should never see raw financial credentials.

Every payment action should carry a task ID, policy decision, counterparty identity, and audit trace.

Approval rules should be deterministic, not hidden inside a prompt.

Failed payments should be typed errors the agent can handle.

Disputes should attach back to the agent’s reasoning and tool history.

Spend limits should exist at the organization, wallet, agent, and transaction level.

The payment layer should make “no” cheap.

That last line matters. Most demos optimize for agents saying yes quickly. Production systems need agents that can stop cleanly, escalate politely, and explain why money did not move.

Natural’s \$30 million raise is interesting because it puts a spotlight on the least glamorous part of agent autonomy.

Not the model.

Not the browser.

Not the conversation UI.

The money movement.

And money movement changes the trust model.

When an agent summarizes an article badly, you fix the article.

When an agent pays the wrong vendor, you need authorization logs, dispute rules, transaction history, counterparty identity, refund paths, and probably a tired person in support trying to make sense of the whole thing.

That is why agentic payments feel like a real developer topic, not just fintech gossip. If agents are going to act on behalf of people and businesses, they need financial infrastructure built for software actors.

The best agentic payment layer will not be the one that makes agents spend fastest.

It will be the one that makes every payment explainable after the fact.

Self-Evolving Agents Are Not AutoGPT With Better Memory

Aria Kovac — Mon, 20 Jul 2026 10:28:49 +0000

I do not trust an AI agent because it can run for a long time.

I start trusting it when I can see what changed after it failed.

That is the useful way to read the current wave of self-evolving agents. The phrase sounds dramatic, but the engineering question is very plain: can an agent turn experience into a durable, verified improvement without quietly making itself worse?

As of July 2026, several threads are converging. PaperAgent’s BestHub digest frames the field around model-centric evolution, environment-centric evolution, and model-environment co-evolution. The arXiv survey A Survey of Self-Evolving Agents organizes the problem around what evolves, when it evolves, and how that evolution is guided. Another survey, A Comprehensive Survey of Self-Evolving AI Agents, defines self-evolving agents as systems that systematically optimize internal components through environment interaction while preserving safety and performance.

That last clause is the part I care about.

“Self-evolving” does not mean “the agent keeps trying.” It means the agent has a loop where feedback changes something reusable: a prompt, memory, tool, workflow, evaluator, policy, or model component.

The Smallest Useful Architecture

A practical self-evolving agent architecture needs five pieces:

Task / User Goal
      |
      v
Agent Runner  ---> Tools / Environment
      |                 |
      v                 v
Trace Store <--- Results / Failures
      |
      v
Evaluator / Verifier
      |
      v
Evolution Planner
      |
      v
Proposal Queue ---> Approval Gate ---> Versioned Agent State
                         |
                         v
                      Rollback

The important part is not the agent runner. We already have plenty of those.

The important part is the path from failure to a versioned change.

If the agent fails at a task, the system should capture the trace, score it, explain the weakness, propose an update, test that update, and only then retain it. Without that retention step, you have retry logic. Without the verifier, you have vibes. Without rollback, you have an incident waiting for a polite calendar invite.

Here is the pseudocode version:

state = load_agent_state()

while True:
    task = receive_task()
    trace = run_agent(task, state)

    score = evaluate(trace, task.success_criteria)

    if score.passed:
        maybe_store_success_pattern(trace, state)
        continue

    weakness = diagnose_failure(trace)
    proposal = propose_state_update(
        weakness=weakness,
        mutable_targets=["prompt", "memory", "tool_policy", "workflow_graph"]
    )

    test_result = verify_update(proposal, regression_suite=state.tests)

    if test_result.passed and approval_gate(proposal):
        state = commit_versioned_update(state, proposal)
    else:
        keep_state_unchanged()

That is the boring shape of a real self-evolving agent architecture. Boring is good here. Boring means someone can debug it.

Photo by Rahul Mishra on Unsplash

AutoGPT vs Self-Evolving Agents

AutoGPT was important because it made autonomous agents feel tangible. The current AutoGPT repository describes the project as a platform to create, deploy, and manage continuous AI agents that automate workflows.

But AutoGPT-style autonomy and self-evolution are not the same thing.

An autonomous agent can plan tasks, call tools, and chain actions. A self-evolving agent changes the system that will handle the next task.

The difference is persistence plus validation.

If an agent searches the web, writes a plan, fails, and tries again, that is autonomy.

If it notices that its tool-selection policy caused the failure, proposes a routing change, tests that change against previous tasks, stores the update, and can roll it back later, that is self-evolution.

This is why I would not describe self-evolving agents as “AutoGPT with better memory.” Memory is only one mutable component. The deeper shift is that the agent scaffold itself becomes optimizable.

A July 2026 survey, Self-Improvements in Modern Agentic Systems, frames a modern agent as a foundation model coupled with prompts, memory, tools, and control logic. It also treats self-improvement as an update operator that can commit changes to model parameters or scaffold components. That is a much cleaner mental model.

The model is not the whole agent. But the scaffold matters.

What Should Actually Evolve?

For most developers, model-weight evolution is not the first place to start. It is expensive, risky, and hard to evaluate.

The practical starting points are scaffold components:

Prompts: rewrite instructions based on repeated failure modes.
Memory: decide what to retain, merge, forget, or distrust.
Tool policy: change when and how tools are selected.
Workflow graph: alter the order of planner, executor, critic, verifier, and human review.
Test set: add new regression cases from real failures.
Evaluator rubric: improve the judge, but with extra caution.

The evaluator is the most dangerous piece to evolve. If the agent learns to please a weak judge, it may improve the score while degrading the work.

This is not theoretical. Google Research’s work on scaling agent systems found that multi-agent systems can help on parallelizable tasks but hurt sequential ones. Their study also reported that independent multi-agent systems can amplify errors badly, while centralized orchestration acts more like a validation bottleneck.

That is a useful warning for self-evolving systems: more agents do not automatically mean more intelligence. Sometimes they just create more places for a bad assumption to reproduce.

Where Gemini 3 and Agnes Fit

Skywork’s pieces on Gemini 3 for AI agents and Agnes AI are not primary research sources, but they are useful market signals.

The Gemini 3 article argues for a minimal, auditable agent loop: intent grounding, tool calls, verification, human approval, logging, and metrics. That lines up with the engineering direction Google described when it launched Gemini 3 with stronger reasoning, multimodality, coding, and agentic capabilities.

The Agnes article is more product-facing, but its “workflows, not widgets” framing is also relevant. A self-evolving agent does not live as a floating chatbot. It needs persistent work surfaces, shared memory, review points, and outputs that other people can inspect.

In support work, that distinction matters. A clever agent that cannot leave a readable trace is not helpful. It is just another system someone has to reverse-engineer during a bad week.

Screenshot from Gemini

The Five Questions I Would Use Before Calling Anything Self-Evolving

If a product or paper claims self-evolution, I would ask:

What is the mutable object?

Is it the prompt, memory, toolset, workflow, evaluator, policy, model weights, or multi-agent topology?

What feedback signal drives the change?

Formal tests, environment rewards, human review, LLM judges, user behavior, or the agent’s own self-assessment?

Who verifies the update?

A deterministic test is stronger than a human vibe check. A human review is stronger than a loose LLM judge. The weakest verifier is the same agent praising its own improvement.

Is the change retained?

If nothing durable changes, it is not evolution. It is a retry loop.

Can it roll back?

A system that can improve itself but cannot undo a bad update is not mature. It is brave in the worst possible way.

The Real Technical Frontier

The interesting part of self-evolving agents is not that they might become magical independent researchers next month.

The interesting part is much more grounded: agent systems are becoming measurable, versioned, and improvable.

That gives developers a new design target. Instead of asking, “Can I make this agent smarter?”, we can ask:

Can I make its failure memory better?

Can I make its tool policy safer?

Can I make its evaluator harder to fool?

Can I make its workflow adapt without hiding the change?

Can I preserve performance on old tasks while improving on new ones?

That is where self-evolving agent architecture becomes useful as an engineering topic rather than a buzzword.

Self-evolving agents are not about removing humans from the loop as fast as possible. They are about deciding which parts of the loop can safely learn, under what evidence, with what rollback path.

The strongest systems will not be the ones that say, “I improved myself.”

They will be the ones that can show the diff.

Final Gate: pass on language cleanup. Evidence: the revised article uses English-only terminology such as “self-evolving agents,” “self-evolving agent architecture,” and “autonomous agents.”

Claude Code vs Cursor 2.0 vs Codex: AI Coding Tools Are Becoming Control Rooms

Aria Kovac — Fri, 17 Jul 2026 09:20:58 +0000

A year ago, the most common question around AI coding tools was simple: can it write the patch?

In 2026, the better question is: can it survive the whole loop?

By “whole loop,” I mean everything that happens after the impressive demo. Choosing the task. Keeping multiple agents visible. Approving or rejecting changes. Managing quota. Testing before CI. Explaining the result to a teammate. Making sure the support queue does not inherit a beautiful, half-tested refactor.

That is why Codex Micro, Claude Code, Cursor 2.0, Alibaba Cloud’s Qoder CN / Model Studio path, and CircleCI Chunk Sidecars feel connected. They are not the same product. But they point in the same direction: AI coding is moving from a chat box into a full development control layer.

Codex Micro Is Not Really About the Keyboard

OpenAI’s Codex Micro is listed at US\$230 on the official OpenAI Supply Co. page, so the circulating “\$99 Codex keyboard” framing is not accurate.

The more interesting part is not the price. It is the product assumption.

Codex Micro is a small Work Louder collaboration with 13 mechanical switches, a touch sensor, a rotary encoder, a planar joystick, RGB status lights, and physical controls mapped to Codex workflows. OpenAI describes it as a “command center for agentic work,” with controls for things like PR review, debugging, refactoring, accepting or rejecting changes, and adjusting reasoning level.

That sounds niche because it is niche.

But the interface idea is not silly. Once developers run more than one coding agent at a time, a plain prompt box starts to feel thin. You need status. You need approval controls. You need to know which agent is waiting, which one is running, and which one has finished. You need a way to steer work without constantly context-switching between chats.

A serious Codex keyboard review, then, should not ask only whether a US\$230 macro pad is “worth it.” It should ask whether agentic coding is becoming operational enough to need hardware controls at all.

The answer seems to be yes.

OpenAI’s Codex rate card points in the same direction. Codex pricing moved to token-based credit accounting in April 2026, with usage tied to input, cached input, and output tokens. The page also points users toward usage panels for remaining credit, purchases, and auto-reload management.

That is less glamorous than a keyboard. It is also more important.

If agents run longer, in parallel, and across real repositories, budget control becomes part of the developer workflow. The community joke about a “cyber godfather” watching your quota is funny, but the real signal is governance: agentic coding needs cost visibility, not just clever completions.

Photo from OpenAI

Claude Code Is Becoming a Work Surface

Claude Code is already more than a terminal assistant. Anthropic’s Claude Code overview describes it as an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools across terminal, IDE, desktop app, and browser.

That matters because coding agents need somewhere to work.

A Claude Code tutorial in 2026 is no longer just “install the CLI and ask it to fix a bug.” It has to cover permissions, IDE handoff, desktop sessions, hooks, MCP, CI workflows, and how to keep long-running work understandable.

The June 2026 Claude Code artifacts update makes that shift clearer. Artifacts turn work in progress into live, shareable pages: PR walkthroughs, system explainers, dashboards, release checklists, and incident pages built from the full session context.

From a support-engineering angle, that is more valuable than another flashy benchmark. A coding agent that changes code but cannot explain the work creates operational debt. A coding agent that leaves behind a readable artifact gives the next human a fighting chance.

The Alibaba angle also needs careful wording.

Alibaba Cloud documents a way to connect Claude Code to Alibaba Cloud Model Studio through Anthropic-compatible endpoints and model mappings in its Claude Code Model Studio guide. Separately, Alibaba Cloud’s Qoder CN suite is a family of domestic AI agent products for coding, work, terminal use, and cloud agents, built around Chinese models and China-based deployment.

So I would not call this simply “Alibaba’s Claude Code.” That blurs the facts.

The better read is this: Claude-Code-like workflows are becoming important enough that cloud vendors now want local model routing, domestic deployment, quota systems, and compliance-friendly agent environments.

That is a much bigger story than a clone.

Photo from Claude

Cursor 2.0 Shows the IDE Is Becoming Agent-First

Cursor 2.0 is useful because it says the quiet part out loud.

In its Cursor 2.0 announcement, Cursor described the release around two major updates: Composer, its coding model, and a new interface for working with many agents in parallel. The Cursor 2.0 changelog also describes multi-agent workflows, up to eight agents in parallel, isolated copies of the codebase, improved code review, and Browser becoming generally available.

That is the important “Cursor 2.0 new features” story. Not one isolated browser feature, but an IDE reorganizing itself around agents.

Traditional IDEs are file-first. Agentic IDEs are task-first.

You ask for an outcome. Agents branch off. They work in isolated environments. You compare results. You review the diffs. You test the running app. You open files when you need depth, not because files are the only interface.

The browser piece fits naturally here. Cursor says Browser for Agent became GA in 2.0 and can be embedded in-editor, with tools to select elements and forward DOM information to the agent. That matters especially for frontend work, where a patch can be syntactically correct and visually wrong.

A browser-aware coding agent can inspect the app it just changed. That is the difference between “I edited the CSS” and “I checked the actual screen.”

Photo from Cursor

Chunk Sidecars Close the Loop Agents Keep Breaking

CircleCI’s Chunk Sidecars may be the least flashy product in this comparison. They may also be the most practical.

CircleCI describes Chunk Sidecars as lightweight, preconfigured environments that run alongside local or agent workflows and validate changes as they happen. The sidecar mirrors the project stack, detects test commands and build systems, runs scoped “microbuilds,” and feeds results back to the agent before the code reaches full CI.

That solves a real problem.

AI agents make the inner loop faster. They create more diffs, more branches, and more attempted fixes. But if validation still happens only after push, CI becomes the cleanup crew. The agent has already moved on, the context is colder, and the human has to reconstruct what happened.

Chunk Sidecars move validation into the agent’s working loop.

A coding agent can make a change, run a targeted check, read the failure, fix the issue, and repeat before polluting the shared pipeline. CircleCI’s follow-up on agent hooks goes even further, showing how validation can trigger automatically at checkpoints in the agent workflow.

This is what AI coding tools need more of.

Not more confidence. More evidence.

Photo from circleci Blog

How I Would Actually Compare AI Coding Tools in 2026

A serious AI coding tools comparison should not start with “which one writes the most impressive demo?”

It should start with questions like these:

Can the tool see the system it is editing?

Can it run tests before CI?

Can it explain its work to another human?

Can I control permissions and cost?

Can I compare multiple agent attempts without creating chaos?

Can the workflow survive handoff, review, and rollback?

Codex is pushing toward agent control, usage management, and physical workflow surfaces.

Claude Code is pushing toward long-running, inspectable, cross-surface development work.

Cursor 2.0 is pushing the IDE toward multi-agent, browser-aware coding.

CircleCI Chunk Sidecars are pushing validation closer to the agent’s inner loop.

Alibaba Cloud’s Model Studio and Qoder CN show the same pattern under local deployment, Chinese model routing, and compliance pressure.

The products are different. The direction is shared.

AI coding is becoming less like autocomplete and more like an operating layer for software delivery.

The Real Shift

The headline is not “Codex got a keyboard.”

The headline is that coding agents now need keyboards, browser state, credit controls, artifacts, hooks, sidecars, model routing, and CI-adjacent validation.

That is what happens when a tool moves from toy to infrastructure.

When AI writes a snippet, a prompt is enough.

When AI edits production code, you need approvals.

When AI runs longer tasks, you need budget controls.

When AI changes UI, you need a browser.

When AI opens PRs, you need validation before CI.

When AI touches a real team, you need artifacts and handoff.

So the 2026 question is not just “Claude Code vs Cursor vs Codex.”

It is: how complete does your development loop need to be?

The best AI coding tool is not the one that writes the most code.

It is the one that leaves the least mess after the code is written.

LingBot-Video Isn’t Trying to Make Better Videos for Humans

Aria Kovac — Fri, 10 Jul 2026 03:45:00 +0000

A normal video model tries to make something a person wants to watch.

A robot video model has a strange job. It needs to make something a robot can learn from.

That difference sounds obvious until you start looking at what gets optimized. Human-facing models are usually judged by visual fidelity, style control, prompt following, camera motion, and whether the result feels coherent to us. Embodied video models need a different kind of coherence: object permanence, contact physics, action consequences, egocentric motion, manipulation intent, and whether the generated scene could actually teach a robot something useful.

That is why the LingBot series is worth paying attention to.

The newly released LingBot-Video paper describes a DiT-based mixture-of-experts video foundation model built specifically for embodied intelligence. The authors call it an inaugural large-scale, open-source MoE video foundation model for robotics, which I would repeat carefully as the paper’s framing rather than as a settled industry label.

Still, the direction is clear: video generation is moving from cinematic output toward robot training infrastructure.

As someone who spends a lot of time thinking about messy workflows, this is the part I find interesting. The question is not whether LingBot-Video makes prettier clips than Sora-style models. The question is whether video generation can become part of the data loop for embodied AI.

Why Robot Video Is a Different Problem

When a text-to-video model makes a cup slide strangely across a table, a human viewer may forgive it if the shot still looks beautiful.

A robot cannot forgive that.

If the cup moves without contact, the model is teaching the wrong physics. If a gripper passes through an object, the trajectory is useless. If the camera motion looks smooth but breaks spatial consistency, an embodied agent may learn a shortcut that fails in the real world.

That is the difference between video as media and video as training signal.

LingBot-Video addresses this by focusing its data and reward design around robot-relevant scenes. The paper describes a data profiling engine that augments generic internet video with embodied data sources: robot manipulation, robot navigation, and egocentric human video. It also introduces reward modeling around physical rationality and task completion, not just visual quality.

That matters because robot training data is expensive.

You can scrape enormous amounts of internet video, but most of it was not filmed from the perspective of an agent acting in the world. It rarely contains clean action labels. It may show objects, but not the causal structure a robot needs: what changed because of which action.

So the value of a model like LingBot-Video is not simply that it generates videos. It is that it tries to generate videos in a distribution closer to embodied learning.

Why MoE Makes Sense Here

The MoE part is not just a buzzword.

Robotics is not one task. Navigation, grasping, tool use, object interaction, and egocentric prediction all stress different parts of a model. A dense model has to carry all of that capacity everywhere. A mixture-of-experts model can route tokens or conditions through different expert pathways.

In practice, the promise is simple: more capacity without always paying the full compute cost.

That is especially relevant for embodied AI, where the data distribution is broad and awkward. A kitchen manipulation clip is not the same as a corridor navigation clip. A third-person video is not the same as a head-mounted view. A model that treats them all as one flat video problem may miss the structure that matters.

For developers, I would watch whether LingBot-Video’s expert routing actually improves downstream robotics tasks, not only whether the generated samples look convincing. If the model produces prettier robot videos but does not improve policy learning, it is still mostly a demo.

LingBot-World 2.0 Is the Other Half of the Story

LingBot-Video is about embodied video generation. LingBot-World 2.0 is closer to a world model.

The LingBot-World 2.0 paper, titled “Infinite Worlds with Versatile Interactions,” reports an interactive world model aimed at long-horizon generation and action-controllable simulation. The authors describe a pilot/director style generation harness and a distilled real-time variant targeting 720p video streams at 60fps.

This distinction matters.

A video foundation model can generate plausible embodied video. A world model tries to maintain an interactive environment over time. The second problem is harder because errors accumulate. A small spatial inconsistency at minute two can become nonsense by minute twenty.

I would treat LingBot-World 2.0’s reported capabilities as research claims to evaluate, not production guarantees.

But direction is important.

If a robot can train inside a reasonably controllable generated world before touching the real world, the cost curve changes. Not because simulation replaces reality. It will not. But because it can make exploration cheaper before expensive real-world validation.

Where VLA Models Fit

A VLA model is still a different layer.

Vision-language-action models consume visual state and language goals, then produce actions. LingBot-VLA 2.0, described in a separate technical report, focuses on embodied control using a large dataset that combines robot trajectories and egocentric human videos.

So I would separate the stack like this:

LingBot-Video generates embodied video distributions.

LingBot-World 2.0 simulates longer interactive environments.

LingBot-VLA 2.0 turns perception and language into robot actions.

Those layers can support each other, but they are not interchangeable.

This is also where I think a lot of quick coverage gets fuzzy. Calling everything a world model or everything a VLA model hides the engineering question: what part of the robot learning loop does this component actually improve?

What I Would Test Before Getting Excited

If I were evaluating LingBot-Video for a real robotics data loop, I would not start with the nicest demo video.

I would ask five boring questions.

First, does generated data improve downstream policy performance compared with real-only training?

Second, does it help on tasks outside the generation distribution, or only on visually similar benchmarks?

Third, does the model preserve contact physics well enough for manipulation?

Fourth, can failures be filtered automatically, or does the pipeline still need heavy human review?

Fifth, what happens when generated data is fed back into training repeatedly?

That last one worries me the most.

Synthetic robot video can be useful, but it can also amplify model mistakes. If a world model learns slightly wrong physics and a policy trains on that at scale, the policy may become very good at a world that does not exist.

That is not a reason to ignore the approach. It is a reason to build verification into the loop from the start.

The Real Shift: Video as Robot Infrastructure

From Sora-style models to LingBot, the shift is not simply better video.

It is a shift in purpose.

For human viewers, video generation is a creative medium. For robots, video generation may become a training substrate: a way to create scenarios, stress-test policies, expand rare cases, and reduce the cost of physical trial and error.

The next useful benchmark will not be whether the robot video looks cool on social media. It will be whether a robot trained with it becomes more reliable, more sample-efficient, and less surprised by the real world.

As a developer, that is the line I care about.

Not: did the model make a better video?

But: did the generated world teach the agent something true?

That is why LingBot-Video feels like a meaningful signal even if the field is still early.

Prompt Engineering Isn’t Dead. It Just Got Wrapped in a Harness.

Aria Kovac — Thu, 09 Jul 2026 05:48:22 +0000

A few months ago, if someone on my team said an AI workflow was “bad,” the first question was usually: What prompt are we using?

Now I find myself asking a different question:

Where does the model get feedback, and what is allowed to change after it fails?

That shift sounds small, but it changes almost everything.

Lilian Weng’s July 2026 post, “Harness Engineering for Self-Improvement”, helped frame a pattern many agent builders have already been wrestling with in practice. The model is still important. Of course it is. But the system wrapped around the model — tools, memory, workflow, permissions, evaluation, file state, background jobs, feedback loops — is becoming just as important as the prompt itself.

Weng defines a harness as the system around a base model that orchestrates execution: how the model plans, calls tools, acts, manages context, stores artifacts, and evaluates results.

That is the part that caught my attention.

I work close enough to customer support workflows to know that “better AI” rarely means “one better answer.” In practice, it means you stop getting the same repeated failures, the system actually recovers instead of freezing when things get ambiguous, and human handoffs become a whole lot smoother. Plus, you finally get a system that doesn't completely forget why something broke last Tuesday.

That is not prompt engineering anymore.

That is harness design.

A Prompt Is an Instruction. A Harness Is a Working Environment.

Prompt engineering is not useless. I still care about clear goals, constraints, examples, and tone.

But a prompt is mostly instruction.

A harness is environment.

The difference matters because most agent failures are not just wording problems. They are system problems:

The model gets too much context and loses the relevant bit.

The tool result is noisy.

The agent retries the same broken action.

The workflow has no memory of previous failures.

The evaluation step is vague or missing.

The system cannot tell whether an answer is merely plausible or actually verified.

You can patch some of this with a better prompt. For a while.

But eventually the prompt becomes a crowded apartment: instructions, warnings, examples, tool notes, edge cases, memory snippets, formatting rules, and “please don’t do that weird thing again” all squeezed into one place.

A harness gives those responsibilities proper rooms.

Memory can live in files or structured stores.

Evaluation can run as a check, not a paragraph of advice.

Tools can have permissions.

Retries can have policy.

Logs can become evidence.

Failures can be mined instead of forgotten.

That is why I do not read “harness vs prompt engineering” as a replacement story. It is more like a promotion. Prompt engineering becomes one component inside a larger runtime system.

Forget Code Rewriting: The Real Reality of AI Self-Improvement

The hype around AI self-improvement loves to paint a dramatic picture: a model autonomously rewriting its own weights, training its next iteration, and scaling up recursively. But that’s the Hollywood version.

Maybe someday. But near-term self-improvement looks much more boring and much more useful.

It starts outside the model.

In Weng’s framing, the practical near-term path is not necessarily a model directly editing its own weights. It is the harness becoming an optimization target. The system learns better ways to select context, manage state, run workflows, evaluate outputs, and preserve useful artifacts.

That matches what I see in developer tooling.

If an agent fails a coding task, maybe the model is not smart enough. But maybe the harness failed first:

It did not inspect the right file.

It did not run the failing test.

It did not preserve the error trace.

It did not know when to ask for clarification.

It did not compare the final patch against the original requirement.

This is where AI agent loop design becomes interesting. A minimal loop might look like this:

Plan the next action.
Execute through a tool.
Observe the result.
Store useful evidence.
Evaluate against the goal.
Update the workflow or memory.
Try again with better state.

That loop is not magic. It is just software engineering applied to agent behavior.

But the moment you can actually look under the hood and tweak that loop, the system finds a real path to self-improvement—without having to pretend the model magically became its own R&D lab overnight.

The New Unit of Optimization Is the Run

What I like about the harness framing is that it moves attention from the answer to the run.

A run has traces. Tool calls. Files touched. Tests executed. Errors ignored. Assumptions made. Human interventions. Final evidence.

That means the system can learn from more than success or failure.

The Self-Harness paper makes this explicit. It describes a loop where an LLM-based agent improves its own operating harness through weakness mining, harness proposal, and proposal validation. The important part is not “the agent rewrites itself” in some vague way. It is that failures are clustered, proposed harness changes are bounded, and accepted edits must pass regression checks.

That last part matters.

Self-improvement without regression testing is just automation with confidence issues.

The same pattern appears in newer harness research around coding agents. Agentic Harness Engineering frames harness evolution around observability: editable components, distilled experience, and decisions that can later be checked against outcomes.

That is the version of AI self-improvement I can actually imagine trusting in production.

Not an agent randomly rewriting its system prompt because it “reflected.”

A system that says:

“This failure pattern happened 14 times.”

“The root cause appears to be missing project-state recovery.”

“Here is a narrow harness change.”

“Here is the regression set.”

“Here is what improved, and here is what did not.”

That is less cinematic. It is also much closer to how reliable engineering works.

ECC Shows the Developer Version of This Shift

The GitHub repo affaan-m/ECC is a useful signal because it turns the harness idea into something developers can poke at.

The repo describes itself as a harness-native operator system for agentic work, spanning skills, memory optimization, security scanning, cross-harness workflows, and support for tools like Claude Code, Codex, Cursor, OpenCode, and others.

I would not treat any GitHub project as proof that a concept is mature. But I do think ECC shows why the harness idea is spreading.

Developers do not just want a smarter model.

They want agents that remember project conventions.

They want repeatable workflows.

They want security boundaries.

They want skills that can transfer across tools.

They want logs, hooks, rules, and recovery paths.

That is exactly the layer prompt engineering does not fully cover.

A prompt can tell an agent to be careful.

A harness can prevent it from touching production secrets, require tests before completion, preserve failure traces, and route uncertain cases to a human.

That difference is not cosmetic. It is the difference between advice and infrastructure.

So Is Prompt Engineering Over?

No.

But the era where prompt engineering was the main interface for improving AI systems is fading.

A good prompt still matters. It tells the model what the work is. It shapes behavior. It encodes constraints.

But for long-running agents, the harder problems now sit around the prompt:

What context should be loaded?

Which tool should be available?

What should be persisted?

What counts as done?

Who verifies the result?

What happens after failure?

What is allowed to change next time?

That is why “AI Harness” feels like a more useful keyword than another prompt trick.

For a small team, the practical move is not to build a grand self-improving agent on day one. It is to make your current loop visible.

Start with one workflow.

Log every tool call.

Save the important artifacts.

Define a verifier.

Separate memory from instructions.

Let failures produce structured notes.

Only then consider letting the system propose changes to the harness.

The scaling law bottleneck is not that models stopped improving. It is that better base models do not automatically give you better deployed systems. The gap between capability and reliability is increasingly filled by harnesses.

That is where I think Lilian Weng’s post lands hardest.

Prompt engineering asks: What should I say to the model?

Harness engineering is really about one big question: how do you build a system that lets a model screw up, learn from it, verify the fix, and try again—all without turning your entire workflow into a total black box of hidden states? Having watched countless shiny AI features blow up in actual user-facing apps, I know exactly which problem I’d rather spend my time solving.

The AI Race Is Becoming a Routing Problem, Not a Size Contest

Aria Kovac — Mon, 06 Jul 2026 07:00:00 +0000

Last week, I was looking at a support dashboard with three very unglamorous columns: average response latency, failed requests, and cost per resolved ticket.

No launch video. No leaderboard screenshot. No beautiful demo where everything works on the first try.

But that is usually where AI becomes real for me.

I work close enough to customer support workflows to know that “state-of-the-art” only matters if it survives messy inputs, multilingual users, peak-hour traffic, and a finance team asking why the API bill doubled. So when I look at the current wave of AI infrastructure news — Meituan’s LongCat line, Google’s Nano Banana 2, world-model research like World-VLA-Loop, and Baidu’s Unlimited-OCR — I do not read them as separate stories.

I read them as one story: AI is moving from “how powerful can we make this model?” to “how much useful capability can we deliver per dollar, per second, and per deployment target?”

LongCat-2.0 Is Interesting, but the Safer Signal Is LongCat’s Efficiency Pattern

The most sensitive LongCat headline right now is LongCat-2.0. A recent AFP report, picked up by Omni, says Meituan has launched LongCat-2.0 and that the company claims it was trained only on domestically made chips in its size class. That is an important claim, but I would treat it carefully until more technical details are publicly available.

The better-documented technical signal is Meituan’s earlier LongCat work.

In the LongCat-Flash technical report, Meituan describes a 560B-parameter MoE language model that activates only 18.6B to 31.3B parameters per token, around 27B on average. The paper also reports more than 100 tokens per second for inference and a cost of \$0.70 per million output tokens.

That is the part I care about as an engineer. The number on the box is huge, but the serving logic is about dynamic compute allocation.

LongCat-Next pushes the same direction from another angle. The LongCat-Next paper describes a native multimodal model that processes text, vision, and audio under one autoregressive objective.

So for me, a real Meituan LongCat-2.0 review should not start with national tech excitement. It should ask boring production questions:

Can p95 latency stay stable?

What is the cost per million output tokens?

How does the model behave on agentic tool-use tasks?

Can the training and serving stack be repeated outside the usual Nvidia-centered assumptions?

“Domestic chips for large-scale AI models” is not only a policy headline. For developers, it is a deployment question.

Nano Banana 2 Makes Image Generation Feel More Operational

Google’s Nano Banana 2 represents the other side of the efficiency race.

Here, the story is not domestic training infrastructure. It is high-volume image generation becoming easier to price and route.

According to the official Gemini API pricing page, Nano Banana 2 is a gemini-3.1-flash-image. Standard pricing lists 1K image output at \$0.067 per image, while Batch pricing lists 1K image output at \$0.034 per image. The cheaper Lite model, gemini-3.1-flash-lite-image, is listed at \$0.0336 per 1K image on standard pricing and \$0.0168 in Batch.

That distinction matters. “\$0.034 per image” is real, but it is not automatically the price of every real-time user interaction. It depends on Batch mode, image size, retries, and whether the user expects instant feedback.

Google’s image generation docs position Nano Banana 2 as the general-purpose image model in the current Gemini image family, with support for 4K output, text rendering, world knowledge, grounding, and multiple reference-image workflows.

For a small product team, I would split the decision like this:

Use Nano Banana 2 Lite when speed and cost matter more than complex editing.

Use Nano Banana 2 when you need better text rendering, higher-resolution output, grounding, or more reliable multi-reference work.

Use a more expensive model only when the creative task actually justifies it.

The benchmark conversation should not stop at “cheap API.” Product cost also includes retries, moderation, queueing, storage, and human review. A cheap image model can still become expensive if every third output needs to be regenerated.

World-VLA-Loop Shows Why “World Model” Still Means Research First

The original brief mentioned Loop world-model research, so I checked the public sources carefully. The verifiable paper I found is World-VLA-Loop, listed on Hugging Face Papers and published on arXiv in February 2026.

This is not something I would describe as a ready-to-use product. It is research around a closed-loop framework connecting video world models and Vision-Language-Action policies for robotics.

The project page explains the idea more concretely: train a world model, let a VLA policy roll out inside that world model, use failures to refine the system, then deploy and iterate. The World-VLA-Loop project page describes this as a cycle for improving both the world model and the policy.

That is exciting, but I would keep the language cautious.

World models matter because they try to preserve environment state over time. Objects should stay consistent. Actions should follow physical constraints. Failure trajectories should teach the system something useful.

But from a production perspective, I would still ask:

How quickly do errors accumulate?

Does the model preserve object identity after viewpoint changes?

Can developers inspect why a rollout failed?

Does this work beyond controlled robotics benchmarks?

This is where world models and support systems have something in common: the first response matters, but the fifth interaction is where the system usually reveals itself.

Unlimited-OCR Is the Kind of AI Project Developers Actually Use

The GitHub attention around baidu/Unlimited-OCR feels especially practical.

OCR is not glamorous. It is invoices, scanned PDFs, screenshots, forms, contracts, tables, weird fonts, and long documents someone uploads right before close of business.

That is why the repo is interesting. Its own README describes “one-shot long-horizon parsing,” shows Transformers inference, and includes deployment paths through vLLM and SGLang. It also includes multi-page and PDF parsing examples.

This is the practical side of lightweight AI. Not one universal model, but specialized models that solve painful tasks cleanly.

In a real stack, I would rather route OCR to a document parser, simple image generation to a low-cost image model, sensitive flows to local or private deployments, and complex reasoning to a stronger model only when needed.

That sounds less exciting than “one model to rule them all,” but it is usually how reliable systems are built.

The Real Trend Is Model Routing

The common thread across LongCat, Nano Banana 2, World-VLA-Loop, and Unlimited-OCR is not that they all do the same thing.

They obviously do not.

The common thread is efficiency pressure.

High performance still matters. But low cost, low latency, deployment flexibility, and task-specific reliability now matter just as much.

For developers, the winning AI architecture in 2026 may look less like choosing one “best” model and more like building a routing layer:

A powerful model for complex reasoning.

A cheap image model for high-volume creative drafts.

A specialized OCR model for document parsing.

A local or edge model for privacy-sensitive workflows.

A world model only where persistent simulation actually matters.

That is the part of the AI race I find more useful than leaderboard screenshots.

The future is not just bigger models. It is better decisions about when not to use the biggest model.

The Claude Code “Trojan” Panic Is Really About Trust

Aria Kovac — Thu, 02 Jul 2026 09:02:26 +0000

What I changed in my AI tooling audit after the latest Anthropic controversy

Last week, a thread about Claude Code started moving through my feeds in three languages.

In English, people called it geofencing.

In Chinese, people called it a “Trojan.”

In my work Slack, someone asked the practical question: “So, should we uninstall AI coding tools from company laptops?”

That was the moment I paid attention.

I work as a customer support engineer at a cross-border e-commerce company in Amsterdam. Most days, I deal with messy human systems: angry customers, multilingual tickets, half-broken automations, API logs, and the strange middle layer where software decisions become customer pain.

So when developers argue about whether Claude Code secretly checked IP addresses, system language, proxy behavior, or account identity signals, I do not read it only as an AI news story.

I read it as a trust story.

And trust, once it enters a workflow, needs logging.

First: I Don’t Like the Word “Trojan” Here

The word “Trojan” does a lot of emotional work.

It suggests malware. It suggests deception. It suggests that a tool entered your system as one thing and behaved as another.

Maybe that is why the term spread so fast. It captured the feeling many developers had: “Wait, this coding assistant I invited into my terminal may also be evaluating whether I am allowed to exist as a user?”

That feeling is real.

But I would still separate three things:

1. Malware behavior
2. Telemetry and fraud detection
3. Policy enforcement based on location or identity

They are not the same.

A tool that steals secrets is one category. A tool that collects usage data is another. A tool that enforces regional restrictions using IP, identity verification, device signals, or proxy detection is another again.

The trust problem begins when users cannot tell which category they are in.

The Important Part Is Not China

A lot of the current discussion focuses on China.

That makes sense. Public reporting has described Anthropic’s strict access limits for users in China, workarounds involving VPNs and relay services, and anti-proxy detection systems used to disrupt unauthorized access. WIRED also reported that Anthropic does not offer commercial Claude access in China or to Chinese-owned subsidiaries outside the country.

But if you only read this as a China story, you miss the part that will affect everyone.

The real question is:

What signals can an AI development tool collect from your local environment, and what decisions can the vendor make with those signals?

Today the signal might be region.

Tomorrow it might be enterprise policy.

Next month it might be “suspicious automation.”

Later it might be whether your company, country, payment method, IDE, proxy, or usage pattern fits a risk model you cannot inspect.

That is not science fiction. That is normal platform enforcement, arriving inside developer tools.

My Small Audit Checklist

After this story, I made a checklist for every AI tool that touches my work machine.

Not because I think every vendor is malicious. I do not.

Because “I trust this company” is not an audit control. It is a mood.

Here is the first version:

AI Tool Audit

1. What local data can it read?
   - current working directory
   - file contents
   - shell history
   - git metadata
   - environment variables
   - system language / locale
   - OS and device metadata

2. What network calls does it make?
   - API endpoint
   - telemetry endpoint
   - update endpoint
   - crash reporting endpoint

3. What identity signals are linked?
   - account email
   - payment country
   - phone number
   - ID verification
   - organization domain
   - IP address / proxy signals

4. What actions can it perform?
   - edit files
   - run shell commands
   - install packages
   - commit code
   - call external tools

5. What happens if access is revoked?
   - can work continue?
   - are local files safe?
   - are logs available?
   - is there an export path?

This is not paranoia. This is the same way I think about customer support automations.

If a tool can touch the customer, it needs controls.

If a tool can touch code, it needs better controls.

The Local Environment Is Customer Data Too

Support engineers learn this lesson early: metadata is not “nothing.”

A customer’s language, country, refund history, device type, order timing, and support channel can reveal more than the message itself.

Developers sometimes treat machine metadata as less sensitive because it feels technical.

It is not.

Your system language may reveal location or working context. Your IP may reveal office routing. Your project path may reveal a client name. Your git remote may reveal private infrastructure. Your environment variables may reveal things nobody should paste into a model, ever.

So when an AI coding tool runs locally, the question is not only “does it send my source code?”

The question is:

What else does it observe while helping me?

What I Would Expect From Vendors

I do not think AI companies should pretend regional compliance does not exist.

Export controls, sanctions, enterprise agreements, abuse prevention, fraud detection, and model safety policies are real constraints. A vendor may have legal reasons to block access. I understand that.

But I expect four things.

First, say what signals are collected.

Not in a 9,000-word privacy policy written for lawyers. In a developer-readable table.

Second, say which decisions those signals influence.

There is a difference between “we collect locale for UI language” and “we use locale as one signal in account enforcement.”

Third, provide an audit mode.

Let me run:

ai-tool doctor --privacy

and see what endpoints, config files, local permissions, and telemetry settings are active.

Fourth, make rollback visible.

If a controversial enforcement mechanism changes, publish the version, the behavior, and the migration path. Do not make developers reverse-engineer trust from rumor.

What I Changed Personally

I did not uninstall every AI coding tool.

That would be dramatic and not very useful.

I changed how I use them.

For personal projects, I still use AI tools freely, but I keep secrets out of the working directory. For work-adjacent experiments, I use separate folders, separate tokens, and less ambient access. For anything involving customers, I do not let an AI agent roam.

My current rule is simple:

If I would not paste it into a support ticket,
I do not let an AI tool inspect it by default.

That rule is imperfect. It is also easy to remember, which means I actually follow it.

I have a similar rule for my restaurant database, oddly enough. If a field will later be used for filtering, ranking, or automation, I define it clearly at the start. Otherwise future-me will build queries on vibes and regret it in Lisbon over bad clams.

Same lesson. Different table.

The Account Ban Problem

The SEO-friendly version of this article would probably be “What to Do If Your Claude Account Gets Banned.”

The honest version is less exciting:

Do not build a critical workflow around a single account you do not control.

Have an export path. Keep local copies of prompts and configs. Know which projects depend on which AI vendor. Keep a second model good enough for emergencies. Do not route sensitive work through random relay services because they are cheaper.

Especially do not send company code or customer data through unofficial proxy tools.

That is not a clever workaround. That is a data incident waiting politely in line.

The Bigger Lesson

The Claude Code controversy is not only about Anthropic.

It is about the next phase of AI tooling.

We are moving from chatbots we visit to agents we install. They sit closer to our files, terminals, repos, tickets, and internal systems. That makes them more useful.

It also makes vague trust much more expensive.

So my takeaway is not “Claude Code is safe” or “Claude Code is unsafe.”

My takeaway is this:

Any AI tool powerful enough to help with real work is powerful enough to deserve an audit.

Not a dramatic one. A practical one.

What can it read? What can it send? What can it change? What can get my account blocked? What happens if it disappears tomorrow?

If the answer is “I don’t know,” that is not a reason to panic.

It is a reason to open the settings, read the docs, check the network calls, and write the first version of your own checklist.

That is where trust starts.

Not with a statement from a vendor.

With a workflow you can inspect.