Kilo’s Slack Bot Wants to Turn Engineering Chat into Shippable Code

Kilo Code, an open-source AI coding startup backed by GitLab cofounder Sid Sijbrandij, is betting that the next phase of AI-assisted software development will live inside tools engineering teams already use every day—starting with Slack. Its new product, Kilo for Slack, is designed to turn conversations in channels and threads directly into code changes, pull requests, and debugging sessions without requiring engineers to open an IDE or switch context.

The launch comes as AI coding tools draw enormous investment and attention. But instead of competing on yet another IDE plugin or proprietary interface, Kilo is positioning itself as a workflow-first, model-agnostic layer that lives across Slack, IDEs, cloud agents, GitHub, and the command line.

From bug report to pull request without leaving Slack

Kilo for Slack is built around a simple observation: the full context needed to fix a bug or implement a feature often emerges in Slack threads, not code editors. Product managers describe issues, engineers debate root causes, and stakeholders add constraints—all before anyone touches the repository.

Kilo’s Slack bot tries to act at the moment that context stabilizes. When a user @mentions @Kilo in a thread, the bot reads the conversation, pulls in relevant code from connected GitHub repositories, and either answers questions about the codebase or opens a new branch and submits a pull request. The entire interaction, including status updates, stays visible inside Slack.

A representative workflow looks like this: a product manager files a bug in a channel; developers discuss that a null pointer exception is coming from the Authentication service; instead of a human copying the discussion into an IDE and re-explaining the problem to a coding assistant, a developer posts, “@Kilo based on this thread, can you implement the fix for the null pointer exception in the Authentication service?” The bot then spins up a cloud agent, interprets the thread, applies a fix in the connected repo, and pushes a pull request.

Kilo argues this eliminates the friction of moving information between tools and reduces the number of context switches required to get from problem description to candidate solution. For teams already using Slack as the primary venue for technical decisions, the system’s value proposition is straightforward: trigger non-trivial code changes with a single message, while keeping the discussion and the implementation tightly linked.

Targeting Cursor and Claude Code’s weak spots in Slack workflows

Kilo is not entering an empty market. Tools like Cursor and Anthropic’s Claude Code are already prominent in the AI coding space, and Kilo’s launch explicitly contrasts its Slack integration with those offerings.

According to Kilo cofounder and CEO Scott Breitenother, one of the main limitations of Cursor’s Slack integration is its repository model. The integration is configured on a single-repository basis per workspace or channel. If a thread touches multiple services or repos—common in microservice-heavy architectures—users must manually switch or reconfigure which repository the integration can see. That introduces friction precisely when engineers are trying to move quickly across codebases.

On the Anthropic side, Kilo points to what it views as gaps in thread-level continuity. Claude Code’s Slack documentation describes how Claude can be added to a workspace and respond based on the surrounding conversation. However, Kilo notes that the documentation does not describe persistent multi-turn thread state or task continuity for longer workflows. Each interaction is processed based on whatever context is provided with that prompt, rather than maintaining an evolving execution state linked to a specific task or thread over time.

In contrast, Kilo claims its Slack integration can operate across multiple repositories simultaneously, maintain conversational context across extended Slack threads, and support handoffs across touchpoints: Slack, IDEs, cloud agents, and the CLI. For engineering leaders, the promise is less about any single reply being better and more about having an AI agent that can follow a task from conversation through implementation, regardless of which repo or interface the work touches.

Choosing MiniMax’s M2.1 by default—and answering security questions

One of the more unconventional decisions in this launch is Kilo’s default model selection. Instead of centering on a U.S.-based frontier model, the company has chosen M2.1 from MiniMax, a Hong Kong–listed AI company headquartered in Shanghai, as the default backend for Kilo for Slack.

That choice inevitably raises questions for enterprises that are sensitive to data sovereignty and the use of Chinese AI providers for proprietary source code. Breitenother addresses the concern by pointing to MiniMax’s recent Hong Kong IPO, which drew backing from global institutional investors including Baillie Gifford, ADIA, GIC, Mirae Asset, Aspex, and EastSpring. Kilo frames this investor mix as evidence that MiniMax is building models for a global customer base rather than a purely local market.

