DEV Community: Dave Kurian

Lovable Raises $330M Series A to Scale AI-Powered No-Code Platform

Dave Kurian — Tue, 02 Jun 2026 09:03:04 +0000

Lovable’s $330M Series A at a $6.6B valuation is the kind of milestone that rarely happens this early — especially for an AI platform pitching that its “vibe coding” conversation-first builder can give non-technical users software superpowers. That sheer capital, led by heavyweight venture arms Capital G and Menlo Ventures, signals more than optimism — it’s a hard bet on a paradigm shift where app-making becomes as common as editing a doc, and the winners are the infra players, not just the models.

[[IMG: Lovable team in Stockholm office, schematic showing natural language converting into app code]]

What is Lovable’s $330M Series A funding and who led it?

Lovable secured $330 million in Series A investment in December 2025, led by Capital G and Menlo Ventures for a total valuation of $6.6 billion (CNBC Disruptor 50). This brings Lovable’s total funding to $552.5 million — a number that stands out given the company was founded in 2023.

Capital G (Alphabet’s growth arm) and Menlo Ventures both specialize in fueling high-velocity SaaS and AI efforts with broad market potential — so their leading role isn’t an accident: the bet is that Lovable’s architecture enables the next wave of software democratization. Few AI SaaS companies attract over half a billion dollars before a Series B; even OpenAI and Cohere’s early funding rounds were outpaced by this raise. That gives Lovable one of the largest war chests for an AI-native coding tool built for the mass market, not just engineers.

In an AI software market swimming with half-steps and wrappers, a $330M Series A is a sharpened signal: the real gold is platforms enabling new classes of users, and the capital backs going for scale now, not later.

How does Lovable’s AI-powered vibe coding platform work?

Lovable’s platform lets users build apps by describing their purpose, interface, and data flow in ordinary language through prompted chat. The engine then parses these natural language interactions and scaffolds a working application, presenting suggestions rather than requiring traditional manual coding, all in real time.

The core idea: instead of expecting users to understand frameworks or syntax, Lovable interprets intent — “build me a time-tracking tool that emails CSV logs every Friday” — and iterates interactively, with the user refining via conversational feedback (think: “Let’s add a dashboard” or “Make this mobile-friendly”). There’s no hard wall; every prompt is a building step.

Underneath, Lovable’s “vibe coding” concept uses purpose-built LLMs that stitch together scaffolding, code generation, UI wireframes, and integration glue based on ongoing conversation. That moves well beyond simple code-completion or no-code block arrangement — it’s a stateful dialog that refines both business rules and UX. The user doesn’t see the code unless they ask for it. Suggestions appear (“Would you like to connect to Google Sheets?”), guiding even absolute beginners forward.

Founded by Anton Osika and Fabian Hedin in Stockholm in 2023, Lovable isn’t positioning as just another UI-builder or static template engine — it’s a play for AI-powered, fully interactive app synthesis. With a mission of making software creation as accessible as natural conversation, every piece of Lovable’s product design aims to eliminate handoffs and the cognitive load required to build even relatively complex logic.

Why is Lovable’s platform important for non-technical users?

The fundamental win: non-technical users can finally move from brainstorm to working product without being bottlenecked by engineering bandwidth, tutorials, or learning curves. For anyone who’s ever been told to “fill out a requirements doc and wait,” Lovable’s conversational enable transforms how ideas become deployable.

This is especially relevant for business units and independent creators who don’t get a prioritization slot on the dev backlog. Enterprise workers, operations leaders, sales, HR, education — all stand to benefit. Now, they can describe what they want (“I need a notification when inventory drops below 10, connected to our Slack”) and see it built, tested, and iterated within the hour.

Lovable is targeting both the consumer (“just ship your side project without code”) and enterprise market (“let every team automate their workflows without waiting on IT”). This dual focus supports runway for mass adoption, drawing in everyone blocked by traditional software gatekeeping.

Recent growth and funding make clear the ambition: not just a playground for hobbyists, but a durable SaaS infra layer to speed up the slowest parts of knowledge work — delivering working apps wherever descriptions exist. In the near term, expect a dramatic expansion of the addressable software maker population, with business units accelerating their own tools rather than purchasing one-size-fits-none SaaS products.

How will Lovable use the $330M Series A funding?

Lovable lists three concrete priorities for deploying its new capital:

Accelerate team hiring across AI research, product, and customer success
Drive feature milestones and scale platform reliability for enterprise demand
Expand go-to-market for both consumer and enterprise segments

The capital will allow Lovable to compete for top LLM engineering talent against the largest AI labs, actively iterate on product stability and vertical features, and expand its devops and support capabilities as user base surges. Expect a strong focus on horizontal scalability, LLM safety/reliability improvements, and AI-human feedback cycles making even more nuanced suggestions for app-building edge cases.

Enterprise onboarding and compliance support are clear near-future targets, as Lovable aims to become not just a playground, but the backbone powering business-critical processes (with an API, admin tools, audit logs, and permission controls to match).

