It Looks Cooler if I Toss You the Keys, Right?

We've asked Claude Code some exploratory questions, described our app, and let the agent commit the details to memory. Now we're getting into the exciting part. If you're not familiar with what Claude Code can really do, you might be surprised.

We're just going to dive right into things. The steps I take going forward will resemble what I would do as I begin the development process, but only loosely. Because Claude works so quickly, there's really no sense in prototyping the front end before I begin thinking about the database and backend structure. We'll see how our agent handles the changing requirements—from database to styles.

Claude asks for permission before any change, but you have the option to turn that off and just let it work. In future posts, I will do my best to summarize its actions without showing every single approval step, but in this post I want to show you exactly what the workflow looks like.

We've created our database admin user.

Saved the database URL to our development environment.

And checked to be sure the database is accessible and our user is present. Our local development database is ready to go!

Claude already knows how we want our back end built, so we just tell it to go ahead. I added a small request here to see how well the agent would perform something I would normally do.

We create our backend directory. Our repo will be a monorepo, because it's easier for Claude to maintain the context of what it needs to do that way. And it saves me the trouble of having to jump between two VS Code windows while I document for this blog series. Of course, you aren't restricted to this method.

We create our Rust Cargo file to define our dependencies.

A health check endpoint is created and tested...

This is less an error and more Claude intentionally waiting for the build to complete.

And we have a response!

Claude automatically stops the backend process.

And that's it! Our initial back end is set up.

If we're going to let Claude run wild and make broad changes as we hand it tasks, we want to make sure we can capture every acceptable state of the codebase so we can revert changes if Claude decides to, I don't know, lose all your code.

We have some files in our project now, so we should set up version control and make sure to commit our changes.

Claude intializes an empty git repository...

...creates a gitignore file to make sure certain files don't get included...

...stages our new files...

...checks for any existing commits (call it silly, but a nice sanity check)...

...and creates our first commit!

Now we'll want to push this commit to our remote repository.

I ignore Claude's question here because I noticed an issue with the email address used for our commit metadata.

We've updated the info and checked that the issue has been corrected.

I usually use SSH to authenticate with GitHub personally, and I didn't want Claude to accidentally cause issues with my host aliases, so I chose to use the GitHub CLI here...

...but quickly abandoned that idea for the sake of moving forward. SSH it is!

Claude generates an SSH key.

Adds it to our SSH agent.

And kindly provides our public SSH key to enter into GitHub settings.

Claude wants to be sure it has the correct account name.

We've already created our repo on GitHub, so we just provide the name...

And we're all set! Just like that, we have a database, a back end, and version control. It's worth noting that this was incredibly fast. I keep personal notes about the software projects I create and I refer to them and documentation with each new project. I like knowing how to do these things, and I'll always have projects that I interact with manually to keep my knowledge fresh. But you can see how a general knowledge of the process can help you inform Claude of exactly what you want and get it done without much of the trial and error.

During this process, I spent some time thinking about how our interaction with AI agents might evolve, especially when it comes to critical matters. I've already mentioned the format some have recommended for your project specifications, and Anthropic has made it possible to use XML tags to structure your prompts. I can't help but wonder: because the agent emulates a human conversation, and human conversations are rife with misread context, misunderstandings, and preconceptions, will our prompts eventually cycle back to a form of pseudocode for the most critical informational tasks? Will we simply find ourselves programming with many more layers of abstraction?

We'll see if an unintentially vague prompt gets us into any trouble in upcoming posts. Maybe we've already created issues we're not aware of?