Stanford and Berkeley wrote how to build a $100k/month AI company. Here's the full system.

You don't need to work at Anthropic. You don't need a $10 million compute budget. You don't need access to a closed frontier model that nobody else has.

Stanford and Berkeley spent years researching exactly what separates AI systems that work reliably from AI systems that look impressive in demos and fail in production. They published the findings. Anyone can read them. Most people don't.

The companies that will win the next wave of AI are not the ones with the best model access. They're the ones that turn public models into reliable systems - with proprietary workflows, private data, evaluation loops and compound knowledge that competitors cannot easily copy.

Bookmark This and follow I'm Noisy, a developer with 4 years of experience. I build AI systems, automation pipelines and find ways to turn technology into real income.

Kimi K3 is the model. These five principles are the system. Here's how to build it.

Principle 1 - Don't prompt. Program the workflow.

Stanford DSPy - https://openreview.net/forum?id=sY5N0zY5Od

Stanford researchers looked at how most people use language models and identified the core problem. Every time you write a better prompt you're doing manual optimization. You're hand-tuning one specific input for one specific output. It doesn't scale and it doesn't compound.

DSPy proposed a completely different mental model. Instead of writing prompts write programs. Define the pipeline as a sequence of modules - research, retrieval, reasoning, verification, output. Then let the system optimize the prompts for each module automatically based on a metric you define.

import dspy

# Define your pipeline as a program
class ResearchPipeline(dspy.Module):
    def __init__(self):
        self.research = dspy.ChainOfThought("topic -> key_facts")
        self.compare  = dspy.ChainOfThought("facts -> comparison")
        self.verify   = dspy.ChainOfThought("comparison -> verified_output")

    def forward(self, topic):
        facts    = self.research(topic=topic)
        compared = self.compare(facts=facts.key_facts)
        result   = self.verify(comparison=compared.comparison)
        return result

# Optimize the entire pipeline automatically
optimizer = dspy.BootstrapFewShot(metric=your_metric)
optimized = optimizer.compile(ResearchPipeline(), trainset=your_examples)

Applied to Kimi K3:

User question
↓
Kimi Research Module    - finds relevant information
↓
Kimi Retrieval Module   - pulls specific data points
↓
Kimi Reasoning Module   - analyzes and compares
↓
Kimi Verifier Module    - checks the output
↓
Final answer

Kimi K3 stops being a chat assistant and becomes a module inside a program. The pipeline is stable. The quality compounds as the optimizer runs more examples. The prompts improve automatically.

Stanford's experiments showed that compiled DSPy pipelines outperformed both standard few-shot prompting and expert-written demonstrations on complex multi-step tasks.

The practical product: an AI analyst that doesn't just answer questions but follows a stable pipeline - research, compare, calculate, verify, report - every single time.

Principle 2 - Don't trust the model. Build verifiers.

UC Berkeley 2026 - Scaling Environments and Verifiers for Software Engineering Agents

Berkeley researchers identified why software engineering is the perfect domain for AI agents. Not because code is easy. Because code has objective feedback.

A compiler either accepts or rejects. Tests either pass or fail. A type checker either finds errors or doesn't. These are verifiers - systems that can evaluate the agent's output without human judgment.

The key insight from Berkeley: the environment and the verifier determine what tasks an agent can reliably learn to complete. A powerful model with no verifier produces confident garbage. A moderate model with a strong verifier produces reliable output.

WITHOUT VERIFIER:
Kimi K3 writes code
→ claims it's correct
→ you have no way to know
→ you review manually
→ you find bugs yourself

WITH VERIFIER:
Kimi K3 writes code
↓
Test runner executes
↓
FAIL - specific error returned
↓
Kimi K3 reads error
↓
Kimi K3 fixes
↓
Test runner executes again
↓
PASS - verified by objective evidence

In code:

def agent_loop_with_verifier(task, kimi_client, max_iterations=5):
    for attempt in range(max_iterations):

        # Agent writes the solution
        solution = kimi_client.complete(
            prompt=f"Implement: {task}\nPrevious errors: {errors}"
        )

        # Verifier checks objectively
        result = run_tests(solution.code)

        if result.all_passed:
            return solution  # Verified correct

        # Feed failure evidence back to agent
        errors = result.failure_details

    return None  # Escalate to human

