Case 06 Rails · React · AI-assisted development
Relevant context: Rails and React in one repository
On a NAK project in Germany, I proposed keeping the Rails backend and the React frontend in the same repository. The team preferred separate repositories; I explained the trade-offs and the proposal was adopted.
Context
The project is a goal-oriented employee management system for NAK in Germany, with direct contact with international clients. It is a different project from other NAK work mentioned on this site.
Development relied on AI assistants day to day, to implement features, fix bugs and answer questions about the system.
Problem
The team followed the familiar pattern of separate frontend and backend repositories. In AI-assisted development that has a subtle effect: when investigating a bug or building a feature, the assistant sees one side of the contract and has to guess the other.
Too little context hides contracts and dependencies. Too much irrelevant context distracts from the actual problem.
My responsibility
I proposed keeping the Ruby on Rails backend and the React frontend in the same GitHub repository. Other developers initially preferred the usual separation.
I explained my reasoning and the trade-offs, and the team adopted the shared repository.
Decision
Keeping related code together makes it easier to inspect both sides of a feature or a bug, while still selecting only the context each task needs.
The decision is not "put everything in the prompt". It is about keeping relevant context within reach so it can be chosen.
In AI-assisted development process: Context is King.
Alternatives and trade-offs
Present-day analysis written for this site. It is not a record of the alternatives evaluated at the time.
- A shared repository has costs too: pipelines, permissions and conventions must account for both parts, and the codebase grows.
- It does not, on its own, guarantee better AI answers. Separate repositories can work well with other ways of exposing contracts, such as versioned API specifications. What matters is being able to gather the right context for each task.
Implementation
How the decision shows up in daily work:
Visible contract
Component, API call, controller and serializer are reachable in the same search, and contract changes show up together in review.
Selected context
For each task, the assistant gets the files that matter from both sides, not the whole repository.
Human verification
Answers are still reviewed and tested; better context reduces guesswork but does not replace judgment.
Visualization
Separate repositories
React frontend
ReportStatus.tsx(in context)api/reports.ts(in context)useReportStatus.ts(in context)Sidebar.tsx(in context)theme.css(in context)
GET /reports/:id { id, title, ??? } (guessed shape)Rails backend
reports_controller.rb(out of context)report_serializer.rb(out of context)report.rb(out of context)mailer.rb(out of context)seeds.rb(out of context)
The assistant sees the frontend. The contract with the backend has to be guessed.
Likely answer: Suggests changing the component, unaware that the serializer never sends the field.
Shared repository, selected context
React frontend
ReportStatus.tsx(in context)api/reports.ts(in context)useReportStatus.ts(in context)Sidebar.tsx(out of context)theme.css(out of context)
GET /reports/:id { id, title, status } Rails backend
reports_controller.rb(in context)report_serializer.rb(in context) missing the status fieldreport.rb(in context)mailer.rb(out of context)seeds.rb(out of context)
The relevant files from both sides enter the context; the rest stays out.
Likely answer: Points to the missing field in the serializer and adjusts both sides of the contract.
Outcome
In my experience on that project, feature work and bug fixes became faster, and questions about the system received more accurate and useful answers, because the assistant could inspect frontend and backend together.
These are qualitative observations. I do not have a measured percentage improvement to publish, and a monorepo alone does not guarantee better answers.