In the crowded AI builder field, getting to broad, reliable support for real-world workflows is capital- and talent-intensive work. This raise switches Lovable from “interesting toy” to “funded for industrial reliability” overnight.

What does Lovable’s valuation and funding round mean for the AI industry?

A $6.6B valuation for a pre-Series B AI startup isn’t just a sign of a hot market — it’s a signal that investors see major value in generation-over-instruction platforms, where builders don’t need to touch code or even drag blocks.

Compared to other recent funding rounds for no-code/low-code or LLM-based builder tools, Lovable’s Series A is an order of magnitude larger. (Even previously well-funded platforms like Bubble or Airtable haven’t broken this valuation/funding ratio at such an early stage.) When investors like Capital G (Alphabet’s venture arm) and Menlo Ventures pile in this quickly, the message is clear: the next phase of enterprise digitization will hinge less on who has the best models and more on who can surface those models to a new class of users.

Lovable’s approach — going for scale, broad language understanding, and enterprise reliability — positions it as one of the leading infra rails for the coming wave of “AI-extended” knowledge workers, not just solo app-makers. The valuation sets a benchmark for how quickly AI builders-for-builders can leapfrog their human-in-the-loop, instruction-heavy competitors.

For founders and technical leads watching the space: funding velocity of this magnitude points to open opportunities in AI-powered abstraction, integration, and workflow composition layers. The user demand is real — the capital will go to the players who abstract away the brittle points of current no-code and SaaS builder stacks.

How can non-technical users start using Lovable’s platform today?

Getting started is as simple as signing up at lovable.dev. There’s no steep onboarding: once you’re in, you’re greeted by a chat-style UI that prompts, “What do you want to build today?” The process is entirely conversation-driven:

Start with a goal: Type a plain-English description (“Build a personal expense tracker with a dashboard and weekly email report”).
Follow AI-led suggestions: The platform recommends integrations, features, or next steps in real time (“Would you like to import data from a spreadsheet?”).
Refine via conversation: As you reply, the app’s components, visuals, and backend logic evolve automatically. You handle exceptions (“Connect to PayPal for payments”) as conversational follow-ups.
Deploy: After a few minutes of dialog, Lovable publishes your app with a shareable link; export options are available for more advanced use.

Public demo accounts are available, and both free trials and enterprise onboarding are supported — with higher limits and access to enterprise-control features (e.g., SSO, audit logs) on request.

No setup or IDE to configure. No “learn our builder syntax”-type manual. It’s just chat, suggestion, and ship.

For those used to classic SaaS onboarding, the difference is night-and-day in time-to-first-productivity.

[[IMG: Lovable platform chat interface with a simple business app being specified and generated step-by-step]]

The backbone layer for a shifting toolchain

Lovable’s $330M Series A, at a $6.6B valuation, isn’t just a capital headline. It’s a functional inflection where the “describe, don’t code” model is now funded at the scale needed to build durable software rails beneath the LLM/model churn. For builders, that means a faster path from idea to working app for anyone — not just engineers. For technical teams, it means the glue code and vertical SaaS explosion is just getting started, and the platforms abstracting away “how” in favor of “what” will become the critical productivity multiplier. New AI models, frameworks, and APIs will keep coming — but the stack that can talk to both non-technical users and legacy infra is the one that endures.

Same component, web + mobile — the architecture behind @otfdashkit/ui

Dave Kurian — Tue, 02 Jun 2026 07:17:58 +0000

The dream of "write once, run on web + mobile" has burned a lot of people. Cordova /
Ionic / Native Script / React Native Web / Flutter for web — each generation tries to make
the platforms agree, and each generation pays a tax somewhere.

OTF doesn't try to dissolve the difference. It does something narrower: share the
design system across web and mobile, but keep the implementation native on each side.

Same Card component name, same prop intent. Different file, different render path. One
mental model.

This post is about how that's structured, and where it bends.

The two packages

@otfdashkit/tokens       — design tokens (CSS variables + JS object)
@otfdashkit/ui           — web implementation (Radix + Tailwind)
@otfdashkit/ui-native    — native implementation (Tamagui)

tokens is the seam. It exports the same values in two formats:

web.css — CSS custom properties (--background, --primary, …)
native.ts — JS object consumed by Tamagui's createTamagui

When you change --primary in theme-warm, both web and native pick it up. There's
exactly one source of truth for color, spacing, radius, motion.

Why two implementation packages, not one

We tried unified. It went badly.

We tried React Native Web — running RN components in a browser via react-native-web. It
works, but the bundle is huge (you're shipping RN's entire layout engine to the browser),
the styling story is awkward (StyleSheet.create is a worse fit than Tailwind for web), and
the animation primitives don't map cleanly to web idioms.

We tried Tamagui-everywhere — Tamagui generates its own web output from the same source as
its native output. Closer to the dream, but Tamagui's compile-step adds friction to web
projects that don't need it, and the web-side ergonomics aren't as good as Radix + Tailwind
for our use case (heavy keyboard accessibility, nested overlays, etc.).

So we split. @otfdashkit/ui uses Radix + Tailwind, optimised for the web. @otfdashkit/ui-native
uses Tamagui, optimised for native. They share names (where the abstraction is honest)
and tokens (always).

