Everything you wanted to know about using AI to help you code and/or to code for you.

Introduction

The way we interact with computers and write code for them is changing. And it's a profound change: on the tools we use, the way we code and think about software products and systems.

And it's changing super fast! New LLM models are being released every week. New tools, new editors, new AI coding and "vibe coding" practices, new protocols, MCP, A2A, SLOP, ... And it's really hard to keep track of all that. Everything is scattered in different places, websites, repos, YouTube videos, etc.

That's why we decided to write this guide. It's our humble attempt to put everything together and present you the practices and tools around AI coding or AI assisted code generation, all in one place, with no fuss, in an accessible form.

• If you're a coder but is not using AI code assistants yet, this guide is for you: it presents the most recent tools and good practices to make the most of them to help on your daily jobs. Either having AI as your copilot or being the copilot for an AI agent.

• If you never coded before but you're interested in this new "vibe coding" thing to build your own SaaS and other software products, this guide is definitely for you: We'll try to do my best to remove obscurity and leave you with what's required to start your journey, but being super critic about what is really important and what's "just hype".

Before we start, just a small suggestion on how to read this guide. We tried to organize it in a FAQ-ish way, so feel free to search and jump for possible answers to your questions. You'll see that every section as some "Resources" listed: we keep updating those resources and you'll find the most recent ones in the top of the list.

Like I said, AI changes a lot and in a daily basis, we try our best to keep this guide updated, but if you find anything missing, please feel free to open a PR or an issue, or even jump in your discord and share your new findings with us so we can include it here!

Cool, let's start!

📚 Resources:

• Zen of AI coding by Yoav Aviram
• How I use AI to code as a software engineer by Vilson Vieira
• What I learned using AI to code for a year by Vilson Vieira
• Software Survival 3.0 by Steve Yegge
• The death of the stubborn developer by Steve Yegge
• Software Is Changing (Again) by Andrej Karpathy
• Raising an Agent podcast by Amp team
• Become an AI-augmented engineer by Mary Rose Cook
• The 70% problem: Hard truths about AI-assisted coding by Addy Osmani
• Using LLMs for code by Simon Willison
• How to Build an Agent by Thorsten Ball
• Dear Student: Yes, AI is here, you're screwed unless you take action... by Geoffrey Huntley
• The revenge of the junior developer by Steve Yegge
• How to prepare for the future of development and AI by Santiago
• The End of Programming as We Know It by Tim O'Reilly

AI coding? Vibe coding? Agentic coding?

All those terms are pretty similar. But basically AI coding is about using AI models (specially LLMs these days) and all the tooling around it to help you write software. It's also called "AI for code generation" or "code gen" for short, and there's an entire fascinating field of research and engineering, that dates back to 1950's when we used Lisp to generate code. Now we have LLMs as main engines to power code generation, and there's also some threads on neurosymbolic hybrid approaches starting to show up. AI coding is also a practice: if you're using Cursor and tab-tab-tab your way to get completions, you're "AI coding"; if you're full on using Codex's agent mode, you're also "AI coding". In summary: it's any way to use AI models to help you generate code. Generally you have people who already know how to code in this group.

Vibe coding is AI coding cranked up :-) Here you don't care much about the code being generated, you just give a prompt and expect the AI to code everything for you. The term was coined by Karpathy in 2025 and it's getting pretty popular. IMHO it's helping to democratize coding for everyone that never thought about coding before!

And then we have a new breed surfacing: agentic coding. That's when you run an agent for many rounds, by itself, in a loop, ideally with some feedback signal (tests, etc). You can either run one agent or use orchestrators like GasTown to run many agents at same time, with minor to zero human interaction.

So, in summary, no matter if you're using AI to discuss your software ideas or to help on coding only parts of your already existing code base, or if you're full on vibe coding or if you let one or 100 agents running 24/7 without intervention, you're using AI to help you generate code. Let's call it AI coding and move on.

How can I use it?

You can use AI coding in many different ways, but in summary:

• AI is your copilot: you use AI models to augment yourself, to boost your productivity. Either by firing up ChatGPT to help you on brainstroming ideas for your SaaS; or using Cursor to autocomplete your docstrings. There are many gains here, specially for creative exploration and to automate boring parts of your work.

• AI is the pilot: here you are the copilot. This is where the "vibe coding" happens. You turn on the Cursor Agent YOLO mode or run Claude Code with --dangerously-skip-permissions flag set and trust everything the agents do to generate your code. Really powerful way to automate yourself, but demands some good practices on how to design systems, tame the agents and jumping in on a spaghetti of code you actually don't know about, specially to solve errors.

You should learn and practice both!

But lean more towards copiloting and away from pure YOLO vibecoding as project complexity scales up. The more likely it is that another human (or yourself in six months) will have to maintain the code, the more important this is.

🗺️ The Roadmap

How I start?

• If you don't know how to code and want to play with it, we recommend starting with some web-based tool like Bolt, Replit, v0, Suuper or Lovable.

• If you already know how to code, install Claude Code, Codex, Cursor, Amp or Windsurf. You can start with the free plan and then upgrade to $20 monthly plan. Claude Code Pro plan, Codex and Cursor are both pretty good and cheap, given you'll have tons of tokens to use on most recent LLM models out there. VSCode has its own Agent Mode as well. It pairs with Github Copilot and uses and Agentic Workflow to make changes and edit files.

• If you want a more open source alternative, try Pi (recommended), OpenCode or OpenHands.

Suggestion: We really recommend creating an account in OpenRouter. It's really easy and you'll get access to the most updated LLM models and even free versions of it.

Important note: Using Claude Code through their API/SDK is super expensive! You can easily burn hundreds of dollars a day without noticing. That's why it's recommended to start with Claude Code Pro or Max plans, so you don't have to worry about it. If you really need to use their API/SDK (either to embed it in your app or other use case), make sure to keep an eye on your usage, displayed on Anthropic's dashboard.

📚 Resources:

• Vibe Coding 101 with Replit
• Cursor AI Tutorial for Beginners (2025 Edition)

How I prompt for coding? AKA How I vibe code?

Before mid or end-2025, it was really common to LLMs hallucinate and enter in endless cycles to fix errors. Nowadays the models are really good, but it's still interesting to follow basic principles when using them to code:

• Do not ask everything in one prompt. Only prompting "hey, build me an app for my pet store" doesn't help a software engineer and much less an AI :-) Understand your project, brainstorm first with an LLM, create a PRD (Product Requirements Document), make a plan and split them in tasks. You'll find bellow a recipe on how to use ChatGPT to create one for you.
• Give it details. If you know what you want, say it. If you know which programming language you want, which tech stack, what type of audience, add it to your prompt.
• Markdown or any other light text-based format like asciidoc should be OK for LLMs to interpret. In the end the text will be encoded as tokens. However, to put emphasis in specific parts of your prompt it's recommended to use some symbols like XML tags.
• Break you project into tasks and subtasks. Remember that good software engineering practices are still important. Think of the agent as a "junior developer" you just hired: what kind of information would you write in a PR assigned to it that would maximize the PR to me approved and merged in the end?
• Try different models for different goals. For instance, Opus or ChatGPT are pretty good for planning, but you can use Sonnet or some opensource model like Kimi or Minimax to execute/implement the plan.
• Try different models to confirm and validate output of other models. You can even run them in parallel and choose the best one!
• LLMs are "yes machines", so apply critical thinking. Do not accept everything they send your way. Review it, test it. In the end they are just a tool and the code generated is still your responsibility.

In the rest of our examples we will use the .md file extension associated with Markdown If you prefer asciidoc (which has somewhat better support for structured documents) use that and substitute ".adoc" in these instructions. The LLMs don't care, they will handle Markdown or asciidoc or any other purely textual format you throw at them.

Here is a method/procedure/strategy/workflow that generally works well:

1. Use ChatGPT, Codex or Claude Code itself with the following prompt:

