I was speaking with someone this week who’d recently used Claude Code for the first time. He went on to describe something he was building, and I recognized the experience immediately. It’s one many have had—or will have—when they try agentic command-line coding for the first time.
There’s little that prepares you for the ability to transform an idea into an executable prototype in minutes to hours.
I’m not a software engineer by trade. I’ve spent 30 years in IT infrastructure and support. But since last summer, I’ve been spinning up new websites or simple web applications roughly every three weeks. And I’d like to share a few things I’d want someone to tell me if I were just getting started today.
I’ll focus on Claude Code throughout this post, but a similar experience can be had with OpenAI Codex CLI, Google Gemini CLI, Amazon Q Developer CLI, and others.
AI Models Are Stateless
Despite various options to save files in browser-based AI tools, the AI model itself doesn’t remember from one session to the next. And within a session, it will forget earlier context every time it auto-compacts.
Auto-compaction is a mechanism these tools use when conversations grow too long. When the context window starts to fill up, the tool summarizes your conversation history into a condensed form and continues from there. It’s necessary to keep working, but details get lost in the process.
For this reason, it’s helpful to have a strategy to self-document in real time as you go.
After an auto-compact—which you’ll notice when it happens—or when returning to a project on a subsequent day, the first thing I do is ask Claude to re-familiarize itself with the project. If you’ve been updating your README.md as you go, Claude will pick it up during this review, and that file serves as valuable context. Think of it as preserving the AI’s memory over time in a text file.
Start With a README
When I start a new AI project, I do so by launching a terminal window. I navigate to or create an empty directory for my new project, change into that directory, and run claude from the command line.
The very first thing I ask Claude on a new project is:
Create a file README.md for the following project, and document all of the following in it.
I then describe the project in as much detail as I can—typically a handful of paragraphs. I ask it to assign a version number such as 0.0.1 and use Semantic Versioning (SemVer). I don’t want to reach version 1.0 until I’m ready to call it a Minimum Viable Product (MVP).
Why README.md? The README convention dates to the mid-1970s—the name is meant to say “read this first.” On GitHub, a README.md file in your project’s root directory is automatically displayed on the repository’s front page. It’s become the standard place to document what a project does, how to install it, and how to use it. By creating it first and keeping it updated, you ensure the AI always has a reference point—and so do you.
It’s likely I don’t have all the answers about implementation, so I’ll ask Claude for strategies on how to tackle various challenges. When I see answers I like, I ask Claude to update the README.md. Soon we’re ready to start coding, but first I do one more thing.
Set Up Version Control
Version control is essential for any project that will go through periodic revisions—and that includes any software created with agentic command-line coding.
In my case, I’ve previously installed Git—the version control system—and configured it to work with my GitHub account. I’ll ask Claude to:
Create a private GitHub repository using the name of this folder and sync with GitHub.
If I have personal and work GitHub accounts—which I do—I may specify where to create the repository:
Create a private GitHub repository in organization my-company-name using the name of this folder and sync with GitHub.
You can set up a personal GitHub account for free. If you’re one of my colleagues reading this, please ask to join our corporate GitHub Team account. It’s $4/user/month, we set up two-factor authentication, and we back up the content to AWS periodically.
If you’re new to Git and GitHub, consider the GitHub Foundations Certification. It covers 4–6 hours of fundamentals, and the study materials on Microsoft Learn are worth reviewing even if you don’t take the exam.
Before your first commit, I also ask Claude to create a .gitignore file. This tells Git which files and directories should not be tracked—things like credential files, temporary caches, and the .claude directory that Claude Code creates for its own state. This is especially helpful if you switch between machines (I work from Linux, Windows, and Mac), since those local files shouldn’t follow you to GitHub.
Let Claude Code
Now that we have a README.md and a GitHub repository synced, I ask Claude to begin coding. If we’ve given reasonable instructions on what we want, it will create something within a matter of minutes.
Whether we can execute that something locally depends on what we’ve built and what dependencies we may or may not have previously installed. I code mostly from a Linux laptop, and Claude runs into limitations when an installer requires sudo (administrator) privileges. If I see Claude struggling to install a dependency, I’ll ask it for the command so I can run it myself from another terminal window.
When something fails—and it will—read the error message. Beginners often panic, but error messages usually tell you exactly what’s wrong. You can paste them directly to Claude and ask for help. Nine times out of ten, it’ll know the fix.
Getting an app running locally is a great party trick, but you’re only halfway there—unless you’re developing something to run on your own desktop, which for me is rarely the case. Mostly I’m deploying to the web.
Deploying to AWS
Over the past year or two I’ve become comfortable with AWS. If you have the AWS Command Line Interface (AWS CLI) installed and authenticated, then Claude Code can do anything on AWS that you can do. This includes:
- Registering domain names via Route 53
- Updating DNS entries
- Creating S3 buckets for static content
- Creating CloudFront distributions for global content delivery
- Creating DynamoDB tables
- Provisioning SSL certificates via AWS Certificate Manager
If you don’t know what these services do, you’re not ready to deploy. I had a decent understanding of each before Claude ever deployed anything for me. But if you’re familiar and ready to move forward, here are two things I always tell Claude:
Use AWS CLI, not Terraform or CloudFormation. Claude seems to prefer scripting the creation of everything in one go using infrastructure-as-code tools. I’ve yet to see it get a massive, one-shot deployment script to work correctly. I’ve had much better success telling Claude to use AWS CLI and work on one service at a time.
Prefix everything with the project name. When creating this blog, I told Claude: “Prefix all AWS resources with ap7i.” Otherwise Claude may pick generic names, and you’ll end up with an AWS account populated with S3 buckets and Lambda functions that are difficult to trace back to specific projects.
Set up billing alerts. Before you deploy anything, configure AWS Budgets to alert you if spending exceeds a threshold. It’s easy to accidentally spin up resources that cost real money, and you don’t want your first lesson in cloud computing to be a surprise bill.
Trust, but Verify
AI coding agents are remarkably capable, but they’re not infallible. Claude can occasionally hallucinate package names that don’t exist, suggest outdated syntax, or confidently propose AWS configurations that won’t work. When something seems off—or when you’re dealing with security, billing, or anything consequential—verify it independently. You can ask Claude itself to research a topic; it will search the web for information more current than its training data. A quick search or a check of the official documentation can save you hours of debugging.
A Note on Security
I’m not going to attempt comprehensive security guidance here—that warrants its own series. But two things are important enough to mention now:
Never let an AI coding agent hardcode API keys into your application. In AWS, I manually add sensitive values to AWS Systems Manager Parameter Store (or AWS Secrets Manager for credentials that need rotation) and tell Claude to reference them. You don’t want someone extracting an API key from your website’s source code.
Lock down your functions. Make sure any Lambda functions or API endpoints you create can only be called from your CloudFront distribution—unless you’re intentionally creating a public API.
Commit Often
Every time you make a meaningful change, ask Claude to:
Update README.md with what we just did, bump the version number, commit to Git, and push to GitHub.
The terminology: a commit saves a snapshot of your changes locally; a push uploads those commits to GitHub. Frequent commits give you the ability to roll back if something breaks.
Once you’ve got a prototype deployed, security-tested, and ready to use, ask Claude to advance the version to 1.0 in your README.md—your Minimum Viable Product.
These Are Just the Basics
This is a starting point, not a complete guide. I’m sure a long-time software engineer would add much more—proper testing, CI/CD pipelines (automated systems that test and deploy your code whenever you push changes), code review practices. But these fundamentals have served me well for the past six months of building things I couldn’t have built before.
The barrier to creating working software has dropped dramatically. Whether you’re an IT leader, a clinician with an idea, or anyone else who’s been on the sidelines of software development, the tools are now accessible in a way they never were before.
Happy coding.