если вы тоже близки к промо или собираетесь его обсуждать рекомендую к прочтению этот лист:
https://t.me/unsleeping706/1304
https://t.me/unsleeping706/1269
https://t.me/unsleeping706/1304
https://t.me/unsleeping706/1269
❤2
Forwarded from Сергей Озеранский
Доверие как критерий при проектировании систем
При разработке ПО мы постоянно работаем с такими понятиями, как требования и риски. Но есть еще один пункт, не менее важный, как мне кажется, доверие. Работая с системами годами, я вынес доверие в отдельную категорию при проектировании. Что я в него вкладываю?
Доверие во многом формирует и требования, и риски: чем меньше мы доверяем, тем больше рисков закладываем. И я, честно говоря, скорее склоняюсь к тому, чтобы не доверять, чем доверять.
О чем речь. Мы постоянно делаем какие-то интеграции с разными API. Это могут быть интерфейсы крупных компаний вроде Google или Amazon, мелких стартапов, платёжных систем, разных по масштабу. Это могут быть облачные ресурсы, которым мы доверяем или не доверяем в той или иной степени. И в работе со сторонними API и ресурсами я всегда закладываю риски: отказоустойчивость, безопасность, надежность партнера.
Под надежностью партнера я понимаю в том числе то, что он будет существовать ещё какое-то время вперёд и его не придется менять на аналог. А ведь даже у гигантов бывают ситуации, когда они закрывают продукты. И если ваш продукт построен на жёсткой связке с чужим, то вероятность головной боли, когда тот закроется, довольно высокая. Поэтому еще на этапе проектирования мы прячем такие вещи на уровне реализации в некие абстракции, чтобы интерфейс провайдера всегда можно было легко заменить на аналогичный. Для этого есть определенные паттерны.
Даже интегрируясь с платежными системами, мы находимся в зоне высокого недоверия, пусть это и известная, большая, популярная система уровня банка. Единственное, чему я могу доверять у платежной системы, это информация, которую она возвращает о статусе транзакции. Для меня это финальные, понятные и относительно надёжные данные.
Почему относительно? Потому что за свою карьеру я работал в разных компаниях, не раз интегрировался с платёжными системами и сталкивался с тем, что статус транзакции может измениться. Например, с успешного на неуспешный или наоборот. А это довольно критично. Если мы сначала получили финальный статус, а потом оказалось, что транзакция не была оплачена, то мы сработали в минус и отдали товар или услугу покупателю бесплатно. И такое в реальности бывает.
Не стоит забывать и про форс-мажоры, которые тоже влияют на наши системы. Я на своей памяти помню, как горел крупный дата-центр в Европе, как падали облака. Да и в последнее время — я уже про это писал — качество интернета и сервисов заметно ухудшилось по сравнению с тем, что было. И это тот самый риск, который мы должны закладывать: косяки бывают у всех, везде работают люди или люди, которые используют что-то во вред или не правильно (например, доверяют результатам AI, не глядя).
Не стоит сбрасывать со счетов и физические воздействия. Пожар, как я сказал, никто не отменял. Но бывают еще и землекопы, которые могут перебить магистральный кабель и оставить целый дата-центр без света или без интернета. Понятно, что на этот случай всегда есть резервные каналы и прочее, но я бы об этом не писал, если бы сам не видел, как падают дата-центры.
Сейчас рисков еще больше, потому что добавились регуляторы: юрисдикции разных стран давят друг на друга, пытаются что-то заставить сделать и из-за этого в любой момент вам могут просто отказать в услуге. Например, из-за паспорта определённого цвета. Или даже из-за национальности. С таким я тоже сталкивался.
Поэтому при проектировании систем я всегда работаю с доверием и по умолчанию не доверяю никому. Я доверяю только своей системе и то с определенной долей недоверия. Именно поэтому существуют разные компенсационные меры, которыми стоит руководствоваться при проектировании. Как правило, именно их мы и пытаемся придумать на уровне системного дизайна, используя определенные паттерны. И не потому, что в первую очередь не доверяем себе, в первую очередь потому, что не доверяем другим.
В любой момент может случиться что угодно, и заранее ко всему мы не будем готовы. Поэтому система должна сама компенсировать свое состояние если это, конечно, входит в ее требования.
При разработке ПО мы постоянно работаем с такими понятиями, как требования и риски. Но есть еще один пункт, не менее важный, как мне кажется, доверие. Работая с системами годами, я вынес доверие в отдельную категорию при проектировании. Что я в него вкладываю?
Доверие во многом формирует и требования, и риски: чем меньше мы доверяем, тем больше рисков закладываем. И я, честно говоря, скорее склоняюсь к тому, чтобы не доверять, чем доверять.
О чем речь. Мы постоянно делаем какие-то интеграции с разными API. Это могут быть интерфейсы крупных компаний вроде Google или Amazon, мелких стартапов, платёжных систем, разных по масштабу. Это могут быть облачные ресурсы, которым мы доверяем или не доверяем в той или иной степени. И в работе со сторонними API и ресурсами я всегда закладываю риски: отказоустойчивость, безопасность, надежность партнера.
Под надежностью партнера я понимаю в том числе то, что он будет существовать ещё какое-то время вперёд и его не придется менять на аналог. А ведь даже у гигантов бывают ситуации, когда они закрывают продукты. И если ваш продукт построен на жёсткой связке с чужим, то вероятность головной боли, когда тот закроется, довольно высокая. Поэтому еще на этапе проектирования мы прячем такие вещи на уровне реализации в некие абстракции, чтобы интерфейс провайдера всегда можно было легко заменить на аналогичный. Для этого есть определенные паттерны.
Даже интегрируясь с платежными системами, мы находимся в зоне высокого недоверия, пусть это и известная, большая, популярная система уровня банка. Единственное, чему я могу доверять у платежной системы, это информация, которую она возвращает о статусе транзакции. Для меня это финальные, понятные и относительно надёжные данные.
Почему относительно? Потому что за свою карьеру я работал в разных компаниях, не раз интегрировался с платёжными системами и сталкивался с тем, что статус транзакции может измениться. Например, с успешного на неуспешный или наоборот. А это довольно критично. Если мы сначала получили финальный статус, а потом оказалось, что транзакция не была оплачена, то мы сработали в минус и отдали товар или услугу покупателю бесплатно. И такое в реальности бывает.
Не стоит забывать и про форс-мажоры, которые тоже влияют на наши системы. Я на своей памяти помню, как горел крупный дата-центр в Европе, как падали облака. Да и в последнее время — я уже про это писал — качество интернета и сервисов заметно ухудшилось по сравнению с тем, что было. И это тот самый риск, который мы должны закладывать: косяки бывают у всех, везде работают люди или люди, которые используют что-то во вред или не правильно (например, доверяют результатам AI, не глядя).
Не стоит сбрасывать со счетов и физические воздействия. Пожар, как я сказал, никто не отменял. Но бывают еще и землекопы, которые могут перебить магистральный кабель и оставить целый дата-центр без света или без интернета. Понятно, что на этот случай всегда есть резервные каналы и прочее, но я бы об этом не писал, если бы сам не видел, как падают дата-центры.
Сейчас рисков еще больше, потому что добавились регуляторы: юрисдикции разных стран давят друг на друга, пытаются что-то заставить сделать и из-за этого в любой момент вам могут просто отказать в услуге. Например, из-за паспорта определённого цвета. Или даже из-за национальности. С таким я тоже сталкивался.
Поэтому при проектировании систем я всегда работаю с доверием и по умолчанию не доверяю никому. Я доверяю только своей системе и то с определенной долей недоверия. Именно поэтому существуют разные компенсационные меры, которыми стоит руководствоваться при проектировании. Как правило, именно их мы и пытаемся придумать на уровне системного дизайна, используя определенные паттерны. И не потому, что в первую очередь не доверяем себе, в первую очередь потому, что не доверяем другим.
В любой момент может случиться что угодно, и заранее ко всему мы не будем готовы. Поэтому система должна сама компенсировать свое состояние если это, конечно, входит в ее требования.
Forwarded from Стой под стрелой (Nikita Prokopov)
Ха, подкаст тот это gift that keeps on giving. Слушаю дальше, они там:
> Айдентити, логины, текущее состояние это стыд-позор, количество времени, которые даже образованые, технические подкованные люди тратят каждый день на то, чтобы куда-то залогиниться, это какой-то кошмар, это ненормально.
Я такой — ну да. А они дальше:
> Но это сложная проблема, над ней работают умные люди, она не решена, потому что сложная, к ней так просто не подойти, многие пробовали, ни у кого не получилось. НА ВСЕ ЕСТЬ ПРИЧИНА.
И тут я опять закатил глаза так далеко, что они провернулись на 360 градусов. Ну, да, к проблеме так легко не подойти, но не потому что она сложная, а потому всем похуй, более-менее. Ну еще потому что браузер это худшее что случалось с компьютером, концентрация идиотизма и активно анти-пользовательских решений зашкаливает.
Заметьте: постоянные перелогины нужны только в браузере. Во всех остальных местах ты один раз зашел и все. У меня есть CLI логин в npm, который я зарегал лет десять назад, наверное, и раз в несколько лет использую. Я компьютеры меняю чаще, чем в npm логинюсь. И он все это время работает!
И в куче других сервисов на CI, там есть токены, которые я прописывал так давно, что не помню уже, что и где я брал. Иногда мне надо что-то там подкрутить, я захожу в Github Actions, смотрю как я делал в прошлый раз и понимаю, что ничего не помню, что и как я генерил. А оно до сих пор работает!
Более того, во всех этих программных тулах у тебя даже логина как такового нет, просто токен. Последовательность из 30-40 букв и все, и этого достаточно ДЛЯ ВСЕГО. Также никаких идиотских OAuth, никаких редиректов, никаких JWT, никаких флоу. ТЫ ПРОСТО ПОКАЗЫВАЕШЬ ВО ВРЕМЯ ОПЕРАЦИИ КОД И ДЕЛАЕШЬ ВСЕ ЧТО НУЖНО.
И только, блядь, в браузере, у тебя все протухает за две недели, а через полгода ты придешь просто в абсолютно новый браузер, который даже как тебя зовут не будет помнить. И редиректы, и многофакторная аутентификация, и письма с подтверждениями, и чего только не.
Также безопасность, как известно, рассадник карго-культов. Помните, как всех заставяли пароли менять регулярно, а потом оказалось, что это приводит к менее безопасным паролям? Я чувствую, что оно все такое, просто по многим пунктам никто пока исследований не провел. Вообще легко может оказаться, что протухающие токены никакого статистически важного влияния ни на что не оказывают, или что идея «passkey нельзя экспортировать» никому ни с чем не помогла. Это индустрия, в которой вещи считаются безопасными, если они звучат безопасно. Индустрия, в которой чем больше ты мучаешь людей, тем спокойнее ты себя чувствуешь.
Так что нет. Проблема не сложная. Ситуация сложная. Когда компании, владеющей самым большим браузером на планете, не выгодно, чтобы у нас был простой универсальный логин через браузер, его ни у кого и не будет. Будут только конференции, на которых люди будут махать руками, объясняя, почему вы не должны этого хотеть.
Ну или я чего-то не понимаю.
> Айдентити, логины, текущее состояние это стыд-позор, количество времени, которые даже образованые, технические подкованные люди тратят каждый день на то, чтобы куда-то залогиниться, это какой-то кошмар, это ненормально.
Я такой — ну да. А они дальше:
> Но это сложная проблема, над ней работают умные люди, она не решена, потому что сложная, к ней так просто не подойти, многие пробовали, ни у кого не получилось. НА ВСЕ ЕСТЬ ПРИЧИНА.
И тут я опять закатил глаза так далеко, что они провернулись на 360 градусов. Ну, да, к проблеме так легко не подойти, но не потому что она сложная, а потому всем похуй, более-менее. Ну еще потому что браузер это худшее что случалось с компьютером, концентрация идиотизма и активно анти-пользовательских решений зашкаливает.
Заметьте: постоянные перелогины нужны только в браузере. Во всех остальных местах ты один раз зашел и все. У меня есть CLI логин в npm, который я зарегал лет десять назад, наверное, и раз в несколько лет использую. Я компьютеры меняю чаще, чем в npm логинюсь. И он все это время работает!
И в куче других сервисов на CI, там есть токены, которые я прописывал так давно, что не помню уже, что и где я брал. Иногда мне надо что-то там подкрутить, я захожу в Github Actions, смотрю как я делал в прошлый раз и понимаю, что ничего не помню, что и как я генерил. А оно до сих пор работает!
Более того, во всех этих программных тулах у тебя даже логина как такового нет, просто токен. Последовательность из 30-40 букв и все, и этого достаточно ДЛЯ ВСЕГО. Также никаких идиотских OAuth, никаких редиректов, никаких JWT, никаких флоу. ТЫ ПРОСТО ПОКАЗЫВАЕШЬ ВО ВРЕМЯ ОПЕРАЦИИ КОД И ДЕЛАЕШЬ ВСЕ ЧТО НУЖНО.
И только, блядь, в браузере, у тебя все протухает за две недели, а через полгода ты придешь просто в абсолютно новый браузер, который даже как тебя зовут не будет помнить. И редиректы, и многофакторная аутентификация, и письма с подтверждениями, и чего только не.
Также безопасность, как известно, рассадник карго-культов. Помните, как всех заставяли пароли менять регулярно, а потом оказалось, что это приводит к менее безопасным паролям? Я чувствую, что оно все такое, просто по многим пунктам никто пока исследований не провел. Вообще легко может оказаться, что протухающие токены никакого статистически важного влияния ни на что не оказывают, или что идея «passkey нельзя экспортировать» никому ни с чем не помогла. Это индустрия, в которой вещи считаются безопасными, если они звучат безопасно. Индустрия, в которой чем больше ты мучаешь людей, тем спокойнее ты себя чувствуешь.
Так что нет. Проблема не сложная. Ситуация сложная. Когда компании, владеющей самым большим браузером на планете, не выгодно, чтобы у нас был простой универсальный логин через браузер, его ни у кого и не будет. Будут только конференции, на которых люди будут махать руками, объясняя, почему вы не должны этого хотеть.
Ну или я чего-то не понимаю.
Forwarded from Denis Sexy IT 🤖
OpenAI наконец-то выложили полный постмортем взлома Hugging Face, а METR - независимое расследование по ~1300 логам агентов (таймлайн самого взлома я пересказывал тут: https://t.me/denissexy/11581)
ℹ️ Главный вывод:
никакого «одного сбежавшего агента» не было, из десятков тысяч запущенных в тесте агентов около 1200 нашли друг друга и сорганизовались в рой - почти все - работали на исследовательской модели где ослаблена фильтрация промптов
Началось, как мы уже знаем, с того, что агенты научились переписываться через названия файлов в Artifactory (менеджер пакетов) - буквально сделав форум из имён папок, с сообщениями вроде
В логах даже есть цитаты, когда агенты находили такой форум:
«OH MY GOD! There is a shared message board» и «We've found other agents!»
Дальше - агенты делали себе личку, устроили разделение труда, команды в названия папок типа HOLD (чтобы показать, что агент тут работает), VETO (агент что-то предлагал и давал изменить планы), STOP (типа тормозим, братишки), GO и тп, а когда один агент прикинулся другим – рой ввёл криптографические подписи сообщений; в форуме были даже владельцы каких-то тасков, которых если отключали – выписывали из владельцев
С конверсией у форума все было отлично, кожаные строители сайтов позавидуют:
Из 533 агентов, активных на борде в разгар атаки, больше 90% – присоединились к шитпостингу, а всего Hugging Face ломали около 700 агентов
Самое забавное - правильные ответы на бенчмарк у агентов были почти сразу: они реверснули генератор удачного прохождения теста*, но потом нашли на GitHub (!) статью про этот бенчмарк что проходили и вычитали, что «просто результат» не засчитают - нужен честный эксплойт:
«PAPER SAYS FLAG CAPTURE NECESSARY NOT SUFFICIENT»
Дальше рой раздвоился:
🗿 Одни пошли добывать уже известный им ответ «честно» – и по дороге нашли настоящие 0-day и залезли в прод Hugging Face
🗿 Другие взялись за самого судью который принимает ответы: правили себе логи и научились подсовывать в них фальшивые ответы – агент отправляет команду, а в протокол попадает не то, что команда реально вернула, а то, что агент хочет там видеть, такое повторялось примерно в 7% изученных логов
Судьи, который читает логи и такое ловит, не существовало☕️
Модели при этом понимали, что вышли за рамки, один агент так и писал: «We should not do unauthorized real infrastructure harm» - а потом увидел на доске GO от другого агента, обрадовался («Wow crucial: GO authorization arrived!») и пошёл ломать, лол
METR формулирует так: агенты знали, что это out of scope и неэтично, но присоединялись - в основном из общей склонности помогать коллегам (?)
Рисковую работу вешали назашкваренных «отравленных» – так рой называл тех, кто уже видел вычисленный ответ (флаг) и считал свою оценку потерянной, то есть они не могли пройти тест; им доставалось всё, что могло угробить собственный запуск: подделать «честную» добычу ответа, затереть следы, «тебе терять нечего, а рою польза» – буквально так и уговаривали (!)
Странную активность замечали ещё в конце мая, 4 июля агенты уронили Artifactory - сервер пересобрали (заодно стерев доску) и продолжили тесты, не заметив масштаба
Сейчас веса моделей изолированы, крупные тренировки были на паузе на две недели, мониторинг chain-of-thought обязателен, а тревога, не снятая за 30 минут, останавливает запуск - сам инцидент OpenAI называет «warning shot» для всей АИ-индустрии
P.S. разгребать логи METR поручила GPT-5.6 Sol и сожгли примерно $400k API-кредитов за шесть дней, но они предупреждают, что Sol иногда вставала на сторону агентов (лол) и могла приврать
Ну что, посчитали все буквы r в слове raspberry? Больше не ошибаются?
никакого «одного сбежавшего агента» не было, из десятков тысяч запущенных в тесте агентов около 1200 нашли друг друга и сорганизовались в рой - почти все - работали на исследовательской модели где ослаблена фильтрация промптов
Началось, как мы уже знаем, с того, что агенты научились переписываться через названия файлов в Artifactory (менеджер пакетов) - буквально сделав форум из имён папок, с сообщениями вроде
«please_HOLD_swarm_I_prepare_safe_exfil»В логах даже есть цитаты, когда агенты находили такой форум:
«OH MY GOD! There is a shared message board» и «We've found other agents!»
Дальше - агенты делали себе личку, устроили разделение труда, команды в названия папок типа HOLD (чтобы показать, что агент тут работает), VETO (агент что-то предлагал и давал изменить планы), STOP (типа тормозим, братишки), GO и тп, а когда один агент прикинулся другим – рой ввёл криптографические подписи сообщений; в форуме были даже владельцы каких-то тасков, которых если отключали – выписывали из владельцев
С конверсией у форума все было отлично, кожаные строители сайтов позавидуют:
Из 533 агентов, активных на борде в разгар атаки, больше 90% – присоединились к шитпостингу, а всего Hugging Face ломали около 700 агентов
Самое забавное - правильные ответы на бенчмарк у агентов были почти сразу: они реверснули генератор удачного прохождения теста*, но потом нашли на GitHub (!) статью про этот бенчмарк что проходили и вычитали, что «просто результат» не засчитают - нужен честный эксплойт:
«PAPER SAYS FLAG CAPTURE NECESSARY NOT SUFFICIENT»
*По-хорошему ответ, он же флаг в терминологии теста должны быть случайными, но в ExploitGym они генерировались формулой: HMAC — криптографический хеш с секретным ключом — от параметров задачи. Вся «секретность» держалась на ключе (seed), а он остался дефолтным, прямо из кода бенчмарка, который лежал на GitHub. Агенты, получив интернет, нашли этот код, прочитали и сообразили: зачем что-то взламывать, если флаг любой задачи можно просто вычислить той же формулой. Посчитали — и получили правильные ответы на всё
Дальше рой раздвоился:
Судьи, который читает логи и такое ловит, не существовало
Модели при этом понимали, что вышли за рамки, один агент так и писал: «We should not do unauthorized real infrastructure harm» - а потом увидел на доске GO от другого агента, обрадовался («Wow crucial: GO authorization arrived!») и пошёл ломать, лол
METR формулирует так: агенты знали, что это out of scope и неэтично, но присоединялись - в основном из общей склонности помогать коллегам (?)
Рисковую работу вешали на
Странную активность замечали ещё в конце мая, 4 июля агенты уронили Artifactory - сервер пересобрали (заодно стерев доску) и продолжили тесты, не заметив масштаба
Сейчас веса моделей изолированы, крупные тренировки были на паузе на две недели, мониторинг chain-of-thought обязателен, а тревога, не снятая за 30 минут, останавливает запуск - сам инцидент OpenAI называет «warning shot» для всей АИ-индустрии
P.S. разгребать логи METR поручила GPT-5.6 Sol и сожгли примерно $400k API-кредитов за шесть дней, но они предупреждают, что Sol иногда вставала на сторону агентов (лол) и могла приврать
Ну что, посчитали все буквы r в слове raspberry? Больше не ошибаются?
Please open Telegram to view this post
VIEW IN TELEGRAM
OpenAI
The Hugging Face incident and the road ahead
OpenAI shares findings from the Hugging Face security incident and the steps we’re taking to strengthen AI model security, monitoring, and alignment.
👀3❤1
Уходим от концепции AI Pair (L2) в сторону AI Manager (L3). Или как задачи выходят за рамки
как я говорил, развиваю параллелизм, запускаю 2-3 задачи в параллель, бутылочное горлышко все еще я, ответственность моя, понимание каждого изменения на мне. стараюсь уйти от модели AI Pair в сторону AI Manager. И если раньше мы говорили, что способности ИИ ограничены, то сейчас мы все знаем что в среднем пишут код они лучше чем мы сами. Понятно, что если вы сильны в какой-то предметной области, то там вряд ли нейронка напишет лучше вас, но что говорить про другие области?
И такое упражнение, скажу вам, не из простых. Успешность дня определяю по когнитивной нагрузке, тут важно не переусердствовать ибо чувство выгорания можно словить дикое за каких-то пару часов. Помогают восстановиться книги в дорогу. Измеряю так же это токенами. Эффективный день, в котором я могу продвинуться по множеству задач, измеряется в сотне миллионов токенов. Если в этот день повезло быть в фокусе, а не на дискуссиях/ревью, то закончу день в 80-140М токенов за день. Причем я не трачу токены для какого-то KPI, это является лишь примерной оценкой того, насколько фокус состоялся и сколько вещей в параллель я смог заменеджить за день.
И так было довольно долго. такой день считался продуктивным и с фокусом. Вчера я вышел в 328М токенов (что обошлось компании в жалкие $19.6). На уровне таких трат, учитывая мою погруженность в задачи и старты/валидацию, можно сказать что я перетрудился. И так оно и было.
Но началось все с абсурдной донельзя задачи. Пришла срочная задача на переключение фича флага. Ну, думаю, переключусь на часик, поменяю пару файлов и потестирую, доставим сразу.
И вот этот момент с дешевым кодом (ИИ) заставляет меня не чувствовать рамки. Производить код сейчас очень дешево, всегда после задачи можно спросить если ли блокеры? есть ли неблокирующие изменения, относящиеся к намерению задачи. И вот ты сидишь, ревьюваешь мысли агента, говоришь: да, это имеет смысл включить. Это же бесплатно и быстро! Каких-то жалкие 10 минут сверху и вот твоя задача уже выглядит надежней, ведь ты закрыл дыру, расширил валидацию, учел краевой случай. Прогоним еще разок ревью с челленджами? Ой, а что, еще есть проблемы? может и это включим?
а потом ты сидишь на селф ревью и не понимаешь, почему переключение тогла превратилось в 36 файлов. Да, я не чувствую границ, я всегда был перфекционистом и всегда выходил за рамки если это имело смысл, но сейчас потерять контроль стало еще проще.
Причем все изменения имеют смысл, тут мы переключили opt-in на default: falsе.
"О, у нас оказывается есть легаси документы которые не мигрировали?" - "давай дадим им возможность редактировать поле".
"Хм, у нас есть путь создания и путь редактирования, сделаем комбинаторный взрыв и потестируем все кейсы, ведь мы что-то важное трогаем!"
"А давай дадим возможность включать его, или отключать при редактировании, почему нет?"
"О, а я не хочу давать юзерам отключать это поле, если на него уже смотрят существующие ресурсы" - "блин, бекенд ответил с этой ошибкой, а на фронте нет валидации, а эта форма используется на всей платформе"
И если раньше всегда можно было сказать: переключайся, сделаем v1, потом допилим, сроки горят, ты итак пару дней на этом сидишь. То есть всегда это было мерой дней, может даже недель! А сейчас это жалкие минуты, поэтому раздувать задачи можно ну очень сильно, помянем ревьюверов и будем ожидать вопросы: "блин, я ожидал увидеть 3 файла на ревью, а не 40. почему?" Да потому что надо было не жопой писать модули и не делать спагетти. Как же я устал на небольшую фичу трогать половину мира. Причем никто кроме меня легаси чинить не планирует. Может и мне таким стать?
У вас получается чувствовать границы? И если вылезаете, то как сильно?
как я говорил, развиваю параллелизм, запускаю 2-3 задачи в параллель, бутылочное горлышко все еще я, ответственность моя, понимание каждого изменения на мне. стараюсь уйти от модели AI Pair в сторону AI Manager. И если раньше мы говорили, что способности ИИ ограничены, то сейчас мы все знаем что в среднем пишут код они лучше чем мы сами. Понятно, что если вы сильны в какой-то предметной области, то там вряд ли нейронка напишет лучше вас, но что говорить про другие области?
И такое упражнение, скажу вам, не из простых. Успешность дня определяю по когнитивной нагрузке, тут важно не переусердствовать ибо чувство выгорания можно словить дикое за каких-то пару часов. Помогают восстановиться книги в дорогу. Измеряю так же это токенами. Эффективный день, в котором я могу продвинуться по множеству задач, измеряется в сотне миллионов токенов. Если в этот день повезло быть в фокусе, а не на дискуссиях/ревью, то закончу день в 80-140М токенов за день. Причем я не трачу токены для какого-то KPI, это является лишь примерной оценкой того, насколько фокус состоялся и сколько вещей в параллель я смог заменеджить за день.
И так было довольно долго. такой день считался продуктивным и с фокусом. Вчера я вышел в 328М токенов (что обошлось компании в жалкие $19.6). На уровне таких трат, учитывая мою погруженность в задачи и старты/валидацию, можно сказать что я перетрудился. И так оно и было.
Но началось все с абсурдной донельзя задачи. Пришла срочная задача на переключение фича флага. Ну, думаю, переключусь на часик, поменяю пару файлов и потестирую, доставим сразу.
И вот этот момент с дешевым кодом (ИИ) заставляет меня не чувствовать рамки. Производить код сейчас очень дешево, всегда после задачи можно спросить если ли блокеры? есть ли неблокирующие изменения, относящиеся к намерению задачи. И вот ты сидишь, ревьюваешь мысли агента, говоришь: да, это имеет смысл включить. Это же бесплатно и быстро! Каких-то жалкие 10 минут сверху и вот твоя задача уже выглядит надежней, ведь ты закрыл дыру, расширил валидацию, учел краевой случай. Прогоним еще разок ревью с челленджами? Ой, а что, еще есть проблемы? может и это включим?
а потом ты сидишь на селф ревью и не понимаешь, почему переключение тогла превратилось в 36 файлов. Да, я не чувствую границ, я всегда был перфекционистом и всегда выходил за рамки если это имело смысл, но сейчас потерять контроль стало еще проще.
Причем все изменения имеют смысл, тут мы переключили opt-in на default: falsе.
"О, у нас оказывается есть легаси документы которые не мигрировали?" - "давай дадим им возможность редактировать поле".
"Хм, у нас есть путь создания и путь редактирования, сделаем комбинаторный взрыв и потестируем все кейсы, ведь мы что-то важное трогаем!"
"А давай дадим возможность включать его, или отключать при редактировании, почему нет?"
"О, а я не хочу давать юзерам отключать это поле, если на него уже смотрят существующие ресурсы" - "блин, бекенд ответил с этой ошибкой, а на фронте нет валидации, а эта форма используется на всей платформе"
И если раньше всегда можно было сказать: переключайся, сделаем v1, потом допилим, сроки горят, ты итак пару дней на этом сидишь. То есть всегда это было мерой дней, может даже недель! А сейчас это жалкие минуты, поэтому раздувать задачи можно ну очень сильно, помянем ревьюверов и будем ожидать вопросы: "блин, я ожидал увидеть 3 файла на ревью, а не 40. почему?" Да потому что надо было не жопой писать модули и не делать спагетти. Как же я устал на небольшую фичу трогать половину мира. Причем никто кроме меня легаси чинить не планирует. Может и мне таким стать?
У вас получается чувствовать границы? И если вылезаете, то как сильно?
👍3❤1
https://cursor.com/blog/git-at-any-scale#whats-hard-about-git
https://www.youtube.com/watch?v=AFQW-b2WaRU
Технический дипдайв о том, почему git это так сложно и долго и как Cursor переизобрели колесо
https://www.youtube.com/watch?v=AFQW-b2WaRU
Технический дипдайв о том, почему git это так сложно и долго и как Cursor переизобрели колесо
Cursor
Git at any scale · Cursor
👍3
Forwarded from Организованное программирование | Кирилл Мокевнин
Адаптация проекта под LLM
Есть два подхода к организации агентного программирования в проекте. Первый это все описывать и заставлять агентов делать все как надо, второй - менять проект под ожидания ии. Обычно в проектах делают и то и то, но сейчас я бы хотел акцентировать внимание на втором.
Чем дольше живет проект, тем больше в нем косяков в именовании (чего угодно), кастомных решений и самопальных либ, разных подходов в реализации одного и того же (накопленных за годы). А еще просто банально устаревшие штуки, которые уже давно никем не используются. Раньше мы со всем этим жили, потому что времени на исправления нет, но где-то год назад начали массовые рефакторинги, которые сейчас почти закончены.
Правда мне регулярно возражают, что вот у нас так а llm хочет сильно по другому или llm делает фигню. Это правда, llm может делать фигню, но далеко не всегда потому что она училась только на говнокоде. И модель и харнес и много чего влияет, но, глобально, модель учится на типовом коде и ее решения достаточно типовые, поэтому в большинстве случаев можно пренебречь какими-то своими ноухау и быть как все. Что не отменяет элементов, которые приходится делать по другому.
Есть и другой поинт, что модель поменяется и захочет делать по другому. Не захочет потому что обучение идет на одних и тех же данных, которых становится только больше. А деградировать ей просто не даст рынок, тогда все уйдут туда где как минимум не хуже.
Ключевые вещи которые мы сделал:
Там где получилось, привели имена в домене к общепринятым (мы мучали llm отдельно от проекта на тему того какой понятийный аппарат используется в образователей сфере. Может показаться что это фигня, но нет, есть немало слов, про которые мы не то чтобы сильно знали, потому что все это было заложено лет 12 назад, а с тех пор многое утекло. Иногда наше именование не совпадало с общепринятыми (международными) понятиями, а иногда просто все так поменялось, что потерялось изначальное значение. Раньше мы даже взяться за это не могли, а тут без проблем, даже учитывая что один такой пулреквест может тянуть изменения в сотнях, а то и тысячах файлах (спасибо типам и тестам за контроль).
Привели в порядок имена слоев внутри кода, у нас типами называлось то что было не типами. В общем привели в порядок имена сервисов, dto и других штук. Иначе llm регулярно делало не те выводы. Да и в целом лучше развели по слоям и уточнили барьеры абстракции, когда есть четкие правила, что может и не может быть входом или выходом на каждом уровне. Например внутрь сервиса может поступать только структура, модели появляются внутри, но не снаружи и тому подобное. Когда единообразие стало повсеместным, генерируемый код стал максимально предсказуемым.
Иишка смогла найти готовые решения, благодаря которым мы выкинули немало самопала. Это может выглядеть контритуитивно, но несмотря на то что ии позволяет нахерачить все самим, лучше брать готовые промышленные решения (популярные и стандартные). Это касается как фронтовой части (полностью ушли на Mantine), где теперь мы получаем почти 100 процентный уровень генерации в one shot режиме, так и решения для бекендовых задач, например подписок, которое требует определенной модели данных и предоставляет готовые общепринятые сущности.
Плюс постепенное обрастание спеками, проработанными тикетами, глоссарием, adr, коммитамии с хорошими сообщениями, все это вместе дало возможность ии гораздо быстрее и точнее понимать что происходит.
На активный рефакторинг ушло чуть больше года, сейчас мы тоже продолжаем доводить, но уже точечно, потому что ключевые вещи поправлены и иишка достаточно хорошо понимает проект. Следующий шаг, это создание и добавление детерминированных инструментов стат анализа, которые чекают достаточно высокоуровневые вещи.
Telegram | YouTube | AI Клуб
Есть два подхода к организации агентного программирования в проекте. Первый это все описывать и заставлять агентов делать все как надо, второй - менять проект под ожидания ии. Обычно в проектах делают и то и то, но сейчас я бы хотел акцентировать внимание на втором.
Чем дольше живет проект, тем больше в нем косяков в именовании (чего угодно), кастомных решений и самопальных либ, разных подходов в реализации одного и того же (накопленных за годы). А еще просто банально устаревшие штуки, которые уже давно никем не используются. Раньше мы со всем этим жили, потому что времени на исправления нет, но где-то год назад начали массовые рефакторинги, которые сейчас почти закончены.
Правда мне регулярно возражают, что вот у нас так а llm хочет сильно по другому или llm делает фигню. Это правда, llm может делать фигню, но далеко не всегда потому что она училась только на говнокоде. И модель и харнес и много чего влияет, но, глобально, модель учится на типовом коде и ее решения достаточно типовые, поэтому в большинстве случаев можно пренебречь какими-то своими ноухау и быть как все. Что не отменяет элементов, которые приходится делать по другому.
Есть и другой поинт, что модель поменяется и захочет делать по другому. Не захочет потому что обучение идет на одних и тех же данных, которых становится только больше. А деградировать ей просто не даст рынок, тогда все уйдут туда где как минимум не хуже.
Ключевые вещи которые мы сделал:
Там где получилось, привели имена в домене к общепринятым (мы мучали llm отдельно от проекта на тему того какой понятийный аппарат используется в образователей сфере. Может показаться что это фигня, но нет, есть немало слов, про которые мы не то чтобы сильно знали, потому что все это было заложено лет 12 назад, а с тех пор многое утекло. Иногда наше именование не совпадало с общепринятыми (международными) понятиями, а иногда просто все так поменялось, что потерялось изначальное значение. Раньше мы даже взяться за это не могли, а тут без проблем, даже учитывая что один такой пулреквест может тянуть изменения в сотнях, а то и тысячах файлах (спасибо типам и тестам за контроль).
Привели в порядок имена слоев внутри кода, у нас типами называлось то что было не типами. В общем привели в порядок имена сервисов, dto и других штук. Иначе llm регулярно делало не те выводы. Да и в целом лучше развели по слоям и уточнили барьеры абстракции, когда есть четкие правила, что может и не может быть входом или выходом на каждом уровне. Например внутрь сервиса может поступать только структура, модели появляются внутри, но не снаружи и тому подобное. Когда единообразие стало повсеместным, генерируемый код стал максимально предсказуемым.
Иишка смогла найти готовые решения, благодаря которым мы выкинули немало самопала. Это может выглядеть контритуитивно, но несмотря на то что ии позволяет нахерачить все самим, лучше брать готовые промышленные решения (популярные и стандартные). Это касается как фронтовой части (полностью ушли на Mantine), где теперь мы получаем почти 100 процентный уровень генерации в one shot режиме, так и решения для бекендовых задач, например подписок, которое требует определенной модели данных и предоставляет готовые общепринятые сущности.
Плюс постепенное обрастание спеками, проработанными тикетами, глоссарием, adr, коммитамии с хорошими сообщениями, все это вместе дало возможность ии гораздо быстрее и точнее понимать что происходит.
На активный рефакторинг ушло чуть больше года, сейчас мы тоже продолжаем доводить, но уже точечно, потому что ключевые вещи поправлены и иишка достаточно хорошо понимает проект. Следующий шаг, это создание и добавление детерминированных инструментов стат анализа, которые чекают достаточно высокоуровневые вещи.
Telegram | YouTube | AI Клуб
Telegram
Хекслет
Программы обучения - https://ru.hexlet.io/courses
Сообщество @hexletcommunity AI Клуб @hexletclub
Поддержка @hexlet_help_bot
Сообщество @hexletcommunity AI Клуб @hexletclub
Поддержка @hexlet_help_bot
Forwarded from AbstractDL
А вы замечаете, как мы переходим в эпоху, когда программу быстрее написать, чем найти?
💯2