The shared name policy

Where the abstraction is honest, the names match:

Component	Web	Native
`Card`	`<Card>` from `@otfdashkit/ui`	`<Card>` from `@otfdashkit/ui-native`
`Avatar`	`<Avatar>` + parts	`<Avatar>` + parts
`Input`	`<Input>`	`<Input>`
`Button`	`<Button>` (variant prop)	`<Button>` (variant prop)
`Tooltip`	`<Tooltip>` + parts	`<Tooltip>` (long-press on native)
`Tabs`	`<Tabs>` + parts	`<OtfTabs>` (prefixed to avoid Tamagui conflict)

Where the abstraction is not honest, the names diverge:

Web <Sheet> (right-slide modal) → Native <BottomSheet> (drag-up sheet, snap points, different physics)
Web <Drawer> → Native <ActionSheet> (iOS-style action picker) or <BottomSheet>
Web <Toaster> (DOM-mounted) → Native <OtfToastProvider> (RN context-mounted)

This is deliberate. A named abstraction that papers over a real platform difference will
break. Better to keep names different where the implementations are different.

Tokens that work on both sides

The tokens package emits two outputs from one source.

Web (CSS custom properties):

/* @otfdashkit/tokens/web.css */
:root {
  --background: 0 0% 100%;       /* HSL components — multiplied through hsl() at use site */
  --foreground: 220 8% 12%;
  --primary:    212 100% 47%;
  /* ... */
}
.dark {
  --background: 220 12% 7%;
  --foreground: 0 0% 96%;
  /* ... */
}
.theme-warm {
  --primary: 28 100% 56%;        /* Override single tokens to retheme */
  /* ... */
}

Native (JS):

// @otfdashkit/tokens/native.ts
export const tokens = {
  color: {
    background: 'hsl(0, 0%, 100%)',
    foreground: 'hsl(220, 8%, 12%)',
    primary: 'hsl(212, 100%, 47%)',
    // ...
  },
  // ...
}

export const themes = {
  light: {
    background: tokens.color.background,
    foreground: tokens.color.foreground,
    primary: tokens.color.primary,
    // ...
  },
  dark: {
    background: 'hsl(220, 12%, 7%)',
    // ...
  },
}

Both come from the same themes.ts source object that's transformed into CSS or JS during
the package build.

Charts: the recharts problem

Charts are the place where we deliberately broke "same name, same place". @otfdashkit/ui
exports BarChart, LineChart, AreaChart, etc. — wrappers around recharts. There is no
equivalent in @otfdashkit/ui-native, because recharts doesn't run on RN.

Native charts in our kits use react-native-svg directly with custom tokens. They look
similar to the web charts but their API doesn't match. We considered shipping a thin abstract
layer to make them match, but the SVG-direct approach is honest and the abstraction would
have leaked the moment we needed dual-axis or interactivity.

Theming with one switch

Both web and native read from the tokens package. Switching themes is one mechanism on each:

Web: swap a class on <html>:

document.documentElement.className = 'theme-warm dark'

Native: swap a Tamagui theme prop:

<Theme name="dark">
  <App />
</Theme>

The kits both wrap this in a useThemeColor() hook + <FloatingThemePicker> component so
the user-facing UX is the same: tap the palette icon, pick a theme, both web and native
re-render to match.

What we gave up

This split costs you two things:

Two implementations to maintain when adding a new component. A new Banner ships
on web first. The native side gets it later (or never, if it's not needed natively).
~80% of components are on both sides. ~20% are platform-specific (e.g. Marquee is web-only,
OnboardingCarousel is native-only).
Per-platform mental load when reading the kit. A developer who's only on web reads
@otfdashkit/ui and ignores @otfdashkit/ui-native. A developer who's on both reads both.
The kits make this clearer by structuring kits/<name>/ consistently — same hooks shape,
same Hono routes shape, same CLAUDE.md template — so cross-platform fluency comes from
the kit's structural conventions, not from a unified component layer.

What we got back

In return:

Web bundle stays small. No RN engine in the browser. Vite tree-shakes the unused
primitives. The SaaS Dashboard kit's prod bundle is ~180 KB gzipped including all of
@otfdashkit/ui.
Native feels native. Tamagui's per-platform optimizations (Skia for animations on
iOS, Reanimated worklets, native gesture handler) all ship through. No layout-engine
emulation tax.
Theming is a class swap. No re-renders, no provider changes, no animation glitches.
Both web and native pick up token changes immediately.
Each side stays idiomatic. Web devs see Radix + Tailwind. Native devs see Tamagui.
Neither has to learn the other to be productive on their side.

