An agent in my workflow

2026-07-28T00:00:00+00:00

Hook</h2>
Last week, I was asked how Claude Code</a> actually improved my productivity, past the pitch of "it writes code for you." I didn't have a sharp answer on the spot. Turns out the honest answer isn't about writing code faster, it's about writing the thing that does the task once, instead of re-explaining the same task every time.

ToC</h2>
What it is</a></li>
How it fits your workflow</a></li>
A practical example</a></li>
When it's not a good fit</a></li>
More on this topic</a></li> </ol>
What it is</h2>
An agentic coding tool is an interactive cli tool. You run it, from a project directory, and it can manage your workflow, directly from your terminal: reads files, greps for symbols, edits code, runs your test suite, commits changes... All of this through natural language instructions.
How it fits your workflow</h2> You don't hand the agent a vague goal and walk away. You point it at a concrete, bounded task: add a migration, patch a flaky test, trace where a Django task</a> raises an exception. Your agent works best when your Git</a> repository already carries conventions it can follow: an existing test pattern, a linter it can run against its own output, some pre-commits rules. Without that scaffolding, it tends to invent its own conventions.
A practical example</h2>
Say you want to open a pull request on Bitbucket</a> once your branch is ready. The blunt way: just ask Claude Code to do it. Assuming the right credentials are already sitting in environment variables, it can go read Bitbucket's REST API documentation</a> itself, ask you for whatever inputs it's missing: title, description, destination branch. Then, fire off the right curl</code> calls directly in the terminal. No code gets written. API driven by hand, once.
That works, but it doesn't scale: opening a PR is something you'll do again for the next ticket. So instead of asking for the same ad hoc sequence of curl</code> calls every time, you ask for a reusable capability instead. A create_pull_request</code> Python helper Claude Code writes once, and a matching Claude Code skill</a> that wraps it, something you (or another agent session) can invoke by name instead of re-explaining the task from scratch.
This helper is meant to be reused unsupervised: so it should default to a dry run, nothing ships by accident when it's called from a script, a hook, or another agent's loop:
import os import subprocess import requests API_ROOT = f"https://api.bitbucket.org/2.0/repositories/{os.environ['BB_WORKSPACE']}" def create_pull_request( title: str, description: str, repo: str, destination: str = "develop", *, confirm: bool = False, ) -> None: source = subprocess.run( ["git", "rev-parse", "--abbrev-ref", "HEAD"], capture_output=True, text=True, check=True, ).stdout.strip() payload = { "title": title, "description": description, "source": {"branch": {"name": source}}, "destination": {"branch": {"name": destination}}, } if not confirm: print(f"DRY RUN: {source} -> {destination}: {title}") return response = requests.post( f"{API_ROOT}/{repo}/pullrequests", auth=(os.environ["BB_USER"], os.environ["BB_API_TOKEN"]), json=payload, ) pr = response.json() print(f"Created PR #{pr['id']}: {pr['links']['html']['href']}") </code></pre> The matching skill</a> enforces the same gate one level up, in the conversation itself, before confirm</code> ever gets set. What matters here isn't the API call. It's the shift from "do this task" to "build the thing that does this task". Every future PR reuses the same tested default instead of re-deriving the correct call, and its safety behavior, from scratch each time. When it's not a good fit</h2> Coding agents automate</a> the execution of well-understood tasks. Every time something becomes well-understood enough to prompt, it gets automated. Judgment, your job, is the ability to make good decisions under incomplete information, time pressure, and conflicting constraints: Developing opinions about system design that survive "but the LLM suggested X"</li> Being able to evaluate tradeoffs LLMs do not surface (org politics, migration risk, team capability)</li> </ul> More on this topic</h2> So, back to the original question. The gain isn't lines of code written per hour. The distinction, task vs. capability, is doing more for your output than any single agent feature. To dig deeper on the subject, here are some interesting links: Claude Code CLI reference</a></li> Zero Token Architecture</a></li> Software engineering isn't writing code</a></li> Engineering practices that make coding agents work</a></li> </ul>

The actors</h2>
Who is in the room? Customer, user, sponsor, provider.</p>

Kiesse_

An agent in my workflow

ITIL 4... as fast as possible

Kiesse_

An agent in my workflow

More on this topic</h2> So, back to the original question. The gain isn't lines of code written per hour. The distinction, task vs. capability</em>, is doing more for your output than any single agent feature. To dig deeper on the subject, here are some interesting links:</p>

ITIL 4... as fast as possible

Disclaimers</h2> Opinions expressed in this post do not reflect the views/positions of no affiliated group.</p> </li>