Lessons from my 1 year of collaborative coding with AI

Let's get straight to the point. Coding has changed drastically, particularly in the past year or so. As a content creator in AI, I fortunately try out all the models and collaborative dev tools early on. Along the way, I have started building collaboratively alongside coding models such as Claude 3.7 Sonnet and Gemini 2.5 Pro. Using these tools is turning out to be a skill in itself.
Before the software world goes through a complete transformation, I thought I would pen down my learnings. (All condensed and crisp. So you can read quickly and get back to work). Well, get AI to work 😄
Below is my ever-growing list of things I have learned.
Model/tool level tips
- MCP is a steroid. While your AI model is good at coding, it often needs access to documentation, schema definitions and as such access to several tools. For example, to write SQL queries and change the DB schema, your AI model needs to know what your SuperBase schema looks like. This is where MCP is handy.
- Claude.md. I am assuming you are using Claude's family of models as your pair programmer. Mention all sorts of things like project information, conventions, and frequently used commands in this. As such, dump as much info as possible in this file so that your model works consistently and follows standards. Make the most of this file or its counterpart based on the coding model you use.
- Cursor rules. If you are using an IDE like Cursor for your collaborative coding, make use of cursor rules. I use Cursor and so mentioning cursor rules here. There are user rules and project rules. Project rules are shared across everyone in the project while the user rules are specific to you. Provide system-level guidance in these. Define your context, preferences, or workflows in this. As such make sure the settings are right for your IDE.
Prompting tips
Needless to say, English is the new programming language. So professional prompting means professional, working code. Simple.
- In almost all of my prompts, I add a like at the end that goes, “Do not make any code changes until you are absolutely confident about the changes. Ask follow-up questions if you are not confident enough”.
- Don’t ask for too much in one prompt. In other words, don’t “one-go” it. For example, “Build a platform for selling products. Companies should be able to log in as sellers to post their products. Buyers should be able to browse the products and buy any of them. They should also be able to bid … “. You know where I am going with this. Yes, I just asked AI to build e-bay 😐
- Be very specific instead. Here is one example:
Write a function in python that takes an image file, encodes it using uuid2 and stores it in the file system under “uploads”. Raise an exception if the file is not an image or if there is a problem with storage.
- Build incrementally. Here is a continuation of be above prompt.
Verify if the user is authenticated. Also verify if the user is authorized for file uploads. If authorized, invoke the file upload function with the uploaded file.
- Definitely off-load the boilerplate. For instance, if you are an ML Engineer, you will write the code to read data and feed it to the model for inference a few times a month. This is boilerplate and the coding models are so good at these.
- Treat AI like a junior dev or pair programmer. If you have a huge feature in. mind, first break it down into smaller chunks. As engineers, we always do this. So why not to the LLM too? Prompt for the smallest chunk possible at a time. Build incrementally as you would as a developer.
- Never ever lose or switch context.
If you are working with a junior developer on a feature, would you ask him/her to drop it and move on to something else? I probably wouldn’t.
Similarly, if you started a chat window to build a feature, chat your way to completion before closing the chat or moving on to another chat/topic. As we are working with bots, we can get away with storing the chat rather than discarding them. But don’t end up in tab nightmares as we do with Chrome browser 😆
- When in doubt, I ask for the plan before coding. Start with the prompt “Tell me your plan of action. Don’t code yet” if you are overly concerned it will screw up some sensitive code.
- Lastly, I try to make it TDD so that I am sure what it has written actually works. The prompt goes like, “Write tests first. Then code. Update the code till the tests pass”.
UI tips
An image is worth a thousand words.
If you are full-stack and developing UIs, you don’t have to do a pro-level figma design. But at least a quick sketch (like the one below) and uploading the image along with your prompt could produce way better outcomes.

The above is far better than the prompt, “I want you to build a UI with React and Tailwind CSS. I want a header with the logo on the left and sign-up, login buttons on the top left. I would also like a side panel with buttons, a dashboard, a sales report, and settings on the panel.
- Once you have a basic UI code churned out from the LLM, start iterating by uploading screenshots of the result to see results far more quickly
- Get very specific as to which files to change. For example, for the UI changes I generally say, “Just build the react components with buttons and links. Do not make any actions or server calls yet”. You can even provide the list of files to change if you want to be more involved.
Hope that helps. Will keep posting as I keep learning!