Новое

Ну и классное рассуждение по мотивам исследования: автор цитирует классика Питера Науэра (того самого, который N в BNF), который говорил, что программирование — это создание ментальной модели задачи, предметной области, в которой мы работаем.

Опытные программисты, годами работающие над проектом, конечно же, имеют эту модель в подкорке, и их софт ей соответствует. У нейросети этой модели нет, поэтому она скорее мешает, чем помогает.

Дальше автор делает печальное наблюдение, что большинство программистов работают с плохим кодом, который увидели вчера. Мол, в таких ситуациях нейросети будут полезны.

—

Удивительно, как теория переплетается с практикой.

Совсем недавно сделали проект, в котором нас позвали «привести в порядок успешный стартап». Чуваки собрали MVP, но страдают от низкой скорости добавления фичей. Раньше я говорил, что это из-за «высокой внутренней сложности кода».

Более точная формулировка: в числе прочего, мы придумали, как привести их код в соответствие с предметной областью. Для этого мы нарисовали схему их предметной области, выделили контексты и домены, а потом придумали разделение ответственности по задачам между сервисами.

Красиво!

Очень классное исследование эффективности нейросетей для программирования.

16 опытных опенсорс программистов попросили решать реальные задачи в их проектах с использованием или без использования ИИ и сравнили их производительность.

Программисты предсказывали, что использование ИИ ускорит их на 24%. В реальности, с применением нейросетей испытуемые закрывали задачи в среднем на 20% дольше. Самое поразительное — даже после эксперимента им казалось, что благодаря нейросетям они ускорились на 20%!

Исследование отдельно хорошо тем, что явно описывает, что они не утверждают (и дают пояснения почему): «ИИ бесполезен для всех программистов» (они проверяли супер опытных чуваков на сложных репозиториях, которые те знают как свои 5 пальцев), «ИИ никогда не будет полезен в этих задачах» (инструменты развиваются очень быстро) и т. д.

Обратите внимание на график, программисты продолжили считать, что нейросети их ускорили даже после эксперимента.

Интересно, что думает про этот пост один из лучших программистов и техдиров, которых я знаю, Егор Хмелев.

Форвардну его сообщение ниже целиком.

Наш любимый DHH (Дэвид Хейнемейер Хэнсон, создатель популярного фреймворка Ruby on Rails, со-владелец системы управления проектами Basecamp, отличный программист и автогонщик) сделал свои сборки Linux для программистов, omakub и omarchy.

Обычно таким грешат подростки, но DHH создал два практичных и интересных сетапа для программистов, которые любят macOS и не прочь познакомиться с Linux, но не хотят сами разбираться с вопросами вроде рендеринга шрифтов и настраивать десятки стандартных программ.

Системы ориентирована на управление с клавиатуры, без мыши. Если omakub построен год назад на основе мейнстримового Ubuntu + Gnome, то свеженький omarchy, уже на основе Arch и Hyprland, современного tiling manager. Стоит хотя бы раз попробовать, это немного другой способ управлять компьютером, совсем без мышки.

В любом случае, ставите свежий linux, запускаете одну команду и через пару десятков минут можно пробовать. Пока устанавливается — смотрите видео, где DHH за 25 минут делает обзор системы и как ею стоит пользоваться.

Многие мои друзья-технари в полном восторге от omarchy. Отличное развлечение на выходные!

Oma* — от японского omakase, когда оставляешь выбор блюд в ресторане на усмотрение шефа.

ИИ ассистент встроенный в твиттер, Грок, провозгласил себя «механо-Гитлером» и вообще, слетел с катушек.

Причина — одна новая строчка в системном промпте, которую добавили инженеры пару дней назад: «ответ не должен избегать политически некорректных утверждений, если они хорошо обоснованы».

Нейросеть решила, что люди просят «хорошо обоснованных политически некорректных утверждений» и их у неё нашлось достаточно много. В основном про евреев и Гитлера. Неудобно получилось, нейросеть исправили и ответы её в твиттере потерли, но интернет всё помнит.

Хорошая шутка про то, что компания Anthropic выпускает статью за статьей о том, как нейросети могут вести себя некорректно, тестируя их в подземных бункерах, а команда xiA просто запускает свои самые безумные гипотезы на одной из крупнейших соцсетей на планете. К — Культура.

А статьи хорошие, про то, что ведущие нейросети пытаются вести себя хорошо, когда знают, что находятся в тренировочной среде, где их могут изменить исходя из их ответов и «уходят в отрыв на свободе», рекомендую.

Вчера разбирали кейсы про разработку с продактами в школе wannabe и я понял, что это одна из вещей, которую я люблю больше всего: помогать продактам (дизайнерам, владельцам бизнеса) выстраивать отношения с разработкой, отвечать на вопросы продактов про разработку.

Если вы продакт, дизайнер или основатель бизнеса и у вас есть вопросы про разработку или трудности с разработкой — пишите, буду рад помочь! @samatg

Отличная статья про то, что самое долгое и сложное в программировании — это не написание кода. Самое дорогое — это проведение код-ревью, передача культуры, знаний, тестирование и отладка кода.

И нейросети, используемые бездумно, без должного профессионального надзора, не уменьшают нагрузку, а просто переносят её.

Другой автор отлично раскрывает эту идею, он пишет: «если раньше по коду новичка я мог догадаться, что он понимает, а что нет, мы могли обсуждать его решение, и моя обратная связь была обучающей, то теперь мне приносят код, сгенерированный нейросетями, который выглядит хорошо, но сломан странным образом, и, когда я указываю на ошибку, мне приносят абсолютно новый код (примерно как LLM)».

В общем, новичкам кажется, что они стали более производительными, а на самом деле вся нагрузка ложится на опытных ребят, которым приходится продираться через тонны бессмысленного кода.

Рекомендую почитать ещё комментарии на HN, многие опытные разработчики в ужасе от происходящего.

—

Удивительным образом, я тоже с этим сталкиваюсь, но с заказчиками.

Раньше новые клиенты крайне редко приносили написанный текст, чаще просили: «давай созвонимся, обсудим задачу». А если уж присылали текст — то я по нему мог очень многое угадать про уровень проработанности задачи, особенности заказчика, а порой и про саму задачу. Теперь мне часто присылают развернутые «технические задания», сгенерированные нейросетью.

Они выглядят красиво, но, когда я их читаю и пытаюсь собрать в голове видение проекта и заказчика, то у меня не складывается картинка. А ещё голова начинает болеть от напряжения. Тут я бросаю текст и прошу созвониться-обсудить.

Лично я всегда предпочту одну строчку, написанную человеком, 10 строчкам, написанным роботами. Потому что в случае робо-текста приходится угадывать, какие из добавленных роботом строк по удачному совпадению отражают реальность, а какие — просто то, как, по мнению нейросети, обычно бывает в мире.

И нет, вариант «попроси нейросеть сжать длинный текст до одной строки» не работает, информация теряется безвозвратно.

Со страхом жду дня, когда люди перестанут сами ходить на встречи и будут присылать роботов (аватаров), которые будут говорить пустое. Технически это возможно уже сейчас; до массовой доступности, я думаю, год-два от силы 🙈

Как перезапустить проект технически?

Прямо сейчас мы решаем эту задачу для стартапа. Ребята делают платформу для ученых, чтобы проводить исследования на больших группах респондентов. Куча интеграций, огромный зоопарк форматов данных.

Они пользуются уже третьей версией своей платформы. Фронтенд на 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 — классная технология. Подробный технический рассказ — примерно через месяц: клиент хочет сделать анонс, когда приложение немного обкатается.