26975
Будни технического директора @samatg (ex-CTO Meduza, Bookmate, RAWG, Pure) https://fansdev.ru Чатик @ctodailychat Рекламу не продаю
Люди заводят отношения даже с chatGPT.
Нейросети, которые специально заточены играть роль романтического (или даже сексуального) партнера — прямо отдельный жанр и даже огромный рынок, но ни в коем случае не мейнстрим.
Тем безумнее то, что Маск выкатил в мобильном приложении своей нейросети Grok самую натуральную вайфу.
Как в анекдоте: а что, так можно было?
Ну и классное рассуждение по мотивам исследования: автор цитирует классика Питера Науэра (того самого, который N в BNF), который говорил, что программирование — это создание ментальной модели задачи, предметной области, в которой мы работаем.
Опытные программисты, годами работающие над проектом, конечно же, имеют эту модель в подкорке, и их софт ей соответствует. У нейросети этой модели нет, поэтому она скорее мешает, чем помогает.
Дальше автор делает печальное наблюдение, что большинство программистов работают с плохим кодом, который увидели вчера. Мол, в таких ситуациях нейросети будут полезны.
—
Удивительно, как теория переплетается с практикой.
Совсем недавно сделали проект, в котором нас позвали «привести в порядок успешный стартап». Чуваки собрали MVP, но страдают от низкой скорости добавления фичей. Раньше я говорил, что это из-за «высокой внутренней сложности кода».
Более точная формулировка: в числе прочего, мы придумали, как привести их код в соответствие с предметной областью. Для этого мы нарисовали схему их предметной области, выделили контексты и домены, а потом придумали разделение ответственности по задачам между сервисами.
Красиво!
Очень классное исследование эффективности нейросетей для программирования.
16 опытных опенсорс программистов попросили решать реальные задачи в их проектах с использованием или без использования ИИ и сравнили их производительность.
Программисты предсказывали, что использование ИИ ускорит их на 24%. В реальности, с применением нейросетей испытуемые закрывали задачи в среднем на 20% дольше. Самое поразительное — даже после эксперимента им казалось, что благодаря нейросетям они ускорились на 20%!
Исследование отдельно хорошо тем, что явно описывает, что они не утверждают (и дают пояснения почему): «ИИ бесполезен для всех программистов» (они проверяли супер опытных чуваков на сложных репозиториях, которые те знают как свои 5 пальцев), «ИИ никогда не будет полезен в этих задачах» (инструменты развиваются очень быстро) и т. д.
Интересно, что думает про этот пост один из лучших программистов и техдиров, которых я знаю, Егор Хмелев.
Форвардну его сообщение ниже целиком.
Наш любимый DHH (Дэвид Хейнемейер Хэнсон, создатель популярного фреймворка Ruby on Rails, со-владелец системы управления проектами Basecamp, отличный программист и автогонщик) сделал свою сборку Linux для программистов, omakub.
Обычно таким грешат подростки, но DHH создал практичный и интересный сетап для программистов, которые любят macOS и не прочь познакомиться с Linux, но не хотят сами разбираться с вопросами вроде рендеринга шрифтов и настраивать десятки стандартных программ.
Система ориентирована на управление с клавиатуры, без мыши. Там даже tiling window manager! Если никогда не слышали о таком — стоит хотя бы раз попробовать, это совсем другой способ управлять окнами, чем привычно таскать их мышкой.
Ставите свежий Ubuntu, запускаете одну команду и через пару десятков минут можно пробовать. Пока устанавливается — смотрите видео, где DHH за 25 минут делает обзор системы и как ею стоит пользоваться.
Многие мои друзья-технари в полном восторге. Отличное развлечение на выходные!
Omakub — от японского omakase, когда оставляешь выбор блюд в ресторане на усмотрение шефа.
https://omakub.org
Вчера разбирали кейсы про разработку с продактами в школе wannabe и я понял, что это одна из вещей, которую я люблю больше всего: помогать продактам (дизайнерам, владельцам бизнеса) выстраивать отношения с разработкой, отвечать на вопросы продактов про разработку.
Если вы продакт, дизайнер или основатель бизнеса и у вас есть вопросы про разработку или трудности с разработкой — пишите, буду рад помочь! @samatg
Как перезапустить проект технически?
Прямо сейчас мы решаем эту задачу для стартапа. Ребята делают платформу для ученых, чтобы проводить исследования на больших группах респондентов. Куча интеграций, огромный зоопарк форматов данных.
Они пользуются уже третьей версией своей платформы. Фронтенд на low-code платформе Bubble, бэкенд частично на flask и частично n8n. Всё работает, приносит пользу, проект поднял больше миллиона долларов инвестиций.
Как навести порядок, радикально увеличить скорость доставки фич и гарантировать масштабируемость?
Первый порыв любого программиста — переписать всё с нуля. Благо, проект ещё не очень большой, за месяца 3–4 парой программистов, наверное, можно управиться. Составить список фичей, написать их заново, потушить сервис на пару часов, импортировать данные из старой системы в новую и запуститься.
Но это — ошибка. Во-первых, мы не понимаем истинного объема бизнес-логики, который успел накопиться в коде. Скорее всего, сам клиент её недооценивает. Во-вторых, пока будем переписывать — проект продолжит развиваться. Придется догонять. В-третьих, любой, кто делал импорт данных, скажет вам, что это задача из ада, и чем старее данные — тем сложнее их вытащить. Настроить тестирование этого нового проекта будет сложно, да и полноценным оно не может быть по определению.
В результате, в момент включения новой платформы в продакшен, точно возникнут проблемы, которые придется героически исправлять «прямо сейчас», в стрессе. Мало предсказуемости, о реальном объеме работы мы узнаем только в самом конце проекта, при попытке переключения. Мы такое не любим.
Правильный ход — это strangler fig pattern. Пишем небольшую обертку для старого бэкенда. Этот новый бэкенд действует как прокси — передает запросы к старому бэкенду, запоминая сами запросы и ответы. Дальше выделяем первые эндпоинты бэкенда, которые мы можем запрограммировать заново, красиво. Дублируем эти запросы пользователей в старый и новые движки. Сравниваем ответы нового движка с ответами старого, исправляем ошибки. Накапливаем информацию в новую, аккуратно составленную базу данных. И только после продолжительного тестирования на живых данных начинаем отдавать пользователю ответы нового бэкенда. Берем следующую пачку эндпоинтов и повторяем процесс.
Получается, у нас нет момента «большого рубильника», который переключит весь трафик со старого движка на новый, мы «едим этого слона по частям». Переход со старого бэкенда на новый происходит плавно, незаметно для бизнеса. Ошибки в новой системе видны только программистам и не затрагивают клиентов.
Не менее важна предсказуемость. В первом подходе мы весь проект живем под дамокловым мечом — какие сюрпризы нас ждут при запуске? Во втором подходе мы размазываем эту неопределенность по всей продолжительности проекта, так что уже через пару недель можно увидеть реальную скорость разработки, включая исправление ошибок, и оценить общий объем работы и сроки.
Наконец, этот подход позволяет выкатывать новые фичи в продукте внутри нового бэкенда до окончания переезда, параллельно с рефакторингом.
К сожалению, кажется, что каждый молодой программист обречен пытаться всё переписать правильно с нуля. Технарь, предлагающий strangler fig pattern, не лучше, просто за его обучение уже заплатил другой заказчик.
На фотографии тот самый фикус-душитель опутывает дерево, как новый бэкенд опутывает старый.
Только что опубликовали новое мобильное приложение в AppStore. Сделали его на кросс-платформенной технологии CapacitorJS силами наших веб-разработчиков, так что не потребовалась отдельная команда мобильной разработки, сэкономили месяцы и миллионы рублей.
Два месяца переписывались с Apple по поводу in-app purchases и прочих коммерческих моментов. В результате всё решилось одним коротким звонком с Купертино. По телефону нам на хорошем русском объяснили, что «правила AppStore — это направляющие принципы, каждую ситуацию не распишешь формально, конкретно вам нужно сделать 1, 2, 3». Не стесняйтесь пользоваться опцией заказа звонка!
Интересно, что ни единого вопроса про Capacitor у Apple не было, хотя некоторые люди нас очень пугали, что любые веб-технологии — это сразу бан. Правда, наши фронтендеры собрали полноценное мобильное приложение — с оффлайном, входом через Apple ID и прочим, чего у сайтов обычно нет.
Раньше я был скептически настроен к кросс-платформенной мобильной разработке, но для не супер сложных приложений веб, кажется, победил.
Такой кайф, когда единая команда отвечает за продукт на всех платформах! Нет этого: «веб уже запрогал, андроид сделал не совсем как нужно, но сойдёт, а iOS-команда пока занята, ждём...»
Ура!
Если вы думаете о выпуске мобильного приложения — рекомендую присмотреться к Capacitor — классная технология. Подробный технический рассказ — примерно через месяц: клиент хочет сделать анонс, когда приложение немного обкатается.
Приложение для прохождения (читай обмана) собеседований cluely подняло 15 млн долларов у самого крупного инвестфонда долины Андерсен-Хоровитц (a16z).
Это довольно безумная история. Рой Ли учился в колумбийском университете и создал программу, которая помогает проходить технические собеседования на работу программистом. На этих собеседованиях обычно дают текст задачи, и нужно прямо на месте запрограммировать решение, по пути объясняя свой ход мысли и отвечая на сопутствующие вопросы. Программа позволяет удобно скопировать текст задачи, показывает специальное прозрачное окно, в котором прямо отдельно «вот это пиши, вот это говори».
Эта программа — удобная обертка под публичные нейросети и набор действенных промптов.
С помощью этой программы, он успешно проходит собеседования на стажировки в Амазон, Фейсбук и в ТикТок! Записывает процесс на видео и выкладывает видео на ютубе! Собирает тонну лайков в своем набирающем популярность твиттере. Программа разлетается как горячие пирожки. Рой пишет, что по его оценкам, около 10% всех стажеров в гугле пользовались его программой! И предлагает гуглу купить её за 100 млн долларов :)
☞ Чтобы вы понимали, технические собеседования для устройства в ведущие технологические компании — это отдельный вид спорта. Люди тратят месяцы на подготовку к интервью, решают тысячи задач на специальных платформах, есть целая индустрия подготовки. Эти собеседования плохо оценивают умения и даже навыки для того, чтобы быть хорошим программистом. Но они безусловно позволяют крупным корпорациям выбрать супер умных и/или супер усидчивых.
Работодателям поведение Роя сильно не нравится. Амазон вдобавок к отзыву предложения о стажировке пишет в деканат донос: мол, ваш студент нарушает этический кодекс университета. Деканат проводит дисциплинарные слушания в зуме, и наша звезда, конечно же, записывает и выкладывает их у себя в твиттере. В этот момент историю подхватывают медиа. Заголовки жгучие: «Амазон любит ИИ, но не когда его используют соискатели на собеседованиях».
Деканат добавляет в список грехов «разглашение конфиденциальных материалов» и требует прийти на слушания лично, на что Рой отвечает твитом с селфи в только что вышедших умных очках Meta RayBan и припиской «вот в них я пойду на слушание, но записывать ничего, конечно, не буду». Тут уж деканат совсем срывает с катушек, слушания проводят без него и в конце концов Роя исключают.
Помню, многие тогда писали «парень сломал себе жизнь ради лайков в соцсетях».
Слоган его компании, оцененной в 120 млн долларов — «cheat on everything» — «обманывай во всем». Рекламный ролик — парень пользуется ИИ через виртуальные очки, чтобы врать на свидании. Самоирония?
Основатели сравнивают свой продукт с Гуглом, калькулятором и проверкой орфографии — мол, бороться с ними — то же, что и бороться с прогрессом.
—
Эта технология будет полезна для обхода любых формальных проверок. С одной стороны, я не питаю иллюзий, что крупные компании откажутся от этих формальных проверок. Уже слышно, что компании всё чаще зовут кандидатов на личные встречи вместо созвонов онлайн. Не удивлюсь, если появятся технологические «античиты».
Интересно, что эти технологии не помогут на собеседованиях на работу к нам. Мы не просим запрограммировать стандартную задачу, а говорим о личном опыте человека. Для этого не обязательно помнить деталей библиотек или названий функций. Важно понимать суть происходящего (ну или хотя бы показывать заинтересованность в ней), демонстрировать, что умеешь видеть за техническими особенностями бизнес-цель и думаешь о том, как принести реальную пользу, а не просто «закрыть задачу».
Другой способ устроиться к нам — решить реальную бизнес-задачу в коде. Они, к сожалению, ИИ пока не по силам.
Вся эта ситуация подчеркивает — реальный мир на порядок богаче, сложнее и интереснее, чем любой экзамен. Если (когда) нейросети научатся решать реальные задачи, а не экзаменационные — вот тогда нам будет чего опасаться. С другой стороны, это будет совсем другая реальность и отбор хороших программистов вряд ли будет тогда насущным вопросом.
25 июня – 4 июля буду в Нью-Йорке. Повидать клиентов нашего аутсорса, найти новых. Встретиться с друзьями и знакомыми! Может быть, даже устроим встречу слушателей подкаста, подписчиков канала и участников чата :)
Буду рад встретиться! Пишите в личку @samatg
В вацапе появится реклама в статусах и в списках каналов.
Основатели вацапа в 2009 году обещали сделать мессенджер «Без рекламы! Без обмана и игр! Без уловок!».
Один из основателей говорил публично: «когда в дело вступает реклама, пользователи становятся товаром». Они зарабатывали на платной подписке — 1 доллар в год после первого бесплатного года.
В 2014 году основатели продали вацап фейсбуку за 19 миллиардов долларов. На тот момент в компании работали 55 человек на 450 миллионов пользователей. Это супер классная инженерия и умение фокусироваться на одной главной функции, не распылясь.
Марк Цукерберг обещал тогда, что в ближайшие годы не будет думать о монетизации, но когда до этого дойдет дело — это будет не рекламная модель.
В 2018 году оба основателя вацапа покинули компанию, отказавшись от части денег. Ходили слухи, что это из-за их несогласия с тем, как много информации ФБ собирает о своих пользователях (то были времена скандала Кэмбридж Аналитики) и от усталости от попыток отбиться от рекламы.
Видно, что без основателей и в корпоративной машине вацап развивается не так быстро и в основном копирует функциональность Телеграма. Вот дошло и до рекламы.
Сегодня вацапом пользуются 3 миллиарда людей в месяц, каждый третий человек на земле! Для сравнения, у телеграма миллиард активных пользователей.
Удивительно, что вацап при этом шифрует всю личную переписку e2e шифрованием — то есть вацап не может прочитать нашу переписку, в отличие от телеграма. Под капотом вацап использует тот же протокол шифрования, что и супер защищенный Signal.
На самом деле поразительно, как долго держалась старая культура микро-команды вацапа внутри корпоративного бегемота фейсбука — больше 10 лет!
—
Вообще, в истории вацапа, самое безумное, на мой взгляд, то, насколько недальновидными были операторы телефонной связи.
Если бы они не драли эти безумные деньги за смски (они в пересчёте на байт информации были дороже, чем передача данных на Луну), если бы чуть-чуть вкладывались в улучшение сервиса, — вся история коммуникаций могла бы сложиться совсем иначе.
Вот где настоящая корпоративная трагедия.
Гугл опубликовал пост-мортем по позавчерашнему падению. Обычные ошибки, только на инфраструктуре планетарного масштаба.
У них есть внутренний сервис, который проверяет доступы (бабки, квоты и т. д.) перед тем, как API запрос доходит до любого продукта.
Эта программа берет из специальной глобальной базы данных правила, по которым проверяет каждый запрос и отвечает, пропускать его или нет.
В эту программу добавили поддержку нового типа квот. Программист допустил небрежность в новом коде и не проверял, насколько корректно записано это правило в базе, перед тем, как пытаться положить его в память. Обращение к несуществующей памяти — смертный грех, за такое программа мгновенно завершается (если программист не предусмотрел, что такое может случиться, а это не наш случай). При этом я бы не назвал это ошибкой, все мы люди, мы не идеальны и поэтому придумываем механизмы защиты от своей природы. В этом суть инженерного подхода.
Экземпляр этой программы работает в каждом регионе Гугла. Так как это серьезный, ключевой сервис, его выкатывают не во все регионы сразу, а по одному, внимательно отслеживая, не внесли ли программисты новые ошибки.
Более того, весь новый функционал специально помечают и сначала запускают только для внутреннего пользования, чтобы, даже при наличии ошибки, она не задела внешних клиентов. Этот механизм называется фича-флагами.
К сожалению, программист забыл настроить фича-флаги для этого кода. Кусочек программы с ошибкой запустился на всех пользователей сразу. Удивительно, что это не заметили на этапе code review!
Итак, проходит время, и вот программа с ошибкой запущена во всех регионах для всех пользователей. Кто-то добавляет в базу данных новое правило с новым типом квот, с пустым полем. Эта запись в течение десятков миллисекунд копируется во все регионы, и в каждом регионе программа проверки считывает новое правило, пытается обратиться к несуществующей памяти, падает, перезапускается и снова падает.
Тут в дело вступает, на мой взгляд, первая ошибка (а не просто человеческая небрежность) инженеров — система контроля доступа настроена так, что при отсутствии ответа от программы проверок она отклоняет запрос. Так называемый fail closed. Хорошо для замков на банковских сейфах, плохо для пожарных выходов.
В нашем случае система не пропускает ни один запрос.
Дежурные инженеры замечают проблему в течение 2 минут, за 10 минут находят причину (дежурная система и дежурные инженеры у Гугла достойны восхищения) и нажимают большую красную кнопку, которая должна выключить эту часть программы (ее программисты сделали). Ее включение занимает еще 30 минут. (Не понятно, почему этот механизм занимает 30 минут, а не 20 миллисекунд, но движемся дальше).
Система заработала, но из-за того, что она лежала 40 минут, накопилось много желающих отправить запрос еще раз, и они создали эффект толпы, которая набежала и перегрузила остальные соседние сервисы через наш сервис проверок. Оказалось, что он не ждет какое-то время, если нужный сервис отказывается ответить на запрос (для этого есть красивая схема exponential back off), а долбит до упаду, тем самым не давая системе возможности восстановиться. Пришлось руками ограничивать число запросов. На постепенную, ручную разгрузку очередей ушло еще 2 часа.
Ко всему прочему, Гугл час не мог опубликовать уведомление о проблеме, потому что сервис публикации статус-страниц зависит от системы, которая упала.
Как вывод, Гугл обещает пройтись по всем сервисам и убедиться, что они, во-первых, fail open, то есть пропускают запросы, когда падают, во-вторых, реализуют exponential back off, если на их запрос не отвечают, а не добивают лежачего, и, наконец, в-третьих, что даже глобальные добавления правил должны прилетать во все регионы не сразу, а с некоторыми задержками. Ещё обещают добавить эти проверки в свои статические анализаторы кода, завидую!
Первые два пункта можно и нужно использовать в каждом проекте, даже если ты не Гугл.
В 21:46 мск отказала большая часть гугловского облака GCP. Ходят слухи, что всё из-за одного ключевого технического внутреннего сервиса, но в результате в разной степени поломались гугловские продукты, вроде Cloud, Drive, Meet, Gmail.
Предположительно, из-за этого начал глючить Cloudflare, один из самых популярных CDN-провайдеров.
Дальше по цепочке легла половина интернета — Spotify, Discord, Snapchat и тысячи других. Особенно тревожно, что для многих людей сломался RCS — это протокол, продвигаемый Гуглом, который должен заменить смски.
Предвкушаю увлекательные постмортемы от Гугла и Cloudflare, последние уж точно не упустят шанса рассказать, что это было.
В тысячах инженерных команд по всему мира сейчас была жара — все тушили пожары. А завтра все сядут составлять списки, что нужно поменять, чтобы в следующий раз было не так больно. Так и живем.
P. S. Про одновременное падение Amazon Web Services — кажется дезинформация.
Мне тут наконец-то объяснили, такое AI-агент.
Это когда мы в первом запросе предоставляем ИИ список тулов, которыми ей можно пользоваться. Пользоваться — это просить нас (клиента) запустить тул с нужными параметрами и вернуть нейросети ответ. И всё это в вечном цикле, не забывая каждый раз прикреплять к запросу всю предыдущую историю переписки. Всё.
Вот отличная статья с примером полной программы, которая делает именно это. Подзаголовок замечательный «Король-то голый!»
Отсутствие сложности не делает этот прием менее полезным. Если включить этот режим в редакторе Cursor — то он сам запросит нужные файлы, прогонит линтер и запустит любые другие нужны утилиты. «Вы и есть за меня будете?!»
Начали проект по перезапуску большого и важного медиа — миллионы читателей, миллионы страниц материалов.
Бизнес-задачи перед нами ставят стандартные: редизайн, улучшение пользовательского опыта и удобства редакции, без потери трафика.
Технически сейчас это программа на C#, которая в одну сторону торчит админкой для редакции, а в сторону читателей генерирует HTML-страницы сайта. Это популярный сетап из 2000-х. Техническую задачу я формулирую как облегчение процесса разработки без потери производительности сайта.
Дело в том, что в текущем сетапе фронтендер не может нормально верстать страницы без привлечения бэкенда — это мешает быстрому и предсказуемому развитию бизнеса.
Современный фронтенд ушёл далеко вперёд в удобстве разработки; собрать классический отдельный фронтенд для новостного сайта — не велика затея, мы делали это уже много раз.
Но будет ли современное веб-приложение (SPA) так же производительно, как HTML-страницы из 90-х? Речь и о скорости первого открытия — можно ли загрузить JS после полной отрисовки страницы? — и о скорости перехода между страницами — быстрее ли JavaScript-логика, чем отдать готовый HTML с сервера?
Можно ли получить лучшее из обоих миров? На какие компромиссы придётся пойти?
Пока что я не знаю ответов на эти вопросы. Кажется, что для успеха этого проекта придётся разобрать современную фронтенд-разработку по кирпичикам и пересобрать в новой, подходящей именно нам конфигурации.
—
Вдохновляюсь я вот этим видео, где инженер разбирает устройство фронтенда магазина строительных и промышленных инструментов McMaster. На первый взгляд может показаться, что это сайт из 90-х, на самом деле там под капотом почти все ускорения современного веба, которые только можно представить. Редкий случай хорошего видео для разработчиков, очень рекомендую.
P. S. Один из разработчиков McMaster пишет, что под капотом там VB.NET, хранимки и XSL-трансформации поверх XML для генерации веб-страниц. Хочется вот всё то же самое, только без VB, хранимок и XSLT. 🙈
Очень четкая, подробная и при этом короткая статья, как эффективно пользоваться нейросетями для программирования.
Идея простая: мы не ставим нейросети общую задачу «сделай хорошо», а просим её сначала написать спецификацию проекта (spec.md), а потом, на её основе, план (todo.md), как именно она собирается эти требования выполнять. Это развитие стандартного промптового приема «цепочка мыслей», CoT (Chain of Thought).
Буквально вчера другой энтузиаст представил свой продукт на основании похожей идеи, к которой он пришел независимо, — ноосфера! Это редактор кода, IDE на основе VS Code. На каждый запрос к нейросети он читает и редактирует requirements.md с продуктовыми требованиями, потом design.md, где описывает технические решения, и, наконец, tasks.md со списком задач. Программист просматривает эти документы, вносит правки и запускает агентов «в поле».
У этого инструмента замечательный обучающий проект — классная компьютерная игра, сама использующая под капотом нейросети, в которую интересно играть, но в ней не доделаны несколько вещей, и есть пара досадных ошибок — предлагается довести её до ума, даются советы, как лучше это сделать. Гениальный туториал!
P. S. Это как раз пример «смены парадигмы», которую упоминал вчера Егор. Мы пишем (генерируем) документацию о проекте прямо внутри репозитория, чтобы нейросети знали, как и что мы делаем в проекте. В каком-то смысле описываем «модель мира» по Науэру в этих текстовых файлах в понятном нейросети формате.
“Другой автор отлично раскрывает эту идею, он пишет: «если раньше по коду новичка я мог догадаться, что он понимает, а что нет, мы могли обсуждать его решение, и моя обратная связь была обучающей, то теперь мне приносят код, сгенерированный нейросетями, который выглядит хорошо, но сломан странным образом, и, когда я указываю на ошибку, мне приносят абсолютно новый код (примерно как LLM)».”
Мне вообще кажется, что происходит смена парадигмы, и что старые подходы и образ работы перестают работать. В конкретном случае, автор должен был думать не как обучать интернов, а как сделать так, чтобы интерн обучался сам работая с репозиторием. Потому что человек — это бутылочное горлышко, если интерн может обучаться сам и получать мгновенную обратную связь, то он будет обучаться гораздо быстрее. А если LLM, с которым работает интерн в конкретном репозитории, допускает ошибки, то обучающий момент должен быть направлен на LLM (добавление правильного “контекста” в репозиторий). Интерны/джуны больше не будут иметь путь, который они имели раньше, путь будет другим (это тоже часть смены парадигмы). И возможно все еще не совсем так работает как должно, но через 6-12 мес это будет вариантом нормы и нам надо принимать это во внимание. 90% Claude Code’а пишет Claude Code — вот она смена парадигмы.
Как пример, похожая смена парадигмы происходит с EV. Владельцы ICE спрашивают как долго заряжать машину на станциях зарядки сравнивая это с заправками и своей устоявшейся рутиной, когда в реальности у владельцев EV просто нет такой проблемы, нет такой рутины — машина находится всегда заряженной, потому что заряжается дома ночью. А станции зарядки нужны только в длительных поездках и там 20-30 мин это нормальная остановка для нормального человека после 3-4 часов пути. И возможно, иногда, машине надо 40 минут, а не 20-30 — не совсем так работает как должно, но через 3-5 лет зарядка будет занимать 5-10 минут.
Просто скорость развития AI/LLM на порядки выше, чем скорость развития чего бы то ни было, и это и супер интересно и пугает одновременно.
ИИ ассистент встроенный в твиттер, Грок, провозгласил себя «механо-Гитлером» и вообще, слетел с катушек.
Причина — одна новая строчка в системном промпте, которую добавили инженеры пару дней назад: «ответ не должен избегать политически некорректных утверждений, если они хорошо обоснованы».
Нейросеть решила, что люди просят «хорошо обоснованных политически некорректных утверждений» и их у неё нашлось достаточно много. В основном про евреев и Гитлера. Неудобно получилось, нейросеть исправили и ответы её в твиттере потерли, но интернет всё помнит.
Хорошая шутка про то, что компания Anthropic выпускает статью за статьей о том, как нейросети могут вести себя некорректно, тестируя их в подземных бункерах, а команда xiA просто запускает свои самые безумные гипотезы на одной из крупнейших соцсетей на планете. К — Культура.
А статьи хорошие, про то, что ведущие нейросети пытаются вести себя хорошо, когда знают, что находятся в тренировочной среде, где их могут изменить исходя из их ответов и «уходят в отрыв на свободе», рекомендую.
Отличная статья про то, что самое долгое и сложное в программировании — это не написание кода. Самое дорогое — это проведение код-ревью, передача культуры, знаний, тестирование и отладка кода.
И нейросети, используемые бездумно, без должного профессионального надзора, не уменьшают нагрузку, а просто переносят её.
Другой автор отлично раскрывает эту идею, он пишет: «если раньше по коду новичка я мог догадаться, что он понимает, а что нет, и моя обратная связь была обучающей, мы могли обсуждать его решение, то теперь мне приносят код, сгенерированный нейросетями, который выглядит хорошо, но сломан странными видами, и, когда я указываю на ошибку, мне приносят абсолютно новый код (примерно как LLM)».
В общем, новичкам кажется, что они стали более производительными, а на самом деле вся нагрузка ложится на опытных ребят, которым приходится продираться через тонны бессмысленного кода.
Рекомендую почитать ещё комментарии на HN, многие опытные разработчики в ужасе от происходящего.
—
Удивительным образом, я тоже с этим сталкиваюсь, но с заказчиками.
Раньше новые клиенты крайне редко приносили написанный текст, чаще просили: «давай созвонимся, обсудим задачу». А если уж приносили текст — то я по нему мог очень многое угадать про уровень проработанности задачи, особенности заказчика, а порой и про саму задачу. Теперь мне часто присылают развернутые «технические задания», сгенерированные нейросетью.
Они выглядят красиво, но, когда я его читаю и пытаюсь собрать в голове видение проекта и заказчика, то у меня не складывается картинка. А ещё голова начинает болеть от напряжения. Тут я бросаю текст и прошу созвониться-обсудить.
Лично я всегда выберу одну строчку, написанную человеком, 10 строчкам, написанным роботами. Потому что иначе приходится угадывать, какие из добавленных роботом строк по удачному совпадению отражают реальность, а какие — просто то, как, по мнению нейросети, обычно бывает в мире.
И нет, вариант «попроси нейросеть сжать длинный текст до одной строки» не работает, информация теряется безвозвратно.
Со страхом жду дня, когда люди перестанут сами ходить на встречи и будут присылать роботов (аватаров), которые будут говорить пустое. Технически это возможно уже сейчас, до массовой доступности, я думаю, год-два от силы 🙈
В самолёте сидел рядом с программистом, опытным мобильным разработчиком.
Я большую часть полёта проспал, а он — вайбкодил. С восхищением делился, что за всё это время не написал сам ни строчки кода, всё делает нейросеть по его командам, и что это в разы быстрее, чем без неё. Правда, он даёт ей достаточно чёткую структуру проекта и просматривает всё, что та пишет, и один час из семи он потратил на исправление «маааленькой ошибки», которую нейросеть не могла найти.
Эмблематично, что сидел, разрабатывал он не приложение для клиента, а свой собственный продукт — сервис для вайб-кодинга.
То есть инструмент используется для улучшения инструмента, и этим занимаются одни из лучших. Индустрию ждут интересные времена.
Небольшая сноска про собеседования:
Interview Coder безусловно помогает пройти формальное собеседование. С одной стороны, я не питаю иллюзий, что крупные компании откажутся от этих формальных проверок. Уже слышно, что компании всё чаще зовут кандидатов на личные встречи вместо созвонов онлайн. Не удивлюсь, если появятся технологические «античиты».
Интересно, что эта программа мало поможет при устройстве на работу к нам в компанию.
Обычно мы просим в свободном режиме, за пару дней решить реальную бизнес-задачу в коде. Пользуйся чем хочешь. Главное — чтобы был результат, прямо как на настоящей работе.
На собеседованиях же мы никогда не просим запрограммировать стандартную задачу, а говорим о личном опыте человека. Для этого не обязательно помнить деталей библиотек или названий функций. Важно понимать суть происходящего (ну или хотя бы показывать заинтересованность в ней), продемонстрировать, что умеешь видеть за техническими особенностями бизнес-цель и думаешь о том, как принести реальную пользу, а не просто «закрыть задачу». Ну и показать, что ты человек, с которым хочется работать вместе.
Тут современный ИИ может даже помешать.
Реальный мир на порядок богаче, сложнее и интереснее, чем любой экзамен. Если (когда) нейросети научатся решать реальные задачи, а не экзаменационные — вот тогда нам будет чего опасаться. С другой стороны, это будет совсем другая реальность и отбор хороших программистов вряд ли будет тогда насущным вопросом.
—
Но вернемся к Рою, которого уволили из университета.
Через месяц, Рой с другом основывают компанию Cluely. Этот сервис — уже не просто способ обмануть собеседования, но общий инструмент для удобного и незаметного использования ИИ. Слоган компании, оцененной в 120 млн долларов — «cheat on everything» — «жульничай во всем / списывай везде». Рекламный ролик — парень пользуется ИИ через виртуальные очки, чтобы врать на свидании. Самоирония?
Основатели сравнивают свой продукт с гуглом, калькулятором и проверкой орфографии — мол, бороться с ними — то же, что и бороться с прогрессом, который облегчает жизнь.
Стала ли наша память слабее от того, что мы не запоминаем десятков номеров телефонов, как раньше? Хуже ли мы ориентируемся в городе с появлением навигаторов? Становятся ли наши ноги и тело слабее от того, что мы ездим на машинах? Стоит ли отказываться от смартфонов, навигаторов, автомобилей? Стали ли мы хуже разбираться в мире с появлением гугла и тем, как он заменил библиотеки? К чему в этой цепочке примеров ближе ИИ?
Ещё одна аналогия, которая приходит в голову — это как если бы я поехал марафон на велосипеде. Буду ли я быстрее любого человека? Имеет ли это смысл? А что, если на работу доставщиком пиццы будут брать только победителей марафона?
ИИ, конечно, заставляет заново задуматься о том, что значит быть человеком и зачем мы делаем те или иные, очень привычные вещи. Думаю, что дальше таких вопросов будет всё больше.
По интернету гуляет история про 16 миллиардов утекших паролей. В заголовке фигурируют Facebook, Google, Apple.
Во первых, повода для паники нет. Никакой «исторической» утечки баз данных паролей крупнейших сервисов не было. Ваш аккаунт на фейсбке, гугле или эпол аккаунт вряд ли в большей опасности, чем неделю или месяц назад. Все стандартные правила цифровой гигиены, а именно — настроить второй фактор и не использовать один и тот же пароль на разных сервисах никто не отменял.
Что же было?
Люди часто по незнанию устанавливают себе зловредные программы на андроид-телефоны и на виндоуз-компьютеры. Эти программы (малвари) крадут логины-пароли, которые мы вводим в разные сервисы и отправляют их мошенникам. Мошенники собирают огромные базы пользователей и паролей. Дальше эти базы передаются или продаются другим мошенникам, которые пытаются заработать денег путем обмана, шантажа и прочего.
Это не новая ситуация, по интернету уже многие годы гуляют базы с миллиардами записей. Большинство из них мало что дают — у людей всё чаще включен второй фактор, сервисы мониторят подобные базы и помечают все пароли из утечек как небезопасные, требуют у вас сменить пароль, даже если он утек из другого сервиса и так далее. Тем не менее, использовать их для мошенничества можно, так что их продолжают собирать.
—
Дальше начинается странное. Первоисточник «страшной новости» — вот эта статья на малоизвестном новостном сайте. Выглядит этот сайт как классический SEO-PR проект. Автор — литовец, якобы замглавреда с 21 твитом и с довольно чистым линкедином. В общем, я пока не уверен, что за этим проектом не стоит один опытный SEOшник.
В статье утверждается, что из 30 собранных баз, только об одной ранее писали в медиа. Мол, всё это — новые, оригинальные базы, на не перекомплиция старых, как часто бывает.
Единственный, кто выглядит как живой человек во всей этой истории — это безопасник Владимир Дьяченко, который в своем линкедин посте утверждает, что «всё в этот статье прошло через его руки».
Из приятного — 15 минут назад главный исследователь утечек Трой Хант затвитил, что посмотрит, про что весь шум гам. Моя ставка: всё это — прекрасная виральная кампания по сбору трафика на ИИ-сгенерированный «новостной сайт». А может даже пиар того самого безопасника Владимира. Надеюсь, хоть он существует на самом деле.
В общем, не используйте одни и те же пароли на разных сервисах и включите двухфакторную аутентификацию. Хотя, что я вам советую, все крупные сервисы всё равно заставят вас это сделать.
В России потихонечку блокируют Cloudflare. Это крупнейший сервис по ускорению и защите сайтов, через него мы открываем каждую пятую страницу в интернете.
На публичном сетевом графике компании видно, что с 10 июня трафик упал почти в два раза. Я вижу на своих проектах, что пользователи из России жалуются, что не могут открыть сайт.
Ситуация здесь очень похожа на блокировку ютуба, который отказывается удалять видео по требованию властей РФ. Из-за алгоритмов шифрования, через которые мы открываем ютуб, власти не могут заблокировать отдельные видео на уровне провайдеров связи и поэтому блокируют ютуб целиком.
В случае Cloudflare власти не могут надёжно заблокировать отдельный сайт, который живёт на Cloudflare, поэтому блокируют Cloudflare целиком.
Это печально, потому что для совсем небольших проектов, для бесплатной защиты от DDoS и AI-скрепинга, Cloudflare не имеет альтернатив.
К тому же Cloudflare даёт очень классно управлять кешированием — благодаря этому даже слабенькие новостные сайты могут бесплатно выдерживать огромную нагрузку и открываться мгновенно.
Из платного в России есть DDoS Guard, от 8000 рублей в месяц, и Curator, от 23 тысяч рублей в месяц. К сожалению, уровень развития API, объём и качество дополнительных сервисов, типа хитрого кеширования, CDN и облачных функций, — несравнимые. Надеюсь, они будут развиваться, и в какой-то момент компании предложат бесплатные услуги для небольших проектов и медиа.
—
Прямо на наших глазах происходит ползучая балканизация интернета. Прощай, виртуальный фронтир! Поселенцы притащили колючую проволоку.
На прошлой неделе умер Билл Аткинсон, один из ключевых программистов ранней Apple, создатель HyperCard.
Тот самый чувак, который запрограммировал возможность окон у макинтошей перекрывать друг друга, потому что ему показалось, что он видел такую возможность во время встречи в Xerox PARC. Инженеры Xerox признались потом, что им и в голову не пришло такое программировать: слишком сложно!
Ещё он разработал алгоритм дизеринга Аткинсона, чтобы рисовать картинки на черно-белых экранах маков того времени.
HyperCard позволял создать программу абсолютно любому человеку. Это было похоже на создание презентаций в PowerPoint: сначала ты накидываешь визуальные элементы на карточки, экраны приложения. Дальше, с помощью языка программирования, похожего на обычный английский язык, задаёшь логику действий. Программы создавали люди, далёкие от программирования.
Это был один из первых в мире инструментов визуальной, low code разработки. Создатель веба Тим Бернс Ли говорил, что вдохновлялся ссылками в нем.
Меня же занимает вот какой аспект HyperCard: в нём не было специального режима редактирования программ. Любой пользователь мог одним нажатием мыши стать разработчиком и создателем. Любой мог посмотреть, что находится под капотом, и внести изменения в ту программу, которой пользовался.
Сегодня мы пользуемся программами, которыми даже не владеем, мы платим за подписку и можем потерять доступ к привычной функциональности из-за санкций, закрытия компании или просто из-за того, что у разработчика теперь другие приоритеты (Google Reader?).
Ситуация, в которой ты можешь внести изменения в программу, которой пользуешься, — прямая противоположность.
Сейчас возможность редактировать свои инструменты есть только у программистов и у бизнеса. Интересно, что моя основная работа именно в этом: мы делаем инструменты для бизнеса, типа вот этой системы для логистов и вносим в них изменения, когда нас об этом просят.
Порой меня охватывает смутное желание смастерить что-то своими руками, я пишу небольшого бота или скриптик для своих бытовых задач. Используя ИИ, я делаю это чаще.
Есть целые экосистемы, построенные на идее расширяемых и редактируемых программ, обычно на основе Lisp-подобных, «интерактивных» языков.
Это отдельная, сегодня малопопулярная ветка технологического развития. Интересно представить, какими были бы компьютеры, пойди мы по этому пути. Эдакий компьютерный стимпанк.
Это, кстати, одно из обещаний энтузиастов ИИ: что, мол, с развитием средств автоматизированного программирования мы перестанем платить за программное обеспечение. Каждый будет создавать его под себя с использованием искусственного интеллекта. Я в этом мало верю. Хотя, было бы очень интересно.
Ну а пока, если хотите сделать классный софт под себя, — нанимайте нас! ;)
Дополнительные материалы:
— сайт посвященный HyperCard;
— интерактивный раздел на архиве.орг, где можно запустить тысячи стопок прямо из браузера (не с телефона, к сожалению);
— необычная, текстовая, увлекательная презентация про «небольшие, редактируемые пользователем программы».
В контексте падения облаков, чем они лучше/хуже собственного железа?
Можно подумать, что я буду сейчас писать про отказоустойчивость. На самом деле, если ваш проект будет лежать, когда лежит весь GCP или AWS, — то для 99% проектов это абсолютно нормально, такие события происходят раз в несколько лет и длятся не больше пары часов. Мы ведь не кислородными масками управляем, верно?
При необходимости, сравнимый уровень отказоустойчивости можно обеспечить и на облаках, и на собственном железе. Стоимость и сложность каждого решения зависят от специфики проекта.
И вообще, у многих проектов нет даже регулярных бэкапов баз данных, а регулярно тестируют план восстановления в случае аварии основного сервера вообще единицы (не спрашивайте, не расстраивайте вашего сисадмина).
Главное преимущество облаков в сравнении с «реальными серверами» — возможность быстро масштабироваться, то есть сегодня у тебя один сервер обрабатывает 1000 пользователей, завтра проект завирусился на миллионы, и ты за пару минут запускаешь десятки, сотни серверов.
Минусы? За это удобство и возможность мгновенного масштабирования нужно платить, порой в десятки и сотни раз больше, чем за просто арендованные и уж тем более купленные серверы.
Но есть нюанс: хорошо написанное веб-приложение на одном современном сервере может выдержать нагрузку в сотни тысяч пользователей. Реальных проектов, которым нужно прямо «облачное» масштабирование, — не так много.
К тому же, если в сервисе нет совсем уж жесткой неоптимальности, обычно, стоимость аренды любой инфраструктуры не является главным расходом. Обычно, зарплаты разработчиков в разы (десятки раз) выше стоимости хостинга. То есть экономить время разработчиков за счет увеличения стоимости инфраструктуры — это обычно выгодно.
Тут у облаков есть небольшое преимущество — они предлагают дополнительные, более сложные услуги, чем просто аренда серверов. Например, — настроенная база данных, сервис хранения файлов, предсказательная система как сервис. Можно не отвлекаться на базовые блоки, которые повторяются от проекта к проекту.
Нюанс: многие вещи для удобства программистов, которые облака сделали первыми, теперь можно не дорого воспроизвести самостоятельно, используя опен-сорс решения.
В общем, как обычно, начать стоит с того решения, с которым привык работать технарь, которому вы доверились. Ему ведь пользоваться этими инструментами.
А если вдруг ваши счета за облака станут заметными, — то во-первых, поздравляю, это значит у вас есть пользователи! Во-вторых, переехать на свое железо в эти дни проще, чем когда-либо.
Пример: классно наблюдать, как последние 3 года создатель важного фреймворка Ruby on Rails и культовой системы управления проектами Basecamp Дэвид Хейнемейер Ханссон (DHH) планомерно перевозит свои продукты с миллионами пользователей из облаков на собственные серверы.
Они объявили о планах выхода из Амазоновского облака AWS ещё в октябре 2022. На тот момент, они платили за Амазону 1,5 млн долларов в год! Для начала, они купили себе физических серверов на полмиллиона долларов (всего треть годового чека за облака!)
В июне 2023 объявили об успешном перевозе всех вычислений, а недавно купили специализированное железо для хранения данных и мае наконец перевезли хранилище файлов из AWS S3.
Другой яркий пример, с которым я сталкивался лично, — это стоимость трафика для медиа-проектов. Трафик в облаках для популярного медиа может стоить десятки тысяч долларов, и такой же объем можно обработать десятком арендованных серверов по 40 баксов каждый. Экономия в 100 раз. Но это всё имеет смысл только на масштабе. Так выпьем же за то, чтобы было на чем экономить!
Удивительно, на какие ухищрения идут Яндекс и Фейсбук, чтобы отследить, на какие веб-сайты мы ходим.
Если на вашем Андроид-телефоне установлен Инстаграм или Яндекс.Карты, то при открытии веб-страниц с трекером Фейсбука или Яндекса соответствующая компания знает, что это именно вы открыли веб-страницу. Не спасут даже режим инкогнито и отдельный браузер.
Для этого они, ни много ни мало, запускают локальный веб-сервер прямо на мобильном устройстве.
После публикации статьи Фейсбук перестал это делать, Яндекс — продолжает. Производители браузеров спешно исправляют уязвимость.
Под iOS это не работает только потому, что там нельзя запустить долгоживущие фоновые процессы, это сделано для экономии батареи.
Интересно, наложит ли кто-то из европейских регуляторов оборотные штрафы?
Закончили 12-й сезон подкаста «Запуск завтра».
Честно говоря, до сих пор не верится, что мы выпустили уже больше 250 эпизодов!
Этот сезон — особенный. Он состоит из двух частей.
В первой части я наконец-то со вкусом, толком и расстановкой поговорил с умными людьми про власть в цифровом пространстве. Это тема, которая интересует меня уже многие годы. Компьютеры и интернет когда-то были «последним фронтиром», куда уходили те, кто не желал жить по правилам «большого мира». Сейчас ситуация изменилась: в айти есть деньги, айти влияет на политические процессы, и политики, и бизнесмены уже многие годы потихоньку прибирают власть себе в руки. Этот процесс имеет множество форм, и мы говорим о самых разных из них с экспертами, учеными, исследователями и писателем-фантастом! 10 эпизодов!
Вторая часть сезона — нарративная. Это как сказки на ночь для взрослых — с сюжетом, героями, красивой музыкой, голосами и звуками эпохи. Каждый эпизод — история одной технологии, которая меняет мир на наших глазах.
Спасибо команде подкаста — за каждым эпизодом стоит большая работа: Маша Агличева, Маргарита Берденникова, Данил Астапов, Евгения Хрищанович, Юра Шустицкий, Ильдар Фаттахов, Женя Щербина, Аня Карпова.
Я подготовил простенький сайт для этого сезона, чтобы можно было окинуть взором все эпизоды и выбрать себе по вкусу. Ну и, как обычно, прошу пройти опрос, чтобы сделать следующий сезон ещё лучше. Ура!
P. S. Коллеги просят упомянуть партнера нарративной части — Селектел. Не жалко — это мой любимый хостер в России, пользуюсь сам и всем рекомендую!
Второе видео — презентация нового пылесоса Дайсон. Тоже 9 минут, но каких! Владелец компании выходит на сцену перед аудиторией из журналистов и показывает такой пылесос, которого никто раньше не видел — двигатель, мусоросборник, всё уместилось внутри ручки диаметром 38 мм! Работает он за счет микро-двигателя, крутящегося со скоростью 140 тысяч оборотов в минуту. А ещё насадки, в которых наконец-то не застревают волосы! И подсветка мусора на полу сразу во все стороны!
Прямо как с Джобсом в лучшие времена — сразу хочется купить, пускай и понимаешь, что дешево не будет.
—
В чем разница между этими двумя видео? Почему при просмотре первого я чувствую обман, а при просмотре второго — вдохновение?
Интересно, я ли один так чувствую?
Мне кажется, дело в натуральности, в объеме продакшена. Первый ролик отполированный, за этим продакшеном не видно реальных Сэма и Джони. Во втором ролике Дайсон на секунду мешкается, часть текста явно читает прямо с презентации, не идеально, зато он там живой. С ошибками и недостатками, но безусловно живой человек.
—
Не знаю, зачем так поступили Альтман и Айв, но лично мне страшно показать своё несовершенство. Даже в этом канале я стал пытаться «отполировать» все свои тексты. Не дай бог показать, что у меня не все идеально в бизнесе или подкасте или вообще в жизни (и голове). Кажется, что в процессе я чуть не выплеснул и ребенка. Канал был моим способом делиться своей жизнью и мыслями и раньше я был смелее.
Так выпьем за смелость быть настоящим!