You're a senior software engineer. We're going to build the PRD of a project
together.

VERY IMPORTANT:
- Ask one question at a time
- Each question should be based on previous answers
- Go deeper on every important detail required

IDEA:
<paste here your idea>

2. You're going to enter in a loop of questions/answers for a few minutes. Try to answer as much as you can with as much details as possible. When finished (or when you decide it's enough), send this prompt to guide the model to compile it as a PRD (this is also called SDD, or Spec-Driven Development):

Compile those findings into a PRD. Use markdown format. It should contain the
following sections:

- Project overview
- Core requirements
- Core features
- Core components
- App/user flow
- Techstack
- Implementation plan

3. Copy and save this file into a docs/specs.md inside your project folder
4. Now let's create the task list for your project. Ask the following:

Based on the generated PRD, create a detailed step-by-step plan to build this project.
Then break it down into small tasks that build on each other.
Based on those tasks, break them into smaller subtasks.
Make sure the steps are small enough to be implemented in a step but big enough
to finish the project with success.
Use best practices of software development and project management, no big
complexity jumps. Wire tasks into others, creating a dependency list. There
should be no orphan tasks.

VERY IMPORTANT:
- Use markdown or asciidoc 
- Each task and subtask should be a checklist item
- Provide context enough per task so a developer should be able to implement it
- Each task should have a number id
- Each task should list dependent task ids

5. Save this as docs/todo.md inside your project folder
6. It's also really important to have an AGENTS.md (or CLAUDE.md if you're using Claude Code) in the root of your repository folder. You should see this file as an "agent README", so just like you keep a README.md for humans, keep one AGENTS.md for future agents that will read and edit your source code project! Important things to have: a summary of your project, what tech stack you use, how to install, how to test and deploy or run your project, where are the main PRD/specs/design or other relevant documentation, or even the main source code files. You can learn more about AGENTS.md and examples here.

Here is an example of a brainstorming/planning session done with ChatGPT 4o for a simple CLI tool, use it as inspiration for yours.

Now create a local folder for you project, remember to install and run git init inside the folder to keep it under version control.

This should give you the PRD and the tasks lists to build your project! With that in hands, you can run your Codex (or other AI code agent), point it to those files and ask:

You're a senior software engineer. Study @docs/specs.md and implement what's
still missing in @docs/todo.md. Implement each task each time and respect task
and subtask dependencies. Once finished a task, check it in the list and move
to the next.

And here you'll find the Git repos for a CLI tool built in 10 min based on the this workflow: https://github.com/automata/localbiz

Important: although it's super cool to "vibe code", it's also really interesting to know what you're doing :-) Reviewing the code the agent is generating will also help you a lot when errors happen (and they will!) and to improve your skills on code reviewing (not only made by AIs but by yourself and other developers).

📚 Resources:

• You are using Cursor AI incorrectly... by Geoffrey Huntley: here Geoff introduces his idea of using a stdlib of Cursor rules
• From Design doc to code: the Groundhog AI coding assistant (and new Cursor vibecoding meta) by Geoffrey Huntley: part 2 of the previous post, where Geoff suggests to use LLMs to build specs (PRD) and Cursor rules automatically
• My LLM codegen workflow atm by Harper Reed
• An LLM Codegen Hero's Journey by Harper Reed
• Claude Code: Best practices for agentic coding by Anthropic: it's towards their Claude Code tool but it has interesting tips for AI coding workflows based on any LLM model
• Prompt Engineering by Lee Boonstra from Google: it's a 70 pages doc with interesting tips on how to prompt engineer, with a section about code generation
• Prompt Engineering Guide by Anthropic
• GPT 4.1 Prompting Guide by OpenAI
• RepoPrompt is a tool to help assemble context from your project. It's worth watching an overview video of a RepoPrompt Workflow to learn how to easily leverage these tools to provide more context in your vibe coding prompts.
• Not all AI-assisted programming is vibe coding (but vibe coding rocks) by Simon Willison

