If you spend too much time on the internet, it’s pretty easy to believe that everyone out there has outsourced their job to AI and is just letting their LLM of choice run free. I’ve been talking with engineers in the real world recently though, and the truth is that there is wild variability in adoption from none to very advanced.
As with any new tool, using it well is about both developing the skill of how to use it and the judgement to know when to use it.
This post is for people who are wanting to get started with new tools, but also want to maintain control of their code quality and output. I’m most familiar with Claude, but this guide should work with nearly any modern AI model + tool, though you may need to Google around for the specifics of syntax (or just ask the LLM).
I joined a healthtech startup last October as the first technical hire. We started from zero lines of code, so it was a great opportunity to experiment with new tools, but under the pressure to ship real product quickly. We don’t have the runway to waste time tinkering with our setup, but couldn’t ignore the benefits of AI. For some context, we operate in a regulated space, where privacy, compliance, and security are top of mind. Since I joined, we’ve brought on 4 software engineers and continued to iterate on what works for our team.
All of the lessons in this guide are organized around one guiding principle: Expert human attention and energy remains the scarce resource. This could be many types of tasks, from writing code, designing UX flows, financial modeling, to designing a pricing plan or more. The goal of AI is to offload work where the human is not critical or to augment the human attention when possible. Humans must be involved at critical phases, but what those are will depend on your company, team, tooling, and the state of AI models.
But this is getting ahead of ourselves. Let’s begin with:
Start by creating (or borrowing) skills[1] for planning and executing. This is both a simple step and will meaningfully customize the output you get with less effort.
We’re certainly not the first team to realize that having a separate /plan and /execute process for coding tasks is important. In fact, many AI coding tools have formalized this with planning modes. We started by leveraging 3rd party skills (like humanlayer or superpowers) before moving on to writing our own. Both of these provide a great starting layer of skills.
Skills can typically be added as either AI-invoked or human-invoked (or either). In this case, you want to make these human-invoked (often called commands), so you can call them with /command-name and they will inject their prompt into the AI’s context for you.
If you have a small team, I’d suggest adding your plan and execute skills to your repo, so everyone can share common patterns and iterate together to improve them. If this isn’t feasible for your team, then consider putting them in a separate repo and sharing them with the people you work most closely with. Some larger companies may even create repositories of shared skills to leverage.
Once you’ve done your first few features with these vanilla skills, you can move to:
If you find yourself retyping the same guidelines to the AI in every thread or are frustrated with getting inconsistent code, despite being in the same codebase, you’re violating our core principle of managing human energy. Let’s fix that.
Many AI agents provide ways to auto-inject context into every prompt. In Claude, you can add a CLAUDE.md file that will be added to your chats. By auto-injecting some basic instructions that are specific to your repo’s way of doing things, you can cut down on the amount of time you have to spend correcting the AI. (Thus preserving your scarce resource: developer time!)
At my company, the root level CLAUDE.md file contains a succinct description of what lives in the repo, what our tech stack is, critical rules for working with healthcare data, a high-level architecture summary, how to test, dev commands available, and some key skills we wanted to emphasize. (Claude auto-loads skills, so this may not be necessary, but I haven’t eval’ed it.)
Note: Because the Claude.md file is loaded on every load, it’s recommended to keep it short (like 200 lines). According to Anthropic, “Bloated CLAUDE.md files cause Claude to ignore your actual instructions!”[2]
If you plan to implement this pattern, definitely read the best practices page from Anthropic beforehand. I noticed that Claude Opus 4.6 does not always follow these best practices itself, so I often will give it this link or tell it to search the internet for best practices before having it modify skills or my CLAUDE.md file.
This brings us to the next part:
Now that you have the plan/execute scaffolding, you can start to add more custom skills. Each custom skill is a small tool that is registered with the LLM and invoked when it is working on a task that seems like it is related. This is a bit of a weird concept if you’re used to writing code that always works the same 100% of the time. The skill use is non-deterministic, but does seem to work.
Start simple here as well. For use, we mapped out our software lifecycle and identified places where we were spending time that could be automated. For example:
If you want some inspiration, the repos above are good. Here’s some examples from anthropic. This set of skills is less coding-focused, but does some cool stuff.
These are fairly simple to write if you read some examples. They are essentially natural language instructions. Don’t overcomplicate your first skills. You can even ask the AI to help author them. Keep in mind though that if you let the AI fully write the skills, you’ll probably get generic approaches that may not perform much differently from just raw model prompting.
At this point, your files should look something like this. (Note that this is only showing the files applicable to what we’ve talked about, you may have more stuff in your .claude folder)
Whenever you find yourself copy/pasting context into an LLM, stop and ask if there’s a better way. Another big unlock was adding some key MCPs/CLI tools. We used Linear’s MCP (our project management tool), the Figma MCP (for design/frontend coding), and Github’s CLI. Before using these, we were doing a lot of copy/pasting between various places in order to collect or write the context needed. The biggest missing piece (come on Google…) is a way to easily read/write into Google Docs through an MCP. Because of this, we’ve started to leverage Linear for more documentation.
For example, starting a new feature workflow could look like:
As with any dev tool, you can get lost personalizing and tweaking your prompts and forget to ship real work product. Start simple and build as you see opportunities and find the right amount of experimentation for yourself. As you customize and play with your setup, you will improve your intuition for when and where to best apply (or avoid) LLMs to improve your output.
The tools and capabilities are constantly changing, so don’t expect this to be a one and done investment. Smaller investments over time are more likely to let you keep up with the shifting practices and tools. Learning the basics now will help you recognize new opportunities for improvements and even this fairly rudimentary setup will create a meaningful improvements in development output and new ways of thinking about what’s possible with AI use.
[1] A skill is simply a tool that can be invoked by the LLM or a human. They can either execute code snippets or simply inject a prompt into context
[2] Supposedly Claude 4.7 follows instructions better, so this is probably going to change over time.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。