are usually divided into a separate frontend and backend. The frontend handles what the user sees, while the backend handles all of the logic and processing. This is a natural separation of concerns that most platforms simply use because it works well.
However, when you make changes to your application, you often need to make changes to both the frontend and the backend. This is where full-stack engineers come in: engineers who work with both the frontend and backend.
Working with both frontend and backend can be challenging, however, due to multiple reasons:
- They’re often written in different languages: frontend with TypeScript and the backend with Python
- You have to deal with permissions and auth, and deal with challenges like CORS errors
- They’re in different repositories and are deployed separately.
With the release of coding agents, working with both frontend and backend code at the same time has become simpler. In this article, I’ll give you a high-level overview of how I work on a daily basis with both frontend and backend code, and make sure the two systems integrate seamlessly.
Why work with both frontend and backend
The reason you work with both frontend and backend code at the same time is simply because of necessity. Let’s say you want to add a new feature in your application, where a user can store their AI chatbot conversations and access them later.
This feature simply requires changes in both the frontend and the backend. You need to update the frontend to display the previous conversations, and you need the backend to handle the storage and retrieval of conversations. Thus, you don’t have an option to work with both the frontend and backend code.
Furthermore, as an engineer, it’s usually more effective to work with both frontend and backend. Imagine if you had to implement the AI chatbot conversations feature, and you were only working on the frontend. You would then have to implement the frontend part of the course, and then coordinate with another backend engineer on how to store the conversations. You’d have to spend time discussing:
- The schema for storing conversations
- Which data should be included?
- What should the endpoint be called
This is super time-consuming. If you’ve ever worked in a processional software engineering setting, you know how much time it takes.
Instead, if you do the work solo, you don’t have to do any coordination and can move at a much greater speed.
Techniques to work effectively with frontend and backend code
In this section, I’ll cover some techniques I use to work effectively with both frontend and backend code. With the release of a super-effective coding agent, this has become much simpler, and you don’t need to have extensive experience in both frontend and backend code to be effective.
Use Workspaces
Workspaces are an incredibly powerful feature when working in multiple repositories. You can do this with Cursor using “Add workspace”, or with any CLI tool by simply pointing the agent to the repositories you want to work with. Now the model will have the context of both relevant repositories and thus be able to implement a full-stack solution in one go.
Workspaces are incredible. Before I discovered it, I used to work with two separate Cursor tabs, one with the frontend code and one with the backend code. I’d then make one change in the frontend, and manually update the backend to accept this new change.
No wonder it took ages for me to put out features. Now, I simply prompt my agent to update the frontend according to some instructions, and it automatically updates the backend with the corresponding code to accept the frontend changes. Of course, this works the other way as well.
Monorepos
Monorepos are also super powerful. The opposite of a monorepo is to have all of your code spread into different repositories (usually referred to as microservices). In my experience, this doesn’t work very well, as it simply makes it harder for you and your coding agents to keep track of where everything is.
Instead, I highly recommend moving everything to a monorepo, where you have all your code in one codebase. Now you can easily create rules, such as pre-commit hooks, that apply to all of your code and do not have to replicate them across multiple repositories. Furthermore, you can easily have AGENTS.md files covering and explaining the whole repository, so agents easily keep track of where everything is.
If all your code is in a monorepo, you’d also not need workspaces, as I described in the last section. However, it’s quite common to have a monorepo for the frontend/API code, and then a separate repository handling more complex processing, such as running agents or doing document processing. Thus, you’ll often have to use workspaces anyway.
AGENTS.md as context
Another very important tip is to actively use and update AGENTS.md. There are many alternatives to AGENTS.MD, such as CLAUDE.md, WARP.md, or .cursorrules. In my experience, however, AGENTS.MD is read by all coding agents, no matter which one you use.
Thus I recommend using AGENTS.md because if you ever change an agent in the future, or your coworkers are using different agents, you can all benefit equally.
You can have an AGENTS.md file in the root of your repository that provides a high-level overview of the repository, kind of like a README. This can explain to the agent which folders contain which logic, making it easier for the agent to navigate the code.
Furthermore, you can have AGENT.md in all subfolders as well. For example, if you have a service in one folder, you could have an AGENTS.md file there explaining how the service works, or any quirks to be aware of.
I also want to add that whenever you make changes to your code, be sure to update AGENTS.md. You can, for example, prompt your coding agent to update the relevant AGENTS.md files for you, given what it learned in its last session, and it will automatically add important notes. Be sure to push these changes to GitHub as well, of course, so your colleagues can benefit from the knowledge you’ve gained.
Conclusion
In this article, I’ve discussed how to effectively work with both frontend and backend code. I started off by explaining why it’s important to know how to work with both frontend and backend, highlighting that it’s usually a more effective way of getting stuff done. Furthermore, I elaborated on some techniques I use to work effectively with frontend and backend, covering the use of Workspaces, monorepos, and AGENTS.md. I believe that in the future, we’ll all be full-stack engineers, considering how effective coding agents are. The work of a human engineer will simply be to coordinate all your agents in the most effective way possible, in order to solve the most important problems, in the best and most efficient manner.
👉 My free eBook and Webinar:
🚀 10x Your Engineering with LLMs (Free 3-Day Email Course)
📚 Get my free Vision Language Models ebook
💻 My webinar on Vision Language Models
👉 Find me on socials:
💌 Substack