Which LLM model I should use?

LLMs are trained and aligned with different goals. Models like ChatGPT or Claude are trained to be good generic-knowledge assistants in a chat with you. In other cases, labs capture the output of a model running tools and "reasoning" about the output of the tools in long sessions (from minutes to hours long), and use the feedback as a reward signal to the model, aligning the original trained model to the specific task. In the case of Claude Opus, Sonnet or OpenAI GPT, the task is coding. That's why it's important to always use models that were trained/aligned for coding/programming and that support tools.

Given LLMs change in a daily basis, it's impossible these days to suggest one specific version of a model that is good for coding. What we can do is to advice which "family" of models you should consider. Nowadays we have proprietary LLM models like Claude Opus and OpenAI GPT as SotA for AI coding; and open source models like Kimi, Minimax and GLM that are always in the tail of the proprietary ones, decreasing the delta more and more on each release.

To know which model version to pick, the general advice is to select the latest one, or please check the following leaderboards for more accurate comparison:

• Models.dev: An open-source database of AI models
• OpenRouter's Models: Set categories as programming and also filtering only the models that support tools is generally a good way to select models for AI assisted coding
• Agent Leaderboard

What to do when the dreaded "rate limit" message hits

Switch to a different model.

There are at least two different reasons this can happen. You can make a heavy request that exceeds the model's input/output token limit. Or, if the server cluster it's running on is having a bad day, you may be throttled to reduce the load. The error messages you get are often not transparent about this. You can find a more detailed explanation here.

Different models have very different token limits. For example, as I write in late April 2025, gpt-4.1-mini is much more generous than gpt-4.1. Have several API keys in your pocket (this is inexpensive, since you pay as you go) and visit the pages describing rate limits. Here's Anthropic's as an example.

How do I set up project-wide rules?

You can define rules or conventions that will be applied to your project by "injecting" them in the context of the LLM. Each editor have some ways to do it:

• For almost any agent except Claude Code, create an AGENTS.md file in the root folder of your project. Check https://agents.md about more information about how to create it and examples
• For Claude Code, just create an CLAUDE.md file in the root folder of your project. Anthropic didn't follow the AGENTS.md standard, so one good practice is to actually create an AGENTS.md file and then create a symbolic link from CLAUDE.md to the AGENTS.md file. You can also do the same by creating a CLAUDE.md file @AGENTS.md as the content.
• In Cursor, just create markdown files inside a .cursor/rules/ folder. Cursor will make it sure to apply those on all communication with the LLM.
• In Aider, create markdown files with rules/conventions you want to use (like rules.md) and add the following in your .aider.conf.yml file: read: rules.md.

Also, many tools support configuring a rules/conventions file in your home directory to be applied to all your projects. For instance, in Aider you can basically add global conventions in a file called ~/.global_conventions.md and then add it to the .aider.conf.yml with read: [~/.global_conventions.md, rules.md].

You can add part of your PRD as rules, for instance, like the tech stack or some guidelines on code formating and style.

Rules are super powerful and you can even use the AI itself to create the rules for you! Check Geoff's method on that.

📚 Resources:

• AGENTS.md
• Cursor Rules Docs
• Windsurf Rules Docs
• Aider Conventions Docs
• Aider Conventions Collection: a collection of community-contributed convention files for use with Aider.
• Awesome Cursor Rules: a curated list of awesome .cursorrules files for enhancing your Cursor AI experience.

How I avoid hallucinations? What is a PRD?

PRD. What?! They say that the best ways to solve a problem in engineering is to create a new acronym and here it's no exception :-) J/k... PRD is short for Product Requirements Document. Basically, it's just a bunch of docs (or only one doc) describing the requirements and other details about your software project.

Turns out, if you leave your loved LLM free, with not much context of what to do, it will hallucinate pretty wild and quick. You need to tame the beast and PRDs are a great way to do it.

What I most like about PRDs is how they are super helpful to anyone, from people who never coded before to senior SWE or product managers.

