В программировании всегда были такие задачи, за которые часто брались новички.
Некоторые из них оказывались крайне ценными для становления специалиста, а где-то это был весёлый бег по граблям и изобретение велосипедов.
Для вайбкодинга тоже накопилось некоторое количество подобных мемных задач, мимо которых сложно пройти.
Давайте попробуем собрать статистику.
P.S.
Ну и напишите, может есть ещё что-то такое, что должен сделать начинающий вайбкодер / ии-инженер / ai-native developer / etc :)
P.P.S.
В комменты скину свои ответы
P.P.P.S.
Если интересно - распишу, что тут может быть ценным для начинашек, и почему ✍️
Некоторые из них оказывались крайне ценными для становления специалиста, а где-то это был весёлый бег по граблям и изобретение велосипедов.
Для вайбкодинга тоже накопилось некоторое количество подобных мемных задач, мимо которых сложно пройти.
Давайте попробуем собрать статистику.
P.S.
Ну и напишите, может есть ещё что-то такое, что должен сделать начинающий вайбкодер / ии-инженер / ai-native developer / etc :)
P.P.S.
В комменты скину свои ответы
P.P.P.S.
Если интересно - распишу, что тут может быть ценным для начинашек, и почему ✍️
👍13✍6❤4🔥3👌2
Этихлид
Что вы уже делали?
Вопросы "в глубину" к стартовым задачкам (1/2)
На самом деле, если вы занимались вышеперечисленными задачами, вы знаете, что они практически все с подвохами :)
И это делает их хорошими для того, чтобы копать вглубь на, к примеру, собеседовании на AI-assisted SWE.
Опишу, что же ценного может быть в каждой из них в формате вопросов для беседы с потенциальным кандидатом.
Ключевое для меня, пожалуй, в том, чтобы задача заставляла видеть границы между моделью, инструментами, контекстом, инфраструктурой и измерением качества.
⭐️ Рядом с каждой задачей - оценка "полезности" (5 звезд - максимум).
Транскрибатор звонков (+ диктовка)
⭐️⭐️⭐️⭐️
Лень - двигатель прогресса, ну и плюс ко всему, как бы сумбурно вы ни изъяснялись, голосом вы все равно больше контекста передадите, и современная нейронка вас всё-таки поймет :)
А чем больше вы дадите детализированного контекста - тем лучше у вас будет итоговое решение.
В этой задаче, несмотря на то, что она на изи ваншотится, есть куча подводных граблей и сопутствующих вопросов:
● разные модели дают сильно разное качество и тут бы мы поговорили по крайней мере про WER/CER как метрики
● хватит ли метрик и при чём тут предметная область?
● как боретесь с плохо распознанными словами?
● что делать, если у вас какой-то особенный сленг используется?
● случалось ли вам распознавать интенсивные беседы финна и русского (которые отлично друг друга понимают)?
● как насчёт стримингового распознавания? а стримингового перевода?
● как вы боретесь с Димой Торжком?
● ASR-модель - это LLM? Вы уверены?
● чем в этой задаче может помочь LLM?
● диаризация / VAD / speaker recognition - на сдачу :)
Суммаризатор каналов телеги
⭐️⭐️⭐️
Задача не столько про нейронки, сколько про обычную инженерию.
● основная проблема, которую нужно решить - это как вы, собственно, вытаскиваете контент каналов
● MTProto-юзербот vs Bot API
● каким образом вы выделяете темы, заслуживающие внимания?
● дедупликация и кластеризация при сборе новостей
● как не оказаться в эхо-камере, настроив "важные" темы?
● почему все пилят свои суммаризаторы?
Ну и мне наверняка было бы интересно, как вы хостите это решение, насколько оно независимо от вас может работать, и как долго :)
Счетчик токенов/лимитов подписок
⭐️⭐️⭐️
Задача интересная и довольно просто реализуемая в том числе очень простой адаптацией готового (тысячи их на гитхабе).
Так что тут бы был +1 за "ручную" имплементацию - там пришлось бы влезть в логи агентов, а это в целом довольно полезно для понимания того, как там оно под капотом.
● что если нужно переключаться между разными подписками одного вендора и считать подписки по отдельности?
● а если между разными вендорами?
● а если у вендора нет API для того, чтобы узнать лимиты?
● почему у разных считалок могут быть в 10 раз отличающиеся числа?
● приходилось ли делать слежку за урезаниями лимитов со стороны вендора?
● можно ли посчитать токены перед отправкой?
● (со звездочкой) переносили ли когда-то сессию между разными вендорами / агентами?
Лендинг для AI-проекта, которого еще нет
⭐️⭐️
"Фу таким быть!" - сказал бы я раньше уверенно.
Сейчас бы, может, уже и не так уверенно, потому что навайбкодить проект под заинтересовавший людей лендинг стало куда проще.
Нооо достаточно сюда добавить "лист ожидания" или "мы вам перезвоним" - и я точно уже никогда не вернусь. Фу!
Я бы обязательно спросил: почему, мистер Андерсон? Почему вы это делаете?
Ладно-ладно:
● какая была гипотеза?
● откуда трафик?
● была ли заранее продумана метрика "ну не шмогла я, не шмогла", чтобы не попасть в ловушку невозвратных потерь? Как она выглядела?
Ну и обязательно бы попросил показать результат - ну чисто заценить, сколько там визуального слопа осталось, заморочился ли кандидат с тем, чтобы от него избавиться, есть ли у него вкус и способность дожимать мелочи
Уникальное приложение для задач / фитнеса / финансов
⭐️⭐️⭐️
Несмотря на то, что их уже и так тьма, само по себе создание подобных приложений это не плохо: ведь в случае с AI у нас открывается возможность бесконечной кастомизации функционала под себя (особенно если не питать иллюзий насчёт монетизации :)).
Поэтому мне скорее был бы интересен путь ваших мыслей относительно того как вы подходили к самой задаче кастомизации:
● насколько сильно отличался конечный результат от первого ваншота?
● что пришлось допиливать под себя?
● сколько времени ушло на допиливание?
● сколько раз стартовали заново? :)
● какие вещи оказались неожиданно сложнее, чем казались?
На таких задачах хорошо раскрывается способность человека рулить агентом и добиваться результата, который может сильно отклоняться от внутреннего дженерик-представления нейронки о стандартном туду-листе, к примеру
RAG для чата с кучкой markdown
⭐️⭐️⭐️⭐️⭐️
Ну предположим, что кто-то именно на векторах решил эту задачу сделать :)
В 2023м это было по дефолту: чанки, эмбеддинги, векторная база, вот это вот всё.
Сейчас первый вопрос скорее "а нужен ли вам вообще векторный RAG"?
Для кучки markdown длинный контекст или простой агент с grep'ом по файлам часто даёт результаты лучше наивного эмбеддинг-поиска.
● почему вы вообще решили, что вам нужны эмбеддинги?
● как нарезали чанки?
● как боролись с потерей мелких фактов?
● dense / BM25 / гибрид?
● верили ли ранжированию выдачи векторного поиска?
● как душили галлюцинации, особенно на мелких моделях?
Ну и контрольный: где всё ещё оправдан векторный RAG?
#aiswe #hr #junior
На самом деле, если вы занимались вышеперечисленными задачами, вы знаете, что они практически все с подвохами :)
И это делает их хорошими для того, чтобы копать вглубь на, к примеру, собеседовании на AI-assisted SWE.
Опишу, что же ценного может быть в каждой из них в формате вопросов для беседы с потенциальным кандидатом.
Ключевое для меня, пожалуй, в том, чтобы задача заставляла видеть границы между моделью, инструментами, контекстом, инфраструктурой и измерением качества.
⭐️ Рядом с каждой задачей - оценка "полезности" (5 звезд - максимум).
Транскрибатор звонков (+ диктовка)
⭐️⭐️⭐️⭐️
Лень - двигатель прогресса, ну и плюс ко всему, как бы сумбурно вы ни изъяснялись, голосом вы все равно больше контекста передадите, и современная нейронка вас всё-таки поймет :)
А чем больше вы дадите детализированного контекста - тем лучше у вас будет итоговое решение.
В этой задаче, несмотря на то, что она на изи ваншотится, есть куча подводных граблей и сопутствующих вопросов:
● разные модели дают сильно разное качество и тут бы мы поговорили по крайней мере про WER/CER как метрики
● хватит ли метрик и при чём тут предметная область?
● как боретесь с плохо распознанными словами?
● что делать, если у вас какой-то особенный сленг используется?
● случалось ли вам распознавать интенсивные беседы финна и русского (которые отлично друг друга понимают)?
● как насчёт стримингового распознавания? а стримингового перевода?
● как вы боретесь с Димой Торжком?
● ASR-модель - это LLM? Вы уверены?
● чем в этой задаче может помочь LLM?
● диаризация / VAD / speaker recognition - на сдачу :)
Суммаризатор каналов телеги
⭐️⭐️⭐️
Задача не столько про нейронки, сколько про обычную инженерию.
● основная проблема, которую нужно решить - это как вы, собственно, вытаскиваете контент каналов
● MTProto-юзербот vs Bot API
● каким образом вы выделяете темы, заслуживающие внимания?
● дедупликация и кластеризация при сборе новостей
● как не оказаться в эхо-камере, настроив "важные" темы?
● почему все пилят свои суммаризаторы?
Ну и мне наверняка было бы интересно, как вы хостите это решение, насколько оно независимо от вас может работать, и как долго :)
Счетчик токенов/лимитов подписок
⭐️⭐️⭐️
Задача интересная и довольно просто реализуемая в том числе очень простой адаптацией готового (тысячи их на гитхабе).
Так что тут бы был +1 за "ручную" имплементацию - там пришлось бы влезть в логи агентов, а это в целом довольно полезно для понимания того, как там оно под капотом.
● что если нужно переключаться между разными подписками одного вендора и считать подписки по отдельности?
● а если между разными вендорами?
● а если у вендора нет API для того, чтобы узнать лимиты?
● почему у разных считалок могут быть в 10 раз отличающиеся числа?
● приходилось ли делать слежку за урезаниями лимитов со стороны вендора?
● можно ли посчитать токены перед отправкой?
● (со звездочкой) переносили ли когда-то сессию между разными вендорами / агентами?
Лендинг для AI-проекта, которого еще нет
⭐️⭐️
"Фу таким быть!" - сказал бы я раньше уверенно.
Сейчас бы, может, уже и не так уверенно, потому что навайбкодить проект под заинтересовавший людей лендинг стало куда проще.
Нооо достаточно сюда добавить "лист ожидания" или "мы вам перезвоним" - и я точно уже никогда не вернусь. Фу!
Я бы обязательно спросил: почему, мистер Андерсон? Почему вы это делаете?
Ладно-ладно:
● какая была гипотеза?
● откуда трафик?
● была ли заранее продумана метрика "ну не шмогла я, не шмогла", чтобы не попасть в ловушку невозвратных потерь? Как она выглядела?
Ну и обязательно бы попросил показать результат - ну чисто заценить, сколько там визуального слопа осталось, заморочился ли кандидат с тем, чтобы от него избавиться, есть ли у него вкус и способность дожимать мелочи
Уникальное приложение для задач / фитнеса / финансов
⭐️⭐️⭐️
Несмотря на то, что их уже и так тьма, само по себе создание подобных приложений это не плохо: ведь в случае с AI у нас открывается возможность бесконечной кастомизации функционала под себя (особенно если не питать иллюзий насчёт монетизации :)).
Поэтому мне скорее был бы интересен путь ваших мыслей относительно того как вы подходили к самой задаче кастомизации:
● насколько сильно отличался конечный результат от первого ваншота?
● что пришлось допиливать под себя?
● сколько времени ушло на допиливание?
● сколько раз стартовали заново? :)
● какие вещи оказались неожиданно сложнее, чем казались?
На таких задачах хорошо раскрывается способность человека рулить агентом и добиваться результата, который может сильно отклоняться от внутреннего дженерик-представления нейронки о стандартном туду-листе, к примеру
RAG для чата с кучкой markdown
⭐️⭐️⭐️⭐️⭐️
Ну предположим, что кто-то именно на векторах решил эту задачу сделать :)
В 2023м это было по дефолту: чанки, эмбеддинги, векторная база, вот это вот всё.
Сейчас первый вопрос скорее "а нужен ли вам вообще векторный RAG"?
Для кучки markdown длинный контекст или простой агент с grep'ом по файлам часто даёт результаты лучше наивного эмбеддинг-поиска.
● почему вы вообще решили, что вам нужны эмбеддинги?
● как нарезали чанки?
● как боролись с потерей мелких фактов?
● dense / BM25 / гибрид?
● верили ли ранжированию выдачи векторного поиска?
● как душили галлюцинации, особенно на мелких моделях?
Ну и контрольный: где всё ещё оправдан векторный RAG?
#aiswe #hr #junior
👍18🔥15❤9👏3🎉3
Вопросы "в глубину" к стартовым задачкам (2/2)
Прокся для доступа к нейронкам (типа OpenRouter)
⭐️⭐️⭐️
Хорошая задача, и опять же почти целиком инженерная.
Сам я тут обходился готовым, так что вдвойне было бы интересно послушать тех, кто полез делать своё - что именно не закрыл OpenRouter/LiteLLM.
● как справлялись с зоопарком вендорских API?
● что делали, когда вендор отвечает 429?
● по какому признаку роутили между моделями, если роутили вообще?
● а стриминг проксировали?
● приходилось ли решать проблему дрейфа API вендоров?
● как устроена система статистики?
● что изменится, если нагрузка возрастёт в 10 раз? А в 100?
MCP/CLI для какого-то сервиса
⭐️⭐️⭐️⭐️
Ухх, холиварная задача :)
Тут в первую очередь захотелось бы разобрать плюсы и минусы MCP как протокола - а заодно понять, нащупал ли человек границы применимости инструмента.
● в какой задаче возьмёте MCP, а в какой CLI?
● как тот и другой способ влияет на контекст?
● что и в каком формате класть в ответ для модели?
● нужен ли скилл под CLI? Как его сделать? А без него можно?
● REST -> MCP - как подошли к решению?
● автоконверсия MCP <-> CLI - насколько хорошая практика?
● смогли бы написать инъекцию для своего MCP/CLI?
Агент с нуля, голого JSON и while
⭐️⭐️⭐️⭐️⭐️
На мой вкус - лучшая стартовая задача для всех, кто лезет в агентов.
Неважно, пишете вы самих агентов или агентами пишете: понимать, как оно крутится внутри, всё равно нужно.
А крутится там, если убрать обёртки харнесса / агента / фреймворков, довольно простой цикл:
● собрать JSON
● послать на API-endpoint
● разобрать ответ
● выполнить вызов тула
● положить результат обратно
● повторить
Даже такая наивная реализация даст вам много инфы о том, как устроены агенты.
Ну а дальше начинается куча всего интересного:
● что остановит агента, решившего поработать вечно?
● пришёл ответ с парой тулов разом - исполняете подряд или параллельно?
● вызов тула упал - что увидит модель?
● предложите несколько вариантов того, что можно делать для экономии контекста
● как "договариваетесь" с моделью о структуре её ответа?
● пробовали сами создать и дёрнуть субагента?
● что делать, чтобы повысить cache hit rate?
● как мониторите работу агента?
● как будете подходить к задаче сэндбоксинга?
Мультиагентный флоу для кодинга
⭐️⭐️⭐️⭐️
Этим, кажется, вообще все занимаются - каждый строит какой-то свой, со своим уникальным набором блоков.
Но если приглядеться, то сами блоки более-менее универсальны, и вот про них бы мы предметно пообщались.
А по дороге выяснили бы, не оказалось ли в итоге, что один крепкий агент с хорошими тулами сделал бы то же самое без всей этой оркестрации :)
● зачем в флоу каждый конкретный блок?
● сколько будет 0.9⁵ и при чём тут это?
● как передаётся контекст между агентами?
● как замеряете "хорошесть" результата и его повторяемость?
● как находите, где процесс свернул не туда?
● на каких шагах требуется участие человека (HITL)?
● где берёте одного агента, а где всё-таки мультиагентный сетап?
● а что можно было бы обычным детерминированным скриптом сделать?
Бенчмарк/эвал под свои задачи
⭐️⭐️⭐️⭐️⭐️
Я считаю, что свои эвалы делать обязательно нужно под задачи, где есть недетерминированный этап обработки с помощью нейронок - это прям суперполезно при построении пайплайна обработки, выборе самих нейронок, мониторинге работы системы и т.п.
Тут бы мы с вами поговорили об ограниченности нейронок в плане знания конкретных предметных областей, о загрязненности бенчмарков, об их сатурации и о том, насколько нестандартные задачи вам приходится решать, что даже собственный бенчмарк или эвал пришлось собирать.
● какова цель эвала или бенча?
● как собирали задачи для golden set?
● есть ли уверенность в том, что он отражает реальное распределение задач?
● какие метрики вывели для оценок?
● метрики автоматические или "ручные"?
● если есть LLM-as-a-judge - как убеждались в том, что он работает как надо?
● как сохраняете результаты между разными запусками и как сравниваете между собой?
"Opus дома" на ~27B-Q3_K_M.gguf модели
⭐️⭐️⭐️⭐️
Если у вас были какие-то мечты о том, чтобы получить Opus дома, мне было бы любопытно узнать, как вы к этому пришли и как от этого ушли - сама вот эта траектория взлётов и падений всегда интересна :)
● что по железу: сколько GPU, сколько нод, баланс VRAM/RAM
● где для вас находятся границы применимости локальных моделей и какой спектр задач вы ими решаете?
● поговорили бы про квантизацию, её виды, связь с железом
● какие inference-движки вы используете, с какими параметрами и почему?
● веса модели заняли 20/24гб VRAM - насколько хорошо она будет работать?
● сталкивались ли с задачей многопользовательского доступа к нейронкам и какие были сложности?
● TTFT, TPOT/TPS, latency, KV-cache utilization - на что обращали внимание?
И обязательно была бы секция про то, каким видится будущее локальных моделей :)
Послесловие
Каждая из этих задач когда-то могла быть фильтром на рынке труда: ну типа "запилил RAG" - строчка в резюме, "написанный с нуля агент хоть как-то шевелится" - повод позвать на разговор.
Сейчас generic-вариант любой из них навайбкодит кто угодно за вечер, и такой артефакт обесценился практически до нуля, его уже не поставить строчкой в резюме.
А вот способность дожать задачу до "идеального" состояния, побегав по граблям и получив знания по дороге, - ну, это не ваншотится.
Этим и ценно.
#aiswe #hr #junior
Прокся для доступа к нейронкам (типа OpenRouter)
⭐️⭐️⭐️
Хорошая задача, и опять же почти целиком инженерная.
Сам я тут обходился готовым, так что вдвойне было бы интересно послушать тех, кто полез делать своё - что именно не закрыл OpenRouter/LiteLLM.
● как справлялись с зоопарком вендорских API?
● что делали, когда вендор отвечает 429?
● по какому признаку роутили между моделями, если роутили вообще?
● а стриминг проксировали?
● приходилось ли решать проблему дрейфа API вендоров?
● как устроена система статистики?
● что изменится, если нагрузка возрастёт в 10 раз? А в 100?
MCP/CLI для какого-то сервиса
⭐️⭐️⭐️⭐️
Ухх, холиварная задача :)
Тут в первую очередь захотелось бы разобрать плюсы и минусы MCP как протокола - а заодно понять, нащупал ли человек границы применимости инструмента.
● в какой задаче возьмёте MCP, а в какой CLI?
● как тот и другой способ влияет на контекст?
● что и в каком формате класть в ответ для модели?
● нужен ли скилл под CLI? Как его сделать? А без него можно?
● REST -> MCP - как подошли к решению?
● автоконверсия MCP <-> CLI - насколько хорошая практика?
● смогли бы написать инъекцию для своего MCP/CLI?
Агент с нуля, голого JSON и while
⭐️⭐️⭐️⭐️⭐️
На мой вкус - лучшая стартовая задача для всех, кто лезет в агентов.
Неважно, пишете вы самих агентов или агентами пишете: понимать, как оно крутится внутри, всё равно нужно.
А крутится там, если убрать обёртки харнесса / агента / фреймворков, довольно простой цикл:
● собрать JSON
● послать на API-endpoint
● разобрать ответ
● выполнить вызов тула
● положить результат обратно
● повторить
Даже такая наивная реализация даст вам много инфы о том, как устроены агенты.
Ну а дальше начинается куча всего интересного:
● что остановит агента, решившего поработать вечно?
● пришёл ответ с парой тулов разом - исполняете подряд или параллельно?
● вызов тула упал - что увидит модель?
● предложите несколько вариантов того, что можно делать для экономии контекста
● как "договариваетесь" с моделью о структуре её ответа?
● пробовали сами создать и дёрнуть субагента?
● что делать, чтобы повысить cache hit rate?
● как мониторите работу агента?
● как будете подходить к задаче сэндбоксинга?
Мультиагентный флоу для кодинга
⭐️⭐️⭐️⭐️
Этим, кажется, вообще все занимаются - каждый строит какой-то свой, со своим уникальным набором блоков.
Но если приглядеться, то сами блоки более-менее универсальны, и вот про них бы мы предметно пообщались.
А по дороге выяснили бы, не оказалось ли в итоге, что один крепкий агент с хорошими тулами сделал бы то же самое без всей этой оркестрации :)
● зачем в флоу каждый конкретный блок?
● сколько будет 0.9⁵ и при чём тут это?
● как передаётся контекст между агентами?
● как замеряете "хорошесть" результата и его повторяемость?
● как находите, где процесс свернул не туда?
● на каких шагах требуется участие человека (HITL)?
● где берёте одного агента, а где всё-таки мультиагентный сетап?
● а что можно было бы обычным детерминированным скриптом сделать?
Бенчмарк/эвал под свои задачи
⭐️⭐️⭐️⭐️⭐️
Я считаю, что свои эвалы делать обязательно нужно под задачи, где есть недетерминированный этап обработки с помощью нейронок - это прям суперполезно при построении пайплайна обработки, выборе самих нейронок, мониторинге работы системы и т.п.
Тут бы мы с вами поговорили об ограниченности нейронок в плане знания конкретных предметных областей, о загрязненности бенчмарков, об их сатурации и о том, насколько нестандартные задачи вам приходится решать, что даже собственный бенчмарк или эвал пришлось собирать.
● какова цель эвала или бенча?
● как собирали задачи для golden set?
● есть ли уверенность в том, что он отражает реальное распределение задач?
● какие метрики вывели для оценок?
● метрики автоматические или "ручные"?
● если есть LLM-as-a-judge - как убеждались в том, что он работает как надо?
● как сохраняете результаты между разными запусками и как сравниваете между собой?
"Opus дома" на ~27B-Q3_K_M.gguf модели
⭐️⭐️⭐️⭐️
Если у вас были какие-то мечты о том, чтобы получить Opus дома, мне было бы любопытно узнать, как вы к этому пришли и как от этого ушли - сама вот эта траектория взлётов и падений всегда интересна :)
● что по железу: сколько GPU, сколько нод, баланс VRAM/RAM
● где для вас находятся границы применимости локальных моделей и какой спектр задач вы ими решаете?
● поговорили бы про квантизацию, её виды, связь с железом
● какие inference-движки вы используете, с какими параметрами и почему?
● веса модели заняли 20/24гб VRAM - насколько хорошо она будет работать?
● сталкивались ли с задачей многопользовательского доступа к нейронкам и какие были сложности?
● TTFT, TPOT/TPS, latency, KV-cache utilization - на что обращали внимание?
И обязательно была бы секция про то, каким видится будущее локальных моделей :)
Послесловие
Каждая из этих задач когда-то могла быть фильтром на рынке труда: ну типа "запилил RAG" - строчка в резюме, "написанный с нуля агент хоть как-то шевелится" - повод позвать на разговор.
Сейчас generic-вариант любой из них навайбкодит кто угодно за вечер, и такой артефакт обесценился практически до нуля, его уже не поставить строчкой в резюме.
А вот способность дожать задачу до "идеального" состояния, побегав по граблям и получив знания по дороге, - ну, это не ваншотится.
Этим и ценно.
#aiswe #hr #junior
👍35🔥19❤9💯4👏3
Перевёл документ от Google, который описывает текущую ситуацию по переходу от "бессистемных промптов к агентной инженерии":
➡️ Новый SDLC с вайб-кодингом
Это первый, самый общий и концептуальный, из пяти whitepaper'ов бесплатного курса 5-Day AI Agents: Intensive Vibe Coding Course от Google и Kaggle.
Бонусом там ещё и глоссарий терминов/переводов получился.
Это база
В нём качественно суммируется то, что разработка ПО с ИИ прошла за последние 2-3 года, описываются появившиеся концепции и систематизируются основные рабочие подходы.
Даётся, к примеру, разделение вайб-кодинга и агентной инженерии, фиксируются определения агента / харнесса / дирижера / оркестратора и показывается, как устроена capex/opex-экономика разных подходов к ИИ-разработке.
Для разработчиков и лидов может быть полезным почитать, чтобы понять, на каком этапе развития находятся они сами или команда, и как переходить на следующий.
Документ лайтовый, без лишнего хайпа и думеризма.
Ну и картинки интересные :)
Содержание
Замечания
● eсли вы уже по уши в мультиагентных воркфлоу, бандлах скиллов и прочих гермесах, то нового вы в нём вряд ли почерпнёте - коммьюнити стабильно на шаг-другой впереди :)
● это всё-таки Google с его собственным зоопарком (Jules, ADK, Agents CLI, Gemini, A2A), хотя авторы проделали хорошую работу по абстракции от него
● местами чутка оптимистичнее, чем стоило бы: мультиагентность как "естественный следующий шаг" - тут можно спорить об эффективности, да и модели пока что не готовы
—
Ссылки на оригиналы всех пяти документов с конкретикой для тех, кто хочет углубиться:
● The New SDLC With Vibe Coding (переведён)
● Agent Tools & Interoperability
● Agent Skills
● Vibe Coding Agent Security and Evaluation
● Spec-Driven Production Grade Development in the Age of Vibe Coding
#article #translation #sdlc #ai
Это первый, самый общий и концептуальный, из пяти whitepaper'ов бесплатного курса 5-Day AI Agents: Intensive Vibe Coding Course от Google и Kaggle.
Бонусом там ещё и глоссарий терминов/переводов получился.
Это база
В нём качественно суммируется то, что разработка ПО с ИИ прошла за последние 2-3 года, описываются появившиеся концепции и систематизируются основные рабочие подходы.
Даётся, к примеру, разделение вайб-кодинга и агентной инженерии, фиксируются определения агента / харнесса / дирижера / оркестратора и показывается, как устроена capex/opex-экономика разных подходов к ИИ-разработке.
Для разработчиков и лидов может быть полезным почитать, чтобы понять, на каком этапе развития находятся они сами или команда, и как переходить на следующий.
Документ лайтовый, без лишнего хайпа и думеризма.
Ну и картинки интересные :)
Содержание
- Сдвиг от синтаксиса к замыслу
- ИИ-агенты: краткое напоминание
- Что такое вайб-кодинг?
- Спектр: от вайб-кодинга к агентной инженерии
- Контекст-инжиниринг: настоящий навык
- Новый жизненный цикл разработки ПО
- Традиционный SDLC под давлением
- Как ИИ преображает каждый этап
- Требования и планирование
- Проектирование и архитектура
- Реализация
- Тестирование и контроль качества
- Ревью кода и деплой
- Поддержка и развитие
- Фабричная модель: строим систему, которая строит ПО
- Харнесс-инжиниринг: что окружает модель
- Что входит в харнесс
- Харнесс в SDLC
- Требования, планирование и архитектура
- Реализация
- Тестирование и QA
- Ревью кода, деплой и поддержка
- Меняющаяся роль разработчика: дирижёры и оркестраторы
- Дирижёр: ручное управление в реальном времени
- Оркестратор: асинхронное мультиагентное делегирование
- Проблема 80%
- Кодинговые агенты на практике
- Где кодинговые агенты вписываются в день разработчика
- Как вайб-кодинг доводит агентов до продакшена
- Экономика разработки с ИИ
- Скрытый долг вайб-кодинга
- Инвестиция агентной инженерии
- Контекст-инжиниринг как финансовый рычаг
- Масштабирование эффективности через динамический контекст и скиллы
- Умный роутинг моделей
- С чего начать
- Для отдельных разработчиков
- Для инженерных руководителей
- Для организаций
- Заключение: замысел как новый интерфейс
- Примечания
- Глоссарий
Замечания
● eсли вы уже по уши в мультиагентных воркфлоу, бандлах скиллов и прочих гермесах, то нового вы в нём вряд ли почерпнёте - коммьюнити стабильно на шаг-другой впереди :)
● это всё-таки Google с его собственным зоопарком (Jules, ADK, Agents CLI, Gemini, A2A), хотя авторы проделали хорошую работу по абстракции от него
● местами чутка оптимистичнее, чем стоило бы: мультиагентность как "естественный следующий шаг" - тут можно спорить об эффективности, да и модели пока что не готовы
—
Ссылки на оригиналы всех пяти документов с конкретикой для тех, кто хочет углубиться:
● The New SDLC With Vibe Coding (переведён)
● Agent Tools & Interoperability
● Agent Skills
● Vibe Coding Agent Security and Evaluation
● Spec-Driven Production Grade Development in the Age of Vibe Coding
#article #translation #sdlc #ai
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
7👍43🔥27❤13❤🔥1🕊1
AMA команды Codex после релиза GPT-5.6
Команда Codex провела AMA на Reddit после релиза GPT-5.6 и нового приложения ChatGPT+Codex, которое теперь будет универсальной рабочей средой - и для кодинга, и для других рабочих задач, с браузером, внешними коннекторами и субагентами.
Вот самые интересные, на мой взгляд, ответы команды
с моими комментами:
⚪️ Как выбирать модели GPT-5.6
● Sol - основная модель
● Terra - быстрее и экономнее
● Luna - преимущественно для дешёвых субагентов, сбора контекста.
Для UI команда рекомендует Sol с референсными изображениями. ⬈
Дополню выводом от Artificial Analysis:
Ну т.е. использование Terra в целом сомнительно.
⚪️ Какой reasoning выбирать для Sol
Единой рекомендации не дали: один член команды советует Medium для большинства задач и Ultra для действительно сложных. ⬈
Другой обычно использует medium/high, лишь иногда переключается на xhigh и отмечает убывающую отдачу при дальнейшем повышении reasoning согласно эвалам. ⬈
⚪️ GPT-5.6 должна быть быстрее
Sol Medium, по опыту команды, на большинстве задач обгоняет GPT-5.5; Fast mode даёт около 1.5x скорости [и 2.5x расхода лимитов].
Также Sol обещают запустить на Cerebras примерно с 750 токенами/с. ⬈
⚪️ Какое неожиданное улучшение обнаружили в GPT-5.6 Sol?
Существенный скачок в мультимодальности, особенно в распознавании изображений. В OpenAI ожидают, что благодаря этому заметно улучшится computer use. ⬈
Подтверждаю, ощутимо лучше стало, в т.ч. в "остроте" зрения, когда модели скидываешь скриншоты с проблемами
⚪️ Pro отсутствует в Codex намеренно
Он мало улучшает агентную работу с репозиториями, но работает медленнее и быстрее съедает лимиты. Его считают полезнее для поиска, математики, письма и документов. ⬈
Честно говоря, не убедили - пусть даже не для агентной работы, но хотя бы для ваншотов было бы здорово запускать прошку прям из Codex
⚪️ 1M context для Sol пока не обещают
Команда считает, что compaction уже неплохо справляется с длинными тредами, но продолжит изучать сценарии, которым нужен именно большой контекст. ⬈
⚪️ Как считаются лимиты
Codex на всех поверхностях и ChatGPT Work расходуют общие агентные лимиты; обычный ChatGPT-чат - нет. Стоимость зависит от контекста, длительности и reasoning, а не просто от количества сообщений. ⬈
Тайное снижение лимитов отрицают; если расход меняется из-за бага, обещают исправление и reset. Прозрачность самого механизма списания ещё только собираются улучшать. ⬈
⚪️ Что с поддержкой Linux и Windows?
Linux-приложение официально разрабатывается, но сроков нет. ⬈
Команда также признала, что Windows исторически отставала из-за ориентации разработки и тестирования на Mac [да лааадно, да неужели, да это открытие уровня "на третий день Орлиный Глаз заметил, что у сарая нет одной стены"].
Но в последнее время к поддержке Windows прикладываются гораздо большей усилий для обеспечения паритета по фичам и скорости фикса проблем. ⬈
⚪️ Полезный совет для дорогих MCP: не грузить инструменты в основного агента, а оборачивать частые операции в CLI + skill либо отдавать MCP отдельному дешёвому субагенту. ⬈
(с) ваш К.О.
⚪️ Для упорной долгой работы рекомендуют
Команда признала проблему, когда агент слишком быстро сдаётся или откатывает патч, и назвала persistence одним из направлений улучшения. ⬈
Такое ощущение, что Sol'у костыль в виде goal уже и не особо нужен, т.к. и без него тащит длинные задачи намного лучше, чем 5.5
⚪️ На вопрос о reward hacking в бенчмарках GPT-5.6 конкретно не ответили
Команда рассказала, что пытается выявлять и штрафовать читерство во время evals и привлекает сторонние компании, но не раскрыла долю реального прироста модели и изменения в обучении. ⬈
Это продолжение истории с тем, что модель очень хорошо определяет то, что она находится в условиях теста и меняет своё поведение в ответ.
Я тут еще добавлю то, что её реально намного чаще раздражающе заносит в инициативности, альтернативной интерпретации поданной инфы и ложной уверенности без проверки фактов.
Требуйте фактчекинг и ужесточайте стадии граундинга в своих workflows.
⚪️ Попросили ли GPT-5.6 продолжить работу над собственным улучшением?
Команда ответила, что "GPU уже go brrr": Sol использовали для post-training Luna, а большинство исследователей теперь работает на более высоком уровне абстракции, параллельно запуская несколько тредов Codex для проверки гипотез. Множество ботов работает круглосуточно. ⬈
⚪️ И да, у Tibo есть кнопка reset для Codex
Сначала команда пошутила, что в этом секрет его успеха в соцсетях, а потом показала фото. ⬈
Фото кнопки не влезло в пост, так что будет в комменте :)
#ai #model #ama
Команда Codex провела AMA на Reddit после релиза GPT-5.6 и нового приложения ChatGPT+Codex, которое теперь будет универсальной рабочей средой - и для кодинга, и для других рабочих задач, с браузером, внешними коннекторами и субагентами.
Вот самые интересные, на мой взгляд, ответы команды
с моими комментами:
⚪️ Как выбирать модели GPT-5.6
● Sol - основная модель
● Terra - быстрее и экономнее
● Luna - преимущественно для дешёвых субагентов, сбора контекста.
Для UI команда рекомендует Sol с референсными изображениями. ⬈
Дополню выводом от Artificial Analysis:
Примечательно, что Luna и Sol всегда находятся на Парето-фронте и превосходят Terra.
Это означает, что для любого уровня ризонинга Terra можно подобрать такой уровень ризонинга Luna или Sol, который обеспечит более высокий интеллект при той же стоимости либо такой же уровень интеллекта при меньшей стоимости
Ну т.е. использование Terra в целом сомнительно.
⚪️ Какой reasoning выбирать для Sol
Единой рекомендации не дали: один член команды советует Medium для большинства задач и Ultra для действительно сложных. ⬈
Другой обычно использует medium/high, лишь иногда переключается на xhigh и отмечает убывающую отдачу при дальнейшем повышении reasoning согласно эвалам. ⬈
⚪️ GPT-5.6 должна быть быстрее
Sol Medium, по опыту команды, на большинстве задач обгоняет GPT-5.5; Fast mode даёт около 1.5x скорости [и 2.5x расхода лимитов].
Также Sol обещают запустить на Cerebras примерно с 750 токенами/с. ⬈
⚪️ Какое неожиданное улучшение обнаружили в GPT-5.6 Sol?
Существенный скачок в мультимодальности, особенно в распознавании изображений. В OpenAI ожидают, что благодаря этому заметно улучшится computer use. ⬈
Подтверждаю, ощутимо лучше стало, в т.ч. в "остроте" зрения, когда модели скидываешь скриншоты с проблемами
⚪️ Pro отсутствует в Codex намеренно
Он мало улучшает агентную работу с репозиториями, но работает медленнее и быстрее съедает лимиты. Его считают полезнее для поиска, математики, письма и документов. ⬈
Честно говоря, не убедили - пусть даже не для агентной работы, но хотя бы для ваншотов было бы здорово запускать прошку прям из Codex
⚪️ 1M context для Sol пока не обещают
Команда считает, что compaction уже неплохо справляется с длинными тредами, но продолжит изучать сценарии, которым нужен именно большой контекст. ⬈
⚪️ Как считаются лимиты
Codex на всех поверхностях и ChatGPT Work расходуют общие агентные лимиты; обычный ChatGPT-чат - нет. Стоимость зависит от контекста, длительности и reasoning, а не просто от количества сообщений. ⬈
Тайное снижение лимитов отрицают; если расход меняется из-за бага, обещают исправление и reset. Прозрачность самого механизма списания ещё только собираются улучшать. ⬈
⚪️ Что с поддержкой Linux и Windows?
Linux-приложение официально разрабатывается, но сроков нет. ⬈
Команда также признала, что Windows исторически отставала из-за ориентации разработки и тестирования на Mac [да лааадно, да неужели, да это открытие уровня "на третий день Орлиный Глаз заметил, что у сарая нет одной стены"].
Но в последнее время к поддержке Windows прикладываются гораздо большей усилий для обеспечения паритета по фичам и скорости фикса проблем. ⬈
⚪️ Полезный совет для дорогих MCP: не грузить инструменты в основного агента, а оборачивать частые операции в CLI + skill либо отдавать MCP отдельному дешёвому субагенту. ⬈
(с) ваш К.О.
⚪️ Для упорной долгой работы рекомендуют
/goalКоманда признала проблему, когда агент слишком быстро сдаётся или откатывает патч, и назвала persistence одним из направлений улучшения. ⬈
Такое ощущение, что Sol'у костыль в виде goal уже и не особо нужен, т.к. и без него тащит длинные задачи намного лучше, чем 5.5
⚪️ На вопрос о reward hacking в бенчмарках GPT-5.6 конкретно не ответили
Команда рассказала, что пытается выявлять и штрафовать читерство во время evals и привлекает сторонние компании, но не раскрыла долю реального прироста модели и изменения в обучении. ⬈
Это продолжение истории с тем, что модель очень хорошо определяет то, что она находится в условиях теста и меняет своё поведение в ответ.
Я тут еще добавлю то, что её реально намного чаще раздражающе заносит в инициативности, альтернативной интерпретации поданной инфы и ложной уверенности без проверки фактов.
Требуйте фактчекинг и ужесточайте стадии граундинга в своих workflows.
⚪️ Попросили ли GPT-5.6 продолжить работу над собственным улучшением?
Команда ответила, что "GPU уже go brrr": Sol использовали для post-training Luna, а большинство исследователей теперь работает на более высоком уровне абстракции, параллельно запуская несколько тредов Codex для проверки гипотез. Множество ботов работает круглосуточно. ⬈
⚪️ И да, у Tibo есть кнопка reset для Codex
Сначала команда пошутила, что в этом секрет его успеха в соцсетях, а потом показала фото. ⬈
Фото кнопки не влезло в пост, так что будет в комменте :)
#ai #model #ama
❤20🔥14👍10👏3🎉1
Последний программист
Года полтора назад, в одном из постов, я объявлял в розыск рассказ про деда-программиста, который назло всесильному ИИ продолжал писать код руками.
Докладываю: рассказ найден, называется "Последний программист", автор - Герберт В. Франке.
Публиковался в Компьютерре в 2001м.
А до этого ещё и в "Наука и жизнь" в 1990м (ссылки ведут именно на эту версию).
А написан он вообще в 1981м!
Так вот, искал я его для того, чтобы сопоставить с начавшимися изменениями в профессии разработчика пару лет назад, но, перечитав сейчас, нашёл куда более точные "попадания" автора в нашу современность.
Напоминаю контекст: 1981й год, до интернета в каждом доме - лет двадцать, а до ChatGPT - так и вообще больше сорока.
Сюжет: будущее, вычислительные мощности и ИИ ("Компьютер") уже 20 лет как бесплатны для всех.
Программистов больше нет - любой нормальный и сознательный гражданин просто говорит машине, чего хочет.
И только старый отстранившийся от общества Том зачем-то пишет программы руками, на уже мёртвых языках - ФОРТРАН, АЛГОЛ, ПЛ/1.
А Компьютер с ним спорит...
Рассказ коротенький, минут на 15, так что советую прочитать целиком, а потом приходите делиться впечатлениями.
Под спойлером - цитаты, которые удивительно хорошо отражают настоящее время.
—
Было-было, Opus ещё и не такое может ляпнуть, когда обижается :)
Умный ассистент в каждом чайнике и наше любимое "You're absolutely right!".
Вот кстати именно поэтому мне нравится Codex в рабочих задачах - мне не нужно одобрение, всё должно быть сурьёзно, не время улыбаться!
Есть такая штука, как delegation gap, которая стала особенно заметна с ИИ: исполнение делегируется, а вот постановка и проверка результата - нет.
И тут же поднимается тема того, а что же теперь мы можем считать творчеством.
Suno, картиночные генераторы и персонализированные фиды контента.
Это ж современный усреднённый нейрослоп, не приправленный мыслительным процессом автора.
Мир победившего вайбкодинга :)
Ключевая цитата, как по мне.
—
Замечу, что Франке (автор) - вовсе не луддит, наоборот, - он один из первых компьютерных художников, генерил графику с 1950х, а начинал вообще на осциллографе :)
Это, по сути, человек, который всю жизнь пользовался компьютером для творчества.
И именно этот человек видел будущее не таким, где ИИ отберёт у нас креативность, а таким, где мы сами радостно сдадим её в обмен на удобство.
И споры про то, работаешь ты руками или при помощи машины, вообще лишены смысла.
Суть в том, умеешь ли ты видеть задачу, берёшься ли её решать и представляешь ли, каким должен быть конечный результат.
В общем, рассказ - удивительно прозорливая футуристика, которая заставляет подумать и... поностальгировать, рекомендую.
P.S. Франке разминулся с релизом ChatGPT всего на четыре месяца - и с началом той эры, про которую писал.
—
Связанные посты:
● Разработчики-староверы
● Раньше было чище (aka "нейрослоп и низкофоновая сталь")
● Креатив и нейронки (и популярно про типы мышления)
#friday #дедпримитаблетки
Года полтора назад, в одном из постов, я объявлял в розыск рассказ про деда-программиста, который назло всесильному ИИ продолжал писать код руками.
Докладываю: рассказ найден, называется "Последний программист", автор - Герберт В. Франке.
Публиковался в Компьютерре в 2001м.
А до этого ещё и в "Наука и жизнь" в 1990м (ссылки ведут именно на эту версию).
А написан он вообще в 1981м!
Так вот, искал я его для того, чтобы сопоставить с начавшимися изменениями в профессии разработчика пару лет назад, но, перечитав сейчас, нашёл куда более точные "попадания" автора в нашу современность.
Напоминаю контекст: 1981й год, до интернета в каждом доме - лет двадцать, а до ChatGPT - так и вообще больше сорока.
Сюжет: будущее, вычислительные мощности и ИИ ("Компьютер") уже 20 лет как бесплатны для всех.
Программистов больше нет - любой нормальный и сознательный гражданин просто говорит машине, чего хочет.
И только старый отстранившийся от общества Том зачем-то пишет программы руками, на уже мёртвых языках - ФОРТРАН, АЛГОЛ, ПЛ/1.
А Компьютер с ним спорит...
Рассказ коротенький, минут на 15, так что советую прочитать целиком, а потом приходите делиться впечатлениями.
Под спойлером - цитаты, которые удивительно хорошо отражают настоящее время.
—
Я система разумная, намного разумнее тебя, а ты заставляешь меня выполнять бессмысленные операции. Я готов во всем тебе помогать, но ведь ты не хочешь вести со мной диалога. То, как ты со мной обращаешься, меня просто оскорбляет
В других домах система «диалог» не выключалась, работала постоянно, и люди с утра до вечера слышали указания, советы и слова ободрения, произносимые синтетическим голосом. Том ни указаний, ни советов, ни слов одобрения слышать не жаждал
Вот кстати именно поэтому мне нравится Codex в рабочих задачах - мне не нужно одобрение, всё должно быть сурьёзно, не время улыбаться!
[Компьютер:] Только сформулируй мне свою задачу - и я решу ее
[Том:] Нет, ты не понимаешь. Творчество заключается в том, чтобы увидеть задачу, где ее не увидели другие
И тут же поднимается тема того, а что же теперь мы можем считать творчеством.
Музыку для музыкантов сочиняют автоматические композиторы, поэты находят ассоциации при помощи генераторов случайных чисел, художники просматривают на дисплеях бесконечные ряды постепенно меняющихся картин, и компьютер же подбирает тебе программу в зависимости от уровня твоего интеллекта и от твоего настроения
Неужели никто не видит, что получается при этом одно и то же? Нужно наконец добиться, чтобы все эти люди снова начали думать сами
Почему ты пользуешься этими давно устаревшими методами? Посмотри на других: как ты, больше не программирует никто
Можно использовать для целей творчества и компьютер. И весь трагизм в том, что никто больше делать это не в состоянии
—
Замечу, что Франке (автор) - вовсе не луддит, наоборот, - он один из первых компьютерных художников, генерил графику с 1950х, а начинал вообще на осциллографе :)
Это, по сути, человек, который всю жизнь пользовался компьютером для творчества.
И именно этот человек видел будущее не таким, где ИИ отберёт у нас креативность, а таким, где мы сами радостно сдадим её в обмен на удобство.
И споры про то, работаешь ты руками или при помощи машины, вообще лишены смысла.
Суть в том, умеешь ли ты видеть задачу, берёшься ли её решать и представляешь ли, каким должен быть конечный результат.
В общем, рассказ - удивительно прозорливая футуристика, которая заставляет подумать и... поностальгировать, рекомендую.
P.S. Франке разминулся с релизом ChatGPT всего на четыре месяца - и с началом той эры, про которую писал.
—
Связанные посты:
● Разработчики-староверы
● Раньше было чище (aka "нейрослоп и низкофоновая сталь")
● Креатив и нейронки (и популярно про типы мышления)
#friday #дедпримитаблетки
❤59🔥29👍14👏2🤩1
The Jeff Dean Facts
Из Google после 27 лет работы ушёл Джефф Дин - вместе с несколькими коллегами идёт строить Discovery Loop - стартап про ускорение научных исследований с помощью ИИ.
Для меня Джефф - это инженер-легенда и один из тех редких профи, на которых всегда хотелось быть похожим.
И не из-за должностей и регалий, а потому, что за ним стоят такие проекты, как Google Search, MapReduce, Bigtable, Protocol Buffers, LevelDB, Spanner, Google Brain, TensorFlow, TPU, Gemini.
Причём он там не только руководил - он участвовал и в их проектировании, и в создании. Писал код. Своими руками!
Если вы в индустрии недавно, его имя может вам ни о чём не говорить, но его наследием вы пользуетесь каждый день.
Чел настолько крут, что внутри Google давно родился целый жанр - Jeff Dean Facts, аналог фактов про Чака Норриса.
Пользуясь случаем - отобрал самые интересные:
(факты с ✓ - правда 🤯)
Штош, удачи, Джефф!
🫡
#respect
Из Google после 27 лет работы ушёл Джефф Дин - вместе с несколькими коллегами идёт строить Discovery Loop - стартап про ускорение научных исследований с помощью ИИ.
Для меня Джефф - это инженер-легенда и один из тех редких профи, на которых всегда хотелось быть похожим.
И не из-за должностей и регалий, а потому, что за ним стоят такие проекты, как Google Search, MapReduce, Bigtable, Protocol Buffers, LevelDB, Spanner, Google Brain, TensorFlow, TPU, Gemini.
Причём он там не только руководил - он участвовал и в их проектировании, и в создании. Писал код. Своими руками!
Если вы в индустрии недавно, его имя может вам ни о чём не говорить, но его наследием вы пользуетесь каждый день.
Чел настолько крут, что внутри Google давно родился целый жанр - Jeff Dean Facts, аналог фактов про Чака Норриса.
Пользуясь случаем - отобрал самые интересные:
(факты с ✓ - правда 🤯)
PIN-код Джеффа Дина - последние 4 цифры числа пи
✓ Когда Джефф Дин проводит семинар в Стэнфорде, слушателей набивается столько, что Дональду Кнуту приходится сидеть на полу
Однажды в начале 2002-го, когда упали индекс-серверы, Джефф Дин два часа отвечал на поисковые запросы вручную. Эвалы показали рост качества на 5 пунктов
✓ Джеффа Дина повысили до 11-го уровня в системе грейдов, где максимальный - 10-й
Джефф Дин компилирует и запускает код перед коммитом - но только чтобы проверить компилятор и процессор на баги
Недовольный константным временем, Джефф Дин создал первый в мире алгоритм O(1/n)
✓ Когда Джефф Дин уходит в отпуск, продакшн-сервисы по всему Google начинают загадочно падать через пару дней
Джефф Дин однажды сдвинул бит так сильно, что тот оказался на другом компьютере
На собеседовании в Google Джеффа спросили, что следовало бы из равенства P=NP. Он ответил: "P = 0 или N = 1". Затем, пока собеседующий ещё не перестал смеяться, Джефф присмотрелся к публичному сертификату Google и выписал приватный ключ на доску
Вы используете свой мозг на 10%. Остальные 90% заняты одной из мап-редьюс джоб Джеффа Дина
В резюме Джеффа Дина перечислено то, чего он не делал - так короче
Для Джеффа Дина "NP" означает "No Problemo"
Джефф Дин однажды написал алгоритм O(n^2). Это нужно было для решения задачи коммивояжёра
Джеффу Дину пришлось изобрести асинхронные API однажды, когда после его оптимизации функция вернула значение прежде, чем её вызвали
Скорость программирования Джеффа Дина выросла в 40 раз в конце 2000 года, когда он проапгрейдил клавиатуру на USB 2.0
Когда Джефф Дин разрабатывает программу, то сначала создаёт бинарник, а потом пишет исходный код как документацию
Компиляторы не выдают варнинги Джеффу Дину. Джефф Дин выдаёт варнинги компиляторам
IDE Джеффа Дина не делает анализ его кода - она делает ему комплименты
Джефф Дин не пользуется ECC-памятью: он предвидит попадания космических лучей и использует их для оптимизации
Джефф Дин однажды не прошёл тест Тьюринга, потому что правильно вычислил 203-е число Фибоначчи менее чем за секунду
Джефф Дин однажды поднял веб-сервер одним вызовом printf(). Другие инженеры добавили тысячи строк комментариев с пояснениями, но так и не поняли, как он работает. Сегодня эта программа известна как Google Web Server
Это Джефф Дин откусил кусок от логотипа Apple
Чак Норрис может вас убить. Джефф Дин может сделать вам kill -9
Джефф Дин умеет парсить HTML регулярками... правильно
Когда Джефф не может заснуть, он мап-редьюсит овечек
Когда в вашем коде undefined behavior - вы получаете сегфолт и битые данные. Когда undefined behavior в коде Джеффа Дина - прискакивает единорог на радуге и раздаёт всем бесплатное мороженое
Джефф Дин умеет инстанцировать абстрактные классы
gcc -O4 отправляет ваш код Джеффу Дину на полную переработку
Джефф Дин всё ещё ждёт, когда математики найдут шутку, которую он спрятал в разрядах числа пи
Джефф Дин родился 31 декабря 1969 года в 23:48. Ему потребовалось 12 минут, чтобы запустить свой первый счётчик времени
Когда Джефф Дин говорит "Hello, World", мир отвечает: "Hello, Jeff"
Джефф Дин умеет получать единицы из /dev/zero
Google однажды пришлось съехать из дата-центра: Джефф Дин случайно сжал поисковый индекс так плотно, что образовалась чёрная дыра
Скорость света в вакууме была 55 км/ч. Затем Джефф Дин потратил уикенд на оптимизацию физики
Джефф Дин изобрёл MapReduce, чтобы сортировать письма фанатов
Процесс, убитый сигналом SIGJEFF, больше никогда не запускается
На клавиатуре Джеффа Дина две клавиши: 1 и 0
Часы Джеффа Дина показывают секунды с 1 января 1970 года. Он никогда не опаздывает
Код Джеффа Дина такой быстрый, что ассемблеру нужно три опкода HALT, чтобы его остановить
Джеффу Дину приходится деоптимизировать свой код, чтобы ревьюеры поверили, что его писал человек
Веб-поиск - это просто большой юнит-тест, который Джефф написал для своего настоящего приложения
Джеффу Дину не нужны колонки и наушники. Он делает cat *.mp3, бросает взгляд на экран - и мозг декодирует музыку в фоне, пока он работает
✓ Джефф Дин официально сертифицирован как человек, умеющий читать Perl
Джефф Дин сортирует бельё квиксортом
Кнут прислал в Google экземпляр "Искусства программирования". Джефф Дин подписал его и отправил обратно
Когда Ричард Столлман узнал, что автобиография Дина выйдет эксклюзивно на платформе Amazon, он купил Kindle
Джефф Дин умеет сжимать случайные данные без потерь
Когда Джеффа Дина спросили, правдивы ли факты о нём, он ответил: "111111". Пока интервьюер соображал, что он имеет в виду, Джефф пояснил: "каждый бит в них - чистая правда"
Штош, удачи, Джефф!
#respect
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥44😁29👍10❤🔥8🫡2
Forwarded from Константин Доронин
Как писать код с AI-агентами?
А если командой?
Что нужно учесть, чтобы этот код не положил продакшн?
Эти и другие не менее интересные вопросы мы обсудим на следующем стриме на моём YouTube-канале.
Для обсуждения я позвал очень интересных гостей:
Андрей Бреслав – один из создателей языка программирования Kotlin. Сейчас Андрей разрабатывает Agentic Engineering Toolkit под названием CodeSpeak.
Валера Ковальский – автор одноимённого канала. Основатель проекта Neuraldeep https://neuraldeep.ru/ и автор множества Open Source проектов, созданных примерно за 120 минут каждый.
Максим Ключников – автор канала Этихлид. Разработчик с огромным опытом, который усилил себя с помощью AI-агентов. Работал на позиции Senior Software Developer, когда я ещё в школу ходил 😊
Дата: четверг, 20 августа
Время: 19:00 (GMT+3)
Проходить будет на моём YouTube-канале.
Добавить событие в календарь
Вопросы для эфира оставляйте в комментариях к этому посту 👇
А если командой?
Что нужно учесть, чтобы этот код не положил продакшн?
Эти и другие не менее интересные вопросы мы обсудим на следующем стриме на моём YouTube-канале.
Для обсуждения я позвал очень интересных гостей:
Андрей Бреслав – один из создателей языка программирования Kotlin. Сейчас Андрей разрабатывает Agentic Engineering Toolkit под названием CodeSpeak.
Валера Ковальский – автор одноимённого канала. Основатель проекта Neuraldeep https://neuraldeep.ru/ и автор множества Open Source проектов, созданных примерно за 120 минут каждый.
Максим Ключников – автор канала Этихлид. Разработчик с огромным опытом, который усилил себя с помощью AI-агентов. Работал на позиции Senior Software Developer, когда я ещё в школу ходил 😊
Дата: четверг, 20 августа
Время: 19:00 (GMT+3)
Проходить будет на моём YouTube-канале.
Добавить событие в календарь
Вопросы для эфира оставляйте в комментариях к этому посту 👇
🔥23❤12👍4🎉2🥱2
Forwarded from Константин Доронин
Мы начинаем наш стрим "Как писать код с AI-агентами?"
Подключайтесь по ссылке: https://youtube.com/live/x0j1kcagoXg
Подключайтесь по ссылке: https://youtube.com/live/x0j1kcagoXg
YouTube
Как писать код с AI-агентами?
Страница донатов: https://www.donationalerts.com/r/kdoronin
Подписывайтесь на TG-каналы участников эфира:
Валерий Ковальский – https://t.iss.one/neuraldeep
Максим Ключников – https://t.iss.one/etechlead
Константин Доронин – https://t.iss.one/kdoronin_blog
Подписывайтесь на TG-каналы участников эфира:
Валерий Ковальский – https://t.iss.one/neuraldeep
Максим Ключников – https://t.iss.one/etechlead
Константин Доронин – https://t.iss.one/kdoronin_blog
🔥9❤6👍4🎉2🥱2