The ultimate guide to claude projects for software engineers

This section just describes how projects work. If you’re already using them, it won’t be terribly helpful.

What are Claude Projects?

Claude Projects represents a significant advancement in AI-assisted software engineering. It’s a feature that transforms Claude from a simple chatbot into a context-aware development partner, capable of understanding and contributing to your entire codebase.

Think of it as having an AI assistant that finally grasps the nuances of your project without needing a refresher on basic programming concepts every time you interact. Available on Claude.ai Pro and Team plans, Claude Projects aims to streamline your development process and boost productivity – though it might also make you question the efficiency of your human teammates.

Key Features and Capabilities

Persistent Context: Unlike your human colleagues who might forget crucial details between meetings, Claude maintains context across all interactions within a project. It’s like working with a developer who never forgets – for better or worse.
Customized Knowledge Base: Upload your entire codebase, documentation, and even those cryptic code comments. Claude will reference it all, understanding your spaghetti code better than you do after a long weekend.
Tailored Interactions: Customize Claude’s responses to align with your project’s needs. Whether you need it to channel a meticulous code reviewer or a brainstorming partner, Claude adapts to your preferred style of interaction.
Enhanced Collaboration: Share Claude interactions with your team, creating a knowledge base that’s actually relevant to your project. It’s like a smarter, more focused version of your company’s neglected wiki.
Expanded Context Window: With a 200,000 token context window, Claude can handle massive code bases.
Organized Workspace: Keep all project-related interactions and resources in one place. It’s a neat solution for corralling the chaos that typically defines software projects.

Technical Specifications

Powered by Claude 3.5 Sonnet: The latest Claude model, offering enhanced speed and efficiency.
Artifacts Integration: Generated code appears in a dedicated panel, allowing for easy review and integration. It will render HTML and javascript. It’s amazing for UI/UX and prototyping, and even produces interactive React mockups.
Comprehensive File Support: Claude can process a wide array of file types, from source code to documentation. Throw your entire development ecosystem at it, and watch it adapt.

Summary

In essence, Claude Projects offers a sophisticated AI collaboration tool tailored for software engineering. It’s designed to enhance your coding efficiency, provide intelligent insights, and maybe even catch those edge cases you missed during your third cup of coffee.

While it won’t replace the camaraderie of late-night debugging sessions with your team, Claude Projects promises to be a reliable, ever-present assistant in your software development journey.

Setting Up Claude Projects for Software Development

Claude Projects can significantly enhance your software development workflow, from initial planning to implementation. Here’s how to leverage this AI-powered tool effectively throughout your development process.

In essence, you just add documents to your project and start prompting. That’s really it, but the fine details around software engineering are more nuanced.

One of the great things about claude projects is, you already paid the bill so you don’t get charged per token. So, unless you need focused content window, LOAD IT UP. The only concern is keeping the model focused. We recommend removing things that are no longer useful.

Project Planning: Ideation and Design

The planning phase sets the foundation for your project’s success. You should lay out a software design process here, and follow it. During this phase, you should add:

Domain information (logistics, deployment, insurance, etc)
Documentation on design patterns you want to use (DDD, CQRS, N-Tier, Layered)
User requirements/stories
Project collateral
Conversation transcripts
Chat histories with users/stakeholders

Engage Claude in refining your concepts. It’s a tireless brainstorming partner who’s read every software engineering book ever written (and occasionally makes you wonder if it’s time to update your own reading list).
Ask Claude to help generate user stories and personas. While it can’t replace actual user research, it can provide a solid starting point for understanding potential user needs.
Go through the design process. If you don’t have one you use, ask claude, or use this one to get started. We’ve actually lumped much of the planning process into ADR’s (architecture decision records) and we recommend you do the same:

User stories
Prototyping and UI/UX design
Architecture decision records
Data model design
File and folder structure design
Code standards definition
Task breakdown

Add your work products. As you create documentation, add it back to the project. It will help fuel further discussion.
Ask Claude to produce artifacts that are useful for LLM’s. It does a pretty good job of this.

