I’ve been building with Claude Cowork lately, and I figured I’d share my thoughts so far. I chose Cowork over Claude Code to see what it’s like to write code but never read it. Some early thoughts: 1. I’m using natural language, instead of code, but it’s still software development. I don’t need to worry about syntax, but the concepts underlying “traditional” software still matter: observability, client-server splits, pipelines, databases, logging, etc. Non-developers still need to think like engineers to be successful vibe coders – the syntax is gone, but the judgment isn’t (yet?) 2. The primary difference between vibe coding and “traditional” software is non-determinism. Traditional software teaches deterministic thinking – you can run the same function with the same inputs as many times as you want, and the output will always be the same. (When I was learning to code, I found this one of the stranger things; most other experiences in the world aren’t so deterministic!) Agent-driven software is not deterministic – ask an LLM the same question several times, and you will get several answers. The models’ laziness and tendency to cut corners – especially when inference is scarce – adds another twist. Understanding where to demand determinism from your software agents requires judgment. 3. I borrowed the concept of zero trust from security – the principle that an actor or system is only trusted after verification and never by default – to figure out when to demand determinism. I presumed model outputs unreliable until verified with human-in-the-loop checkpoints, retry logic with comparison (LLM as judge), or (deterministic) verification scripts. I realized observability, logging, and verification have to be first-class features of a vibe-coded system if it is to be reliable. Memory doesn’t cut it. 4. I did a lot of debugging through the models’ reasoning traces, which wasn't ideal. I imagine these interactions will improve a lot. If I were building an IDE for agentic coding, I’d start here. 5. What counts as a database? Cowork uses the local file system as the database, which is lazy and convenient and makes for fast prototyping, and comes with tradeoffs: the file system doesn’t enforce data schemas, and laziness means corners get cut. The input and output checks I built at each pipeline stage were repetitive but functional. If I kept pushing, I’d end up rebuilding versions of data integrity, normalization, indexing, query optimization, etc. over the local file system. 6. The tight coupling of the local machine as the client, server, database, etc. works when developing for yourself. To share work with others, you need a better client <> server split. When I asked Cowork to port my system to the cloud, it immediately suggested moving everything to Google Drive – swapping my local file system for a cloud file system. I had to coax it toward the architecture of a simple web app. 7. Cowork doesn’t use or expect version control, which makes tracking changes and multi-agent work near impossible. Developing without version control makes clear why we invented it. Version control is alive and well in the age of software agents. It feels like there’s a new iteration of systems design to be uncovered when building with agents. It’s not wholly new, and most of the primitives and principles of the past are still useful, but they need to be reassembled when some steps are deterministic and others aren’t. I’m excited to see what we uncover.