Building with AI: Lessons from Devloping a Django App with Claude

I’ve recently been exploring AI-assisted development, specifically using Claude to build a Django-based inventory management application for scout and youth groups.

So how did it go? In a couple of weeks of part-time work, I built and deployed a functional MVP to production: www.armaria.club (app.armaria.club). Here are my key takeaways. These aren’t universal rules, just what worked well for me while developing a real application with AI assistance. I’m also very aware that with the current pace of AI assisted tools this will probably be out of date before I post it! 🙂

I’m late to this party – AI-assisted coding has been evolving rapidly over the past few years. But what I’m noticing is that many senior engineers are only starting to engage deeply with AI assistance recently. If that trend is representative across the industry, it means many architects, designers, QA engineers, and software leads are only beginning their AI journey. And we’re only beginning to see the impact of AI across the software development lifecycle.

I’ve experimented with ChatGPT and Claude before on programming tasks and learning exercises, but this was my first time building a production application with AI assistance. I chose Django because it’s a framework I used extensively at Oracle and know well. I assumed I’d be better positioned to review Claude’s design decisions and code changes if I deeply understood the framework. My expectation is that AI assistance works best with greenfield or well-understood codebases – I haven’t yet tried using it extensively with mature legacy code.

I used Claude via a z.ai subscription https://z.ai/subscribe?ic=HI1H8NMTBC (referral link)

1. Refine the Idea (Write a PRD)

This might seem old-school, but step away from the laptop, grab a coffee, and write down what your app needs to do. Create an initial Product Requirements Document (PRD). Ask yourself:

• What problem are you trying to solve?
• Who are the target users?
• What are the core concepts within the app?
• What are the goals?
• What’s the core functionality needed for version 1?
• What’s out of scope now but planned for the future?
• What are your security requirements?
• What are your technical constraints?
• Do you have any guiding principles?

Share this with your AI—it becomes your source of truth for requirements and informs your technical instructions (your claude.md file).

2. Plan (Use Claude’s Planning Features)

Use Claude to discuss and develop a plan for each feature. I found it helpful to:

• Use multiple models as independent reviewers. This reduces blind spots and often surfaces alternative architectural approaches.
• Discuss ideas with ChatGPT first to formulate detailed prompts for Claude.
• Use this exploration phase to clarify what you actually want to achieve.

I found ‘arguing’ with Claude useful here. Explain why you are taking this approach. What alternative approaches could we take? What could go wrong? What if a user did X?

AI output is non-deterministic. Saving prompts, architecture decisions, and generated code history becomes critical for reproducibility and traceability.

3. Break Down Implementation

Once you know what you want to accomplish, have Claude break it down into implementation steps that you can understand and review. This is crucial—you need to be able to verify each step makes sense before code is written.

As with the broader planning stage, ask Claude why it’s suggesting particular approaches.

4. Small, Frequent Commits

Once you’re happy with the plan and steps, commit each step rather than waiting to commit a massive changeset. This is for your benefit so you can understand the changes.

I had cases where a seemingly small change – like adding additional flags to a user model – resulted in Claude suggesting a total model rewrite. You can spot these overreaches when working with small changesets and roll back easily. But you need to actually look at the diff.

I use git and a private repo on GitHub. Give meaningful commit messages. I didn’t use branches but might in future.

5. Test-Driven Development

I fell into the old trap of writing tests after finding bugs. Tell Claude (in your claude.md) to create tests before implementing plan stages. The tests won’t be perfect initially and will need fixing, but you’ll quickly build up a bank of regression tests.

You don’t need to implement Selenium or Playwright initially—regular unit and integration tests within your framework will do just fine.

For Django, start with model tests, then view/API tests. Ensure you have the key data and paths covered, full coverage and complex tests can come later.

Also, you may need to remind your AI assistant to run the tests from time to time!

6. Protect Your Tests

When implementing a new feature, tell Claude not to “fix” existing tests during development. Claude will happily change a failing test to match its latest hallucination if you let it! Treat test changes as a red flag, you want to understand why a change is being made before accepting it.

7. Use Your App

This sounds obvious, but actually use your application as outlined in your PRD. You’ll find many things that need tweaking, and it’s much easier to iterate during the implementation phase than to do big changes later.

Test on different browsers and devices. Have someone else try it. Make a list of bugs/features and iterate through them.

What I Wish I’d Known

The claude.md File Is Critical

Create a claude.md file at the start with:

• Your tech stack and versions
• Coding standards and preferences
• What NOT to do (this is as important as what to do)
• Testing requirements
• Common patterns you want followed

Update it as you learn what works and what doesn’t.

Know When to Step In

AI is a tool, not a replacement for engineering judgment. In particular, step in when:

• The solution seems overly complex
• Security-sensitive code is being written
• The AI keeps going in circles on a problem

Sometimes the fastest path is to write it yourself and move on.

Deploy Often

Don’t wait for perfection. I deployed to production in a couple of days with basic functionality. This:

• Forced me to set up proper CI/CD early (which deserves its own future blog post)
• Revealed deployment issues immediately
• Gave me a real environment to test in
• Provided motivation to keep iterating.

Common Pitfalls I Encountered

• Over-engineering: Claude loves to suggest complex or enterprise patterns for simple problems. AI models are rarely short on confidence – but they are not always correct. Push back. 
• Inconsistent styling: Without clear direction, Claude will use different patterns across files. Your claude.md should enforce consistency. I originally told Claude not to use Django signals. Later, I approved one legitimate use case. Claude immediately generalised that decision and started proposing signals everywhere. AI models are extremely quick to promote exceptions into rules unless you restate your constraints.
• Security assumptions: Don’t assume Claude knows your security requirements or best practices, be explicit about authentication, authorization, data validation, especially if building a multi-tenant system.
• Documentation drift: Claude-generated docstrings can become outdated quickly. Similarly, any documentation you ask Claude to write can quickly become dated.

Am I Still in the “Old Engineering Mindset”?

Am I still in the old engineering mindset, or even – shudder – waterfall development? Yes, to some extent, but I think this oversight is still necessary and proportionate.

Of course, this is all iterative. Whatever functionality you implement in a sprint may cause you to adjust future work. But I think this level of oversight over the AI assistant is appropriate.

It also helps future you. I’ve certainly discovered code I wrote 10+ years ago still running in production that I had to re-understand! The practices above will make that easier – whether it’s future me or a future AI trying to make sense of it. My colleagues at Oracle will remember my frequent code review reminders to think about how “future you” will read today’s changes.

Closing thoughts

AI assistance amplifies both good and bad practices. If you have strong software engineering fundamentals – testing, version control, incremental development, clear requirements – AI will accelerate your work. If you skip the basics, AI will help you build a mess faster.

Experienced engineers entering AI-assisted development now have an advantage: we know what good software and process looks like. The challenge is teaching the AI our standards and staying disciplined about engineering practices even when the AI can generate code faster than we can review it.

The future isn’t “AI replaces developers” – it’s “developers who effectively collaborate with AI replace those who don’t.”

On a personal note, I’m now the Quartermaster for our Scout Group so will be using this tool to solve our actual inventory and maintenance needs. Get in touch and give it a try if you think it might help your group or club!