Engineering Workflow

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.

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.