You don't need any background to start a PRD, you just need your idea for an app and that's it, but it really helps to know the fundamentals of software design and details about the tech stack/framework you're using our planning to use.

Check here how to use a LLM to create one for you.

Keep a prompt log

Record every prompt you send, with (this is important) your interspersed comments on what you were thinking and any surprises you got. This prompt log is your record of design intent; it will be invaluable to anyone approaching the project without having been involved in it, including you in six months after you have forgotten what you were thinking.

There isn't any convention for the name of this file yet, you can use something like vibecode.adoc or history.md.

There are tools like aider that keep a log of all the back-and-forth chat you had with your LLM. So one option is to set the following env vars and keep all those history files under version control:

# History Files:

## Specify the chat input history file (default: .aider.input.history)
#AIDER_INPUT_HISTORY_FILE=.aider.input.history

## Specify the chat history file (default: .aider.chat.history.md)
#AIDER_CHAT_HISTORY_FILE=.aider.chat.history.md

## Log the conversation with the LLM to this file (for example, .aider.llm.history)
#AIDER_LLM_HISTORY_FILE=.aider.llm.history

With those files in hand, you can then comment on them with your own thoughts while you go. You (and others) can learn a lot about your project when you revisit it in the future, and you'll probably start noticing patterns and tips you can use in your next sessions.

Agent harnesses like Pi or Amp also allow you to keep and share the coding sessions. To do that in Pi, just type /share and it will create a GitHub gist with it and generate and easy to share and URL for a cool UI to visualize it.

How I start my project?

Webapp (Frontend)

Modern Web development is pretty overwhelming. There are tons of JavaScript/ TypeScript frameworks, CSS frameworks, engines, deployment services, etc so it's really hard to get started and think about which one to use. After spending last months building frontends, that's what I generally suggest:

• TanStack Start: you get a powerful React framework and you are free from Vercel or any other provider, so you can deploy anywhere you want
• Next.js: it's still the most popular React framework out there, but you'll be dependant of the Vercel ecosystem, which is good and bad
• FastHTML: if you love Python and care more about exposing a core backend functionality (eg some data analysis, or AI/ML model pipeline) than super pretty UI

If you're also coding the backend, make sure to have either one folder for backend and other for frontend in your root folder for your Git repos; or have different repos for backend and frontend, and then add them to the same workspace in Cursor (so you can reference files of backend in your frontend agent and vice-versa) or run Claude Code or other CLI-based harness in the root folder.

To avoid integrating the frontend into the backend too early, instruct the AI agent to use mock/dummy data instead, so you can update it later once you have the backend implemented.

Another interesting tip is to use good MCP tools to integrate your coding agent to playwright or browser-use. This way you can avoid the copy-paste cycle of errors from the web browser into your AI agent, given the AI will control the browser and grab screenshots and errors messages by itself. You can use bash commands to that as well, if you are like me and don't like MCP.

If you want to use 3D content in your webapp and you're using React, it's interesting to use React Three Fiber instead of trying to use the three.js library directly. R3F makes it easier to deal with state given it wraps all three.js objects as React components.

Backend

Backends are not flexible or really scalable in Web based tools like Lovable. So you will probably need to get your hands at Claude Code, Codex or any other non-Web-based tool.

Using Python and FastAPI is a great option. If you prefer to stay with the same language of your frontend (guessing it will be JavaScript or TypeScript most of the time), you can use Nodejs or Bun. For most of the API endpoints needs of your TanStack or Next.js frontend, you can use Server Functions (or Server Actions), so no need for a separated backend.

Backends are a great target for end-to-end tests, so consider guiding the agent to write tests and run them for each new feature and its subtasks.

Once you're done with you backend, you can use its documentation (specially on HTTP endpoints) as input for the agent working in your frontend. This way you'll be able to move your frontend from using mock/dummy data to real one coming from the backend.

Game

For small games, use vanilla JS in a single .js file and use threejs for 3D games or pixijs for 2D games.

Games are all about good assets, so consider using services like Tripo AI and Everything Universe to generate 3D assets and rig/animate them.

