A Practical Guide to AI-Assisted Coding with Claude Code

1.1 Every app is retrieve, process, present

Almost every useful internal app does three things:

• Retrieves data from somewhere: a spreadsheet, a database, another system, a website
• Processes data: filters it, calculates something, flags exceptions, combines sources
• Presents data: sends an email alert, updates a dashboard, writes a report to a folder, shows a searchable list

When someone describes an app idea, it's usually these three steps in a trench coat. Here are the most common things our clients build:

If your idea fits the retrieve, process, present pattern, it's probably buildable. The question is never really "can we build it." It's "what data does it touch and who can reach it."

1.2 The 80/20 rule and the happy path

It's very easy to build the first 80% of an app with AI-assisted coding. The last 20% takes significantly more time, because that's where security, reliability, and error handling live.

Part of that last 20% is getting off the happy path. The happy path is a coding term for the sequence of steps where everything goes exactly as intended: the right file, the right format, buttons clicked in the right order. That's how you test your own app. It's not how real users behave.

Real users create edge cases:

• Uploading a spreadsheet with a missing column
• Typing "next Tuesday" into a date field
• Clicking submit twice
• Pasting 50,000 rows when you tested with 50

An app that hasn't been tested off the happy path will break in ways that range from annoying to dangerous, like silently saving wrong data. Handling edge cases gracefully is a large part of what separates a prototype from real software.

1.3 What makes an app harder to build

Not all apps are created equal. Scope the easy version first.

2.1 Keep it off the public internet

This matters more than anything else in this guide. A publicly reachable app will be found by automated scanners within hours, and an AI-built app that hasn't had a security review is exactly what those scanners are looking for.

Our strong recommendation: put your app behind entry authentication using Microsoft Entra, the login system your firm already uses for Microsoft 365. Entry authentication means nobody sees anything at all, not even the front page, without logging in with firm credentials first. If someone isn't a member of your firm, the app simply doesn't exist for them.

The good news is that Azure has a feature called Entra Easy Auth that provides exactly this: a hard gate in front of your entire app, and it's very easy to implement safely. You do need a developer to set it up for you, but it's a small job, not a project.

2.2 Know your data risks: PII and MNPI

Before building anything, ask what data the app will touch and whether you're allowed to put that data anywhere near an AI. Talk to us or your compliance team first, not after.

2.3 Start with the Guardsman CLAUDE.md file

Anyone building with Claude Code at your firm should start with the Guardsman CLAUDE.md file, a standard instructions file Claude Code reads before writing any code. It does two things:

• Puts guardrails on what the AI is allowed to do
• Tells the AI how to build for your environment: your authentication, your Azure setup, your standards

Without it, the AI makes its own assumptions, and its assumptions won't match your environment. Ask us for the current version before starting any project.

2.4 All code in the firm's GitHub, all repositories private

If your firm is doing any software development, get a GitHub Enterprise license. GitHub is where code is stored and version-controlled, and Enterprise gives the firm central control over accounts and access. Two rules from day one:

• All code goes into the firm's GitHub: Code written for the firm is the property of the firm. If it only lives on someone's laptop, you lose it when they leave, and you can't review what you can't see.
• Every repository must be private: A public repository can be read by anyone on the internet, and people accidentally publish code publicly more often than you'd think. If that code contains an API key or infrastructure details, you've handed an attacker a map. Set the firm-wide default to private and check periodically.

2.5 Be very careful with secrets

An API key is like a password that lets one piece of software talk to another. If your app pulls data from a market data provider, your portfolio system, or an AI service, it's using one. API keys, passwords, and connection details are collectively called secrets.

Anyone who gets hold of a secret can access that system, often with all the permissions of the person who created it. Malicious actors run automated tools scanning for exposed keys constantly. The rules:

• No API keys or other secrets should ever be committed to GitHub
• Secrets are never written into the code itself
• Keys should be restricted to the minimum permissions needed
• For deployed apps, secrets live in Azure Key Vault, a locked digital safe for credentials. A developer can set this up when they deploy the app, so it doesn't need to slow down your prototyping

2.6 Code review before deployment

Once a prototype is something you want to actually use, it needs a code review before deployment: an experienced engineer reads the code looking for security holes, reliability problems, and shortcuts the AI took.

AI-generated code often looks polished and works in a demo while containing real problems underneath: credentials in the wrong place, missing input checks, no error handling. This isn't optional for anything touching firm data. It's the checkpoint between "cool prototype" and "thing we actually run."

Guardsman can provide the code review, or if you'd prefer an independent set of eyes, we can recommend a vendor who does this well.

3.1 Your computer or the cloud

• Single-user app, just for you: keep running it on your own computer as is. Nothing wrong with that for personal tools.
• Needs to survive your computer being shut down or rebooted, or serve other people: it has to live in the cloud.

The standard way we do this is packaging the app as a container and deploying it to Azure Container Apps. A container is a self-contained bundle holding your app and everything it needs to run, so it behaves identically everywhere. Azure Container Apps runs those bundles inside the Azure environment most of our clients already use, so it sits within your existing security perimeter.

3.2 Recommended tech stack

When we review or deploy client-built apps, this is what we recommend:

3.3 How we deploy: CI/CD

We deploy apps using CI/CD, which stands for continuous integration and continuous deployment. In plain terms, it's an automated pipeline built with GitHub Actions, GitHub's built-in automation tool. When a developer saves finished code to GitHub:

1. The code is automatically tested
2. It's packaged into a container
3. It's pushed into Azure

No human copying files by hand. Every deployment happens the same way, there's a log of exactly what was deployed and when, and if something goes wrong we roll back to the previous version. The alternative, someone manually copying files to a server, is how you end up with "it works on my machine" problems and no record of what changed.