Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Agent autonomy is useful only when it is supported by the right context, clear requirements, and evidence that the work is correct. In this first-person account, Maksym Kuzmitskyi compares an established personal coding-agent workflow with Liberty’s early exploration of reusable agent skills. The two approaches share core habits, but the comparison has no measured winner: the company process remains a pilot, and ordinary engineering tasks will be needed to judge what works.
What “earned autonomy” means in this comparison
The author’s central idea is that an agent should not be treated as trustworthy merely because it can take actions. Its latitude should follow from the context it has been given, the rules it must follow, and evidence gathered as it works. As Kuzmitskyi puts it: “The interesting question is not whether an agent can act autonomously. It is whether its autonomy has been earned by context, rules, and evidence.”
That framing keeps the human in the loop without requiring a person to approve every harmless step. The human still owns requirements, architecture decisions, approval, and final review. The design challenge is to reserve human attention for decisions and risks that need it, rather than turn routine progress into an approval queue.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
How the personal workflow carries work through delivery
Kuzmitskyi describes a connected workflow rather than a coding-only handoff. The agent moves from understanding the task to investigating the code, making a constrained change, checking it, and helping with pull-request follow-up when useful.
#1 Best Overall
- Understand the task and its context. Gather the task details, relevant repository instructions, engineering standards, and other information that constrains the work.
- Find the code that controls the behavior. Research the relevant implementation and surrounding code rather than assuming where the change belongs.
- Form a hypothesis and try to disprove it. Identify the likely cause or change, then choose an economical check that could show the hypothesis is wrong.
- Make a small change and validate it. Keep implementation focused, then use an appropriate check—such as a relevant test—to establish whether the change behaves as intended.
- Follow the work through review. When appropriate, use the agent to prepare a pull request, investigate CI failures, and respond to reviewer feedback.
Context can come from personal preferences, shared engineering standards, and repository-specific instructions. The author’s priority is that local, current information takes precedence over general preferences. Memory may help an agent resume work across sessions, but it should not outrank the current code, tests, documentation, or actual tool output.
Connected tools can supply useful context from task systems, documentation, source code, tests, and pull requests. They can also surface irrelevant information. Access to more context is not automatically better; the agent still needs to find what applies to the task.
What Liberty’s reusable-skills pilot adds
Liberty is beginning to investigate a more structured approach built around reusable agent skills: packages of instructions and working patterns for recurring kinds of engineering work, including discovery, planning, implementation, debugging, and review. The process under exploration makes the work more explicit:
Free tools Windows power users keep installed
One-click scans. No signup required.
- Prepare the context.
- Write a specification.
- Plan the work.
- Review the plan.
- Implement the change.
- Validate the result.
- Record observations about quality and usability.
The potential benefit is a shared baseline that does not depend on one engineer’s personal configuration. Reusable skills could make sound habits easier to repeat across engineers and repositories, while the structured process could help distinguish habits that are useful beyond an individual workflow.
This is an early exploration, not a settled company-wide process or a demonstrated result about fully autonomous software development. The source reports no measured comparison or outcome.
Where the two approaches overlap—and where the pilot may cost more
Both workflows emphasize context, requirements, planning, small changes, tests, human review, and reusable knowledge. Their difference is chiefly how explicitly those habits are packaged and sequenced: the personal approach connects them through an individual workflow, while the pilot adds reusable skills and a more formal specification-to-learning sequence.
That added structure may suit complex or high-risk work, where an explicit specification and plan review can expose assumptions before implementation. For a tiny, low-risk change, the same sequence might impose more overhead than the task warrants. These are concerns to test, not findings from a completed comparison.
There is also a risk that process artifacts become goals in themselves. A polished specification or plan can still begin with a mistaken assumption or solve the wrong problem. Documents and reviews are useful only insofar as they improve the work and reveal errors early.
Best Value
How to compare the workflows fairly
The author proposes evaluating both approaches on real engineering tasks, rather than assuming that a personal workflow or a formal process is better. A useful comparison would examine task outcomes and the cost of reaching them, while separating ordinary engineering effort from overhead introduced by the framework.
| Evaluation dimension | What to examine |
|---|---|
| Task outcome | Whether the work met its acceptance criteria. |
| Correction and rework | How much correction was needed after the agent’s initial work. |
| Defects | Which defects were found by the agent, CI, or people. |
| Review | Whether review quality or effort changed. |
| Context recovery | How well relevant context was recovered across sessions. |
| Process cost | How much time went to ordinary engineering work versus framework overhead. |
| Task fit | Whether results differ with task risk and complexity. |
Reporting time alongside quality matters: a process that adds documentation or review steps should be assessed for what those steps improve and what they cost. The author also recommends aggregating and anonymizing data. No comparative measurements or named statistics are reported in the account, so there is no evidence yet to declare either workflow superior.
The open conclusion: combine what proves useful
Kuzmitskyi expects that a useful future approach may combine the personal workflow’s connected, end-to-end execution with reusable skills that make effective practices easier to share. That is a hypothesis, not a verdict. The comparison remains open until real tasks show whether the structure improves outcomes enough to justify its overhead, and which parts of each approach are worth keeping.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsQuick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
