Building Water Monkey pushed me into an interesting mix of technologies: a React interface, a native Rust engine through Tauri, several cloud-provider APIs, operating-system credential storage, and optional local AI.
It was also a good test of AI-assisted engineering. Coding agents can move quickly across a codebase, but speed is only useful when the application still has clear boundaries and predictable behavior. For a desktop application that handles cloud credentials, “the generated code works” is not a sufficient standard.
Give each layer a clear responsibility
Water Monkey is local-first. React owns the interface and user interaction. Rust owns native capabilities and operations that should not happen in the browser layer. Tauri’s IPC bridge connects the two through explicit commands.
That boundary is important. The UI can request a provider scan or ask to store a credential, but it should not gain unrestricted access to the operating system. Rust commands validate the request and perform only the capability they expose.
I treat the IPC surface like an internal API. Commands need deliberate inputs, predictable outputs, and useful errors. A narrow bridge is easier to reason about, test, and secure than a generic escape hatch into native code.
Keep secrets out of frontend state
Cloud credentials are the most sensitive part of the application. Water Monkey stores them in the native operating-system keychain rather than browser storage, source files, or the application’s local database.
The React layer does not need to retain a secret after sending it through an approved command. The Rust backend can retrieve it only when a provider operation requires it. This reduces the number of places where credentials can accidentally appear in state snapshots, logs, persisted settings, or debugging tools.
Local-first does not automatically mean secure. It still requires a clear inventory of what is stored, where it is stored, and which part of the application can retrieve it.
Treat providers as independent integrations
AWS, Google Cloud, and Azure expose different resources, permissions, pricing concepts, and failure modes. Forcing them behind one overly generic abstraction would hide useful differences.
I prefer a shared contract for the parts that truly match—connection testing, scanning, findings, and status—while keeping provider-specific logic inside each adapter. A failure in one scan should not erase results from another provider or prevent the user from retrying only the failed integration.
This approach creates a stable product workflow without pretending that every cloud behaves the same way.
Use AI inside architectural guardrails
AI is effective at implementing a well-defined adapter, expanding test cases, tracing a type mismatch across layers, or updating repetitive documentation. It is much less reliable when the task leaves major architectural decisions implicit.
Before delegating work to a coding agent, I establish the important constraints:
- which layer owns the behavior;
- how data crosses the Tauri boundary;
- where secrets may and may not appear;
- which existing patterns the implementation should follow;
- what tests and validation commands must pass;
- and what requires human review before release.
I also keep repository-specific instructions and reusable patterns close to the code. This gives the agent more than a one-time prompt; it gives it the same architectural context a developer would need.
Review the risk, not just the diff
A generated change can be tidy and still be wrong for the system.
My review asks whether permissions became broader, whether sensitive values could reach logs, whether a new command bypasses an existing safety check, and whether failure states remain recoverable. For cost-remediation features, I also distinguish between read-only recommendations and destructive actions that require explicit confirmation.
Automated tests, Rust checks, TypeScript validation, and CI are essential, but they do not replace this review. They verify known expectations. Human judgment still has to look for risks the test suite does not yet describe.
Velocity should leave the system clearer
AI acceleration is not valuable if it produces more code than the team can safely maintain. The best result is not the largest diff or the shortest implementation time. It is a useful feature that fits the architecture, includes meaningful validation, and leaves the next change easier to make.
Tauri and Rust provide a strong foundation for a small, secure desktop application. React provides a productive interface layer. AI can shorten the path through implementation and testing. But the architecture must remain intentional, and responsibility for the shipped product must remain human.