I tend to be more excited about general principles than particular pieces of technology - which sometimes makes me a rather late adopter. This is why, after some frustrating earlier experiments, I have been using Claude Code seriously for merely three months. I have done it privately and as part of a pilot program at work.

Below you will find rough observations made during this time. Not a single one of them is about running autonomous agent swarms to implement a new operating system over a weekend while burning through thousands of euros’ worth of tokens. Instead, they are mostly about learning what’s meaningful and letting go of everything else.

  1. Claude allowed me to set up this website, based on Eleventy and Pico CSS, during an otherwise quite busy weekend. While it is a small project, I have barely touched any code and used a code editor to observe what changes were applied. I challenged Claude to set everything up from scratch, customize the design, clean up the resulting code, and generate sample content to see what the website would look like. Apart from tiny manual tweaks, it just worked. It was still important to explicitly mention things like cache-busting URLs for CSS definitions, generating an RSS feed or treating URLs as a human-readable linkable interface that needs to be designed rather than left to chance, but otherwise low-level choices were completely offloaded to Claude.

  2. I asked Claude to build utility scripts to automate typical tasks like spellchecking and deployment. I found minor mistakes in them, but instead of fixing them myself, I let Claude do that. It did so with ease. Overall, repeatable, well-defined tasks are still best performed using deterministic code, but the code itself can be developed and documented by Claude as well. Doing so creates a positive feedback loop, in which Claude creates automation tools enabling it to be more effective. No need to burn through tokens when local CPU cycles will do just fine.

  3. For simple projects, creating CLAUDE.md or AGENTS.md is overkill. A well-structured README that is clear to a human and to an agent is enough. Claude can generate it as well, and then refine and update it by comparing it with the current state of the project and what’s still relevant in the session context.

  4. Claude can help troubleshoot issues related to software deployments and infrastructure, provided it has access to the right tooling. Since it is particularly good at using CLIs, it can correlate your code with outputs from multiple tools, like kubectl or az (Azure’s CLI), and suggest what the issue is and how to resolve it. It is even more powerful when augmented with MCP servers that can provide it with additional context about your infrastructure.

  5. I routinely ask Claude for richly referenced research on topics ranging from database internals to social sciences to psychology. It is becoming my ad hoc Wikipedia and brainstorming partner. However, I still use both and make sure the references it offers are not hallucinated.

  6. The general feeling is that of liberation - it is both easier to go deeper and delegate more than before. I work more on my hobby projects because the emotional barrier to entry is now much lower. Even without accessing my code, I can at least discuss and plan a prototype while commuting. This is also one of the advantages of living in a city boasting an expansive network of public transit - you can plan and brainstorm while on the move.

  7. In professional environments, there is a clear incentive to prioritize speed at the expense of understanding. Please try to avoid doing this. Make an effort to understand what the agent created. Ask it to guide you through the code base. Prompt it to create documentation and then read it. This code is still your responsibility, and if you lose track of what is generated, your mental model of the system you take care of will deteriorate.

  8. Learning while vibe coding instead of completely delegating requires a bit of discipline and curiosity, but also good boundary setting. You will need to decide what not to spend time learning and analyzing, as there is always more to learn than time allows. Getting through boilerplate is much faster, and iterations shrink to minutes, so it is easy to get lost in a rapid improvement loop without reflection. Pause whenever you feel uneasy about all of it happening too fast. It is your curiosity telling you it needs to be fed, so feed it.

And one more thing - a story rather than a comment. I have seen a friend of mine vibe code an ERP system for his family business, from scratch. He has no background in software development. He learned enough to know he could deploy it on Vercel and Supabase, and used Codex to develop, test, and review it. Out of curiosity, I checked the code base for basic flaws like incorrect handling of credentials, but found nothing of concern. (Granted, this was not a sweeping audit, but more like a focused check - we will do more of it in the near future.)

Initially, my friend thought he had implemented login using OAuth, but he didn’t. It was a classic username/password flow based on the application code and database with user passwords (hashed and salted properly). I explained to him what adding actual OAuth would mean.

He texted me the next day to confirm it was done.

There is no way back, and I like it this way. Even if the economics of vendor-hosted coding agents collapses at some point, we will deploy them locally if we are willing to fully internalize the cost. We may also swing too far into the realm of letting go, leaving us exposed and having to clean up the results ourselves.

No matter what, though - we will not go back to the world before agent-assisted and agent-directed software development.