---
layout: blog
title: "From Prompt to Production: AI-Generated Microservices That Actually Run"
permalink: /blog/13
description: "micro run --prompt generates real services with business logic, compiles them, starts them, and lets you talk to them. When you need more, the agent builds new services mid-conversation."
---

# From Prompt to Production: AI-Generated Microservices That Actually Run

*June 3, 2026 &bull; By the Go Micro Team*

Every code generator stops at the same point: here's some files, good luck. You get a skeleton, wire it up yourself, hope it compiles. We wanted something different.

```bash
micro run --prompt "a task management system"
```

That's not scaffolding. Two services start, register, and respond to requests. An AI agent can create tasks, organize categories, and orchestrate across services immediately. And when you need a capability that doesn't exist — shipping, payments, notifications — the agent builds it mid-conversation.

## The Full Loop

**1. Describe** — tell it what you need in plain English.

```bash
micro run --prompt "a todo list with tasks and categories"
```

**2. Review** — the LLM designs the architecture. You see every service, field, and endpoint before a line of code is written.

```text
Services:
  ● category — Manages task categories
    Create, Read, Update, Delete, List
  ● task — Core task management
    Create, Read, Update, Delete, List, CompleteTask, GetOverdue

Generate? [Y/n]
```

**3. Generate** — proto files are written deterministically from the spec. Then the LLM writes each handler with real business logic. Not stubs. Not TODOs. Actual validation, edge cases, and persistent storage via go-micro's built-in store:

```go
func (s *Task) CompleteTask(ctx context.Context, req *pb.CompleteTaskRequest,
    rsp *pb.CompleteTaskResponse) error {
    if req.Id == "" {
        return errors.New("id is required")
    }
    recs, err := s.store.Read("task/" + req.Id)
    if err != nil || len(recs) == 0 {
        return errors.New("task not found")
    }
    var task pb.TaskRecord
    json.Unmarshal(recs[0].Value, &task)
    if task.Completed {
        rsp.Success = false
        rsp.Message = "task already completed"
        return nil
    }
    task.Completed = true
    task.Updated = time.Now().Unix()
    data, _ := json.Marshal(&task)
    s.store.Write(&store.Record{Key: "task/" + req.Id, Value: data})
    rsp.Record = &task
    rsp.Success = true
    return nil
}
```

Data survives restarts — generated services use go-micro's built-in store (file-backed by default, swappable to Postgres or NATS KV) instead of in-memory maps. Every handler compiles. If it doesn't, the errors are fed back to the LLM for correction. Most services compile on the first attempt.

**4. Run** — services start, register via mDNS, and an HTTP gateway comes up. Every endpoint is accessible via REST, gRPC, or MCP.

```text
Micro

  Dashboard   http://localhost:8080
  API         http://localhost:8080/api/{service}/{method}

  Services:
    ● category
    ● task

  micro chat --provider anthropic    # talk to your services
```

## Talk To Your Services

```bash
micro chat --provider anthropic
> Create a Work category, then add a task called 'Finish report' to it
```

The agent discovers services from the registry, sees every endpoint as a tool, and orchestrates:

```text
→ category_Category_Create({"name":"Work","user_id":"user1"})
← {"record":{"id":"f633...","name":"Work"},"success":true}
→ task_Task_Create({"title":"Finish report","category_id":"f633..."})
← {"record":{"id":"a1b2...","title":"Finish report","status":"pending"}}

Created Work category and added 'Finish report' task to it.
```

No service-to-service calls. No distributed transactions. No saga patterns. The agent reads the result of one call and uses it as input to the next. Each service stays simple and independent.

This is the answer to the oldest problem in microservices: how do services coordinate? They don't. An intelligent agent does it for them.

## Growing the System

Here's where it gets interesting. You're chatting, the domain grows, and you need something that doesn't exist:

```text
> I need to track shipping for my orders. Create a shipment for order 123 to London.

  ⚡ generating service: a shipping service...
    ✓ task (unchanged)
    ✓ category (unchanged)
    ✓ shipping
  ⚡ starting shipping...
  ✓ 13 tools available

  → shipping_Shipping_Create({"order_id":"123","destination":"London"})
  ← {"record":{"id":"xyz...","status":"pending"}}

  Created shipment for order 123 going to London.
```

The agent recognised that no shipping service exists, generated one, compiled it, started it, discovered its endpoints, and used them — all within the conversation. You didn't leave the chat. You didn't run a separate command. The system grew because you needed it to.

Each service stays small and focused. When you need more, you add more services. The agent orchestrates across whatever exists. If you're running `micro run`, it detects new service directories automatically and starts them — the loop is fully seamless.

## Iteration Without Destruction

Run the same prompt again — services whose proto hasn't changed are skipped entirely:

```text
  ✓ category (unchanged)
  ✓ task (unchanged)
```

Edit a handler by hand, and re-running preserves your changes. The system tracks SHA-256 hashes of generated files and only regenerates what's actually different.

The LLM sees existing service protos and extends the system rather than redesigning from scratch.

## What This Isn't

This isn't a no-code platform. The generated code is standard Go — you own it, edit it, version it, deploy it however you want. There's no vendor lock-in, no runtime dependency on an AI provider, no magic abstraction.

The services are real Go code with real interfaces. The same code you'd write by hand, generated in 30 seconds instead of 3 hours.

## Why This Matters

The barrier to microservices has always been ceremony. Proto definitions, handler scaffolding, service registration, build systems — hours of work before you can test a single endpoint.

The deeper problem was coordination. Services need to talk to each other, and every pattern for that (sagas, choreography, service mesh) adds complexity. Teams spend more time on infrastructure than on business logic.

`micro run --prompt` solves both. The AI handles the ceremony. The agent handles the coordination. You handle the domain.

```bash
micro run --prompt "an order system for dropshipping"
micro chat --provider anthropic
> Place an order for 5 units of SKU-123 shipping to London
```

That's a running system. Not a prototype. Not a demo. Services you can deploy, iterate on, and scale.

## Try It

```bash
go install go-micro.dev/v5/cmd/micro@latest

micro run --prompt "a task management system" --provider anthropic
micro chat --provider anthropic
```

The future of microservices isn't fewer services. It's making them so easy to create and compose that the architecture disappears. Services become tools. The agent becomes the interface. You focus on what matters: the domain.

---

*Go Micro is open source. Star us on [GitHub](https://github.com/micro/go-micro), join the [Discord](https://discord.gg/WeMU5AGxD), or read the [docs](https://go-micro.dev/docs).*
