AI Coding Tools: What Changed, and What I’d Test

First, get the acquisitions right

On 14 July 2025, Cognition announced a definitive agreement to acquire Windsurf. Cognition is the company behind Devin. On 2 June 2026, it introduced Devin Desktop as Windsurf’s next generation, combining the IDE with a workspace for local and cloud agents. Calling the buyer ‘Devin’ confuses the product with the company.

Cursor’s announcement on 14 August 2026 says SpaceX completed its acquisition. It describes the April model-training partnership as the beginning of that process. The buyer named in the completed-deal announcement is SpaceX, not the social network X.

For a team choosing a tool, I would treat an ownership change as a reason to revisit the contract, available models and exit plan. It does not establish that the tool writes better code.

Sources: Cognition: Windsurf acquisition agreement, 14 July 2025; Cognition: Introducing Devin Desktop, 2 June 2026; Cursor: completed SpaceX acquisition, 14 August 2026.

Investment tells one part of the story

On 8 September 2026, Cognition announced a funding round of more than $2 billion at a $48 billion valuation. Those are figures reported by the company. Alongside the acquisitions, they show substantial investment in this part of the industry; they do not measure the size of the entire coding-tool market or the benefit to a particular engineering team.

I would keep funding, product capability and delivery results in separate conversations. A company can raise money without proving that my next migration will take less time. That requires a comparison in the repository where the work happens, including the time spent checking and correcting the result.

Sources: Cognition: Series E announcement, 8 September 2026.

Codex is the tool; Astra is a model

OpenAI’s public model guide lists Astra as GPT-6 Astra, with the identifier gpt-6-astra. It documents selecting it in Codex with ‘codex -m gpt-6-astra’. Access depends on the account, client and rollout. OpenAI positions Astra for complex work involving several steps and tools; that is the vendor’s positioning, rather than evidence that it wins every coding task.

Codex supplies the working environment around the model. Its CLI can inspect repository files, edit code and run local commands. You can choose the model, reasoning effort and permissions, then inspect the commands and changes. In a debugging task, that makes it possible to move from an error report to relevant files, a proposed patch and test output within one session.

OpenAI’s Astra API guide also documents asynchronous tool calls and instructions supplied while a task is running. An application still executes the tools and manages their results. These API features should not be read as a promise that every Codex interface exposes identical controls, or that the model independently has unrestricted access to your machine.

Sources: OpenAI: models available in ChatGPT and Codex; OpenAI: Codex CLI; OpenAI: GPT-6 Astra API guide.

What Claude Code adds around Claude

Anthropic describes Claude Code as a working loop that gathers context, takes action and checks results. Claude models do the reasoning; the surrounding tool supplies file operations, search, command execution and context management. Command output becomes information for the next step. This is why comparing the names of two models alone leaves out much of the coding experience.

Its documentation also describes project instructions in CLAUDE.md, configurable permissions and file checkpoints. Checkpoints cover file changes; they cannot roll back effects on a remote database, API or deployment. For a team trial, I would check both the quality of the proposed patch and whether the chosen environment keeps its actions within the agreed scope.

Sources: Anthropic: how Claude Code works.

Choose the working environment as well as the model

Cursor documents an agent built around instructions, a selected model and tools for searching, editing and running commands. Devin Desktop combines an IDE with management of local and cloud agents, pull requests and their context. These products overlap, but the place where work runs and the way changes are reviewed still matter.

If I were choosing for a team, I would try the editor workflow with someone doing an unfamiliar change, not just someone who already knows where every file lives. Can they follow what changed? Can they stop the agent, run the checks themselves and continue manually? An attractive demo does not answer those questions.

Sources: Cursor: Agent overview; Cognition: Introducing Devin Desktop, 2 June 2026.

The shortlist can include tools you already have

GitHub documents Copilot features spanning editor assistance, chat, code review and an agent that can work on changes and raise pull requests. I would include it in an evaluation where the team already uses GitHub, while checking which capabilities its plan and organization settings allow.

Gemini CLI provides another terminal-based option, with documentation for file tools, shell commands, project context and permissions. A team that prefers command-line workflows can assess it alongside Codex CLI and Claude Code. The useful comparison is the complete setup: tool version, model, permissions, context and price for the work performed.

Sources: GitHub: About GitHub Copilot; Google: Gemini CLI documentation.

I would start with three jobs from the backlog

My proposed trial would use the same starting commit and acceptance criteria for each candidate. I would select a bug, a small feature and a maintenance change that the team actually needs. The examples below illustrate the shape of the trial; they are not results from a comparison I have run.

For the bug, use a search screen where a slow response replaces newer results. Ask for the smallest repair and a regression check. Does the agent reproduce the ordering problem, or merely add a delay that makes it harder to see? Can the reviewer explain why the fix works?

For the feature, add a filter that survives refresh and browser Back. State what the URL should contain and what must happen on an empty result. Check the interaction in a browser, including keyboard use. A plausible component and a passing build are not the whole acceptance test.

For maintenance, update a dependency with a known breaking change. Supply the official migration notes and a boundary around unrelated code. Check whether the agent identifies affected call sites, retains the lockfile policy and reports anything it could not verify.

Count review and repair time

I would record the time from the initial brief to an accepted change, including setup, clarification, review and fixes. I would also record the actual usage cost, failures and any work left for another person. Generated lines and accepted suggestions are easy to count, but neither tells me whether the change belongs in production.

Repeat the tasks from clean copies rather than picking one impressive run. Record the version, model and settings so a later release can be compared with something concrete. A small trial can guide a local decision; it cannot establish a universal ranking of products.

• Correctness: did the change meet the agreed behavior, including failure cases?
• Review: what did a person have to discover, explain or repair?
• Scope: did it change unrelated files or ask for unnecessary access?
• Continuity: can another engineer run the checks and continue the work?

What I would change as a team lead

These tools make it possible to delegate more than the next few lines of code. The documented workflows include reading a repository, making changes and running checks. My response would be to spend more care on the brief, the boundaries of the task and the evidence needed to accept the result. I would still expect the engineer submitting a change to understand it.

I would choose a primary tool for routine work and keep repository instructions, test commands and decisions somewhere the team can use without that vendor’s chat history. A second tool should earn its place on a specific job. I would revisit the choice after a meaningful model, price, policy or ownership change, rather than asking everyone to switch whenever a launch appears.

The practical question is whether the setup helps this team produce a correct, reviewable change at an acceptable cost. If it does, keep the evidence. If it does not, changing the prompt indefinitely is not a substitute for choosing a different tool or doing the task yourself.