The architecture in one diagram

                ┌───────────────────────────┐
                │   @otfdashkit/tokens      │
                │  ─ themes.ts (source)     │
                │  ─ web.css (output)       │
                │  ─ native.ts (output)     │
                └─────────┬─────────────────┘
                          │ imports
            ┌─────────────┴─────────────┐
            │                           │
    ┌───────▼─────────┐         ┌───────▼─────────┐
    │ @otfdashkit/ui  │         │@otfdashkit/      │
    │ Radix + Tailwind│         │   ui-native      │
    │ Web only        │         │ Tamagui + RN     │
    └───────┬─────────┘         └───────┬─────────┘
            │ used by                   │ used by
    ┌───────▼─────────┐         ┌───────▼─────────┐
    │ SaaS Dashboard  │         │  Fitness Kit    │
    │ Vite + Hono     │         │ Expo + Hono     │
    └─────────────────┘         └─────────────────┘

Same theme. Same names. Different files. One mental model.

Try it

The conventions live in the Tokens overview,
the Components overview, and the
Native components overview. The kits at
saas.otf-kit.dev and fitness-preview.otf-kit.dev
are the canonical implementations.

If you're going to ship cross-platform, you have to decide what you're sharing and what
you're not. We share design — colors, spacing, names, vibes. We don't share implementation.
That single decision dropped most of our cross-platform pain.

How to build cross-platform templates AI coding tools actually respect

Dave Kurian — Tue, 02 Jun 2026 07:17:57 +0000

Watch any AI coding tool — Claude Code, Cursor, Antigravity, Lovable, Aider, Continue —
work inside an unfamiliar codebase for ten minutes, and you'll see the same three failure
modes:

It invents conventions that don't exist ("here's a new utility I made up because I couldn't find an existing one").
It ignores conventions that do exist ("I see you use TanStack Query everywhere, but I'll use a fresh useEffect for this fetch because the prompt didn't say not to").
It mistakes scaffold for product ("I see you import from @/components/ui/button — so I'll create a new component at @/components/MyButton.tsx").

Each failure has the same root cause: the codebase isn't legible enough to a model that
hasn't seen it before. The fix isn't to switch models; it's to write code AI models
can read.

Below are the conventions we've landed on while building the OTF SDK and the kits that ship
on top of it. They're not opinions — every one came from watching an AI tool fail and asking
"what would have made this clearer?"

1. One file, one component, one idea

The biggest thing we changed: every component sits in its own file with no clever
inheritance, no index.ts re-exports inside a component folder, no shared base classes.
A model that opens Button.tsx should see the entire button.

// packages/ui/src/primitives/button.tsx — entire file is ~80 lines
export const buttonVariants = cva(...)
export const Button = React.forwardRef<HTMLButtonElement, ButtonProps>(...)
export type ButtonProps = ...

Compare to a file that re-exports from three other files: an AI looking at the import
from '@otfdashkit/ui' has to follow chains to know what Button actually is. With our
flat layout, the answer is a single file read.

2. Naming carries meaning

Names are the cheapest documentation. We invest hard in them:

useCreateProject — "this is a TanStack Query mutation hook for creating a project"
useProjects — "this is a TanStack Query query hook for the list"
<Stat> — "single-purpose stat tile, not a generic card"
<Persona> — "avatar + name + role row, not a generic user list item"

When an AI sees useCreateProject, it doesn't have to read the file to know it returns a
useMutation result. It can call mutate / mutateAsync confidently because that's what
the name implies.

3. Patterns live in the file system, not in your head

Every recurring pattern in the kit gets one canonical implementation that reads like a template:

Hook shape → src/hooks/useProjects.ts (the optimistic-update template)
Hono route shape → server/routes/projects.ts (CRUD template)
New screen shape → step-by-step in CLAUDE.md ("create file at src/pages/..., wrap in <FadeIn>, add to router")

When a user asks Claude "add a tasks endpoint", Claude reads CLAUDE.md, finds the route
shape, copies projects.ts, and adapts. No invention.

4. The AI config file is non-optional

Every kit ships:

CLAUDE.md — for Claude Code
.cursorrules — for Cursor
AGENTS.md — for Antigravity / agent-mode editors

They're hand-maintained right now. They share a structure:

Stack table — what tools and at what versions
File map — top-down where things live
Patterns — 5-10 lines of code per recurring shape
Conventions — strict TypeScript, Tailwind tokens only, no comments unless // Why: ...
Deploy — exact command

Without this, opening the kit in Claude Code and asking "add a new screen" produces something
that almost-works but uses a different naming convention than the rest of the codebase.

5. Tokens, not hex

We never put a hex color outside the tokens package. Every component reads --background,
--primary, --card, etc. — variables defined by @otfdashkit/tokens.

This sounds like a cosmetic choice. It isn't. When an AI asks "make this button red" and
the codebase has hex everywhere, the AI guesses a hex. When the codebase has only tokens,
the AI either asks ("which red — destructive?") or reads the token file and picks
hsl(var(--destructive)). Either is better than a hardcoded color drifting into the
codebase.

We enforce this with @otfdashkit/eslint-plugin-otf-design — it lints out hex literals and
inline style={{ background: '...' }} outside the tokens package.

6. Strict types are AI ergonomics, not just code quality

We turned on strict and noUncheckedIndexedAccess. Every prop is typed. Every hook return
is typed. No any, no as casts unless commented.

The reason: when an AI tool generates a call like useProjects().data.find(p => p.title),
TypeScript catches the missing null check at edit time. The AI sees the error and adapts.
Without strict mode, the bug ships.

