are often divided right into a separate frontend and backend. The frontend handles what the user sees, while the backend handles all the logic and processing. This can be a natural separation of concerns that the majority platforms simply use because it really works well.
Nonetheless, whenever you make changes to your application, you frequently must make changes to each the frontend and the backend. That is where full-stack engineers are available: engineers who work with each the frontend and backend.
Working with each frontend and backend will be difficult, nonetheless, on account of multiple reasons:
- They’re often written in numerous languages: frontend with TypeScript and the backend with Python
- You’ve to cope with permissions and auth, and cope with challenges like CORS errors
- They’re in numerous repositories and are deployed individually.
With the discharge of coding agents, working with each frontend and backend code at the identical time has change into simpler. In this text, I’ll provide you with a high-level overview of how I work every day with each frontend and backend code, and be sure the 2 systems integrate seamlessly.
Why work with each frontend and backend
The rationale you’re employed with each frontend and backend code at the identical time is just because of necessity. Let’s say you desire to add a brand new feature in your application, where a user can store their AI chatbot conversations and access them later.
This feature simply requires changes in each the frontend and the backend. You should update the frontend to display the previous conversations, and you would like the backend to handle the storage and retrieval of conversations. Thus, you don’t have an choice to work with each the frontend and backend code.
Moreover, as an engineer, it’s normally more practical to work with each frontend and backend. Imagine in the event you needed to implement the AI chatbot conversations feature, and also you were only working on the frontend. You’d then need to implement the frontend a part of the course, after which coordinate with one other backend engineer on learn how to store the conversations. You’d need to spend time discussing:
- The schema for storing conversations
- Which data ought to be included?
- What should the endpoint be called
That is super time-consuming. When you’ve ever worked in a processional software engineering setting, you understand how much time it takes.
As a substitute, in the event you do the work solo, you don’t need to do any coordination and may move at a much greater speed.
Techniques to work effectively with frontend and backend code
On this section, I’ll cover some techniques I exploit to work effectively with each frontend and backend code. With the discharge of a super-effective coding agent, this has change into much simpler, and also you don’t must have extensive experience in each frontend and backend code to be effective.
Use Workspaces
Workspaces are an incredibly powerful feature when working in multiple repositories. You’ll be able to do that with Cursor using “Add workspace”, or with any CLI tool by simply pointing the agent to the repositories you desire to work with. Now the model could have the context of each relevant repositories and thus have the ability to implement a full-stack solution in a single 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 within the frontend, and manually update the backend to simply accept this latest change.
No wonder it took ages for me to place out features. Now, I simply prompt my agent to update the frontend based on some instructions, and it robotically updates the backend with the corresponding code to simply accept the frontend changes. After all, this works the opposite way as well.
Monorepos
Monorepos are also super powerful. The other of a monorepo is to have your whole code spread into different repositories (normally known as microservices). In my experience, this doesn’t work thoroughly, because it simply makes it harder for you and your coding agents to maintain track of where all the things is.
As a substitute, I highly recommend moving all the things to a monorepo, where you’ve all of your code in a single codebase. Now you’ll be able to easily create rules, equivalent to pre-commit hooks, that apply to your whole code and don’t have to copy them across multiple repositories. Moreover, you’ll be able to easily have AGENTS.md files covering and explaining the entire repository, so agents easily keep track of where all the things is.
If all of your code is in a monorepo, you’d also not need workspaces, as I described within the last section. Nonetheless, it’s quite common to have a monorepo for the frontend/API code, after which a separate repository handling more complex processing, equivalent to running agents or doing document processing. Thus, you’ll often need to use workspaces anyway.
AGENTS.md as context
One other very essential tip is to actively use and update AGENTS.md. There are a lot of alternatives to AGENTS.MD, equivalent to CLAUDE.md, WARP.md, or .cursorrules. In my experience, nonetheless, AGENTS.MD is read by all coding agents, irrespective of which one you utilize.
Thus I like to recommend using AGENTS.md because in the event you ever change an agent in the longer term, or your coworkers are using different agents, you’ll be able to all profit equally.
You’ll be able to have an AGENTS.md file in the basis of your repository that gives a high-level overview of the repository, type of like a README. This may explain to the agent which folders contain which logic, making it easier for the agent to navigate the code.
Moreover, you’ll be able to have AGENT.md in all subfolders as well. For instance, if you’ve a service in a single folder, you possibly can have an AGENTS.md file there explaining how the service works, or any quirks to concentrate on.
I also need to add that every time you make changes to your code, remember to update AGENTS.md. You’ll be able to, for instance, prompt your coding agent to update the relevant AGENTS.md files for you, given what it learned in its last session, and it’s going to robotically add essential notes. Remember to push these changes to GitHub as well, in fact, so your colleagues can profit from the knowledge you’ve gained.
Conclusion
In this text, I’ve discussed learn how to effectively work with each frontend and backend code. I began off by explaining why it’s essential to know learn how to work with each frontend and backend, highlighting that it’s normally a more practical way of getting stuff done. Moreover, I elaborated on some techniques I exploit to work effectively with frontend and backend, covering the usage of Workspaces, monorepos, and AGENTS.md. I imagine that in the longer term, 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 of your agents in essentially the most effective way possible, in an effort to solve crucial problems, in the most effective and best 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