Berkeley's research on executable specifications took this further. A system using test suites as reinforcement learning rewards achieved 42.2% Pass@1 on SWE-Bench Verified. Hybrid execution-based verifiers reached 51.0% Best@26.

The principle that changes how you build:

Don't ask Kimi K3 whether its output is correct. Build an environment that proves it.

For Kimi Code this is already built in. The coder subagent writes code, the test runner executes, failures come back as evidence, the agent fixes and runs again. You get verified output not claimed output.

User requirement
↓
Kimi writes acceptance tests FIRST
↓
Kimi implements the feature
↓
Tests execute automatically
↓
Failure evidence returned if any
↓
Kimi repairs with specific error context
↓
Tests pass → verified done

A good AI engineer doesn't start with code. It starts with a machine-checkable definition of done.

Principle 3 - Don't use one giant agent. Decompose intelligently.

Stanford AI Index 2026 - hai.stanford.edu/ai-index/2026

Stanford's research on multi-agent systems showed something important and something that gets glossed over in most AI content.

Multi-agent configurations consistently outperformed single-agent variants on complex research tasks. But the improvement was modest - approximately 2 to 4 percentage points. And in CooperBench, two coding agents working together sometimes performed worse than one agent working alone due to coordination failures.

The lesson is not more agents equals better results. The lesson is:

WRONG:
300 agents
→ automatically 300× better output

RIGHT:
Correct decomposition
+ clear roles
+ shared state
+ independent verification
→ reliable improvement

Berkeley's framework from "Toward Scalable and Self-Improving LLM Agents" describes three ways to scale agents:

Sequential   |  agent works longer on a single task
Parallel     |  multiple agents work on different parts simultaneously
Recursive    |  agents spawn sub-agents for specific subtasks

Kimi K3 officially supports up to 300 sub-agents in Swarm for parallel work. But the number of agents is not the variable that matters. The decomposition quality is.

RIGHT decomposition for a research report:

Manager Agent        |  understands full scope, assigns work
Research Agent       |  finds sources, pulls raw information
Competitor Agent     |  analyzes competitive landscape
Financial Agent      |  pulls and interprets numbers
Fact-check Agent     |  verifies claims against sources
Writing Agent        |  synthesizes into coherent output

Each agent has clear input, clear output, clear scope.
No agent duplicates another's work.
Shared state file updated after each step.
Independent verification before final output.

WRONG decomposition:

5 agents all doing "research"
→ duplicate work
→ conflicting outputs
→ no clear synthesis
→ worse than one agent

The Stanford finding about CooperBench is worth sitting with. Two capable agents with overlapping roles and unclear coordination produced worse results than one agent with a clear mandate. Coordination overhead exceeded the benefit of parallelization.

Decompose by role not by scale.

Principle 4 - Don't repeat expertise. Encode it as Skills.

Kimi Code documentation - github.com/MoonshotAI/kimi-code

Every time you explain the same convention to an AI agent you are losing compounding value. Every session that starts from zero is institutional knowledge that disappears.

Kimi Skills solve this directly. A Skill is a folder with a SKILL.md that stores workflow, standards, project rules, domain knowledge and review process. Kimi can decide autonomously when to activate a Skill based on the task at hand. Skills can be stored at user level or project level, accept arguments and nest up to three levels deep.

A real example for a company that builds SaaS landing pages:

---
name: landing-page-production
description: Build conversion-optimized SaaS landing pages
whenToUse: When user requests a new landing page or redesign
---

# Landing Page Production Skill

## Step 1 - Customer Analysis
Identify the target customer segment.
Extract the top three pain points from the brief.
Map pain points to specific product features.

## Step 2 - Architecture
Hero section: pain-focused headline, not feature-focused.
Social proof above the fold if available.
Single primary CTA, no competing actions.

## Step 3 - Implementation
Stack: Next.js, Tailwind, Server Actions.
Mobile-first. Test at 375px before anything else.
Page weight under 200kb. Images next/image only.

## Step 4 - Quality Gates
Lighthouse score above 90 on all metrics.
All CTAs tracked with analytics events.
Zero console errors before handoff.
Never deploy before all gates pass.

## Rules
Never use carousel components.
Never use popups that appear before 30 seconds.
Never launch without heatmap tracking installed.

After this:

