A chatbot gives you an answer. A coding agent can build a way to act on it: read files, write a script, run it, inspect the result and try again. The distinction matters even when the work has nothing to do with developing software.

My route into AI came through sociology and running a restaurant. I was interested in how people interpret a situation and what happens between wanting something and getting it done. That is still the question behind my technical work. Coding agents make part of that gap easier to cross.

Code is a means of doing work

The word “coding” makes these tools sound like they belong exclusively to developers. But code can calculate, reconcile records, transform files and connect systems. An agent that can write and execute it has a way to turn a description into a sequence of operations.

That does not make the result reliable by definition. A script can calculate the wrong formula perfectly. A file operation can be correct and still act on the wrong folder. Code makes a process executable; evidence and checks make it assessable.

Four capabilities are particularly useful:

  • Calculation. Execute a specified calculation and inspect the inputs and outputs, rather than relying on a plausible numerical answer.
  • Tools. Combine a sequence of file or API operations in a script when that is clearer than many separate tool calls.
  • Memory. Store intermediate work, create an index and retrieve relevant material instead of keeping everything in a single conversation.
  • Connections. Write the specific transformation or integration a task needs, provided the system has appropriate access.

The last qualification matters. Access is part of the design, not an inconvenience to work around.

Two examples from my own work

Finding invoices. Expense administration involves more than reading transactions. An invoice may be in an email, a downloaded file or a vendor portal. In my own workflow, I used a coding agent with file, email and browser access to assemble transaction-to-invoice mappings. It could build small pieces of code as the task required them.

The useful output was a mapping I could check. The agent doing the retrieval did not remove my responsibility for deciding what belonged in the expense report or whether an attachment matched a transaction.

Making research material navigable. Work on the Virtual Service Mechanic had accumulated material across documents, code and shared folders. I needed an entry point that would help people and agents find the right context.

I specified the desired structure and split the investigation into smaller tasks. Agents examined parts of the material and wrote indexes and summaries. I reviewed and adjusted the result. The enduring benefit was an organised body of knowledge that subsequent work could use, rather than a single long answer.

These are personal examples, not controlled productivity comparisons. They show what becomes possible; they do not establish how much time another team will save.

The difficult part moves

As execution becomes easier, deciding what should happen becomes more consequential. Someone must define the task, identify the sources, set permissions and decide what counts as a good result.

This is where specialist knowledge matters. The person who knows the workflow can recognise the exception, question an assumption and distinguish a useful output from a polished mistake. Much of that knowledge is tacit. Bringing it into the task is a design activity in its own right.

A well-specified goal helps, but it cannot anticipate everything. The workflow also needs a way to inspect evidence, report uncertainty and stop when the next action requires a person.

What to learn

Start with one recognisable task. Describe its inputs, the result you need and the operations the system may perform. Choose a check that can reveal a mistake. Then examine what happened.

You do not need to learn every new tool. You do need enough understanding to judge access, dependencies, intermediate state and failure. These are familiar questions to anyone who has managed an operation; coding agents give them another technical form.

I expect more conversational AI to acquire the ability to execute work. The opportunity is wider than writing software. So is the responsibility: the clearer we make intent, evidence and boundaries, the more useful that execution can become.