AI Agents

Generated code can be correct and still be expensive to change. I care whether the next engineer can explain its boundaries without reconstructing the prompt.

A plausible API can belong to another release, runtime or feature mode. I want agent advice checked against the package and configuration the project uses.

An agent can validate a change in an environment nobody else can reproduce. I want the handoff to explain the runtime, dependencies and state behind the result.

A model upgrade can change tool use, stopping decisions and recovery, not just answer quality. I would test the workflow contract before trusting a new default.

A coding agent must read repository content without treating it all as authority. I want the boundary between useful evidence and instructions to stay visible.

Generating a patch and understanding its consequences consume different resources. I want agent workflows to respect the capacity of the people reviewing them.

An AI agent made a sound improvement, and I agreed. A colleague found his task implemented in my PR. What should review verify beyond the quality of the code?

An AI agent can write code and tests that agree on the same mistake. I want the expected result to come from somewhere other than the implementation under test.

A successful task can depend on a skill, existing instructions, tool access, tests, or a person correcting the assumption. Evaluating agent workflows means keeping those contributions apart instead of turning one good result into a productivity claim.

Review automation has to track more than whether it has seen a PR. Findings, CI evidence, duplicate suppression and guarded actions need a revision and a lifecycle, while final approval remains an accountable human decision.

Hooks and generators can transform a small, reviewed change into a different committed artifact. Agent workflows need to inspect the output of automation, distinguish unrelated drift, and stop when the final scope no longer matches the task.

A local build can accept a dependency change while a related service rejects its contract. The useful work is establishing the scope and freshness of the evidence, including when the original proposal should be closed rather than completed.

My use of coding agents gradually became work on the environment around them: current context, tool access, focused checks, review and recovery. The useful distinction is not how much an agent can do, but what makes its result defensible.

I built a personal AI reviewer for GitHub Pull Requests, not as a cold rule bot, but as a local and observable tool that checks known risk patterns and turns them into useful engineering conversation.

I arrived at Liberty with a working model for agentic development. Now the company is exploring a more formal approach built around reusable agent skills. I don't know which model will prove better yet, and that uncertainty is the interesting part.

For the Silpo AI Factory hackathon, the interesting problem was not building another AI shopping chat. It was figuring out where AI should stop, where deterministic procurement logic should begin, and how MCP could execute a controlled supplier workflow at the end.

How Nivra went from a vague hackathon direction to a tested WebMCP workspace: choosing the right idea, making architecture the shared context, and proving that human UI, agent tools, and deterministic validation could work from the same model.

Nobody writes agent rules once and walks away — they write them, then keep adding. A line here after a bad run, a paragraph there after a near-miss. Six months later the file contradicts itself, and the agent is following the version of your project that stopped existing in March.

An agent that feels better after a prompt change may still be getting worse. Without a small set of realistic tasks, explicit expectations, and recorded failures, agent improvement is just a sequence of impressions.

A long transcript can remember everything and still help with almost nothing. Durable agent memory is the small set of current facts, decisions, and lessons that makes the next run start from a better baseline.

Autonomy is not a single setting to turn up. A useful agent knows which decisions it owns, which ones it can reverse, and which moments need a human before the next step.

An agent cannot reason about information it cannot reach, and a vague tool description turns a precise capability into a guessing game. Tool design is not plumbing around the model. It is part of how the agent thinks.

A capable model with the wrong context is still a bad agent. The useful part of an agent is not the model in isolation, but the project knowledge, rules, tools, and decisions that shape what it can see before it acts.

An agent is stateful, and its errors compound: one wrong step sends it down an entirely different path, and it can't tell that it's lost. Autonomy without guardrails isn't trust — it's hoping. The job isn't to make the agent never fail. It's to make sure that when it does, the blast radius is small.

The instinct is to put the agent on a schedule: every few minutes, wake up and check the environment. That instinct is where a lot of runaway costs and pointless runs come from. An agent should be woken by a reason — a commit, a deploy, a failing check — not by a clock ticking over whether or not anything happened.

A story made the rounds: someone put an agent on a schedule to keep checking their environment, it got stuck in a loop one night, and instead of a couple of hours it burned through a fortune in tokens by morning. The lesson isn't "watch your usage." It's that cost is a design constraint, and most agent setups treat it as a footnote.

I can open a fresh session, type "take ticket 123 and do it as usual," and the agent runs the entire routine — assign, sprint, branch, commit, PR, pipeline. People assume that's a clever prompt. It isn't. It's months of small corrections turned into rules the agent never forgets.

Open almost any "how I use AI" post and you'll find an orchestra: a planner agent, a coder agent, a reviewer agent, a tester agent, all pinging each other. It looks impressive. It's also the most expensive, most fragile way to get worse results than one agent you actually taught to do the job.