An assistant that is a plugin, not a destination

Baidu Comate is an AI coding assistant built on Baidu's own language model, trained on the company's accumulated data about real development work as well as on public open-source code. The delivery decision is the one that matters most: it arrives as a plugin for the integrated development environments people already use — Visual Studio Code, IntelliJ IDEA, PyCharm, GoLand, WebStorm, CLion, PhpStorm, Android Studio among them — rather than as a separate application with its own editor.

That choice is not cosmetic. A coding assistant is only useful if it can see the context in which the code is being written, and a separate editor has to be told everything from scratch. Living inside the existing environment means the assistant inherits the open files, the project structure and the cursor position for free, and the developer keeps their shortcuts, their debugging setup and their habits.

Completion and generation are different promises

There are two things a tool like this can do, and they are often confused. Completion suggests the next token, the rest of a line, the body of a block you have just opened: it is a continuation of what you are already writing, and its value comes from being right about the immediate future. Generation produces a whole function from a description, and its value comes from being right about intent.

Both rest on the same mechanism, which is prediction over a context window, and both share the same failure: the model is fluent about things that do not exist. A completion that invents a method name on a library it half remembers is worse than no completion, because reading it costs attention and testing it costs time. The habit that makes these tools worthwhile is not accepting more suggestions, it is reading them.

Writing the comment first is the underrated workflow

Generating code from a comment sounds like a party trick and is arguably the most disciplined way to use a model like this. A comment that states what a function should do, what it takes and what it returns is a specification in miniature; writing it first forces the thinking that usually gets skipped, and the generated body becomes a draft that can be checked against the sentence above it.

Comment-driven generation has a second advantage that is easy to miss: the specification survives. Later readers get the sentence that explains the intent, not only the code that happens to implement it. Whether the body was written by a person or suggested by a model matters much less than whether the sentence above it is true.

Unit tests are the best possible target for generation

Of everything this class of tool produces, tests are the most defensible. The reason is structural rather than technical: a test is executable and it has a verdict. A suggested function can be plausible and wrong and nobody notices for a month; a suggested test either runs green or it does not, and either way you have learned something within seconds.

Being able to generate tests for a single function, or in batches across a module, changes the economics of a task that is chronically skipped. Tests are the first thing dropped under deadline pressure because they are tedious and their absence is invisible until much later. A tool that produces a first draft — coverage of the obvious cases, the boundaries, one or two deliberately awkward inputs — turns an hour of tedium into ten minutes of review and extension. The review part is not optional: generated tests often assert what the code does rather than what it should do, which is a description of the bug once the bug exists.

Refactoring suggestions and the equivalence problem

The tool can identify what the trade calls bad smells — functions that became too long, nested conditionals that could be flattened — and propose a restructure, for instance splitting one long function into several with clear names. As a way of seeing the shape of a problem, this is genuinely useful: a long function is hard to read precisely because its parts are not named.

The risk is worth stating plainly. A refactor is only correct if behaviour is unchanged, and a model has no way to guarantee that. It can produce code that reads beautifully and subtly alters an edge case, particularly around error handling, null values, and the order in which side effects happen. That is why the pairing that works is refactoring plus tests: with a suite that fails loudly, a restructure is a proposal that can be checked in seconds; without one, it is a rewrite disguised as tidying.

Reading code is the other half of the job

Explaining a function, either whole or from a selection, addresses a cost that is easy to underestimate: understanding code written by somebody else, or by yourself six months ago. The explanation is not the truth about the program — it is a hypothesis about it, and the program is the truth — but a hypothesis written in ordinary language is exactly what a person needs before deciding where to look.

The technical question answering works the same way. Asking about an error message or an API returns something immediately readable, which is an improvement on the older loop of searching, opening four tabs and reconstructing an answer. The caution is unchanged: answers about library behaviour are the most confidently wrong kind of answer, and the documentation is still the authority.

Breadth of language support is a practical matter

Support for well over a hundred languages, from C, C++, Java, Python, Go, PHP and Rust on the back end through HTML, JavaScript, CSS and the various stylesheet and template dialects on the front end, and on to Objective-C, Kotlin and Swift for mobile work, is not a marketing line. Most real projects are not monolingual: a repository contains the application, the build scripts, the configuration, the database migrations and the documentation, in four or five different syntaxes. An assistant that only speaks one of them is an assistant that keeps disappearing.

The honest caveat is that breadth and depth trade off. Performance is strongest on the most common languages, simply because that is where the training data is densest, and suggestions in a rarely used dialect should be read with more suspicion than suggestions in Java.

Where it fits, and what it does not fix

The tool addresses the mechanical parts of writing software: producing a first draft, filling in boilerplate, writing the tests nobody wants to write, explaining something unfamiliar. It does not decide what the program should do, and it does not carry responsibility for what it produces. Two consequences follow. Everything it emits has to be reviewed as if a stranger wrote it, because a stranger did; and code that arrives from a model deserves a question that code from a colleague rarely gets — where did this come from, and what licence does it carry. That question matters in any organisation that cares about provenance, and it is the one thing an assistant cannot answer for you.