Помню, как увлекался 40% в студенчестве: даже купил себе вот такую красивую необычную клавиатуру у какого-то умелого парня.
В связке с вимом казалось пиком производительности -- это ж любой конфиг за 10 секунд отрефакторить можно!
Но в какой-то момент пришла удалёнка вперемешку с офисом, и пришлось вернуться к ноутбучной клавиатуре: таскать механику с собой неудобно, а плагины не накатишь -- ноут корпоративный.
Ну и вайбкодинг совсем убил потребность в сорока процентах: английские буквы что тут, что там в нужных местах под пальцами. Теперь разве что для души такое…
Основной критерий -- умеет ли агент сам обрабатывать неожиданные ситуации без вовлечения меня в решение, что делать дальше.
С моделями < Fable 5 происходят регулярные прерывания из разряда «я попробовал X, не сработало, что мне делать?». Например не нашел какой-то конфиг, который лежит рядом. Или нашлись две версии библиотеки и он не может понять какую использовать.
Начиная с Fable 5 (видимо и opus 5.5 тоже, не тестировал пока), у моделей появилась какая-то более продвинутая интуиция, агенты копают чуть глубже: идут в гит лог, грепают код, смотрят что есть в соседних файлах/папках. К человеку возвращаются только если есть объективное препятствие, на котором споткнулся бы и мидл-разработчик
Уже сейчас настоящую ответственность за результат несут не разработчики, а владельцы бизнеса. Потому что программист в худшем исходе пойдет к конкурентам, а владелец бизнеса лишится компании -- осязаемого имущества.
То есть цепочка ответственностей выглядит как
Владелец Бизнеса -> [Менеджер ->] -> Программист -> Результат
Разработчики в целом нужны (были) как специалисты, которые потратили какое-то время на изучение языков, получили опыт в проектировании и имеют специфичные знания, которых нет у бизнесмена.
Если же вместо прогера будет llm, выдающая такой же результат, то с точки зрения компании это строго лучше, поскольку в цепочке ответственностей сокращается количество звеньев. Не говоря уже о сокращенных расходах и большей продуктивности.
И это также отличается от истории с высокоуровневыми языками тем, что владельцу бизнеса не нужно получать дополнительные знания для создания продукта. Используя ровно тот же язык делегирования и разделения ответственностей, он может раздать задачи агентам, и они справятся.
Другими словами, llm делает "программистами" тех, кто раньше программировали программистов. По сути, убирая во вторых надобность.
По большей части rust — ровно то, что вы описали. Он из коробки поддерживает нужную модель ошибок, закрывает почти все баги памяти (в safe коде) и много чего еще хорошего дает, например модель синхронизации через send/sync трейты.
Правда их требования к аллокации так легко не решились бы, нужно было бы так же кастомные контейнеры писать.
Пока что трудно сказать наверняка, насколько этот тест устойчив к манипуляциям с текстом -- антропик еще не открыл апи, и без конкретных экспериментов этого не понять.
Но я бы предположил, что "маркерные" места равномерно распределены, и если взять достаточно большие куски вроде абзацев, ватермарка статистически сможет себя проявить.
Там не совсем так работает. Тест проходит скользящим окном (а не всем префиксом) по тексту и для каждого окна высчитывает сигнал "следующий токен был сгенерирован", поэтому перестановка слов ломает знак только в паре соседних позиций, а не во всём тексте. Плюс тест вероятностный, а не точный - он суммирует сигналы по всем окнам и на выходе выдает "насколько вероятно, что в тексте есть ватермарка". Более того, поскольку нам не известен ключ, мы не можем обнаружить все маркирующие места и поменять их. Кажется более-менее рабочий способ только попросить переформулировать текст другую llm, про которую известно, что она ватермарку не проставляет.
Здесь в целом согласен с вами: подмена верности связностью опасна в том смысле, что решение генерируется не на основе фактов, а через некоторое непонятное нам перемножение матриц, которое выдаёт правдоподобный ответ.
Я бы только дополнил, что LLM - это всё-таки чуть сложнее, чем «чистая связность» речи. Интерпретируемость показывает, что внутри моделей есть неречевые концепты, привязанные к структуре реального мира, а не только к статистике слов:
- https://arxiv.org/pdf/2310.02207 - вот здесь внутри моделей нашлись линейные представления пространства и времени, кодирующие реальные координаты городов и даты событий. - https://arxiv.org/pdf/2502.00873 - здесь про то, как модели выполняют арифметику через тригонометрию. То есть тоже что-то более глубокое, чем простая речевая связность.
Но конечно да, концепты выучены из текста, логика генерации для нас непрозрачна, и, видимо, главный вывод - что галлюцинации LLM гораздо сложнее предсказать, чем галлюцинации людей.
Статья оригинальная конечно, но мораль все-таки не ясна.
С точки зрения пользовательского опыта llm vs human, что именно делает человека надёжнее как инструмент?
То, что он боится ошибиться? Так эмоции в работе скорее минус, чем плюс.
Жизненный опыт? Ну llm видела больше кода, читала больше книг и смотрела больше фильмов, чем любой человек.
Интуиция? Возможно, конечно, но поди докажи, что она статистически лучше рандома.
Да, “чистая речь” не улыбается, ничем не рискует и не пахнет - но ведь это чаще хорошо, чем плохо?
Можно провести эксперимент: какому “первобытному обществу” доверим писать реализацию raft - тому, где есть специалист, которого в случае чего съедят, или тому, которое оплатило подписку на fable 5?
P.S. И да, галлюцинаций всё-таки становится все меньше. В обвязке с доп проверками риск от llm как будто бы уже сравнялся с риском от людей (а то и стал ниже)
Помню, как увлекался 40% в студенчестве: даже купил себе вот такую красивую необычную клавиатуру у какого-то умелого парня.
В связке с вимом казалось пиком производительности -- это ж любой конфиг за 10 секунд отрефакторить можно!
Но в какой-то момент пришла удалёнка вперемешку с офисом, и пришлось вернуться к ноутбучной клавиатуре: таскать механику с собой неудобно, а плагины не накатишь -- ноут корпоративный.
Ну и вайбкодинг совсем убил потребность в сорока процентах: английские буквы что тут, что там в нужных местах под пальцами. Теперь разве что для души такое…
Основной критерий -- умеет ли агент сам обрабатывать неожиданные ситуации без вовлечения меня в решение, что делать дальше.
С моделями < Fable 5 происходят регулярные прерывания из разряда «я попробовал X, не сработало, что мне делать?». Например не нашел какой-то конфиг, который лежит рядом. Или нашлись две версии библиотеки и он не может понять какую использовать.
Начиная с Fable 5 (видимо и opus 5.5 тоже, не тестировал пока), у моделей появилась какая-то более продвинутая интуиция, агенты копают чуть глубже: идут в гит лог, грепают код, смотрят что есть в соседних файлах/папках. К человеку возвращаются только если есть объективное препятствие, на котором споткнулся бы и мидл-разработчик
Так ведь на переходе 4 -> 5 как раз и проходит граница, после которой агенты действительно имеют смысл в серьезных проектах
Уже сейчас настоящую ответственность за результат несут не разработчики, а владельцы бизнеса. Потому что программист в худшем исходе пойдет к конкурентам, а владелец бизнеса лишится компании -- осязаемого имущества.
То есть цепочка ответственностей выглядит как
Владелец Бизнеса -> [Менеджер ->] -> Программист -> Результат
Разработчики в целом нужны (были) как специалисты, которые потратили какое-то время на изучение языков, получили опыт в проектировании и имеют специфичные знания, которых нет у бизнесмена.
Если же вместо прогера будет llm, выдающая такой же результат, то с точки зрения компании это строго лучше, поскольку в цепочке ответственностей сокращается количество звеньев. Не говоря уже о сокращенных расходах и большей продуктивности.
И это также отличается от истории с высокоуровневыми языками тем, что владельцу бизнеса не нужно получать дополнительные знания для создания продукта. Используя ровно тот же язык делегирования и разделения ответственностей, он может раздать задачи агентам, и они справятся.
Другими словами, llm делает "программистами" тех, кто раньше программировали программистов. По сути, убирая во вторых надобность.
По большей части rust — ровно то, что вы описали. Он из коробки поддерживает нужную модель ошибок, закрывает почти все баги памяти (в safe коде) и много чего еще хорошего дает, например модель синхронизации через send/sync трейты.
Правда их требования к аллокации так легко не решились бы, нужно было бы так же кастомные контейнеры писать.
Пока что трудно сказать наверняка, насколько этот тест устойчив к манипуляциям с текстом -- антропик еще не открыл апи, и без конкретных экспериментов этого не понять.
Но я бы предположил, что "маркерные" места равномерно распределены, и если взять достаточно большие куски вроде абзацев, ватермарка статистически сможет себя проявить.
Там не совсем так работает. Тест проходит скользящим окном (а не всем префиксом) по тексту и для каждого окна высчитывает сигнал "следующий токен был сгенерирован", поэтому перестановка слов ломает знак только в паре соседних позиций, а не во всём тексте. Плюс тест вероятностный, а не точный - он суммирует сигналы по всем окнам и на выходе выдает "насколько вероятно, что в тексте есть ватермарка". Более того, поскольку нам не известен ключ, мы не можем обнаружить все маркирующие места и поменять их. Кажется более-менее рабочий способ только попросить переформулировать текст другую llm, про которую известно, что она ватермарку не проставляет.
Здесь в целом согласен с вами: подмена верности связностью опасна в том смысле, что решение генерируется не на основе фактов, а через некоторое непонятное нам перемножение матриц, которое выдаёт правдоподобный ответ.
Я бы только дополнил, что LLM - это всё-таки чуть сложнее, чем «чистая связность» речи. Интерпретируемость показывает, что внутри моделей есть неречевые концепты, привязанные к структуре реального мира, а не только к статистике слов:
- https://arxiv.org/pdf/2310.02207 - вот здесь внутри моделей нашлись линейные представления пространства и времени, кодирующие реальные координаты городов и даты событий.
- https://arxiv.org/pdf/2502.00873 - здесь про то, как модели выполняют арифметику через тригонометрию. То есть тоже что-то более глубокое, чем простая речевая связность.
Но конечно да, концепты выучены из текста, логика генерации для нас непрозрачна, и, видимо, главный вывод - что галлюцинации LLM гораздо сложнее предсказать, чем галлюцинации людей.
Статья оригинальная конечно, но мораль все-таки не ясна.
С точки зрения пользовательского опыта llm vs human, что именно делает человека надёжнее как инструмент?
То, что он боится ошибиться? Так эмоции в работе скорее минус, чем плюс.
Жизненный опыт? Ну llm видела больше кода, читала больше книг и смотрела больше фильмов, чем любой человек.
Интуиция? Возможно, конечно, но поди докажи, что она статистически лучше рандома.
Да, “чистая речь” не улыбается, ничем не рискует и не пахнет - но ведь это чаще хорошо, чем плохо?
Можно провести эксперимент: какому “первобытному обществу” доверим писать реализацию raft - тому, где есть специалист, которого в случае чего съедят, или тому, которое оплатило подписку на fable 5?
P.S. И да, галлюцинаций всё-таки становится все меньше. В обвязке с доп проверками риск от llm как будто бы уже сравнялся с риском от людей (а то и стал ниже)
В трети? Получается recall 0.33 у их модели классификации, слабовато как-то 🙃
Еще можно сделать игру, где ты типа грибок, и прыгаешь на супер Марио
Вот бы такой же курс для математиков