7. Comments only for why, never for what

Almost every comment in the OTF kits starts with // Why: or doesn't exist. We don't have
"// fetch the user" above const { data } = useUser() — that comment is just noise. A model
reading the file already knows it fetches the user.

But this:

// Why: Tamagui's defaultConfig pins every weight slot to 300 (thin), which makes
// <H1> headings render drastically lighter than `Text fontWeight=700` elsewhere —
// visually inconsistent. We override only the weight ramp via createFont.
const headingFont = createFont({ ... })

— this is gold for an AI tool. It encodes a design decision that's not derivable from the
code alone. If someone later asks Claude "should we drop this createFont override?", Claude
reads the comment and pushes back: "no, removing this would regress the heading rendering".

8. The deploy script is in the repo

Every OTF kit has a scripts/deploy-railway.sh that owns the deploy. The hook in our
.claude/hooks/check-deploy-script.sh blocks raw railway up so AI tools can't reinvent
the deploy flow.

The script:

Sources .env
Links to the right Railway project + service
Runs railway up --detach --ci
Restores anything it changed via trap

When Claude is asked to deploy, it runs the script. It doesn't construct its own railway up
invocation that might miss the env-source step or the trap. Convention beats configuration.

9. `lessons.md` saves you from rediscovering the same fix

Every time we hit a non-trivial bug — Metro can't resolve a workspace package, dual-React
crashes inside a webpack bundle, Tamagui's peerDeps don't auto-install — we append a lesson
to docs/lessons.md:

## Symptom: `Unable to resolve "@otfdashkit/ui-native"` from a kit

**Cause**: Metro doesn't follow workspace symlinks across the monorepo by default
**Fix**: `npm install --install-links` in the kit's directory before `bun dev`
**Reference**: lessons.md ~line 375

Our master AGENTS.md has a hard rule: before reaching for a custom resolver / Metro config /
plugin, grep docs/lessons.md for the symptom. If it's there, use the documented fix.
Don't rebuild from scratch.

This rule applies to AI agents too. When Claude hits "Unable to resolve" for the third time
in three months, it grep's lessons.md, finds the fix, applies it, and doesn't rebuild a
metro.config.js from scratch.

What this gets us

Watch a Cursor session in a kit set up this way. The user types "add a payments screen with
a Stripe checkout button". Cursor:

Opens .cursorrules, sees the "When you add a screen" pattern
Reads src/pages/home/dashboard.tsx to copy the structure
Reads src/hooks/useProjects.ts to copy the optimistic-update shape
Reads server/routes/projects.ts to copy the route shape
Generates the new files, all naming-consistent with the rest of the codebase
Suggests adding STRIPE_PUBLISHABLE_KEY to env

No invented utilities. No hex colors. No new naming convention. The output looks like the
existing codebase wrote it — because that's what was specified.

What's coming

Phase 6 of the OTF roadmap ships @otfdashkit/ai — a CLI that takes one otf.config.ts and
generates CLAUDE.md, .cursorrules, AGENTS.md, and lovable.md from a single source.
Until then, we hand-maintain.

If you're starting a project from scratch, lifting these conventions wholesale will save you
weeks of "why is the AI making things up" friction. If you want a working example, the
SaaS Dashboard kit and the
Fitness & Wellness kit are the canonical implementations.

JetBrains open-sources Mellum2 to challenge third-party API limitations

Dave Kurian — Tue, 02 Jun 2026 07:05:27 +0000

JetBrains’ Mellum2 open source coding model is a real step-change: a 12B-parameter, on-premises AI infrastructure model, shipped open from day one. This isn’t a warmed-over code completion tool — Mellum2’s speed, scope, and native private-deployment break new ground for agentic AI. On March 25, 2025, JetBrains announced Mellum2 with honest ambitions: go where API-locked models like Claude Code never will. For teams serious about AI infrastructure, not just code suggestions, this changes the map.

Mellum2 vs Mellum: how does the new model actually differ?

Mellum2 is not just “Mellum, scaled up.” The difference is structural. Mellum (late 2024) was a proprietary 4B-parameter model, delivered as a code completion engine for JetBrains IDEs — and eventually open-sourced in April 2025. Mellum2 multiplies the capacity (12B parameters), but the leap is in mandate: from single-task autocomplete to a practical infrastructure brain built for multi-agent AI systems.

Here’s what actually changes:

Parameter scale: Mellum2: 12B (with Mixture-of-Experts, see below). Original Mellum: 4B.
Capabilities: Mellum did code completion, period. Mellum2 was designed to coordinate sub-agent tasks, compress context for retrieval-heavy pipelines, and route queries across models.
Open from launch: Mellum2 shipped open-source “day one”, erasing the window between closed beta and broad adoption that limited “early Mellum.”
Variant support: Mellum2 ships base, “instruct,” and “thinking” models — the last capable of explicit reasoning steps, covering agentic requirements beyond simple codex tasks.

From JetBrains’ own official announcement: "Mellum2 ... runs inference on infrastructure teams control themselves."

