I have also been experimenting with Copilot Cowork and the idea of treating an AI tool less like autocomplete and more like a collaborator that needs direction.

The difference is subtle but important. A collaborator can help explore options, implement a slice of work, explain trade-offs, and check assumptions. But it also needs context, constraints, review, and correction. Without those, it can be confidently wrong in ways that look productive until someone reads the detail.

The capability curve is moving quickly. Coding assistants are becoming more agentic: planning work, making coordinated changes, running checks, responding to feedback, and taking on larger slices of delivery. That is a different thing from a faster editor.

The most useful pattern so far is to be explicit about the outcome, let the tool handle a bounded piece of work, then review the result as if a junior team member had produced it. That review step is not optional. It is where quality, security, maintainability, and business intent get tested.

For leaders, this is the part worth paying attention to. AI may change how software work is organised, but it does not remove the need for clear ownership. If anything, it makes ownership more important.

As code generation gets cheaper, more ideas will make it to prototype. That is useful, but it also means organisations will need stronger habits around prioritisation, review, assurance, and deciding what not to build.

I recently built a small expenses claim application as a practical way to test an AI-assisted development workflow against a familiar business process.

Expenses are deliberately ordinary, which makes them useful. The process has enough real complexity to be interesting: users, claims, receipts, approvals, policy checks, audit trails, exceptions, and reporting. It is not glamorous software, but it is exactly the kind of internal workflow where organisations spend a lot of time and money.

The build made a few things obvious. AI can help move from idea to first version quickly, but the hard work remains in deciding what the process should be, which controls matter, how edge cases should be handled, and what evidence is needed for review or audit.

This is where the falling cost of code generation becomes interesting. If a small team can build a usable first version quickly, then more internal processes become candidates for software. The question changes from “can we afford to build this?” to “is this the right thing to build, and what controls does it need?”

That is where technology leadership becomes less about tools and more about operating judgment. A working prototype is useful, but it is only one part of the decision. The better question is whether the process is simpler, safer, easier to support, and better aligned to how people actually work.

In that sense, the technology is not the whole story. AI may reduce the friction of creating software, but organisations still need to understand the process, the policy, the data, the risk, and the people who will live with the result.

I have been experimenting with OpenClaw as another way to understand where AI-assisted software work is heading, and what happens when the cost of producing code keeps falling.

What interests me is not only whether a tool can produce code. The more useful question is how it changes the shape of the work: how ideas become requirements, how assumptions are tested, how quickly a prototype becomes something reviewable, and where human judgment is still doing the important work.

For a long time, a lot of software decisions have been constrained by the cost of getting something built. That constraint is not disappearing, but it is changing. Coding assistants and agentic tools are making it easier to move from an idea to a working first version, especially for contained internal tools, prototypes, and workflow applications.

My early impression is that these tools reward clarity. If the goal is vague, they can produce plausible noise. If the goal is specific, and the review loop is disciplined, they can make small experiments much easier to start.

That shifts the leadership question. If software becomes cheaper to generate, the scarce thing is not only development capacity. It is knowing what should be built, what should not be built, what needs proper governance, and what can safely remain an experiment.

That matters for software teams, but it also matters for leaders and boards. AI coding tools are not just a productivity story. They raise questions about assurance, maintainability, security, skill development, and how organisations know whether the software they are creating is actually fit for purpose.