Why Streaming Plans in Real Time Was Worth the Architecture Overhaul
Turning async chaos into live progress—one architecture refactor at a time.
The Week Off
Last week i stepped away from Cloud Atlas Insight and Flow to handle some personal matters. Life got messy for a bit. But here's what i learned during that break - building something meaningful brings peace, even when everything else feels scattered.
Now i'm back. Fully focused on shipping the MVP.
What Got Built (56 Commits in 13 Days)
Since July 5th, i've been deep in architectural changes. Took a week off in between, so this was 13 actual working days. Two main projects: Cloud Atlas Insight (the frontend optimization platform) and Flow (the backend execution engine). Both needed major upgrades to handle real-time streaming and production workloads.
Real-Time Streaming Revolution
The biggest change was moving from static plan generation to real-time Server-Sent Events (SSE) streaming. Before this, users would click a button and wait. No feedback. No progress updates. Just waiting.
Now they see everything happen in real-time:
Plan generation streams live
Progress indicators show exactly where we are
Error handling actually works
Content accumulates instead of flickering
Here's the technical stuff that made it work:
SSE Chat Integration: Built a complete streaming system with proper event handling (progress, content, complete, error). Added JSON buffering for multi-chunk responses and 60-second timeouts with retry logic.
Component Reuse: Extracted useSSEChat
hook and SSEChatInterface
components. Cut the FlowEngineChat sendMessage function from ~400 lines to ~100 lines by removing duplicate code.
Real Data: Migrated everything from mock responses to actual SSE data. No more fake loading states.
Backend Architecture Overhaul
The Flow backend needed serious work. 40 commits worth of modernization:
Supabase Migration: Removed all direct PostgreSQL connections. Everything goes through Supabase API now. Cleaner, more reliable, easier to debug.
RESTful Design: Fixed the API structure. Instead of weird POST /workspaces/{id}/init endpoints, we now have proper POST /workspaces patterns that make sense.
Git Worktree Isolation: This was the tricky part. Each optimization candidate now gets its own git worktree. No more conflicts when running multiple optimizations. Proper isolation with cleanup-and-retry patterns.
Comprehensive Testing: Added integration tests covering git operations, streaming APIs, and complex workflows. Because production breaks are expensive.
The Details That Matter
Swagger Documentation: All 16 endpoints now have complete documentation. Request schemas, response examples, error codes. The works.
Enhanced Error Handling: IPv6 connectivity fixes, retry logic, network connectivity testing. All the boring stuff that keeps things running.
Code Organization: Refactored workspace.go from 3,125 lines into 7 focused modules. Much easier to maintain.
Performance: Increased Claude CLI timeout from 30s to 120s for complex operations. Added proper resource cleanup and connection management.
What's Coming Next for MVP
The foundation is solid. Real-time streaming works. APIs are production-ready. But the MVP needs four critical pieces:
1. Plan Execution with Terminal Integration
Right now we generate plans but can't execute them. The next step is connecting plan execution to an actual terminal workspace. For MVP, we'll keep it simple - users click to run commands manually rather than full AI automation. But the infrastructure needs to be there for both approaches.
2. Persistent Data Management
Currently we're in verification mode. Plans get generated but nothing gets saved. For MVP we need proper persistence at every step:
Save all plan data
Track execution progress
Store terminal outputs
Manage credentials (AWS, etc.) securely
Keep workspace state between sessions
3. Step Prerequisites and Dependencies
Plans have steps that depend on each other. Can't run step 3 if step 2 failed. Need proper prerequisite checking before allowing execution. This prevents users from breaking things by running steps out of order.
4. Docker Container Isolation
The big architectural piece - complete workspace isolation using Docker containers. Each workspace gets its own container where users can:
Run Claude to analyze terraform code
Generate code changes
Execute terminal commands
Access all necessary tools
This solves security, isolation, and scalability in one move.
Why This Matters
Building reliable software is hard. Users expect things to just work. They want to see progress. They want errors explained clearly. They want fast responses.
The streaming infrastructure moves us from "prototype that sometimes works" to "production system that handles edge cases." But execution is where the real value lives. Plans are just suggestions until they run.
These next four pieces turn the platform from "interesting demo" to "thing that actually optimizes your infrastructure."
The Path to Launch
Foundation: Real-time streaming ✓ Production-ready APIs ✓ Proper error handling ✓ Workspace isolation ✓ Comprehensive testing ✓
MVP Requirements:
Terminal integration and execution
Complete data persistence
Step dependency management
Docker container isolation
Then we ship.
Building in public keeps me honest. Writing about progress forces me to think clearly about what actually matters. And right now, what matters is turning plans into executed optimizations.
Back to work.
Cloud Atlas Insight helps developers optimize their applications automatically. Flow is the backend engine that makes it happen. Both are getting close to public release.