"Our best developers have not written a single line of code since December."

— Gustav Söderström, Co-CEO, Spotify, February 2026 Earnings Call

Spotify shipped over 50 features in 2025. Their engineers fix bugs and review code from their phones on the morning commute. This is not an experiment. It is the new normal.

The numbers back it up. 85% of Box engineers use Cursor daily. NVIDIA deployed Cursor to 30,000 developers and saw 3x the code committed. Dropbox is merging over one million lines of AI-generated code every month. Salesforce reported a 30%+ velocity increase across their engineering org.

These are not scrappy startups running a weekend hackathon. These are enterprises with tens of thousands of engineers, and the results are real and measurable.

At Parity Cube, we have been watching closely. Project Foundry is our answer.

How We Got Here

Our journey with AI-assisted development has been iterative, moving through distinct phases as the tools matured:

In 2023, we were early adopters of AI autocomplete — Copilot, IntelliJ AI — the kind of tooling where AI suggests and you accept or reject. Useful, but you were still the one typing.

In 2024–25, we moved to AI Composer and multi-file edits via Cursor. This made a real difference. Engineers could describe a change and watch it propagate across the codebase. We lived here for a while and genuinely felt the productivity shift.

In late 2025, we migrated to terminal-native, full-repo-context tooling with Claude Code. More power, more context, more control.

In 2026, we took the next step: autonomous agents operating on Slack, running parallel tasks across remote servers. That is Project Foundry.

Three Levels of AI-Assisted Development

There are three meaningful levels of AI integration in engineering, and most teams are stuck at Level 1 or 2 without realising it.

Level 1 — AI in Your IDE. Copilot, Cursor autocomplete. AI suggests, you accept or reject. You are still in the loop for every keystroke. Most teams start here.

Level 2 — AI on Your Terminal. Claude Code locally. Powerful, with full repo context. But it is still one agent, one task, one branch. Your machine is blocked while the agent works.

Level 3 — Multi-Agent on Slack. Multiple agents, multiple branches, in parallel. Fire three tasks before standup. Review all three merge requests by lunch. Tag an agent in any Slack channel to loop in business teams without them needing to understand the code.

Level 3 is what Spotify built. The two shifts that make it possible: Slack replaces the IDE as the primary interface, and you can run agents in parallel across separate environments. That parallelism is the real multiplier.

Where We Are Right Now

Before Phase 1 even ships fully, general-purpose agents are already working inside the Parity Cube team as day-to-day collaborators.

Maya is the executive and coding assistant — general-purpose orchestrator, handling research, analysis, coding tasks, and coordination across all products.

Soch is the marketing agent, helping the marketing team move faster on creative work, research, and content operations.

Sanjay is the Cuelinks agent, dedicated to product and operational queries with deep context on the Cuelinks platform.

These general-purpose agents handle creative, exploratory, and human-in-the-loop work. Phase 1 is the next layer: scoped, autonomous agents with narrow jobs and hard guardrails.

Why Operations, Not Just Features

The bigger insight behind Project Foundry is that writing features is only a small slice of what engineering actually takes. The real day-to-day is operations: manual, repetitive, reactive work that quietly eats hours.

Bug detection means digging through Sentry manually, triaging, assigning — and by the time someone looks, three more deploys have landed. Performance regressions surface only after users feel the slowness. Infra monitoring is either someone watching dashboards or a naive threshold alert firing after the damage is done. Code review happens when someone remembers to ask for it, rather than automatically on every MR.

Every one of these is repetitive, rule-shaped, and reactive. That is exactly what scoped agents absorb best.

Phase 1: Four Agents, Four Jobs

The design philosophy is simple: scope is safety. A general-purpose agent with an ambiguous instruction has an unpredictable blast radius. A scoped agent has exactly one job. You know what it can do. You know what it cannot. Everything is auditable.

Sentinel — DevOps Agent

Always-on infrastructure observer. Monitors RAM, disk, CPU, load averages, and process counts across every server. Runs every 15 minutes, builds a 7-day rolling baseline, and fires on deviation from normal — not on absolute thresholds. Built on the Hermes Agent by Nous Research. Its SSH FORCECOMMAND restriction means it can only run read-only whitelisted commands, enforced at the transport layer.

Anvil — Bug Fixer Agent

Monitors Sentry 24/7 across web, Android, and iOS. When a genuinely new error appears, it fetches the last 48 hours of commits, runs root cause analysis, writes a fix, and opens a merge request with a Slack ping to the commit author. Built on the Claude SDK. It can push branches and open MRs, but it cannot merge to main — ever.

Argus — Performance Agent

One page per day, per product. Pulls Atatus performance data (P75/P95, TTFB, slowest queries), reads the source code for that page, and generates a PR with targeted optimisations, complete with before-and-after metric citations. Built on Pydantic. Like Anvil, it can only push branches and open MRs — no direct config changes.

Forge — Code Review Agent

Fires automatically on every GitLab MR. Reads the diff against each repo's .agents/ conventions, flags N+1 queries, security issues, missing tests, and style violations. Posts a structured review comment before a human reviewer even opens the diff. Built on OpenHands. Its GitLab token scope means it can comment only — it cannot approve or merge, by design.

Guardrails: Architectural, Not Configured

The constraints on each agent are enforced at the transport layer, not in software settings. Sentinel's FORCECOMMAND restriction is built into the SSH connection — the agent cannot run commands outside the whitelist regardless of what any prompt says. Forge's inability to merge is enforced by the GitLab token scope it holds. These are not settings that can be misconfigured. They are structural limits.

The Bigger Picture

Project Foundry is not about replacing engineers. It is about changing what engineers spend their time on. The best engineers at Parity Cube should be thinking about architecture, product decisions, and the hard problems — not triaging Sentry queues at midnight or leaving code review comments that could be automated.

We are early. Phase 1 is live at POC level. But the direction is clear, and the industry data is unambiguous. The companies that figure out multi-agent engineering workflows in 2026 will have a structural advantage that compounds every year.

That is what we are building.