On the infrastructure side, Kilo emphasizes that MiniMax’s M2-series models are hosted on major “U.S.-compliant” cloud providers, including AWS Bedrock, Google Vertex AI, and Microsoft AI Foundry. MiniMax models were also featured in AWS CEO Matt Garman’s re:Invent keynote, which Kilo cites as further validation that these models are ready for enterprise workloads.

At the same time, Kilo is careful to characterize itself as model-agnostic. The company says it offers access to more than 500 models and does not lock customers into any specific vendor. Enterprise teams can select which models to use, where they are hosted, and how they align with their security, compliance, and risk requirements. M2.1 is the default, not the only option.

This default ties into Kilo’s broader thesis that the performance gap between open-weight models and proprietary frontier systems has narrowed significantly. Citing the Stanford AI Index and benchmarks such as HumanEval, MATH, and MMLU, Kilo says the gap on major general benchmarks has shrunk from around 8% to 1.7%. Breitenother notes that this statistic reflects aggregate convergence between open and closed models on those general benchmarks, not any specific “agentic coding” metric.

Kilo also points to community-driven benchmarking on LMArena, where M2.1 has achieved a number-four ranking, sitting just behind models from OpenAI, Anthropic, and Google. The company interprets this as evidence that M2.1 can compete in real-world coding workflows as judged directly by developers. For teams evaluating Kilo, the practical takeaway is that they can start with a non-U.S. default model that Kilo believes is competitive, while retaining the option to select other models that better match internal policies.

What actually happens to your Slack threads and code

For engineering and security teams, data handling is as important as productivity claims. When an AI bot is able to open pull requests directly from a conversation, the data flow—and its limits—matter.

Breitenother describes Kilo’s behavior in Slack as scoped to the specific thread where it is invoked. When someone mentions @Kilo, the system reads only that thread’s content plus basic metadata needed for context; it does not gain blanket access to the entire Slack workspace. Access is mediated by Slack’s standard permission model and the scopes that a customer approves during installation.

On the repository side, Kilo only touches GitHub repositories that teams explicitly connect via Kilo’s integrations dashboard. It does not index or scan unrelated repos. Permissions mirror what has been granted in GitHub; Kilo cannot see code beyond what the user or workspace has authorized. The company also states that data flowing through the system is not used to train models, and that the visibility of outputs respects existing Slack and GitHub permission boundaries.

The risk that concerns many teams is not just data leakage but code quality and security. If an AI agent can push code, what stops a subtle vulnerability from being merged to production?

Kilo’s answer is to keep merge control firmly in human hands. Nothing is merged automatically. Pull requests opened by the Slack bot still pass through the organization’s existing review workflows, policy checks, and approval rules. In addition, Kilo can automatically run its own code-review feature on AI-generated pull requests, flagging potential issues or security concerns before a developer even starts a manual review.

In practice, this means Kilo is positioning itself as an aggressive automation layer for generating and wiring up changes, not as an autonomous deployment system. For engineering leaders weighing risks, the model is closer to “AI that prepares PRs within existing guardrails” than to “AI that ships code on its own.”

The open-source paradox behind Kilo’s business model

Kilo Code takes an “open core” approach that many developer-tool companies are experimenting with. The company’s IDE extension—where developers can interact with Kilo in a more traditional, editor-centric way—is fully open source under an Apache 2.0 license. By contrast, Kilo for Slack is a paid, hosted product.

For a 34-person startup, this raises an obvious strategic question: what prevents a large competitor, or even a sophisticated customer, from forking the open-source components and replicating the product?

Breitenother’s answer is that the differentiator is not the codebase alone but the surrounding operational stack and experience. In his view, a rival could fork the repo overnight, but they would still lack the infrastructure required to safely orchestrate agentic workflows across Slack, GitHub, IDEs, and cloud agents for many teams and repositories at once. Operating that orchestration at scale—while meeting enterprise expectations for reliability, observability, and controls—is where Kilo believes its real moat lies.

