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 may be a good candidate for a bounded prototype. Feasibility still depends on the data, integrations, controls, and people involved. Start by asking what data it touches, who can reach it, and how a reviewer will catch a wrong result.

1.2 A prototype is not production software

AI-assisted coding can make a convincing first prototype arrive quickly. Production work often takes longer because security, reliability, error handling, and operating ownership still have to be designed and tested.

Much of that production work 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 Put internal apps behind layered access controls

This matters more than anything else in this guide. Publicly reachable apps are routinely probed by automated scanners, and an AI-built app that hasn't had a security review creates unnecessary exposure.

For Microsoft-oriented internal apps, require entry authentication with Microsoft Entra and restrict access to the intended tenant and users. Authentication controls who can enter the application; it does not make the endpoint undiscoverable or replace network restrictions, authorization, and application security.

For firms already standardized on Microsoft 365, Entra Easy Auth can provide front-door authentication. A developer still needs to restrict the tenant, define roles and authorization, review session settings, and test failure paths before the app is trusted with firm data.

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:

• Gives the AI explicit working instructions and review expectations
• Tells the AI how to build for your environment: your authentication, your Azure setup, your standards

Instructions reduce unstated assumptions, but they are not a security boundary. Enforce permissions with sandboxing, scoped credentials, approval gates, and deployment controls. Ask us for the current version before starting any project.

2.4 Keep code in firm-controlled source control

If your firm is doing software development, keep the code in a firm-controlled source-control organization. GitHub Enterprise is one option when centralized identity, policy, and audit controls justify it. Two rules apply from day one:

• All code goes into firm-controlled source control: Code written for the firm should remain accessible to the firm. If it only lives on someone's laptop, you can lose access 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 Local or shared hosting

• 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: move it to durable shared hosting managed by the firm or an approved provider.

For clients already operating in Azure, a common path is to package the app as a container and deploy it to Azure Container Apps. Containers make runtime behavior more consistent across development and production, while the Azure deployment still needs deliberate network, identity, logging, and authorization controls.

3.2 A Microsoft-oriented reference stack

For firms already standardized on Microsoft 365 and Azure, this is a practical default—not a universal requirement. The right choices still depend on the workflow, existing skills, data sensitivity, and operating model.

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

A well-configured pipeline avoids manual file copying, records what was deployed, and can support controlled rollback. Those controls must be designed and tested; adopting GitHub Actions alone does not create them automatically.