выбор пути развития github copilot
Categories:
copilot с февраля по июль прошлого года в vscode insider можно было использовать безлимитно, за это время я наблюдал постепенное ослабление agent-способностей copilot. Трудно представить, что первая предварительная версия copilot оказалась самой эффективной, после чего agent-способности постепенно снижались. Какие именно произошли изменения? Это направление разработки и эволюции copilot, которое в течение последнего года с лишним было направлено на «экономию token». Раньше агенты всех производителей читали файлы целиком за один раз — так делали qwen cli, claudecode, gemini, ранний copilot, — эффект был очень хорошим, просто расход token, вероятно, был довольно большим, контекст также быстро заполнялся, а при пересборке контекста процент попадания в кэш снижался. Позже все пошли по пути фрагментарного чтения: кто-то после grep читал по несколько десятков строк вверх и вниз, при нехватке дочитывал ещё, кто-то использовал структурированные инструменты для работы с кодом вроде LSP. Agent copilot использует метод чтения файла сверху вниз, каждый раз по 50 строк, изредка 200 строк, но постоянно сверху вниз. В сочетании с ограничением по умолчанию в 50 вызовов инструментов и входным контекстом менее 200k, объём выполняемой им работы довольно ограничен. Ранние сервисы всех производителей работали в убыток, рассчитывая занять экосистему по низкой цене, а позже снизить затраты, но за этот год с лишним наконец обнаружили, что затраты не снизить, а принудительное снижение сделает их продукт продуктом третьего сорта. Так что не стоит слишком сильно винить copilot — все агенты, способные сидеть за игровым столом, уже перешли на посчёт по token, и copilot — один из отстающих. Надеюсь, сбросив историческое бремя посчёта по количеству операций, copilot как следует улучшит своего агента и догонит основную массу, ведь он всё ещё лучше всего интегрирован с vscode. Инструменты ИИ могут быть дорогими, но не могут быть слишком слабыми.
