Kodacode 1.3 brings four agent work modes together in a single desktop client

An agent has written the code and changed a dozen files, and then the familiar work begins: open the changes, inspect every edit, run the tests, and then figure out why the CI automation finished with strange text instead of a proper status. Kodacode 1.3 attempts to bring this fragmented process together in one place. The agent can now interact with applications through their interfaces, open pages in a built-in browser, display its own changes, and run in a pipeline with machine-readable output.

The practical value here is not another chat window. Developers get a more cohesive workflow: assign a task, observe the agent's actions, review the diff, and pass the result to the next tool. Product teams can quickly assemble an interactive prototype from project components. Automation teams get visual workflows with HTTP requests, MCP tools, conditions, and mandatory human approval.

The agent moves beyond the editor

Computer Use mode allows Kodacode to see the screen, locate the required window, click interface elements, scroll pages, and enter text. It is available in the desktop application and IDE plugins in Agent mode.

Consider a simple example: data needs to be transferred from an internal dashboard into a spreadsheet, but the dashboard lacks a convenient API. The agent can open the application, find the record, copy the values, and complete the form. Previously, this task would have required separate browser automation or manual work.

A built-in browser is also available. Links open inside the desktop client, a selected page fragment can be sent directly to the agent, and search, element selection, and screenshots are available for verification. This reduces switching among the chat, browser, and editor, although it does not by itself make the agent's actions reliable.

This is precisely where oversight matters. A visual agent can click the wrong button, misread the state of an interface, or continue working after an unexpected window appears. Operations involving publication, payment, data deletion, or settings changes therefore must not be delegated without human confirmation.

Edits and prototypes appear alongside the conversation

The desktop client now provides change review at two levels: for the entire conversation and for an individual message. This helps separate the result of a specific assignment from accumulated edits. The diff even works in folders without Git: the application tracks the agent's changes itself.

The workspace can be split between the chat and a file viewer. It includes a project tree, syntax highlighting, and the ability to attach a specific section to the next request. During a long session, this is more useful than asking the general question, “What did you change?” The developer can point directly to the problematic line and request a targeted fix.

Interactive prototypes are another use case. The agent can assemble several screens from the project's existing components and styles, while the team compares mobile and desktop versions. This does not replace design review, but it accelerates hypothesis testing before developers begin polishing the implementation.

Flows and the CLI make the agent part of the system

Flows is a visual automation builder similar to n8n or Zapier, except that individual steps can be performed by an agent. A flow can be triggered manually, on a schedule, through a webhook, or by another flow. It supports branches, loops, file operations, HTTP, MCP, and pauses for approval.

For example, a morning workflow can collect news, filter it, prepare a draft, and wait for an editor's approval. The key word is “wait”: manual review is built into the process itself instead of relying on a team's promise not to publish the result automatically. Flows is still in beta, so critical processes should also be backed by logging and checks in an external system.

Headless mode has been expanded for CI. The CLI can accept a stream of requests through stdin, return events as newline-delimited JSON, report token consumption, and terminate with an unambiguous code. Code 0 means success; a nonzero code means the task was not completed. A step limit helps stop a run caught in a loop; when the limit is reached, the CLI returns the reason for stopping and code 2.

The practical takeaway is to begin by testing the CLI on a safe check, such as read-only analysis of changes. Then connect streaming JSON to CI logs, set a step limit, and verify the handling of every exit code. Computer Use and Flows are best introduced afterward, starting with reversible operations and requiring confirmation before any external action.