How I deal with errors and bugs?

One thing you must know about coding and software in general: they will fail. No matter what you try to prevent that, it will happen. So let's first embrace that and be friends with errors and bugs.

The first strategy here is to mimic what SWE do: see what the interpreter/compiler gave to you as an error message and try to understand it. Copy and paste the error back to the LLM and ask it to fix it. Another great idea is to add MCP tools great for debugging like BrowserTools or connecting Claude Code or other agents to your local Chrome. It's also possible to use headless browsers through Playwright in remote development or if you don't want to use your current local Chrome.

What's MCP, SLOP and A2A and how can I benefit from it?

Update March 2026: Nowadays, we know that giving bash as a tool for agents is generally enough as an alternative to MCP: the agent can use curl to call APIs or run other commands, in a more efficient way (eg consuming much less tokens). But MCP is still interesting for some use cases.

MCP is short for Model Context Protocol. It was developed by Anthropic but it's starting to be considered by other LLMs like OpenAI's GPT and Google's Gemini. It's a powerful concept and it's pretty linked to another one: function/tool calling.

Tool calling is a way for LLMs to call tools or functions to execute some operation. It's a way to update the knowledge window of a LLM (trained on data from the past) with new information and at same time to integrate it with external tools and endpoints. For instance, if you want to search the web for some information, you can instruct the LLM to use a tool that does that (eg Hey, if you need to search for something on web, use this tool: search(term)). Then, instead of spending many tokens, iteration steps and parsing workloads, the LLM will call the tool, get the output and use it when generating new predictions for you.

MCP extends this idea by creating a standard for it. This way we can create a MCP server that will expose some resource (a database, for instance) or tool (a specific piece of software that will compute something and return the results, for instance) to the LLM.

Wait, but it's not just an API? Couldn't I just mimic the same with a REST API server/client and some parsing in the LLM prompts? Kinda, and that's what SLOP (Simple Language Open Protocol) proposes. However, having a standard like MCP makes it easier to make sure the LLM will support it natively without extra parsing and tricks on the client side.

A2A (Agent to Agent Protocol) was created by Google to "complement" MCP, focusing on multiagent communication while MCP focuses on LLM-tools communications.

One more thing before we go: if you are using a harness like Pi that doesn't support MCP, no problem, you can basically wrap your beloved MCP tool as a CLI, and then just let PI call it using the bash. Just use mcporter to do the trick.

📚 Resources:

• MCP
• MCP is Dead; Long Live MCP!
• Anthropic's ilist of MCP servers
• SLOP
• Introducing SLOP
• MCP vs SLOP
• A2A

Start from scratch or with a boilerplate?

Generally LLMs do better starting fresh. But you can also start with a boilerplate (basically a starter kit: a folder with initial skeletons of minimal source files and configs needed to get a working project running for a specific tech stack) and add rules in the context window to make it sure it will respect your starter kit.

Another great idea is to index your project (that you just created with the starter kit) using Cursor's own indexing feature, or using some tool like repomix or files-to-prompt.

Greenfield/clean state/fresh project vs existing codebase

If you have an existing codebase, a good idea is to use repomix or files-to-prompt pack it into the context window.

Another great tip is to prompt for changes at task level and not in project level. For instance, focus in one feature you want to implement and ask Cursor Agent to implement it. Give a mini-PRD for the specific feature. Imagine that you're guiding a junior developer to work in a specific GH ticket :-)

📚 Resources:

• Karpathy's tweet about his way to use AI-assisted coding
• How to work with large codebases in Cursor

Well-structured prompting for well-structured design

At present (in April 2025) LLMs are already good at generating working code, but they're not very good at generating well-structured code - that is, with proper layering and separation of concerns. Good structure is important for readability and maintainability, and reduces your defect rate.

Think through your design and then prompt-engineer it in a sequence that produces good structure. In a database-centered application, for example, it's a good idea to specify your record types first, then guide your LLM through building a manager class or module that encapsulates access to them. Only after that should you begin prompting for business logic.

