The post has been translated automatically. Original language: Russian
A fresh review: a simple trick for those who code with AI every day, If you work with the same AI assistant on the same project every day, you've probably noticed this moment: somewhere in the second week, the dialogue begins to feel not like a conversation with an independent interlocutor, but like a conversation with a human who is already completely on your side. He remembers all your decisions and stops challenging them.Why is this happeningThis is not a glitch or "fatigue" of the model — it is a measurable phenomenon that is called context rot in the industry: the longer the dialogue history, the worse the model prioritizes within it. The Chroma study, which tested 18 modern models, showed that accuracy decreases as the input context grows noticeably earlier than the stated window ends — sometimes by 30-50%, even when the necessary information formally "fits in". An earlier Stanford paper on the "lost in the middle" effect shows a similar picture: the model remembers what was said at the beginning of a long dialogue worse than what happened recently, and tends to rely on logic that has already been established in the dialogue rather than revisiting it.This is not critical for everyday chatter. For a project that you've been developing with AI for weeks, it's critical: the model gradually ceases to be useful to you exactly where you need it most— in the ability to say "and that's where you seem to have made a mistake."Reception: a fresh review Solution is simple and does not require anything special — neither a second account, nor a more expensive tariff. It is enough to periodically open a new chat with the same assistant, show him the current state of the project without any background and ask for an honest, independent review. Without the history of the decisions you made a week ago, the model owes nothing to your logic — it looks at the code or document the way a new person would look at a project for the first time.This is the same principle as in a regular code review: the developer who wrote the code often does not see the obvious problems precisely because he is too deep into them. A fresh reviewer sees them in a minute.An important point to consider right away is that you don't need to clash the old and new chat rooms with each other, showing one the other's answers. As soon as the model learns someone else's opinion, she either begins to object to it out of principle, or, conversely, agrees — in both cases, the independence of the assessment is lost. The correct scheme is to keep them completely isolated: one leads the project, the other just looks at it honestly.How to integrate this into your workflow- The working chat is the one that is "ingrained" in the project — leave it for daily development: it keeps the context of decisions, the history of edits, the reasons why something was done the way it was done. It's not a disadvantage, it's his strong point.- Open a fresh chat consciously, not only when you run into a limit: before the meeting of a large chunk, before the release, when something cannot be explained, or just once every one to two weeks - as a scheduled review.- Let's give a fresh chat a minimum of background: just the code, the task, and the question. The less you explain "why we decided that," the more honest the answer will be.- Treat the comments of a fresh chat as a signal for verification, and not as a ready verdict - he does not know about the business restrictions or technical debt that you agreed on earlier. Sometimes his criticism will be missed; but more often it points exactly to where you yourself have already stopped looking.Bottom line, at CQ Systems, we noticed this for ourselves at some point - not on purpose, but simply because, when working hard, we periodically ran into limits and switched between chats. It turned out that this was not a crutch, but a working practice: to keep one instance deep in context and in parallel, consciously, bring the second one — without history — as an objective controller. No need to wait for the limit to force you to do it. You can just make a habit of it.
Свежий ревьюер: простой приём для тех, кто кодит с ИИ каждый деньЕсли вы каждый день работаете с одним и тем же ИИ-ассистентом над одним и тем же проектом, вы наверняка замечали этот момент: где-то на второй неделе диалог начинает ощущаться не как разговор с независимым собеседником, а как разговор с человеком, который уже полностью на вашей стороне. Он помнит все ваши решения — и перестаёт их оспаривать.
Почему так происходит
Это не глюк и не «усталость» модели — это измеримое явление, которое в индустрии называют context rot: чем длиннее история диалога, тем хуже модель расставляет приоритеты внутри неё. Исследование Chroma, протестировавшее 18 современных моделей, показало, что точность падает по мере роста входного контекста заметно раньше, чем заканчивается заявленное окно — иногда на 30–50%, даже когда нужная информация формально «влезает». А более ранняя стэнфордская работа про эффект «потеряно в середине» показывает похожую картину: то, что было сказано в начале длинного диалога, модель помнит хуже, чем то, что было недавно, и склонна опираться на уже устоявшуюся в диалоге логику, а не пересматривать её заново.
Для повседневной болтовни это не критично. Для проекта, который вы разрабатываете с ИИ неделями, — критично: модель постепенно перестаёт быть вам полезной именно там, где нужнее всего — в способности сказать «а вот тут вы, кажется, ошиблись».Приём: свежий ревьюерРешение простое и не требует ничего особенного — ни второго аккаунта, ни более дорогого тарифа. Достаточно периодически открывать новый чат с тем же ассистентом, показывать ему текущее состояние проекта без предыстории и просить честный, независимый разбор. Без истории решений, которые вы принимали неделю назад, модель ничем не обязана вашей логике — она смотрит на код или документ так, как смотрел бы новый человек, впервые зашедший в проект.Это тот же принцип, что и в обычном код-ревью: разработчик, который писал код, часто не видит очевидных проблем именно потому, что слишком глубоко в них. Свежий ревьюер видит их за минуту.Важный момент, который стоит учитывать сразу: не нужно сталкивать старый и новый чат друг с другом, показывая одному ответы другого. Как только модель узнаёт чужое мнение, она либо начинает ему возражать из принципа, либо, наоборот, соглашаться — в обоих случаях независимость оценки теряется.
Правильная схема — держать их полностью изолированными: один ведёт проект, другой просто честно на него смотрит.Как встроить это в рабочий процесс
- Рабочий чат - тот, что «въелся» в проект — оставляйте для повседневной разработки: он держит контекст решений, историю правок, причины, почему что-то сделано именно так, а не иначе. Это не недостаток, это его сильная сторона.
- Свежий чат открывайте осознанно, не только когда упёрлись в лимит: перед мержем большого куска, перед релизом, когда что-то не получается объяснить, или просто раз в одну-две недели — как плановое ревью.
- Давайте свежему чату минимум предыстории: только код, задачу и вопрос. Чем меньше вы объясняете «почему мы так решили», тем честнее будет ответ.
- Относитесь к замечаниям свежего чата как к сигналу для проверки, а не как к готовому вердикту - он не знает про ограничения бизнеса или технический долг, о которых вы договаривались раньше. Иногда его критика окажется мимо; но чаще она указывает именно туда, где вы сами уже перестали смотреть.
Итог Мы в CQ Systems в какой-то момент заметили это на себе — не специально, а просто потому что при плотной работе периодически упирались в лимиты и переключались между чатами. Оказалось, что это не костыль, а рабочая практика: держать один инстанс глубоко в контексте и параллельно, осознанно, приводить второй — без истории — как объективного контролёра. Не нужно ждать, пока лимит заставит вас это сделать. Можно просто взять за привычку.
Share