Pro tip: If you find yourself getting carried away with feature ideas, have Claude play devil’s advocate. It might save you from the dreaded scope creep before it begins.

Project Bootstrapping: Using Documentation and Examples

We’ve found that the best way to bootstrap a project is to use Claude to create an implementation guide. Then, feed the LLM each step in the guide to produce the actual code that goes in your project:

Upload external documentation on the languages, frameworks, and libraries you’ll use.
Upload the artifacts you developed in the first step. For a more focused architecture document, ask it to summarize your ADR’s.
Make sure you include your file and folder structure. It will “guide the guide” significantly.
Use “chain of thought” prompts for guide generation. You’ll get significantly better output. Use something like “I want to start bootstrapping this project. Using COT, start creating a guide to get this project running. Do not start creating any of the actual models or endpoints. Just help me get the project up and running.”
Review the guide, and have Claude review the it rigorously. If you find holes, upload examples and documentation that shore up that section and ask for revisions. A helpful concept to use during reviews is “dependency analysis.” Feed it the guide and ask for a dependency analysis, and to re-order the steps based on dependencies.
Once you finish building the guide, you should have something that you, another engineer, or an LLM can use to bootstrap the project. So, follow it, feed each step of the guide back to Claude and ask it for the code, or feed each prompt into a cli tool like (Aider)[https://aider.chat/] and get the commits directly in your repository.
Keep track of where you are, and avoid going down rabbit holes. If your step in the guide doesn’t get your project compiling and working within 3-5 prompts of dealing with errors, strongly reconsider that step. Re-evaluate, read documentation, check out examples.
At the end of bootstrapping, ask for a review. It’s simple: “can you identify any improvements we could make to this project?” Then take the suggestions and go through them iteratively.

Early Implementation: Using Your Existing Code Base

The best thing to do at this point is upload your current codebase to the Project. During implementation, you can let it have the full project for context.

If you planned all the way to your task breakdown, start doing the tasks. You can feed them directly to Claude, ask it to expand the task into a detailed prompt, or ask it to break the task down into subtasks. These are all valid approaches to getting good output from the LLM.
If you didn’t do so during planning, you should specifically ask for tests at each step. It’s an integral part of LLM code generation, because the model may break your application. Claude is a junior on steroids, so you have to keep the guard rails up.
Ask Claude for optimization suggestions. Find good checkpoints to ask it for improvements, like after a major task or feature is complete. It can identify potential improvements in efficiency, readability, logging, or design patterns. It serves as a valuable second set of eyes. Again: “can you identify any improvements we can make to this project?”
Leverage Claude for documentation assistance. It can help draft inline comments and function descriptions, potentially making future maintenance a bit less painful. Additionally that documentation can be used in the future to help the LLM with higher level implementations of that code.

If Claude’s suggestions seem off-base, don’t dismiss them outright. Sometimes an outside perspective, even an AI one, can shed light on alternative approaches you might not have considered.

If you have a “good idea” and code generated around it doesn’t work, consider whether your idea/design decision is really necessary. Ask the model whether it’s a best practice, and whether there’s a better way to do it. If you’re getting in a rabbit hole, strongly consider whether it’s worth it, and whether the model can get you back to the surface.

Fundamentals of Using Claude Projects for Software Development

Your ability to use Claude projects is one of the foundational LLM-assisted development skills:

Managing the context window

Believe it or not, it’s not that different from how you manage your own context window. So, think about what you need to hold in your mind in order to accomplish a specific task.

What do you need to review to plan a large feature?
What do you need to review to fix a bug?
What do you need to review to do a subtask?

Keep this idea in mind as you read this section.

Code files

First things first, resist the urge to dump your entire codebase into Claude’s lap like it’s the night before a deadline. Claude may be smart, but it’s not a miracle worker (yet). Instead, think of Claude as your own brain – give it the relevant portions of your code base:

If you need to plan a large epic, or add large fundamental functionality, give it your entire code base along with documentation and design artifacts. Ask it for high level plans, like which features to implement, architectural decisions, and design patterns. Don’t necessarily ask it to write code here, it may not know which part of your code to look at.
If you need to add a large feature, give it documentation, the code you think it will interact with, requirements, and any additional context (transcripts, chat histories). Create lower level plans, like task breakdowns and guides.
If you need to fix a bug, you’re really interested in the exact code path from the entrypoint to the infrastructure. If you’re in a dynamic language, tracing could be useful to understand the code path. If you’re in a static language, a call graph could be useful. If you’re unable to leverage automated tools, you’ll have to know the code base and figure out which files to include.
The same is true for tasks. You need to understand the dependencies of the task, and the callers, and provide the right code so the model can properly fix the bug or complete the task.

Remember, Claude’s not here to replace your version control. Keep your actual coding in your preferred Git-based platform, where you can rollback when things inevitably go sideways.

Project artifacts

One of the fundamental ideas in using LLM’s to ship software is to use them to generate project artifacts that guide development. You should be using those artifacts in the development process.

If you’re spiking in new functionality, you should include your architectural summary, so it knows what libraries to use.
If you’re creating a new file, include your file and folder structure so it knows where to make that new file.
If you’re writing a new UI component, include your React mockup so it knows how it should look.
If you’re asking the LLM to review code, include your standards and architectural summary.

Go back to the first principle. What do you need in order to accomplish the task? The LLM needs that to. If you thought project artifacts were important when you were writing the software yourself, they are 2x more important with the model.

External content

There are a few categories of external content that are useful. The same first principle applies to external content as it does to code. What content do you need to effectively complete a task?

The answer is exactly the same as it is for LLM’s.

The most useful content is documentation. One of the biggest pitfalls for LLM’s is writing the last versions code. You can typically fix that by providing current documentation, and if it doesn’t work, ask for a guide on how to do the thing with the current documentation in the context.
The second most useful one is examples. You can load up code files from other repositories that demonstrate how to get something done. You can then prompt the LLM, or ask for a guide on how to complete the task, then feed the model the guide entry.
User-contributed guides. Very often, you can find an article on (stackoverflow)[https://www.stackoverflow.com] or (medium)[https://www.medium.com], or logrocket that describes how to do something or how to fix a problem. That’s great, but sometimes the people writing the guide aren’t following best practices, or are using old versions. Be wary with these guides, as they may get you down a bad path.
Console output and stacktraces are incredibly useful for the LLM. However, sometimes it simply will not fix the issue based on stacktrace. If you have the smallest idea of what’s going on, add some color. If you have any idea where the code is broken, and can add it to the context, do so. A little guidance goes a long way here.
Test results are also hugely helpful to the LLM, with one caution. If you have multiple tests failing, copy the results from one test and let it fix things one at a time. Sometimes, feeding it the the results of 19 failing tests isn’t as useful as you might hope, unless they are all related. Sometimes the LLM can triangulate.

If you have a really persistent bug you can’t figure out or fix, load the entire project and start quizzing Claude.

Domain-specific resources

We were working on generating certificates of insurance for certificate holders, and we needed someone to help us understand how to model the data for the domain. The information we received from product was waffly and incomplete at best, we had no resources internally to explain how to do it, and no customers to interact with. It was a big problem.

It doesn’t have to be. 3/4 times you can just go ask Claude. It already understand the domain well enough to help you answer the question. When it can’t, go find a book, paper, or article on the topic, plop it in the context window, and ask your questions. You can have a domain expert weighing in on requirements and the functionality of your code.

Updating project contents

Your project is alive (hopefully), and so should be your Claude Project. Keep it fresh. It’s not practical to update the project every time you change something but you should do it regularly if you expect good results.

Keep a finder window open, and cmd+click the files that are currently relevant. As you progress in the project, cmd+click what you’re using or abandoning. Remove everything from the project, and drag it in. Not exactly elegant, but it works.
Maintain projects for your different phases. Need to go back and replan something? Just maintain the planning project for eternity.

Remember, Claude is here to assist you, not to be your digital hoarding enabler. Keep your Project lean, mean, relevant and fresh. With these fundamentals in mind, you’re well on your way to a beautiful symbiosis of human creativity and AI assistance.