AI transformation, stage 2: strategy and choosing your AI tooling

A real AI strategy for a software team fits on one page. It requires three decisions.

Data rules. The team must know which information may reach a model. First, the organization approves a specific service, account type and configuration after checking the contract terms, retention, use of data for model training, processing region and subprocessors. It then defines which data classes may be sent through that setup. Secrets, production data, personal data and code subject to contractual restrictions stay outside the model unless company policy explicitly approves that use case.

Budget. The per-person cost range should be known before comparing tools, because it eliminates half of the offers before the real discussion starts. Without a set ceiling, the first finance person who sees the subscription invoice blocks the decision.

Freedom of choice. Who tests and approves tools. In teams I have observed, an organic approach worked well: interested developers try tools on their own tasks, and whatever settles into daily work stays. Formal pilots with acceptance criteria rarely said more than a few weeks of real usage.

These three points close the strategy topic. A document describing an organization-wide AI transformation will not move a single pull request.

The least obvious lesson from tool selection reads: fixating on the model achieves nothing. The outcome is decided by the fit between the model, the harness and the specific project. Raw capability measured in benchmarks stays a step behind that fit.

A harness is everything around the model inside a tool: how repository context is gathered, whether commands and tests can run, the loop for fixing its own mistakes, handling of project instructions. The same model in two different harnesses performs so differently that they could be two different models.

Across AI transformation projects I have taken part in, a recurring division of roles emerged:

• Claude Code most often became the primary coding tool because of its mature harness and large user base. Its popularity provided documented working patterns, ready-made configurations and fast community answers to common problems.
• ChatGPT in the desktop app supported analysis, planning and work outside the terminal.
• Open-weight models used through OpenCode appeared where the team optimized cost and the chosen processing setup complied with its data rules.

The conclusion for tool selection: compare the whole package, meaning the model together with its harness, on your own repository and your own tasks. A model ranking describes the model in isolation and leaves out the context where it will work.

An agent running locally in the terminal is a professional developer tool of the same rank as the editor and the compiler. It works directly in the repository, runs commands, executes tests and fixes its own mistakes in a loop controlled by the developer.

Core tasks go to this class: implementing features, refactoring, bug fixing and test work. A local agent gives control over executed commands, but the context may still be processed by an external model. Every change goes through the standard code review process.

This is where the first myth needs correcting, the claim that code created with AI cannot reach good quality. Quality depends on the quality of the verification loop, meaning tests, static checks and human review. When those elements work, the agent produces code through the same quality process as the developer. When they do not, the problem existed before AI was switched on.

The second class covers agents working in the cloud, asynchronously, without involving the developer's machine. In practice they fill two main roles.

The first role covers side tasks: small fixes, dependency updates, simple features with clearly defined acceptance criteria. Such a task can be handed to an agent while you continue your own work, and the result gets evaluated during pull request review.

The second role is remote and mobile work. A cloud agent lets you start a task from a phone between meetings or continue work from a device without a configured environment. For people who travel often this changes how work happens day to day.

The division of roles follows the nature of the task. Core product development stays in the terminal, next to the developer and their tools. The cloud takes over work that does not need constant supervision.

A separate tool class for code review, tests and documentation sounds like a natural part of the landscape. In practice it is usually unnecessary at the start. The same agent that writes code also writes tests, extends documentation and helps review changes.

Specialized tools arrive later, when a concrete load appears. Examples include automated code review in CI, which comments on every pull request against agreed rules, or a notebook-style AI knowledge base holding project context outside the repository. Both answer a real scaling problem.

The order matters economically. A team that buys the coding agent first and adds further tools only when the need is documented spends less and discovers sooner what actually gets used day to day.

Two myths remain to dismantle.

The first claims AI tools are expensive. In teams I have observed, the monthly cost usually ranged from 20 to 200 dollars per person, depending on usage intensity and billing method. This range is limited to those implementations and does not establish a universal price list. The team should test the economics on real tasks by comparing the subscription cost with the time actually saved.

The second myth inverts the first: since the tool works, hand everything over and stop reading code. That path leads to a system nobody on the team understands. An agent accelerates a developer who knows what they want and can evaluate the result. Understanding the system stays on the human side, the agent only shortens the path to the goal.

Finally the data rules, because they constrain every decision above. Approval applies to a specific service, account type and configuration. Before the first piece of code is sent, the team records the permitted data classes together with the processing mode, retention, use of data for model training, processing region and subprocessors.

Checkpoints for this stage:

• Are the data rules, the per-person budget and the tool selection method agreed and known to the team?
• Was the whole package of model plus harness compared on your own repository instead of relying on rankings?
• Does the split of roles between the terminal agent and the cloud agent follow the nature of the tasks?

Positive answers open stage three, choosing where the transformation starts. The decision about where AI begins working in the product builds directly on the tools and rules settled here.