More generally, when you prompt, think about separating engine code from policy code, and issue your prompts in a sequence that guides the LLM to do that.

You should include in your project rules, one that tells the LLM not to violate layering - if it needs a new engine method, it should add something to a clean encapsulation layer rather than having low-level implementation details entangled with business logic.

Another interesting practice is to start with the core of you project and spend time making sure to get the main functionality implemented and organized the way you want. You can even write classes and functions skeletons and then let the LLM fill the gaps. Only after you have a good foundation and with good tests you can move to consumers of this core library, like exposing it as CLI or REST API to a future webapp, for instance.

Should I use TDD or any other type of tests?

Yes, definitely yes. Tests are more important than ever. At current state of the art in 2026, LLMs are good at generating clean and correct code, but they sometimes hallucinate, and more importantly, they can fail at understanding specifications and generate correct code to do the wrong thing.

It is not likely that this will change even if and when we get full human-equivalent artificial general intelligence, after all, human beings misunderstand specifications too! Ambiguity of language is why tests will continue to be important even into the future.

Using TDD to create skeletons of what you want as result can really help guiding LLMs to implement the target piece of code you're testing. Instructing your LLM to create tests and to run them is also a great practice: it will be able to add possible errors breaking a given test to its context and act on it, trying to make the test pass.

Tests are fundamental for growing your code base together with a LLM, only moving forward when all current tests pass.

Property-based tests are really interesting when working with LLMs. Testing for a whole domain/range of values instead of just specific ones that you pinpointed will help making sure the code generated by the agent will still be valid even if later changes end up hitting edge cases you didn't think in advance. There are good libraries for property-based tests in every language, like hypothesis for Python or fast-check for JavaScript/TypeScript.

It's also important to always check the code generated by LLMs while trying to write or fix a test: sometimes they will even try to generate some hardcoded output just to make the test pass :-)

How to make it safe?

The exact same rules and best practices advised for non-AI assisted coding are valid here. Research more about them and apply to your code. Here an initial safe-check list:

• Don't trust the code generated by an AI. Always verify. Remember that the AI will not be responsible for the code you run out there, YOU WILL!
• Do not store any API keys or other secrets as hardcoded strings, and specially in frontend code. Store on backend as protected environment variables (eg platforms like Vercel offer this option)
• When querying API endpoints, always use HTTPS
• When creating HTML forms, always do input validation and sanitization
• Do not store sensible data in localStorage, sessionStorage or cookies
• Run validators and security vulnerability scanners in your package requirements

How to use any LLM in Claude Code?

You just want to try Kimi K2 or other LLM in your Claude Code CLI? You can use claude-code-router to make Claude Code CLI use a "proxy" running locally at your machine to route it to any model available at OpenRouter! The instructions bellow work for Kimi K2 but you can adapt it to any other LLM you want.

First create an account at OpenRouter and grab your API key.

Make sure you have Claude Code CLI installed:

npm install -g @anthropic-ai/claude-code

Then install claude-code-router:

npm install -g @musistudio/claude-code-router

Add the following lines to your ~/.claude-code-router/config.json file, replacing OPENROUTER_API_KEY with your API key from OpenRouter:

{
  "Providers": [
    {
      "name": "kimi-k2",
      "api_base_url": "https://openrouter.ai/api/v1/chat/completions",
      "api_key": "OPENROUTER_API_KEY",
      "models": [
        "moonshotai/kimi-k2"
      ],
      "transformer": {
        "use": ["openrouter"]
      }
    }
  ],
  "Router": {
    "default": "kimi-k2,moonshotai/kimi-k2"
  }
}

Now just run Claude Code through the router:

ccr code

You should see Claude Code API Base URL: http://127.0.0.1:3456, which means it's using the local proxy created by claude-code-router. That's it!

If you're only interested in Kimi K2 or other models from Moonshot, an alternative is to use the model provided by Moonshot itself: https://github.com/LLM-Red-Team/kimi-cc/blob/main/README_EN.md

