Vibe Coding with Claude
While I have some coding experience, it’s limited to data modeling, some machine learning, and building simple Python games like Brick Breaker. I was comfortable manipulating data and writing scripts, but I did not have the skill level to build a real application with both a backend and a frontend, let alone one with a clean UI that other people would actually use.
I had played around with “vibe coding” before, copying and pasting Python scripts from ChatGPT, and messing with Google AI Studio. Sometimes it worked, sometimes it didn’t, but it always felt clunky, friction-heavy, and slow. The sense that a full application was still out of reach never really went away. Real software, in my mind, still required a skilled engineer or a team. That belief collapsed in my first hour of using Claude Code.
The moment it clicked was moving from copy-and-paste workflows to running Anthropic’s Claude Code directly in my terminal, paired with Opus 4.5. Iteration suddenly became seamless and changes almost always worked the first time. Instead of shuttling code between chat windows, I was working inside a live codebase with an agent that understood the entire project. Watching Claude pontificate or canoodle (two of many fun status words Claude uses) on a task creates suspense. Then comes the rush: a seamless new feature or a one-shot full application. I was hooked immediately, and like many others, have been working on side projects any chance I get. Could this be a doom-scrolling replacement?
Using Claude Code, I have built a fully functioning internal CRM for SAIF, the AI safety and security fund where I work. I have also built a dashboard for my book club, a voice-controlled remote for my TV, and even an AI nail polish try-on app for my mother-in-law. I have been religiously following Boris Cherny (Claude Code’s creator) on X for new tips and workflows (Claude in Chrome, code simplifier, etc..) and I’ve loved seeing the community’s hacks like wiring Claude into Telegram via an MCP server for remote approvals and updates. I’ve also started automating my own workflows using Claude in Chrome to sanity-check Vercel deployments, dig through build logs when something breaks, and iterate without leaving the terminal. Not only is it already an extremely powerful tool, but it’s being improved almost daily with new features, plugins, and novel applications.
While the side projects are fun to build and a cool demonstration of the power of this tool, the work I have done on our CRM has certainly shown that this is not just a gimmick. My team and I have now transitioned completely away from our various Google Sheets and docs. We’ve only been building it for two weeks, and honestly, that’s probably longer than it needed to take. This application takes us through our entire pipeline from form intake, partner voting, live collaborative note-taking, portfolio management and more. The biggest change is that we’re no longer relying on memory and manual Google Sheet updates; every interaction is logged automatically, and nothing quietly falls out of view.
Claude even helped me put together a simplified version so you can take a look at a portion of what I built.
Using Claude Code doesn’t feel like working with a dev team. It feels like using a magic wand. I type my wish and watch it become real. I’ve seen plenty of discussion about coding being a key ingredient for AGI. Boris Cherny has publicly said that a vast majority (if not all) new contributions to Claude Code are made with Claude Code. What’s striking is that Anthropic doesn’t have a native image or voice model today, but watching it build tools for itself makes me wonder if, long term, they even need to. If an agent can design and build the capabilities it lacks, the boundary between missing features and temporary constraints start to blur. I caught a glimpse of this when Claude began writing small helper scripts and abstractions on its own, not because I asked for them, but because it decided they would make the task easier.
Claude Code feels like magic and magic always comes at a cost. Opus 4.5 is cheaper than earlier Opus 4.1, but hitting rate limits on a subscription or watching API costs spike mid-project can still be painful. Anthropic heavily subsidizes subscription usage which begs the question of cost viability for regular users at a non-subsidized price. For companies, this is trivial compared to human labor costs but for individuals, it still matters. To minimize my own cost I work on a max subscription and switch to API when hitting rate limits.
While it’s easy to go down the “Claude Code is Magic” rabbit hole, I still run into issues that remind me this is still just a powerful but imperfect tool. Claude sometimes gets stuck in a loop of repeated thinking leading to bugs that require human intervention. In those moments, I have to step back, chat with Claude, and debug on my own. Another frustrating situation is compacting conversations. Claude’s context windows still have token limits like any LLM and if the conversation gets too long it has to compact. Inevitably, that leaves Claude with a thinner understanding of the current task. There’s also something slightly unsettling about constantly granting permissions in your terminal without reading the fine print. Is it risky? Probably, but who has time to read everything?
Despite all of that, the overwhelming feeling is one of agency. The ability to create on a whim, to turn intent into reality, is intoxicating. At the same time, the implications are genuinely scary. What happens to junior engineers? Mid-level? Senior? What does it mean to rely on a system full of code that no human has ever fully read? I don’t know the answers but I certainly feel the ground shifting.
This experience reduced years of learning into days but it also raises hard questions about trust, understanding, and responsibility. I recently wrote about the misallocation of funding between AI capability and AI safety and using tools like this makes that argument feel even more urgent. If this is what individual builders can do today, alignment and interpretability research aren’t optional add-ons, they’re foundational infrastructure.
For SAIF specifically, the implications are massive. Small teams are more empowered than ever. Capital stretches further when spent on compute instead of headcount. Teams build faster but competition intensifies as speed becomes the most important moat. Internally, we’re already changing our own processes with tools that never would have made sense to build before. We’re entering an era of custom software for everything: tools built on demand, modified in minutes, shaped to exact workflows. The next generation of founders will still need to be technical, at least for now, but the shape of teams is already changing.
Working with Claude Code has given us an extraordinary amount of leverage over the digital world and this gives me pause. Tools like this are inherently dual-use. Claude Code is already capable of producing malicious software and while internal guardrails help, determined jail-breakers will always find ways around them. Today that leverage is concentrated in software development but what new capabilities will be unlocked next? As AI tools move into new domains, the average person will gain access to abilities that were once tightly constrained; consider, for example, the power of individuals to create vastly dangerous pathogens. Capabilities are accelerating too rapidly to defer these questions to the future; the stakes are too high not to take them seriously now and this is precisely why SAIF exists.
When the gap between idea and execution collapses, friction stops acting as a brake. As that friction goes away, individual choices have the potential for much greater downstream impact and it’s difficult to believe that everyone using these tools will act carefully or in good faith. That doesn’t mean responsibility falls completely on the user. Claude can write the code, but it doesn’t decide what should exist or what tradeoffs are acceptable. Those decisions are shaped by the people building these systems, the incentives they create, and the limits they choose to enforce. If software is getting easier to create and harder to fully understand, then safety can’t be something we promise to deal with later. The guardrails have to evolve alongside capability, and that is the responsibility we can’t afford to automate away.
