1. В профиле ставим английский язык обязательно (с русским оно не умеет работать).
2. Если это не сработало, то проблема в том, что у вас плохой VPN. Он или использует основной пул адресов Амазона в качестве экзит-ноды, или ведет в какую-то нерукопожатную страну типа Африки, либо где-то еще палится.
Есть куча VPN, которые можно попробовать - NordVPN, ProtonVPN, Surfshark, ExpressVPN... но скорее всего, ничего из этого не работает из России. Чтобы использовать их, нужно подключиться к одному VPN через другой VPN.
Как вариант, можете попробовать Browsec, до него соединение из России есть.
Большая часть современных AAA/AAAA игр не может работать без DLSS, TAA, извращенных апскейлингов с нейросетями, и тому подобного (обычно они все идут одной пачкой, в комплексе). Часть игр без них не выдерживает даже 1080p, где ничего из этого использовать нельзя (но в представлении CTO мыловарни - можно). Если убрать мыло вручную, то окажется, что оно маскирует дребезг или наводит дым и зеркала поверх движка который не в состоянии показать 4k 60фпс ни на чем кроме 4090/5090. Могу долго продолжать, но если коротко, это прям портал в ад. Все современные игры прокляты.
Если бы сейчас игры разрабатывались с тем же уровнем энтузиазма, оптимизации и ненормального программирования, что был у Кармака - возможно, у нас бы 4к летало на 120 фпс, и не только в свежем Kingdom Come, а везде :)
Я читал вашу статью, тоже немного удивлялся, что она в разделе "геймдев", но она реально крутая и передает такой вайб... знаешь, вайб воспоминания, что вообще-то значительную часть работы можно сделать на этапе компиляции, и потом в рантайме пользователю ничего не делать, и выжать на этом еще несколько кадров. Наверное, это тяжело и сложно, и требует совершенно специального подхода к разработке. Но оно того стоит.
хотелось бы наоборот: не в статье про перформанс искать геймдев, а в геймдеве найти оптимизацию. Держу в курсе, оптимизацию не наши, мыло хозяйственное DLSS/TAA антибактериальное, квадрупл эй продаем за 120 баксов мыла кусок
Разве ваше наблюдение не подтверждает статистику? Люди, которые являются экспертами в чем-то, идут работать в компании, которые специализируются на этой же теме.
Условно говоря, я когда-то выиграл один из сезонов на Хабре. Будучи сотрудником компании, которая разрабатывает технологию, про которую был сезон.
В тот момент так получилось, что моя компания не спонсировала этот конкурс. (Совершенно зря, и вероятно, это моя вина). И написание моей статьи она тоже никак не спонсировала. И статью-то написал я просто так, по инерции. Обычно все такие статьи сразу публиковались на английском языке в совершенно другой блог.
Но если бы я, или не дай бог - все сотрудники нашей компании, целенаправленно решили бы что-нибудь там выиграть, мы бы просто залили весь блог соответствующей технологии топовыми статьями. Самый простой способ - скопипастить контент из внутренней вики. Всё, GG. Ни у кого не было бы вообще ни шанса.
Очень сложно конкурировать в написании статей с профессиональными евангелистами, кто десять+ лет подряд пишет статьи именно по этой конкретной технологии, и это их основная фуллтайм работа.
Высокоморально ли такое поведение? Может да, может нет, не берусь судить. Легально ли оно? Вероятно, да. Все люди равны в базовых правах перед законом.
Логично, что например, сотрудники компании-разработчика Искусственного Интеллекта напишут лучшие статьи по искусственному интеллекту. Или что специалист компании-провайдера может очень много всего рассказать про сисадминство. Их именно по этому признаку и нанимали в эти компании!
Яндекс, например, передал призы в номинации AI следующим после своих сотрудников. А мог бы и не передавать, с чего бы.
Имхо, то, что человек из компании выигрывает конкурс, который эта компания спонсирует - само по себе ни о чем не говорит. Вот если бы он не оказался хотя бы в топе - это был бы что-то говорило о его профпригодности :) Оно говорит только в случае, если эти же люди ранее были пойманы на нечистоплотности. Надеюсь, сейчас это не тот случай.
Разница в том, что это не часть классического поиска Гугла. Это полностью отдельный интерфейс в стиле Perplexity, где выдаётся AI ответ и только он. Визуально интерфейс выглядит как чат (в стиле ChatGPT и Perplexity), основная часть страницы - это большой текст статьи который написала в ответ нейросеть, внутрь которого добавлены ссылки на источники. Можно чатиться в чате и продолжать задавать вопросы относительно уже найденного, можно отдельной кнопкой запустить новый диалог. Классических результатов поиска в виде бесконечного набора ссылок на сотни страниц - нет вообще, от него полностью уходят. Поисковой строки и поискового запроса как сущности тоже нет - есть только запросы к нейронке в чате. Первой страницы со строкой поиска (как сейчас в Гугле) тоже нет - по скриншоту видно, что первая вкладка вместо Search полностью заменена на AI Mode, в котором ты всегда сразу попадаешь в интерфейс чата.
Конкретно этот язык означает понижение вероятности взлома через эту утилиту. И это особенно это важно для sudo — это самая главная скрепа безопасности в Linux.
Как раз начинают делать Cursor использует tree-sitter чтобы чего-то гранулярно парсить. У нас в GigaIDE Cloud это тоже уже в бэклоге.
Вот про что я хотел поспорить, так про "статически типизируемых языках с AST".
Например, Java таковым языком не является, потому что во-первых никто не пишет на голой Java — пишут на Java+Spring+куча-других-фреймворков, да и в самой Java миллион рефлекшена. Половина логики лежит в анноациях, XML-ках и конвенциях классов/методов. Это одна из причин, почему мир еще не перешел на штуки типа GraalVM Native Image - не каждый проект можно скомпилировать статически, и более того — совершенно не каждый программист хочет писать на Java статически.
У C# так вообще работают LINQ expressions, за которыми может стоять примерно любой обработчик, и это прям часть языка. (Имхо, это как раз то, чем C# на самом деле лучше, чем Java. Без этой фичи у Java все коллекции выглядят как уродство).
Остальной топ языков: JS/TS, Java/Scala/C#, Python, Ruby, PHP, Lua — у них точно та же особенность. Более подробно можно что-то сказать про C/C++, Go, Rust, Swift. Но C/C++ - это легаси, а Go/Rust/Swift — это все еще считаные проценты от общего использования.
Возможно, вопрос натурально в том, заменят процесс кодирования окончательно, или нет. Станет ли он таким же автоматизированным, как сейчас происходит с трансляцией языков высокого уровня в ассемблер и машкоды.
Если люди более не будут кодировать, НИКАКИЕ из этих языков не нужны и не подходят сами по себе в качестве intermediate language. Нужен язык, который специально сдизайнен для нейросетей и только для них. В котором будут починены проблемы типа "сколько r в слове strawberry", в котором не будут экономить на длине синтаксиса и идентификаторов, и тому подобное.
А если кодирование всё ещё будут делать люди, то наоборот — нейронки совершили прорыв в том, что на "слабосвязанных" языках можно кодировать не менее эффективно, чем на Java/C#/C++. Раньше у тебя была постоянная проблема в том, что в JavaScript-подобных языках с первого взгляда ничего не понятно точно. Что-то понятно, но чтобы быть уверенным — нет. И всякие рефакторинги в IDE из-за этого работали как говно, рефакторить всё равно надо. Теперь же тебе на них гораздо проще программировать потому, что тебе и не нужно ничего до конца понимать. Ты можешь относиться к коду как к чему-то вероятностному и мимолетному, как к промежуточному представлению, некому IR стоящему между спецификацией и исполнением. Да, ты все ещё его пишешь, но можно больше не относиться к этому слишком серьезно. По сути, ты можешь теперь генерировать на JavaScript (даже без TS) раз в 10 больше кода, чем делал это раньше, за то же самое время. Лучше он от этого не станет, но вот что писать можно быстрее в разы — это совершенно точно.
Эта гонка за размер окна и скорость генерации токенов — это просто решение боли живых людей. Которая очень, очень сильно болит. Ну нет у человека в голове такого размера окна. Нельзя с такой скоростью писать буковки на JavaScript. Нейронка дает тебе все эти возможности. Поэтому люди платили и будут платить за окно и скорость генерации. Это как плата за таблетки от которых зависит твоя жизнь — сколько бы ни попросили, как бы (не)качественно они ни работали, всё равно будут покупать, потому что оно утоляет боль.
У нас в VSCode это отлично решается тем, что у тебя есть два автодополнения - базовое и AI inline completion (серый текст-призрак). Призраки настраиваются через назначение шортката экшену editor.action.inlineSuggest.trigger. Это группа шорткатов, в т.ч. там можно сделать отдельный шорткат на переключение к следующей подсказке. Например, можно назначить призрака на ctrl+H, а обычное дополнение останется на ctrl+space и tab. Если у тебя в качестве основного плагина Continue, можно его еще по-разному донастроить, чтобы было удобно (то ли туториал написать...)
Возможно, в Идее разрабам достаточно просто подсвечивать ИИ-дополнения другим цветом, или поставить рядом с ними красивую иконку с мерцающими звездочками. Такое решение сделает больно слабовидящим (скрин-ридеру придется постоянно говорить "эй ай" перед каждым элементом в списке), но полностью зрячим это достаточно мощный индикатор. Ну и раздельные шорткаты утащить из VSCode, конечно. Возможно, в IDE от JetBrains уже так и есть, но с тех пор как я переключился на разработку плагинов для VSCode (в частности, на работе днем я делаю GigaIDE Cloud), попробовать всю эту красоту времени нет.
Про последовательную замену. Зачастую ты делаешь рефакторинг, и у тебя меняется код в десяти тысячах мест. Причем, есть и более сложные рефакторинги, чем rename - например change signature. Часть магии в том, что ты одним нажатием кнопки делаешь работу, которую вручную делал бы неделю. Но да, для пользователя проходить и глазами проверять каждое изменение - не вариант, этих изменений слишком много. Пользователю надо доверять тому, что автоматика ничего не сломает. Особенно если у тебя в проекте нет никаких автотестов, и результат что ничего не посыпалось - можно будет проверить только ручным тестированием.
Делать ринеймы парсингом безусловно можно, надо "всего лишь" правильно распарсить увиденное. Для чего-то это просто (например, Clojure), для чего-то нужно написать нереально сложный компилятор (C++), у чего-то понять структуру вообще невозможно в общем случае (JS с реактами и эвалами). Но распарсить сам язык недостаточно, нужно распарсить ещё и все фреймворки и способы их использования. Например, в Java критичная для ринейма информация может лежать в метаинформации в аннотации, а в PHP так и вообще в комментариях. Насколько критичная? Ну например, структура данных в файлах или в базе данных. Если не заренеймить ненужное (или наоборот - не заренеймить нужное), то у тебя перестанут на проде читаться файлы настроек или перестанут сохраняться файлы в БД, или придется накатывать миграции на БД - и молись чтобы эти миграции не накатывались автоматически по результатам анализа кода (фреймворк Hibernate вполне так может делать). Заметь, что данные о той же структуре БД могут находиться не только даже в строках с полным полным соответствием, а даже где-то внутри названия методов в произвольном месте (стандартный для Java фреймворк SpringData по названию функции findByLastname() автоматически генерит соответствующий SQL запрос в базу). Кроме фреймворков есть и просто какие-то обращения самого пользователя: он может склеить две строковые переменные и потом рефлексией взять у класса поле с таким названием. И хорошо если название есть в непосредственном коде, а не в сгенерировано во время компиляции, или ещё хуже - в рантайме приложения по каким-другим полям, косвенно. С точки зрения компилятора языка все эти вещи никак не связанные, и спросить у LSP-сервера ты это не сможешь. А ведь именно за эту магию люди и используют IDE - если бы ее не было, проще было бы использовать любой другой продвинутый текстовый редактор.
В теории, нейросеть может упростить тебе такие штуки тем, что тебе как разработчику тулинга, больше не нужно писать поиск релевантных символов или даже может, весь рефакторинг тоже не надо писать. Можно прийти к нейросети и сказать: о Великий Вычислитель, взгляни на своего недостойного раба из мяса и костей, и помоги ему заренеймить вот этот кусок текста в координатах 10:20! И на выход нейронка отвечает тебе, в идеале, ченжсет для применения изменений. Тебе больше не нужно писать сложнейшие парсеры и трансляторы коллективом из тысяч умнейших людей, и ежедневно обновлять всю эту машинерию при появлении малейших изменений в языке и фреймворках. Для пользователя это означает гораздо более дешёвые инструменты, которые всегда знают о самых свежих изменениях в языке и фреймворках, и даже учитывают все извращения которые он сам написал в своем коде (например, магия поверх рефлексии и интроспекции).
Собственно, с переходом к AI-first разработке все так и делают, но у этого подхода сейчас много проблем. Например, есть проблема в размере контекстного окна - даже у Gemini с их 1-2 миллионами токенов, внутри большого контекста есть скользящее активное окно, и вне его инструкции забываются (можно напомнить нейронке посмотреть назад и вспомнить что-то конкретное, но для этого надо отдельно индексировать - что именно надо вспоминать). Или например, нейронки сейчас все ещё довольно тупые. Чтобы посмотреть на тупость на какой-то красивой иллюстрации, попробуй поиграть в шахматы с ChatGPT. Она будет ходить невозможными ходами, рубить свои фигуры, доставать фигуры из воздуха и наоборот - игнорировать существующие. То же самое будет и с последовательностью рефакторингов. И с любой другой системой достаточно сложных правил, действующих строго во времени.
С переходом на AI-first приходится привыкать к тому, что любые достаточно невинные действия могут ломать сразу весь код. И чтобы починить его назад приходится после первого модифицирующего запроса делать ещё несколько запросов "пожалуйста, почини этот код", прогонять тесты (если они есть), и - о ужас - даже смотреть диффы изменений. Если это был рефакторинг на десять тысяч строк, тебе обычно не очень хочется смотреть глазами в дифф. И это то, что реально стало неприятным и неудобным при переходе к AI-разработке. Получив огромные магические преимущества в одном месте, мы получили в другом месте пробитие размером во все днище.
Это очень хороший пост. Подпишусь под каждым словом.
1. В профиле ставим английский язык обязательно (с русским оно не умеет работать).
2. Если это не сработало, то проблема в том, что у вас плохой VPN. Он или использует основной пул адресов Амазона в качестве экзит-ноды, или ведет в какую-то нерукопожатную страну типа Африки, либо где-то еще палится.
Есть куча VPN, которые можно попробовать - NordVPN, ProtonVPN, Surfshark, ExpressVPN... но скорее всего, ничего из этого не работает из России. Чтобы использовать их, нужно подключиться к одному VPN через другой VPN.
Как вариант, можете попробовать Browsec, до него соединение из России есть.
del
Что если я не хочу, чтобы мои тексты использовались для создания производных работ.
Большая часть современных AAA/AAAA игр не может работать без DLSS, TAA, извращенных апскейлингов с нейросетями, и тому подобного (обычно они все идут одной пачкой, в комплексе). Часть игр без них не выдерживает даже 1080p, где ничего из этого использовать нельзя (но в представлении CTO мыловарни - можно). Если убрать мыло вручную, то окажется, что оно маскирует дребезг или наводит дым и зеркала поверх движка который не в состоянии показать 4k 60фпс ни на чем кроме 4090/5090. Могу долго продолжать, но если коротко, это прям портал в ад. Все современные игры прокляты.
Если бы сейчас игры разрабатывались с тем же уровнем энтузиазма, оптимизации и ненормального программирования, что был у Кармака - возможно, у нас бы 4к летало на 120 фпс, и не только в свежем Kingdom Come, а везде :)
Я читал вашу статью, тоже немного удивлялся, что она в разделе "геймдев", но она реально крутая и передает такой вайб... знаешь, вайб воспоминания, что вообще-то значительную часть работы можно сделать на этапе компиляции, и потом в рантайме пользователю ничего не делать, и выжать на этом еще несколько кадров. Наверное, это тяжело и сложно, и требует совершенно специального подхода к разработке. Но оно того стоит.
хотелось бы наоборот: не в статье про перформанс искать геймдев, а в геймдеве найти оптимизацию. Держу в курсе, оптимизацию не наши, мыло хозяйственное DLSS/TAA антибактериальное, квадрупл эй продаем за 120 баксов мыла кусок
Разве ваше наблюдение не подтверждает статистику? Люди, которые являются экспертами в чем-то, идут работать в компании, которые специализируются на этой же теме.
Условно говоря, я когда-то выиграл один из сезонов на Хабре. Будучи сотрудником компании, которая разрабатывает технологию, про которую был сезон.
В тот момент так получилось, что моя компания не спонсировала этот конкурс. (Совершенно зря, и вероятно, это моя вина). И написание моей статьи она тоже никак не спонсировала. И статью-то написал я просто так, по инерции. Обычно все такие статьи сразу публиковались на английском языке в совершенно другой блог.
Но если бы я, или не дай бог - все сотрудники нашей компании, целенаправленно решили бы что-нибудь там выиграть, мы бы просто залили весь блог соответствующей технологии топовыми статьями. Самый простой способ - скопипастить контент из внутренней вики. Всё, GG. Ни у кого не было бы вообще ни шанса.
Очень сложно конкурировать в написании статей с профессиональными евангелистами, кто десять+ лет подряд пишет статьи именно по этой конкретной технологии, и это их основная фуллтайм работа.
Высокоморально ли такое поведение? Может да, может нет, не берусь судить. Легально ли оно? Вероятно, да. Все люди равны в базовых правах перед законом.
Логично, что например, сотрудники компании-разработчика Искусственного Интеллекта напишут лучшие статьи по искусственному интеллекту. Или что специалист компании-провайдера может очень много всего рассказать про сисадминство. Их именно по этому признаку и нанимали в эти компании!
Яндекс, например, передал призы в номинации AI следующим после своих сотрудников. А мог бы и не передавать, с чего бы.
Имхо, то, что человек из компании выигрывает конкурс, который эта компания спонсирует - само по себе ни о чем не говорит. Вот если бы он не оказался хотя бы в топе - это был бы что-то говорило о его профпригодности :) Оно говорит только в случае, если эти же люди ранее были пойманы на нечистоплотности. Надеюсь, сейчас это не тот случай.
Так ведь есть Сезон OpenSource!
https://habr.com/ru/specials/898552/
Правда, он заканчивается 23 мая, так что если что-то публиковать - то ПРЯМО СЕЙЧАС.
Ты проверил, что ты находишься в США?
Вот здесь по карте: https://whatismyipaddress.com/
ChatGPT и Claude уже работают над решениями для встроенной рекламы. Остальные тоже подтянутся.
Разница в том, что это не часть классического поиска Гугла. Это полностью отдельный интерфейс в стиле Perplexity, где выдаётся AI ответ и только он. Визуально интерфейс выглядит как чат (в стиле ChatGPT и Perplexity), основная часть страницы - это большой текст статьи который написала в ответ нейросеть, внутрь которого добавлены ссылки на источники. Можно чатиться в чате и продолжать задавать вопросы относительно уже найденного, можно отдельной кнопкой запустить новый диалог. Классических результатов поиска в виде бесконечного набора ссылок на сотни страниц - нет вообще, от него полностью уходят. Поисковой строки и поискового запроса как сущности тоже нет - есть только запросы к нейронке в чате. Первой страницы со строкой поиска (как сейчас в Гугле) тоже нет - по скриншоту видно, что первая вкладка вместо Search полностью заменена на AI Mode, в котором ты всегда сразу попадаешь в интерфейс чата.
Это не то.
Вот как выглядит AI Mode:
Покажи скриншот
Конкретно этот язык означает понижение вероятности взлома через эту утилиту. И это особенно это важно для sudo — это самая главная скрепа безопасности в Linux.
Как раз начинают делать Cursor использует tree-sitter чтобы чего-то гранулярно парсить. У нас в GigaIDE Cloud это тоже уже в бэклоге.
Вот про что я хотел поспорить, так про "статически типизируемых языках с AST".
Например, Java таковым языком не является, потому что во-первых никто не пишет на голой Java — пишут на Java+Spring+куча-других-фреймворков, да и в самой Java миллион рефлекшена. Половина логики лежит в анноациях, XML-ках и конвенциях классов/методов. Это одна из причин, почему мир еще не перешел на штуки типа GraalVM Native Image - не каждый проект можно скомпилировать статически, и более того — совершенно не каждый программист хочет писать на Java статически.
У C# так вообще работают LINQ expressions, за которыми может стоять примерно любой обработчик, и это прям часть языка. (Имхо, это как раз то, чем C# на самом деле лучше, чем Java. Без этой фичи у Java все коллекции выглядят как уродство).
Остальной топ языков: JS/TS, Java/Scala/C#, Python, Ruby, PHP, Lua — у них точно та же особенность. Более подробно можно что-то сказать про C/C++, Go, Rust, Swift. Но C/C++ - это легаси, а Go/Rust/Swift — это все еще считаные проценты от общего использования.
Возможно, вопрос натурально в том, заменят процесс кодирования окончательно, или нет. Станет ли он таким же автоматизированным, как сейчас происходит с трансляцией языков высокого уровня в ассемблер и машкоды.
Если люди более не будут кодировать, НИКАКИЕ из этих языков не нужны и не подходят сами по себе в качестве intermediate language. Нужен язык, который специально сдизайнен для нейросетей и только для них. В котором будут починены проблемы типа "сколько r в слове strawberry", в котором не будут экономить на длине синтаксиса и идентификаторов, и тому подобное.
А если кодирование всё ещё будут делать люди, то наоборот — нейронки совершили прорыв в том, что на "слабосвязанных" языках можно кодировать не менее эффективно, чем на Java/C#/C++. Раньше у тебя была постоянная проблема в том, что в JavaScript-подобных языках с первого взгляда ничего не понятно точно. Что-то понятно, но чтобы быть уверенным — нет. И всякие рефакторинги в IDE из-за этого работали как говно, рефакторить всё равно надо. Теперь же тебе на них гораздо проще программировать потому, что тебе и не нужно ничего до конца понимать. Ты можешь относиться к коду как к чему-то вероятностному и мимолетному, как к промежуточному представлению, некому IR стоящему между спецификацией и исполнением. Да, ты все ещё его пишешь, но можно больше не относиться к этому слишком серьезно. По сути, ты можешь теперь генерировать на JavaScript (даже без TS) раз в 10 больше кода, чем делал это раньше, за то же самое время. Лучше он от этого не станет, но вот что писать можно быстрее в разы — это совершенно точно.
Эта гонка за размер окна и скорость генерации токенов — это просто решение боли живых людей. Которая очень, очень сильно болит. Ну нет у человека в голове такого размера окна. Нельзя с такой скоростью писать буковки на JavaScript. Нейронка дает тебе все эти возможности. Поэтому люди платили и будут платить за окно и скорость генерации. Это как плата за таблетки от которых зависит твоя жизнь — сколько бы ни попросили, как бы (не)качественно они ни работали, всё равно будут покупать, потому что оно утоляет боль.
У нас в VSCode это отлично решается тем, что у тебя есть два автодополнения - базовое и AI inline completion (серый текст-призрак). Призраки настраиваются через назначение шортката экшену editor.action.inlineSuggest.trigger. Это группа шорткатов, в т.ч. там можно сделать отдельный шорткат на переключение к следующей подсказке. Например, можно назначить призрака на ctrl+H, а обычное дополнение останется на ctrl+space и tab. Если у тебя в качестве основного плагина Continue, можно его еще по-разному донастроить, чтобы было удобно (то ли туториал написать...)
Возможно, в Идее разрабам достаточно просто подсвечивать ИИ-дополнения другим цветом, или поставить рядом с ними красивую иконку с мерцающими звездочками. Такое решение сделает больно слабовидящим (скрин-ридеру придется постоянно говорить "эй ай" перед каждым элементом в списке), но полностью зрячим это достаточно мощный индикатор. Ну и раздельные шорткаты утащить из VSCode, конечно. Возможно, в IDE от JetBrains уже так и есть, но с тех пор как я переключился на разработку плагинов для VSCode (в частности, на работе днем я делаю GigaIDE Cloud), попробовать всю эту красоту времени нет.
Про последовательную замену. Зачастую ты делаешь рефакторинг, и у тебя меняется код в десяти тысячах мест. Причем, есть и более сложные рефакторинги, чем rename - например change signature. Часть магии в том, что ты одним нажатием кнопки делаешь работу, которую вручную делал бы неделю. Но да, для пользователя проходить и глазами проверять каждое изменение - не вариант, этих изменений слишком много. Пользователю надо доверять тому, что автоматика ничего не сломает. Особенно если у тебя в проекте нет никаких автотестов, и результат что ничего не посыпалось - можно будет проверить только ручным тестированием.
Делать ринеймы парсингом безусловно можно, надо "всего лишь" правильно распарсить увиденное. Для чего-то это просто (например, Clojure), для чего-то нужно написать нереально сложный компилятор (C++), у чего-то понять структуру вообще невозможно в общем случае (JS с реактами и эвалами). Но распарсить сам язык недостаточно, нужно распарсить ещё и все фреймворки и способы их использования. Например, в Java критичная для ринейма информация может лежать в метаинформации в аннотации, а в PHP так и вообще в комментариях. Насколько критичная? Ну например, структура данных в файлах или в базе данных. Если не заренеймить ненужное (или наоборот - не заренеймить нужное), то у тебя перестанут на проде читаться файлы настроек или перестанут сохраняться файлы в БД, или придется накатывать миграции на БД - и молись чтобы эти миграции не накатывались автоматически по результатам анализа кода (фреймворк Hibernate вполне так может делать). Заметь, что данные о той же структуре БД могут находиться не только даже в строках с полным полным соответствием, а даже где-то внутри названия методов в произвольном месте (стандартный для Java фреймворк SpringData по названию функции findByLastname() автоматически генерит соответствующий SQL запрос в базу). Кроме фреймворков есть и просто какие-то обращения самого пользователя: он может склеить две строковые переменные и потом рефлексией взять у класса поле с таким названием. И хорошо если название есть в непосредственном коде, а не в сгенерировано во время компиляции, или ещё хуже - в рантайме приложения по каким-другим полям, косвенно. С точки зрения компилятора языка все эти вещи никак не связанные, и спросить у LSP-сервера ты это не сможешь. А ведь именно за эту магию люди и используют IDE - если бы ее не было, проще было бы использовать любой другой продвинутый текстовый редактор.
В теории, нейросеть может упростить тебе такие штуки тем, что тебе как разработчику тулинга, больше не нужно писать поиск релевантных символов или даже может, весь рефакторинг тоже не надо писать. Можно прийти к нейросети и сказать: о Великий Вычислитель, взгляни на своего недостойного раба из мяса и костей, и помоги ему заренеймить вот этот кусок текста в координатах 10:20! И на выход нейронка отвечает тебе, в идеале, ченжсет для применения изменений. Тебе больше не нужно писать сложнейшие парсеры и трансляторы коллективом из тысяч умнейших людей, и ежедневно обновлять всю эту машинерию при появлении малейших изменений в языке и фреймворках. Для пользователя это означает гораздо более дешёвые инструменты, которые всегда знают о самых свежих изменениях в языке и фреймворках, и даже учитывают все извращения которые он сам написал в своем коде (например, магия поверх рефлексии и интроспекции).
Собственно, с переходом к AI-first разработке все так и делают, но у этого подхода сейчас много проблем. Например, есть проблема в размере контекстного окна - даже у Gemini с их 1-2 миллионами токенов, внутри большого контекста есть скользящее активное окно, и вне его инструкции забываются (можно напомнить нейронке посмотреть назад и вспомнить что-то конкретное, но для этого надо отдельно индексировать - что именно надо вспоминать). Или например, нейронки сейчас все ещё довольно тупые. Чтобы посмотреть на тупость на какой-то красивой иллюстрации, попробуй поиграть в шахматы с ChatGPT. Она будет ходить невозможными ходами, рубить свои фигуры, доставать фигуры из воздуха и наоборот - игнорировать существующие. То же самое будет и с последовательностью рефакторингов. И с любой другой системой достаточно сложных правил, действующих строго во времени.
С переходом на AI-first приходится привыкать к тому, что любые достаточно невинные действия могут ломать сразу весь код. И чтобы починить его назад приходится после первого модифицирующего запроса делать ещё несколько запросов "пожалуйста, почини этот код", прогонять тесты (если они есть), и - о ужас - даже смотреть диффы изменений. Если это был рефакторинг на десять тысяч строк, тебе обычно не очень хочется смотреть глазами в дифф. И это то, что реально стало неприятным и неудобным при переходе к AI-разработке. Получив огромные магические преимущества в одном месте, мы получили в другом месте пробитие размером во все днище.
Наемным сотрудникам, которые хотят получать ближе к миллиону в месяц, чем ближе к средней зарплате по стране.
Да, файнтюн на русский язык реально повышает качество результата.
Если у вас противоположные приоритеты - не читайте, конечно! Читать нужно то что нужно, а что не нужно — читать не нужно!