What I've Learned Building with AI Agents
Lessons from building projects with AI coding agents: planning work, reviewing output, and keeping project instructions.
I am building my side project with AI coding agents. They write the code so I can focus on the engineering work: deciding what to build, clarifying requirements, reviewing output, and steering the project. Since this is not my first project built with AI, I want to share a few lessons I've learned.
My Setup
- Alacritty as terminal emulator
- Codex/Claude TUI (terminal UI)
- Vim (partially, still learning)
- Cursor (as an IDE) - sometimes I use Claude/Codex directly there.
Basics - folder structure of the project with AI
I am writing this section because later in the article I am talking about some files AI agents are using, and I realized not all people know about them.
Many AI coding tools can use project instruction files to understand a codebase’s conventions and workflow.
What is a Markdown file?
Markdown is a lightweight markup language that you can use to add formatting elements to plaintext text documents Source. You can add # before text to create a heading, or wrap text with ** to make the text bold in a renderer such as Obsidian. You can also read the Markdown file as plain text as well.
What files are used by AI?
Claude uses CLAUDE.md, while Codex can use AGENTS.md. Because I switch between tools, I keep my shared instructions in AGENTS.md and reference that file from CLAUDE.md.
Tip #1 - Do not use new tools
Do not use a new tool unless your goal is to learn a new tool, or you want to address some problem or bottleneck you have. I have used a TUI from the beginning and it works well for me. I don't think I need to use a new tool.
Every week a new version of an existing tool or a brand-new tool comes out - Cursor, T3Code, Codex, Hermes Agent, OpenCode etc.. Don't forget - there is always a learning curve! And your goal is probably to build and ship the product, not to learn a new tool. So be careful when you decide to pick a new tool. If you want to learn and improve your workflow - go for it. Otherwise you will end up only improving and not building.
Tip #2 - Learn to use the plan mode
One of the best parts of AI coding, and the thing that took my workflow to another level is the plan mode.
In an execution mode, when you type your request and press Enter, an agent may immediately begin implementing the request. The end result may not match what you had in mind.
By switching to plan mode - enabled through a tool-specific command or UI control - you can discuss the approach first, answer questions and catch the missing details before code is written.
Tip #3 - The code review
I often hear in YouTube videos and on X that we can stop reading generated code. That's both true and untrue. It really depends on the quality of your prompts.
If you expressed yourself clearly, the code is probably doing what it should. If your prompt looks like this:
Write a function that will return a number between 1 and 10
The agent may infer that you mean a random number - or it may not. Tip #2 should reduce how much time you need to spend reviewing.
Writing the unit tests with AI is a really big plus, but it will only write the test cases you tell it to write. Last week, I entered this prompt:
Let's add the unit tests for the web application in this project
AI installed all the packages such as Jest, but it added only a simple check for the main route page and called it a day. It took a couple of prompts to address that, but without an actual review, I would have the impression that the code was well-tested.
Pay Attention to Instruction Files
This is not a tip - it should be the default when using AI coding agents.
Pay attention to what is in your AGENTS.md or CLAUDE.md files, as it can save you a lot of time repeating yourself.
These files give the agent project guidance. For my monorepo project with React Native, this is part of my AGENTS.md.
## React Native Best Practices
### Component structure
- One component per file. Sub-components used only by one screen live in a corresponding folder.
- Keep screens as orchestrators: data fetching + state + handler wiring. Render logic goes in sub-components.
- Extract reusable logic into custom hooks under `src/hooks/`. Name hooks `use<What>`
### TypeScript
- Always type navigation props: `NativeStackNavigationProp<RootStackParamList, "ScreenName">`.
- Define shared types explicitly — avoid `typeof someArray[0]` as a type alias.
- Use `type` imports (`import type { Foo }`) for type-only imports.
And the best part - you can ask Claude or Codex to update those files for you.
Thank you for reading, and see you next Monday.