You're staring at a Rails schema with 47 tables. The foreign key relationships are a bowl of spaghetti — timestamps everywhere, no documentation, and three different conventions for the same concept. Your PM wants a new feature by Friday. You open Copilot, paste the entire schema, and ask for a migration.
The AI generates something that looks right. You ship it. Three weeks later, you find out it created a circular dependency that takes down the checkout flow every time order history gets queried.
This isn't a Copilot failure. This is a Context Composting failure — the moment you started designing your database schema not for your application's actual requirements, but for what an AI model could reason about in a single prompt window.
I found this pattern dissected in a Japanese developer's post on Qiita that broke down exactly how Japanese Rails teams are thinking about Copilot context strategy differently than Western devs. The post — "トークンをケチるな、設計しろ：GitHub Copilotを賢く使うコンテキスト戦略" (Don't be stingy with tokens, design properly: A context strategy for using GitHub Copilot wisely) — describes an approach that's equal parts technical and philosophical.
What Japanese Rails Teams Are Doing Differently