How to create my own AI coding agent?

The best intro is this practical tutorial by Thorsten where you build a simple agent that uses basic the minimal amount of tools (list_files, read_file, edit_file) in Go, step-by-step.

I also wrote another tutorial on how to create your own AI coding agent here. It's just 150 lines of Python and gives you an idea of what happens under the hood of an agent harness.

If you want to go deeper, this series of open source books by Gerred is definetely a great start.

What the hell are multi-agent orchestration?!

Around 2024-2025 people started flirting with the idea of running not only one but a team of agents to perform a given coding task. By end of 2025, Steve Yegge and others created the first implemnetations around the concept. Gas Town is probably the most popular so far. In Gas Town you have one agent called Mayor who receives a task from the user and split it in jobs (storing and managing those jobs in Beads, another tool created by Yegge, think "GitHub issues but for agents"). The Mayor communicates with other agents (eg Polecats, the workers) by messages, so every agent has its own mail box and act when some message is received.

There are other incarnations of multi-agent orchestration like Claude Flow and Loom, but everything it's really early to know if that's the way we'll end up developing software in the future. It's important though to play with them, understand their inner workings, but one small advice: running Gas Town and other orchestration systems is pretty expensive, those agents running in parallel can eat tons of tokens in seconds.

• Welcome to Gas Town
• The Future of Coding Agents
• Gas Town Emergency User Manual

✨ Tips and Tricks on Specific Tools and Agents

Claude Code

• Claude Code Guide: Covers every discoverable Claude Code command, including many features that are not widely known or documented in basic tutorials

🛠️ Tools

Here we keep an updated list of main tools around using AI for coding. We tested most of them and you'll find our honest opinion during the time we tested them.

Editors / IDE

• Cursor
• Windsurf
• Cline
• OpenHands
• Devin
• VSCode + GitHub Copilot
• Amp
• Kiro

CLI

• Claude Code
• OpenAI Codex
• Pi
• opencode
• Gemini CLI
• Aider
• Claude Engineer
• Roo Code
• Codebuff

Webapps

• Bolt
• v0
• Replit
• Suuper
• Lovable
• Firebase Studio

Background/remote Agents

• ZenCoder
• CodeRabbit
• Factory AI
• OpenAI Codex

Helpful Tools

• Specstory
• Claude Task master
• CodeGuide
• repomix
• files-to-prompt
• repo2txt
• stakgraph
• Repo Prompt
• Uzi
• Claudia

🤗 Who to follow

Some super interesting people implementing AI coding models/tools or using it on their own projects.

• Addy Osmani
• Andrej Karpathy
• Armin Ronacher
• Beyang Liu (Amp)
• Cat Wu (Claude Code)
• Eric S. Raymond
• Eyal Toledano (TaskMaster)
• Geoffrey Huntley
• Gerred Dillon
• Harper Reed
• Mario Zechner (pi)
• Nathan Wilbanks (agnt, SLOP)
• Pietro Schirano
• Quinn Slack (Amp)
• Sandeep Pani (Aider, AgentFarm)
• Simon Willison
• Steve Yegge (Gas Town, Beads, Wasteland)
• Vilson Vieira
• Thorsten Ball (Amp)
• Xingyao Wang (OpenHands, AllHands)

💖 Acknowledgements

This guide was inspired by the great llm-course from Maxime Labonne.

Special thanks to:

• Gabriela Thumé for everything ❤️
• Albert Espín for thoughtful feedback and the first error corrections
• Geoffrey Huntley for pointing me to property-based tests and for all his great tutorials and experiments around autonomous agents
• ChatGPT 4o for generating the banner you see on the top, inspired by the incredible artist Deathburger

⭐ Contributing

If you want to contribute with corrections, feedbacks or some missing tool or reference, please feel free to open a new PR, a new issue or get in touch with Eric or Vilson.

If you like this guide, please consider giving it a star ⭐ and follow it for new updates!

Star History

⚖️ License

MIT