June 3, 2026 • 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.
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.
1. Describe — tell it what you need in plain English.
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.
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:
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.
Micro
Dashboard http://localhost:8080
API http://localhost:8080/api/{service}/{method}
Services:
● category
● task
micro chat --provider anthropic # talk to your services
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:
→ 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.
Here’s where it gets interesting. You’re chatting, the domain grows, and you need something that doesn’t exist:
> 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.
Run the same prompt again — services whose proto hasn’t changed are skipped entirely:
✓ 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.
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.
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.
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.
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, join the Discord, or read the docs.