Takeaway: Mellum2 is built for the agentic AI layer, not just for writing code faster — a mandate shift as much as a scale jump.

Why Mellum2 actually enables on-premises AI — where Claude Code cannot

Most codegen AIs, including Anthropic’s Claude Code, demand third-party APIs. You send your codebase or context “to the cloud," process happens off-premises, and the outputs trickle back. For some orgs, this is fine; for regulated or privacy-minded infrastructure teams, it’s dead on arrival.

Mellum2 is open source, designed to run entirely on your hardware — no API calls, no vendor lock, no forced network hops. This enables:

Private, air-gapped deployments: Ship Mellum2 onto an internal cluster, leave the firewall closed.
Guaranteed data residency: Source never leaves your racks. No shared cloud cache, no cross-border risk.
Latency and control: The Mixture-of-Experts setup means only 2.5B of the 12B parameters go active per-token, keeping inference snappy enough for chained orchestration in high-frequency agent workflows.

In infrastructure overlays — routing, retrieval pipelines, delegated (“sub-agent”) jobs — the round-trip time alone often kills any benefit with a cloud-only model. Mellum2 is tailored for these workloads, where “close to the metal” wins over generality.

Security and compliance pressure, especially in finance, bio, and critical infrastructure, make this a must-have: Mellum2 lets you build agentic AI with zero third-party exposure.

Takeaway: Mellum2 is not just faster on-prem — it’s actually viable there, which API-locked models are not.

How to deploy and use Mellum2 now in real engineering stacks

Ready to run it? Mellum2’s open-source stack and local mode mean you’re not waiting for a commercial host. Here’s your starter workflow:

Get the model files:

JetBrains releases Mellum2 (base, instruct, thinking) under an open license. You’ll need enough disk for a 12B model and RAM/GPU for your preferred throughput. (Real file names/links depend on the release, source link above.)
Run local inference:

Standard practice is using a serving engine like llama.cpp or vLLM, but adapt for Mellum2-specific quirks if needed. Example launch (assuming vLLM and CUDA):

   vllm-server \
     --model /models/mellum2-instruct \
     --dtype float16 \
     --gpu-memory-utilization 0.9

Adapt --model path, dtype, and memory flags to your hardware.

For an instruct-mode endpoint, ensure serving the right variant.

Integrate agentic workloads: For developers orchestrating sub-agents (e.g., task routing, context caching), plug Mellum2 at the coordination layer. Use it for:

Code completion and review within your IDE
Retrieval compression for answering questions over large docs (indexing pipelines)
Sub-agent management: Have Mellum2 broker, break down, and sequence jobs in your own job-queue system.

Here’s a simple Python client using OpenAI API compatibility (assume Mellum2 server running locally):

   import openai
   openai.api_base = "http://localhost:8000/v1"
   openai.api_key = "sk-local-"

   resp = openai.ChatCompletion.create(
       model="mellum2-instruct",
       messages=[
           {"role": "system", "content": "You are an expert code routing assistant."},
           {"role": "user", "content": "Decompose the following task into sub-agent jobs: implement distributed cache with LRU and sharding."}
       ]
   )
   print(resp['choices'][0]['message']['content'])

For JetBrains IDE integration, watch for pluggable language server protocol (LSP) or Mellum2-native plugin updates.

Takeaway: Mellum2 can run today in your own racks, with the workflow as close to “point and serve” as a modern AI stack allows.

[[IMG: schematic of an on-prem server running Mellum2 side-by-side with code editors and an agent routing system]]

What does JetBrains mean by a "focal model" — and how does Mellum2 fit?

JetBrains staff call Mellum2 a “focal model” — not a claim to out-benchmark frontier LLMs, but to nail one high-impact, high-frequency use case: software engineering orchestration. It’s not about broad generative smarts or world knowledge — it’s about:

Speed and specialization: Mixture-of-Experts means per-token inference uses only a working set of 2.5B active params. Real engineering stacks want wire speed and minimal context lag, not an extra few percent in synthetic “general coding” benchmarks.
Lean surface area: Focal models accept narrower mandates — but optimize hard within those bounds, so your orchestration (sub-agents, retrieval, task routing) becomes reliable infrastructure, not novelty.

As JetBrains’ engineers put it: "This specialization ensures the model excels in software engineering environments while remaining lean and fast." Frontier experiments continue — meanwhile, “focal” keeps infra predictable.

Takeaway: Mellum2 is an infrastructure-bias model, built for tasks where latency and determinism matter more than general IQ.

The future: open source AI models as infrastructure control points

Mellum2’s open-source release is part of a visible trend: heavyweight AI models open from first commit, not after-market. For emerging agentic AI, running open models on your own hardware starts becoming the norm, not just a fallback for the risk-averse.

Industry is moving away from the “API-as-datacenter” pattern. It’s not just security rhetoric — control of source, weights, and inference enables:

Auditable, modifiable logic: Tweak, debug, or extend model behavior as needed.
Community-driven variants: Expect “instruct” and “thinking” derivatives to be tuned by integrators for very specific verticals, not just handed down from one vendor.
Ecosystem independence: Avoid getting trapped by upstream API changes, quota limits, or “region not supported.”