Client sends brief
↓
Kimi reads brief
↓
Kimi activates landing-page-production skill automatically
↓
Follows your exact standards every time
↓
Consistent output without re-explaining anything

The compounding effect is significant. Week one you write the skill. Week two it runs automatically. Month three it has been refined based on what worked and what didn't. Month six it encodes more institutional knowledge than most junior employees have.

Skills are the mechanism that turns one-time expertise into repeatable process. Every domain you work in, every client type you serve, every technical standard you maintain - it becomes a skill file that Kimi reads and follows without instruction.

Principle 5 - Don't keep AI in chat. Connect it to tools.

A model that can only see what you paste into a chat window is a consultant who works blindfolded. It can reason about information you bring to it but it cannot see the actual state of your business, your data or your systems.

Kimi Code acts as an MCP client and connects to external tools through stdio, HTTP and SSE. This is the difference between an agent that describes what it would do and an agent that does it.

Without MCP:

You → paste data into chat → Kimi analyzes → you copy output → you act

With MCP:

Kimi → reads your CRM directly
     → queries your database
     → checks your GitHub issues
     → pulls your support tickets
     → analyzes and synthesizes
     → produces report with live data
     → updates your Linear tickets
     → posts summary to Slack

A concrete business scenario:

# Customer asks: "Why are sales down this month?"

# WITHOUT MCP - you do this manually:
# 1. Export CRM data
# 2. Export Postgres revenue data
# 3. Export support ticket themes
# 4. Paste all of it into chat
# 5. Wait for analysis
# 6. Copy output to report

# WITH MCP - Kimi does this automatically:
tools = [
    "crm://read_pipeline_data?period=last_30_days",
    "postgres://query?sql=SELECT revenue, churn FROM metrics",
    "linear://get_issues?label=bug&status=open",
    "github://get_issues?state=open&sort=reactions"
]

# Kimi reads all sources simultaneously
# Cross-references patterns across systems
# Identifies root causes with evidence
# Produces report with specific data points
# Updates the relevant tickets with findings

Real MCP connections that change what Kimi can do:

GitHub      |  reads repos, issues, PRs, commit history
Linear      |  reads and updates tickets, links PRs
Postgres    |  queries live business data directly
CRM         |  reads pipeline, deal status, customer history
Filesystem  |  reads and writes local files and configs
Slack       |  posts summaries, pings on escalations

The vertical AI product that becomes defensible is the one connected to real business data through MCP. The model is public. The data is yours. The connections are your moat.

What the full system looks like

Put all five principles together and the architecture becomes clear.

                  YOUR PRODUCT
                         │
                         ▼
                      KIMI K3
                         │
           ┌─────────────┼─────────────┐
           ▼             ▼             ▼
         SKILLS        MEMORY         MCP
    encoded expertise  shared state  real tools
    repeatable process  handoffs     live data
           │             │             │
           └─────────────┼─────────────┘
                         ▼
                  DSPy PIPELINE
              programmed workflow
                         │
              plan → execute → verify
                         │
                ┌────────┴────────┐
                ▼                 ▼
          FAIL ↺ retry        PASS → output
                                   │
                                   ▼
                              Git commit
                              progress.md
                              next iteration

A real scenario running end to end:

Client asks: "Build me a competitive analysis of the CRM market"

The principle that connects all five

Stanford proved that programmed pipelines outperform prompted models. Berkeley proved that verifiers matter as much as model intelligence. Stanford's AI Index showed that coordination quality determines whether multi-agent systems help or hurt. Kimi Skills encode institutional knowledge that compounds over time. MCP connects the model to the actual state of the world.

Together they point to one conclusion that most people building AI products are missing.

The next valuable AI company probably won't win because it has access to a secret model. It will win because it turns a public model into a reliable system. Proprietary skills that encode domain expertise competitors don't have. Private data that gives the model context no one else can access. Evaluation loops that guarantee quality without human review of every output. Workflows that compound in value the longer they run.

Kimi K3 provides the intelligence and the long context. Kimi Swarm provides the parallel execution. Skills provide the institutional knowledge. MCP provides the real-world data access.

The system is the product. The model is just the engine inside it.

Most developers will keep building chat interfaces on top of public models and wondering why they can't create defensible businesses. A few will spend the time building the five layers above and create something that compounds in value every week it runs.

You build your own life - so choose the right path.

/ If this was useful - follow /