Software Development Lifecycle

The current model requires developers to handle all user-requested features (filed in Jira) through massive, multi-year plugin rewrites. This process is slow and often fails. Personal AI agents offer an alternative where users can have their own agent write and add features directly for their specific use case, keeping the core app clean.

Traditional web apps run on a developer's server, ensuring all users see one 'blessed version.' This centralization prevents user customization. The proposed Gadget model ensures that each gadget is an isolated instance, and sharing/access control is managed by the platform, not the app itself.

The security architecture isolates components: The UI runs in a null origin iframe sandbox with Content Security Policy. Communication is restricted via `postMessage` to the parent frame, which establishes a Cap'n Web RPC session to server code running in a dynamic worker sandbox (durable objects). This prevents XSS bugs from leaking data outside the isolated environment.

The core insight of FDE is that it must function as an extension of the product team to identify areas for generalization. The goal is to define and solve the underlying problem, not just implement the requested solution.

When a customer presents a massive requirement (e.g., a custom BI tool), focus on solving the most immediate, trivial problem first (like a Slack alert). This builds trust and allows the product team to gain ownership of the solution narrative.

The most valuable intelligence is found by observing user behavior (e.g., repetitive tasks, copying/pasting between tools, or using a phone during workflow). These actions indicate missing features or bugs that documentation will never reveal.

FDE must define the domain's terminology (the ontology) to standardize ambiguous terms. By canonicalizing nouns (entities, e.g., 'clients') and verbs (operations), the engineer controls the language that the entire system is built upon.

The traditional 'three pillars' (metrics, logs, traces) are considered overkill for modern agentic workflows. By focusing solely on logs, instrumentation becomes significantly simpler, requiring only basic logging statements, as the platform can reconstruct metrics and traces from log data.

Instead of using AI to triage noisy alerts (alert fatigue), Sazabi autonomously generates actionable alerts directly from logs and codebase analysis. The agent determines what is meaningful to the user at runtime.

Sazabi maintains persistent, shared memory across multiple parallel sub-agents and threads by committing findings (e.g., issue lists, facts) to a dedicated Git branch within the sandbox environment. This allows agents to benefit from collective findings.

The platform operates in a read-only system with no public internet access, ensuring security. All actions are routed through an isolated sandbox environment (e.g., using `bash` tools) to prevent data exfiltration or unauthorized changes.