Where does OTF fit here? The value is in treating models and routing chains as a durable substrate underneath the shifting landscape of models. Mellum2 may be central today, but with open models — and open orchestration frameworks — your workflow persists regardless of which model has the advantage next year.

Takeaway: Open-source models like Mellum2 put engineering teams back in control of their infrastructure layer, propelling a wider trend away from vendor lock.

[[IMG: a code pipeline diagram, showing context retrieval, Mellum2 focal worker, and alternative local models in sequence]]

Mellum2 open source coding model lands as something rare: a high-capacity, high-speed infrastructure model shipped open from the start. It’s not a mere code completion engine; it’s the first “focal model” to face agentic AI tasks head-on — routing, retrieval, orchestration — where API-bound tools like Claude Code cannot safely or practically go. Deployable on your hardware and modifiable by your own team, Mellum2 finally lets engineers prioritize privacy, speed, and specialization over lock-in and latency.

JetBrains open-sources Mellum2 for private, high-speed AI coding infrastructure

Dave Kurian — Tue, 02 Jun 2026 06:42:27 +0000

Mellum2 open-source coding model: JetBrains’ fast AI alternative to Claude Code that runs anywhere

JetBrains’ Mellum2 open-source coding model lands with the rare combination of both speed and genuine infrastructure freedom—a 12B-parameter Mixture-of-Experts designed for agentic orchestration where every token stays on your side of the firewall. In a space dominated by third-party API coding tools and restrictive cloud access, Mellum2 is the first mainstream step toward practical, on-premises agentic AI infrastructure. For AI engineers and teams who demand control, privacy, and tight data locality, Mellum2 enables use cases that are simply out of reach for Claude Code and similar offerings.

What is Mellum2? An overview of JetBrains’ open-source coding model

Mellum2 is JetBrains’ freshly open-sourced, 12-billion-parameter code model built for infrastructure-level agentic AI. Announced in early June 2026, Mellum2 takes aim at a new class of AI engineering requirements: routing actions between sub-agents, managing retrieval contexts, and orchestrating code-based pipelines entirely within an enterprise’s control.

The roots go back to Mellum—a 4B-parameter proprietary coding model JetBrains first fitted into its IDEs in late 2024, then open-sourced in April 2025. Mellum was single-purpose: pure code completion, optimized for a JetBrains-centric workflow. Mellum2 jumps categories. From day one, it is both open and specialized for the jobs that define real AI infrastructure: not just completing code, but coordinating agentic workflows and reasoning across multiple moving parts.

Crucially, the shift isn’t just parameter count. Where Mellum was locked into a SaaS model and limited scope, Mellum2 is “open from the start,” as JetBrains put it in their own announcement. It launches with public weights, a permissive OSS license, and documentation built for self-serve deployment—making it a direct answer to self-hosted agentic AI ambitions, not just another cloud-bound product.

Main data points:

12B total parameters (Mixture-of-Experts, see below).
Open-sourced in early June 2026 by JetBrains.
Public repo, not limited to JetBrains IDEs.
Focused on infrastructure tasks: agent routing, context compression, sub-agent orchestration.

If Mellum was prototype infrastructure, Mellum2 is built for real pipelines.

How does Mellum2 differ from Anthropic’s Claude Code?

The dividing line is clear: Mellum2 runs wherever you control the stack. Claude Code and its kin are API-first, third-party cloud models. What does this mean in practice?

Parameters and model design: Mellum2 sports 12B parameters in a Mixture-of-Experts arrangement (active 2.5B per token), tuned for speed and high-frequency infrastructure tasks. While Anthropic doesn’t publish parameter counts for Claude Code, its design is optimized for cloud API access and general code understanding, not sub-agent orchestration.

Deployment model: Mellum2 can be set up fully on-premises or on dedicated VPC infrastructure. There is no required internet-facing component or dependency on JetBrains itself after download. By contrast, Claude Code cannot be self-hosted and always passes your queries over third-party APIs.

Privacy and data governance: Mellum2 guarantees that all input code, context, and outputs remain under your infrastructure team’s control—crucial for industries with data residency or privacy requirements. Claude Code is, by design, a black box beyond API boundaries.

Scope of usage: Where Claude Code is positioned as a context-rich coding assistant, Mellum2 targets the infrastructure “glue”—routing, context compression, and orchestrating the job of other agents and models, especially in sensitive, local environments.

In short: Mellum2 is built to work wherever Claude Code isn’t allowed.

What are the practical use cases for Mellum2 in AI development?

Mellum2’s real strength is infrastructure flexibility. Its main use cases reflect this bias:

1. Model and sub-agent coordination:

Instead of brute-forcing everything through a general LLM, engineers wire up Mellum2 to manage the flow—splitting complex jobs between specialized agents, handling state, and routing context based on custom business logic.

// Example: Using Mellum2 to broker tasks between retrieval agent and synthesis agent
const routingPrompt = `
[task]
Type: information retrieval
Context: {query}
Actions: route to subagent A, then summarize via subagent B.
`

