Vibe Coding, with Confidence

You can ask an AI tool to write code. What would let you trust the work enough to delegate a complete development task? That is the opening question behind Itamar Friedman’s Vibe Coding, with Confidence. The Qodo CEO and co-founder proposes an interface that may seem less ambitious than a new AI editor: the command line. Qodo is soft-launching its CLI during the talk, inviting installation and feedback subject to unspecified capacity limits.

The audience already knows Claude Code, Codex CLI and AI IDEs. The next question is what those interfaces enable beyond another way to chat. Friedman frames the progression as a move from autocomplete to multi-agent workflows: agents that can take responsibility for work across the software development lifecycle, or SDLC. His opening slide distinguishes tools developers like, tools they love and tools that fundamentally change how they work. He places that last category ahead of the capabilities he is about to examine.

Friedman separates casual, prompt-driven software creation from enterprise development. His shorthand is “noobs versus enterprise,” but this is a distinction between uses, not a ranking of junior and senior engineers: enterprises employ juniors too. Autocomplete helped people who already knew how to develop software. Chat and agentic chat then expanded how much code people could generate, while leaving experienced reviewers with more code to inspect and no corresponding guarantee of quality.

The progression is from IDE plugins to IDE forks, then beyond the IDE itself. In the third stage, an agent receives a task and carries it through an end-to-end flow. The relevant boundary becomes the job to finish, rather than the editor in which code is written.

Friedman’s 10×, 50× and 100× development figures are illustrative aspirations for working with confidence, not measured productivity results. The substantive ambition is a change in how work is organized: delegation that does not leave the developer merely hoping the generated implementation is sound.

For a prototype, a small website or a simple game, end-to-end might mean entering a prompt and receiving a fully managed application. In an enterprise codebase, the useful unit is often smaller but more demanding: a reliable, versatile workflow that finishes a particular development job. Review and testing are central examples because they produce the evidence needed to trust a change.

There is no need to choose between workflows and agents as mutually exclusive designs. Recalling Charles’s earlier discussion of an agent creating and calling workflows, Friedman uses workflow to include agentic execution. An agent can construct a workflow, invoke one or participate in one. The requirement is that the combined system performs these jobs thoroughly and at high quality.

Initial planning and fast implementation cover only part of development. Existing software also needs bug fixes, refactoring and feature changes. Those tasks require moving quickly while preserving behavior that already matters. Testing and review must participate in development, rather than arrive as an afterthought once the implementation feels finished. Friedman describes this as a red-team role: reason like a tech lead, challenge the code and use technology suited to finding problems.

Putting an AI tool at every stage does not, by itself, connect those stages. Qodo positions itself primarily on the verification side, despite also offering generation tools, but Friedman considers even that insufficient. A useful first improvement is to shift review and testing left: bring company best practices into the writing process so the developer receives guidance before pushing, rather than learning about a predictable problem from a later review. The larger opportunity is a workflow that connects implementation and verification continuously.

Friedman redraws the development sequence with time on the horizontal axis and executability on the vertical axis. Planning is not executable. Application code comes next. In the non-TDD sequence he describes, tests follow the implementation; they are executable, but they are not application code. Review follows the tests. The resulting V separates activities that should inform one another.

To squeeze that V is to bring the activities together through communicating agents, or through one agent using tools that connect the stages. Friedman introduces Model Context Protocol, or MCP, and Agent2Agent, or A2A, as coordination references. The architectural choice can vary; the goal is to consider planning, implementation, tests and review rigorously within one connected solution.

His comparison is Wiz’s approach to cloud security. In Friedman’s telling, after roughly a decade of cloud maturity, the opportunity was to replace separate security applications for separate needs with a holistic solution. He expects a similar transition in software development: the value comes from connecting the work, not merely adding another intelligent component.

Friedman describes pushback arriving a month or two after Karpathy’s vibe-coding post. He reads Karpathy’s subsequent distinction between casual vibe code and code he professionally cares about as a quality and maintainability concern. The first recommendation he discusses is to supply context. Manually gathering that context helps, but it still leaves the developer doing the coordination work.

The remaining numbered recommendations become significant as a sequence: Friedman interprets them as a workflow, without walking through each item. Context tells the system what matters; a workflow structures how it proceeds. That workflow might connect to an agent, live inside an agent or form part of a broader development process.

An observation from another commentator sharpens the distinction: AI coding tools can be much less useful on large existing codebases than on greenfield work. Friedman uses this as a practical explanation, not a performance measurement. In a small new project, generating code may account for most of the visible job. In established software, it is the tip of an iceberg whose submerged work includes maintainability, testing and review.

Qodo’s proposed answer is a multi-agent architecture connecting code understanding, review and generation. Friedman sketches the parts relevant to the demonstration rather than enumerating the whole system:

• Code research: A dedicated agent performs deep research or deep questioning of the codebase.
• Code review: Qodo Merge is the flagship review tool.
• IDE assistance: Context and accumulated best practices return to the environment where developers write code.