He links this approach to a pattern seen in other successful open-source companies: the open core builds adoption and trust among developers, while the paid, hosted service provides the convenience, uptime guarantees, and continuous improvements that most organizations are willing to pay for. In that framing, customers are not paying for access to code they could theoretically host themselves; they’re paying for “a system that works every day, securely, at scale.”

The company’s funding story underscores that investors are buying into this model. Kilo raised $8 million in seed funding in December 2025 from firms including Breakers, Cota Capital, General Catalyst, Quiet Capital, and Tokyo Black. Sijbrandij, now GitLab’s board chair after stepping down as CEO in 2024 for health reasons, contributed early capital and remains involved in strategy.

GitLab itself has a limited but notable contractual tie to Kilo. In a recent SEC filing, GitLab disclosed that it paid Kilo $1,000 for a right of first refusal on any acquisition offer Kilo receives before August 2026, giving GitLab 10 business days to respond if a third party moves to acquire the startup. When asked about non-compete concerns given GitLab’s own AI investments, Breitenother’s reply was succinct: there are no non-compete issues, and Kilo views its approach as fundamentally different.

Can a 34-person team win the AI integration race?

Beyond the Slack integration itself, Kilo is entering what some observers call the “vibe coding” market—a term popularized by OpenAI cofounder Andrej Karpathy in 2025 to describe using large language models to write and modify code based more on intent and experimentation than rigid specifications. This space has already produced eye-catching numbers.

Microsoft CEO Satya Nadella said in 2025 that AI now writes about 30% of Microsoft’s codebase. Google spent $2.4 billion acquiring senior staff from AI coding startup Windsurf. Cursor’s November funding round valued that company at $29.3 billion. Against that backdrop, Kilo’s $8 million seed round looks modest, and its main competitive threat may come less from peers and more from frontier labs like OpenAI and Anthropic themselves.

Both OpenAI and Anthropic are building increasingly deep coding integrations and have vastly more resources. Breitenother argues that Kilo’s differentiation is architectural rather than model-based. In his view, the long-term moat in AI coding won’t be raw compute or being first to release a Slack agent; it will be the ability to integrate AI into real engineering workflows that cut across tools, repositories, and environments.

He highlights three dimensions where Kilo aims to stand out:

Workflow depth. Kilo is designed to operate across Slack, IDEs, cloud agents, GitHub, and the CLI with persistent context and execution. Even if OpenAI or Anthropic ship powerful Slack-native agents, those agents remain fundamentally model-centric. Kilo is trying to be workflow-centric, with state and task context that span multiple tools.

Model flexibility. Because Kilo is model-agnostic, organizations are not forced to commit to a single frontier model or vendor roadmap. That kind of multi-model posture is structurally more difficult for companies whose primary business is their own model usage.

Platform neutrality. Kilo is not attempting to pull developers into a new, closed ecosystem. Instead, it integrates with tools teams already use, especially Slack and GitHub, and lets engineers continue to work through familiar interfaces.

This strategy aligns with a broader shift in the AI coding ecosystem. The first generation of tools mainly aimed to prove that LLMs could generate usable code. The current wave is grappling with integration: fragmented context across Slack threads, GitHub issues, IDE windows, and terminal sessions; mixed-model environments where teams use different providers for different tasks; and complex compliance regimes shaping where data and models can live.

Kilo is betting that whoever solves this integration problem best—meeting developers where they already are, preserving thread-level context, and respecting existing security and governance structures—will be positioned to win, regardless of who owns the top benchmark numbers. The company’s Slack integration is an early, opinionated move in that direction.

Kilo for Slack is now available for teams with Kilo Code accounts. Setup is straightforward: connect GitHub repositories in Kilo’s integrations dashboard, install the Slack app, and begin mentioning @Kilo in any channel where the bot has been added. Pricing is usage-based and tracks the rates of whichever model a team selects.

Whether a 34-person startup can defend that position against competitors with billions in capital remains uncertain. But Kilo is clearly aligning around a specific thesis: in AI-assisted development, the hardest problem is not generating code; it’s wiring AI into the messy, human workflows where engineering actually happens. If that’s correct, then turning chat into shippable code may be less a novelty than a preview of how future teams will ship software.