const response = mellum2.run(routingPrompt, customContext)

2. Context compression in retrieval pipelines:

With expensive retrieval pipelines, compacting context before it reaches the main model is crucial for both speed and token budget. Mellum2’s focus on rapid inference makes it suited for pre-filtering and summarization.

python run_mellum2.py \
  --task compress_context \
  --input data/chunked_context.json \
  --output data/short_context.json

3. Private on-premises inference:

Compliance, data residency, and regulatory constraints often bar cloud models entirely. Mellum2 fills the gap, running on private clusters and answering code prompts where API-based assistants are non-starters.

4. Multi-agent workflow management:

Orchestrate complex pipelines (e.g., code review, static analysis, deployment scripting) by letting Mellum2 act as the “glue” between tool outputs and downstream triggers—without ever hitting the public cloud.

Enterprise impact:

In short, Mellum2 lets enterprises finally run agentic AI tooling in environments where Claude Code and co. will never be certified.

How to deploy and use Mellum2 today? Step-by-step guide for developers

Mellum2 is available from JetBrains’ official public repository. A typical deployment—local or cloud-based—can be up in under an hour, assuming adequate hardware for a 12B MoE model.

Requirements:

Hardware capable of 12B parameter models (multiple A100s recommended for production; smaller cards work for dev).
Python ≥3.10.
PyTorch ≥2.1 or compatible.
~32GB+ RAM, fast storage for weights.

1. Download weights

git clone 
cd mellum2
# Download official weights (link in repo readme)
python scripts/download_weights.py --variant base

2. Set up environment

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

3. Run the model

To launch Mellum2 on a single-GPU node for dev/experimentation:

python run.py \
    --model_dir ./weights/mellum2-base \
    --mode instruct

Both “instruct” and “thinking” variants are available. The “instruct” mode answers directly, whereas the “thinking” option produces a reasoning trace before an answer.

4. Integrate with JetBrains IDEs (or your workflow)

JetBrains IDEs: Point the in-IDE AI assistant to your local Mellum2 endpoint using the built-in AI provider configuration UI.
Custom tools: Expose Mellum2 as a REST endpoint or implement as a sub-agent in your workflow (see provided Python wrappers).

5. Extend as needed

Mellum2’s open repo enables:

Custom post-training or fine-tuning for your codebase/domain.
Experimentation with context pipelines and agent routing.
Building adapters for other code and agent infrastructure.

There are no phone-home, callout, or cloud dependencies by default. Once installed, Mellum2 is yours—no caveats.

What makes Mellum2’s architecture and performance stand out?

Mellum2 isn’t just scaling up parameter count. Its Mixture-of-Experts (MoE) architecture means that while the weights total 12B parameters, only 2.5B are active per token. Each input is processed by a routed subset of 64 experts, rather than the full dense network.

What does this actually yield?

Speed: By limiting the number of active parameters, Mellum2 attains fast inference even on hardware that struggles with full-dense 12B models. It’s built for latency-sensitive infrastructure, not maximal model size.
Specialization: JetBrains’ engineers call Mellum2 a “focal model”: lean, targeted for engineered high-frequency tasks (routing, retrieval, orchestration), not general conversation.
Variants: Two shipped variants:
- “instruct” — answers directly, for fast agentic commands.
- “thinking” — explicit step-by-step reasoning trace, for multi-step agent flows.
Efficiency: MoE routing makes it more viable to deploy Mellum2 on mid-range enterprise hardware than you’d expect for its parameter size.

As JetBrains frames it: frontier models will keep pushing raw size and generality, but real AI products need smaller, sharper “focal models” to glue agentic systems together practically.

What are the limitations and future prospects for Mellum2?

Mellum2 is not trying to be a general-purpose coding assistant or conversation partner. Its “focal” specialty is a strength for infrastructure, but you can hit limits if you treat it like a ChatGPT replacement.

Limitations:

Out-of-scope for creative suggestions or open-ended coding support.
Not competitive with cloud LLMs for massive context or full-app codegen.
Dependency on community for further post-training/integration (but repo is open from day one).

Mellum2 is already in active use and JetBrains is inviting the open-source and research communities to contribute, fine-tune, and experiment on real workflows. The roadmap (per hints in the announcement) includes variants for more agents, context formats, and even tighter IDE integration.

In the broader AI dev tooling landscape, Mellum2 signals a move: real, on-prem agentic AI can now be practical, not hype. For industries where owning your entire inference and orchestration stack is a must—not just an ideal—this is the first credible open offering.

Closing thoughts

The Mellum2 open-source coding model is a real advance: a lean, fast, locally routable agentic AI built for the messy, tactical infrastructure jobs that general coding assistants cannot touch. By sidestepping API dependencies and cloud restrictions, Mellum2 finally lets engineering teams run and evolve their own agentic AI infrastructure privately—enabling use cases from secure pipeline orchestration to flexible context retrieval that simply cannot be done on Claude Code. For those ready to move AI out of the public cloud and into real, auditable pipelines, Mellum2 is usable and extensible today.