He identifies Qodo Aware as the context source and says Qodo Merge collects best practices over time. Those inputs can guide generation through Qodo’s tools or another code-generation tool. The intended feedback path runs from understanding and reviewing the existing system back into producing its next change.

The newly introduced Qodo CLI expands workflow capabilities already present in the suite. Friedman also teases another release for two months later without identifying it. The demonstration belongs to the onstage soft launch; the later public launch material now mixes newer branding and package names, so it should not be treated as an exact command reference for this session.

The CLI’s attraction is its reach across the SDLC. Friedman reiterates that the release is a soft launch, with a fuller announcement expected in a couple of weeks. He points to Simon’s earlier demonstration: command-line tools can run in the background, participate in existing workflows and compose new ones without requiring the developer to keep an IDE interaction open.

The demonstration moves from ordinary conversation to reusable specialization. The CLI supports chat and calling a dedicated Explain agent. Friedman skips running Explain and instead asks how such an agent is made. His answer is to have an agent create another agent. The command slide progresses through qodo, qodo chat and qodo explain, then shows a creation request whose goal is to review uncommitted changes and put the results in a Markdown file.

The live request asks for a review agent and could include more information about its goal. With the demonstration dependent on the internet connection, initialization begins; Friedman describes MCP discovering what capabilities are available. He estimates that creating the review-agent definition will take a few minutes, versus two hours for a person, but supplies no controlled timing comparison. He allows it two minutes and continues presenting while it works.

A specialized agent gains much of its usefulness from its tools. Qodo Cover, for example, is intended to generate tests that increase coverage. It is available as open source, but the bundled agent makes it accessible without separately downloading that project. Coverage-report tools give the agent information specific to its testing job.

The command line also exposes ordinary shell operations. Logs can be written to a file, and output can be passed onward to another process. For example, the displayed chat command can be combined with Bash redirection and tee to retain terminal output while showing it:

qodo chat 2>&1 | tee qodo-session.log

Here 2>&1 sends standard error to standard output, and tee writes that stream to qodo-session.log as well as the terminal. This is the composability Friedman is pointing toward: an agent command can participate in the same process plumbing as other developer tools.

He proposes a sequence with distinct responsibilities:

1. Generate: Qodo Code produces the implementation.
2. Extend testing: Qodo Cover works specifically on increasing coverage, supplementing whatever tests the generation agent produced.
3. Review: The newly created review agent examines the result.

At this point, Friedman says the review agent has finished being created. The proposed chain passes results between stages; it does not demonstrate agents communicating with one another. A shell pipeline is composition, not automatically agent-to-agent communication.

The next possibility is hypothetical command-line support for A2A. Instead of waiting for a preceding stage’s result, agents could run in parallel and exchange information as work proceeds. This extends the earlier MCP example: connecting an agent to available tools is a different concern from enabling independent agents to communicate.

Adoption is still an open question in the room. Friedman recounts asking a group of speakers the previous day who used A2A and initially says nobody did. An audience member indicates that they use it, and he corrects himself. The exchange illustrates his limited firsthand exposure, not a survey of protocol adoption.

The concrete reasons he gives for A2A are discoverability and handshakes among agents, including agents running in the background. A2A is one protocol for that interoperability; having multiple agents does not by itself require it. The distinction is between a predetermined sequence of processes and participants that can discover capabilities and establish communication.

Returning to the completed creation task, Friedman opens the generated reviewer definition, referring to it as Merge Agent and later as Merge Review or Qodo Merge Review Agent. It contains instructions, selected tools and an output schema. He adjusts the tool configuration and temporarily removes the output schema before returning to the CLI to invoke the reviewer.

The generated agent also has a parameter for specifying what to review. Friedman invokes it without supplying additional instructions. This is the demonstration’s concrete transition: a natural-language request has produced an inspectable agent definition that can be called again. A completed review result is not shown before time runs out.

He then describes two ways to make that reusable reviewer more useful: provide organizational best practices, and specify success or failure criteria. Coverage is one possible criterion, but he gives no numeric target and does not demonstrate configuring or reaching it. An explicit coverage condition can make a workflow’s completion testable; it does not make coverage a substitute for correctness. The important step is to state what the agent must establish, rather than treating any generated response as success.

Once a workflow is callable, it can attach to pre-commit or post-commit hooks and execute automatically. That moves the agent from a tool someone remembers to ask into a repeatable part of development. The command line provides the execution point, but it need not be the only place a person interacts with the result.

Friedman returns to Simon’s demonstration: execution happened through the CLI, while content inspection used other interfaces. A CLI-driven workflow could similarly generate an interface suited to its task, such as a code-review view. His proposed “flexible IDEs” separate orchestration from presentation: automate through commands, then inspect through the interface that makes the work understandable.

The closing vision is a swarm of specialized agents with different credentials and best practices, working across specification, testing and implementation. Friedman forecasts that this future will arrive rapidly in 2025–2026. The final diagram places those development activities among agents, environment, software data and tools: confidence depends on how the participants coordinate and verify the work, not simply on how quickly one of them writes code.