DevFM

Насколько AI увеличивает продуктивность программистов Недавно METR опубликовали исследование с интригующими выводами: авторы задаются вопросом, насколько AI‑асисты действительно ускоряют или замедляют работу опытных разработчиков. Почему привычные метрики не годятся – Большинство бенчмарков фокусируется на узко поставленных задачах с автоматической проверкой результатов, не требующих контекста больших кодовых баз – Они не учитывают время на настройку подсказок, исправление неточностей и интеграцию AI‑сгенерированного кода в проект – В них отсутствует фактор человеческой правки: в реальности мы тратим дополнительное время на доводку и ревью предложений ИИ Как проходил эксперимент 16 опытных разработчиков из крупных open‑source‑репозиториев (более 22 000 звёзд и 1 млн строк кода) выбрали по 15–20 реальных задач — фиксы багов, новые фичи и рефакторинг. Всего получилось 246 заданий. Каждую задачу случайным образом разрешали выполнять либо с любыми AI‑инструментами, либо без них. Разработчики фиксировали время выполнения каждой задачи. Ключевой вывод И вот барабанная дробь: использование AI‑асистов замедляет разработчика на 19%. При этом участники до эксперимента прогнозировали ускорение на 24%, а после всё ещё считали, что AI их реально ускорили. Размышления авторов Ребята видимо сами удивились своим выводам, поэтому вторая часть статьи посвещена размышлениям о том, почему их выводы не совпадают с другими бенчмарками и ожиданиями пользователями: – Ограниченный объём сэмплирования: в бенчмарках модели могут генерировать тысячи вариантов, здесь — лишь несколько – Крутая кривая обучения: эффект от AI‑инструментов может проявляться после сотен часов практики, а в эксперименте у большинства участников было лишь несколько десятков часов опыта – Высокие стандарты качества: Open‑source репозитории часто имеют строгие требования к тестам, документации и стилю, что требует дополнительной правки AI‑кода От себя хочу добавить: AI – не золотая пуля, а набор специализированных инструментов: какие-то классы задач они выполняет хорошо, какие-то хуже. Чтобы получить реальную выгоду, нужно понимать особенность применения этих инструментов. Именно этот момент, на мой взгляд, упущен в исследовании. Такую же картину я наблюдаю в реальной жизни: некоторые разработчики столкнувшись с тем, что AI не решил задачу под ключ, сразу отказываются от него. #ai

Пятничное развлекательное Недавно вышла забавная заметка. Ребята из Soundslice делают онлайн-сканер нот: загружаешь снимок партитуры, система распознаёт ноты и тут же проигрывает музыку. В какой-то момент они обратили внимание на ошибки в логах. Вместо обычных снимков нот туда заливали ASCII-табулатуру из ChatGPT. После небольшого расследования выяснилось, что модель советовала пользователям загружать табы в Soundslice для воспроизведения. А самое забавное – то, что такой функции у ребят никогда не было: ChatGPT её просто выдумал. Команда встала перед дилеммой: разрабатывать ли эту фичу или просто оповещать пользователей о том, что такая функция не поддерживается. В итоге фичу реализовали. Получилась забавная и немного странная история: фича родилась не из потребностей пользователей, а из-за галлюцинации ChatGPT. #ai

Cursor изнутри Недавно вышла немного рекламная, но легкая и интересная статья от The Pragmatic Engineer о том, как устроен Cursor узнутри. В начале статьи просто любопытные цифры о Cursor. Дальше автор рассказывает нам о технологическом стеке. Из интересного: - TypeScript – бизнес-логика, критические штуки на Rust - Turbopuffer – основное KV-хранилище, держит зашифрованные файлы + Merkle-деревья для синка - Pinecone – векторная БД для семантического поиска по коду - Datadog, PagerDuty, Sentry, Amplitude для обзервабилити - Linear – для таск трекинга (рекомендую попробовать для тех, кто не пробовал, интересное решение) Cursor не хранит наш код на своих серверах. Когда вы отправляете запрос в Chat, происходит следующее: 1. Запрос уходит на сервер 2. Сервер решает, что это – вопрос о коде, и запускает векторный поиск по embedding'ам, которые заранее были созданы на сервере во время “индексации” проекта 3. По результатам векторного поиска сервер понимает, какие файлы могут быть релевантны и запрашивает эти конкретные файлы обратно у клиента 4. Клиент шлёт нужные части кода (зашифрованно) – только те, что реально понадобились 5. Сервер “собирает” полный контекст и запускает inference для ответа 6. Ответ возвращается в чат Отдельно стоит рассказать, как Cursor узнаёт, какие файлы изменились, и переиндексирует только их. Для используются Merkle-деревья: 1. каждый файл разбивается на чанки, каждый чанк хешируется 2. хеши объединяются попарно и формируют узлы следующего уровня 3. в результате строится дерево, корневой хеш которого отражает состояние всего проекта – аналогичное дерево строится и на клиенте, и на сервере Каждые ~3 минуты клиент сравнивает свой корневой хеш с серверным: – если хеши совпадают – индекс остаётся прежним – если отличаются – обход дерева точно выявляет изменённые чанки, и переиндексирует только их

Советы, как сделать полезный дашборд На практике часто видел, что в команде есть какие-то дашборды, но кто ими пользуется, что на них можно увидеть – непонятно. В статье автор делится советами, как превратить набор красивых графиков в полноценный рабочий инструмент команды. Дашборд должен отвечать на вопросы Представьте, что человек открывает дашборд, чтобы получить конкретный ответ: Насколько выросло CPU-потребление у сервиса X? Сколько заявок мы обрабатываем за сутки? Какая температура в серверной прямо сейчас? Если панель не помогает ответить – что-то не так. Относитесь к дашборду, как к продукту – ЦА. Дежурный SRE, разработчик, топ-менеджер? – CJM. Куда пользователь пойдёт после просмотра? Лог, alert, соседний дашборд? – Условия использования. Инцидент на ноутбуке, большой монитор в опен-спейсе, недельный отчёт? – Что улучшилось после изменений. Например, добавил спарклайн -> дежурный быстрее ловит аномалию Проверяйте на целевой аудитории Задайте дежурному реальный вопрос («Почему вырос latency?»). Посмотрите, как он ищет ответ. Соберите обратную связь, доработайте. Показывать дашборд случайным коллегам бесполезно – у них другие задачи. Правила восприятия – Читаем сверху вниз, слева направо – важное размещайте в левом верхнем углу. – Большая панель = важная метрика. Мелкие блоки – второстепенное. – Цвет привлекает внимание: используйте принцип светофора (красный – критично, желтый – предупреждение, зелёный – норма, синий – справочная инфа, серый – неактивно / неизвестно) Не перегружайте – Панель должна умещаться на экране без прокрутки – Не больше 30 линий на графике. В остальных случаях – top-10 и детальный дашборд по клику – Не больше 3 типа визуализации на странице – иначе когнитивная нагрузка растёт – Толщина линий ≥ 2 px – их будет видно даже на созвоне – Null-значения не соединяйте – разрывы важны для диагностики – Стекирование используйте аккуратно и делать максимально непрозрачную заливку Документируйте панели – Заполняйте Description (поддерживает Markdown) – Выводите в названии переменные Grafana – сразу видно контекст – Добавляйте ссылки в настройки панели на инструкции и релевантные дашборды – Добавляйте легенду и следите за ее читабельностью Оптимизируйте данные Старайтесь отфильтровать максимальное количество данных на стороне источника, чтобы не перегружать клиент Осторожно с готовыми дашбордами из интернета Красиво – не значит полезно. Пройдитесь по каждой панели, поймите логику, только потом ставьте в свой контур. Ошибка всплывет в самый неудобный момент – во время аварии.

Как метрики помогут улучшить доставку фич? Ребята из Точки поделились интересным кейсом из своей практики. Команда чувствовала, что в процессе доставки фич что-то идёт не так, но на ощупь определить узкие места не удавалось. Тогда тимлид начал внедрять метрики — и это показало всем объективную картину происходящего. В статье автор описывает, какие именно метрики Точка стала отслеживать и что удалось благодаря этому выявить: 🔹 Cycle time Показал, что задачи надолго зависают на этапе ревью. Проблема оказалась не в самом ревью, а в его ожидании. Решили делать ревью до дейли. Это резко ускорило прохождение задач по пайплайну. 🔹 Time to market Подсветил разрыв между идеей и релизом. Стало видно, как задачи тормозятся ещё до разработки — из-за блокеров и неготовых требований. 🔹 Процент возвратов с тестирования Вскрыл высокий уровень багбэков. Причина — потеря контекста и отсутствие автотестов. После внедрения автотестов возвратов стало меньше, и задачи стали доходить до продакшена с первого раза. 🔹 Распределение времени по типам задач Дало понимание, как балансируется работа между багами, фичами и техдолгом. Например, если количество багов растёт, а времени на них почти нет — это сигнал, что воронка вот-вот начнёт захлёбываться. Метрики не спасут, если процессы разваливаются, но без них ты просто не узнаешь, где именно всё ломается. Ребята из Точки не только поняли это, но и показали на реальных цифрах. Очень годный кейс — стоит почитать. Реклама «АО Точка», tochka.com, 18+

Как проводить встречи эффективно Существуют общепринятые практики организации встреч, но в больших командах даже очевидные правила теряются. Один из лидов недавно задокументировал процесс в виде чеклиста. Этот чеклист выравнивает подходы всей команды и повышает эффективность встреч. Публикую сокращенную версию. Подготовка – Избегай звонков без необходимости – большинство вопросов решаются в чате – Не дергай “на минутку” – если прод не упал, значит не срочно – Анонсируй: кто, когда, зачем. Иногда достаточно треда в чате – Проверяй доступность участников через календарь – Ограничивай время – 30 минут обычно хватает, 1 час — максимум – Готовь повестку заранее: тема, пункты обсуждения, цель встречи, уважай чужое время – Рассылай материалы и документы до встречи – Предупреждай об отмене или задержке как можно раньше – Опаздываешь? Не опаздывай 🙂 Старт встречи – Начинай вовремя – без «ждём ещё кого-то» – Проверь комнату ожидания и список участников – Напомни повестку – это фокусирует команду Фасилитация – Держись повестки и возвращай к цели встречи – Дай слово молчунам, притормози болтунов. – Подводи итоги каждые 10–15 минут: «Итак, договорились, что…» – Следи за чатом и поднятыми руками – Делись экраном, глаза – тоже канал восприятия – Включай камеру по возможности – Не перебивай – сначала дослушай, потом задавай вопросы. – Паркуй спорные темы после трёх заходов – Уважай выделенный слот – если нужно больше времени, спроси – Веди пост-мит в реальном времени После встречи – Напиши постмит, опубликуй до конца дня, тегнув участников #devfm

Оперативный постмит Качественная встреча всегда завершается постмитом. Я обычно тезисно фиксирую ключевые моменты в своих заметках по ходу обсуждения. В конце озвучиваю их вслух для подтверждения, затем немного шлифую текст и отправляю участникам в мессенджер. Недавно подсмотрел, как мой коллега во время встречи сразу шарит экран и на ходу фиксирует постмит: решения, экшн-поинты, ответственных, сроки. Это оказалось супер удобно: – Сразу видно, что записывается, а участники могут поправить, уточнить, добавить – Все сразу понимают, кто на ком стоял, кто за что отвечает – Не нужно тратить время после встречи и что-то дооформлять – Шаблон постмита позволяет ускорить процесс ещё больше #devfm

Про шардирование Postgres и иллюзию ACID Известно, что шардирование PostgreSQL – задача не из простых. Ребята из YDB в своей статье подсветили один важный нюанс. Пока вы работаете с одним шардом – всё как в обычном Postgres. Но как только транзакция затрагивает больше одного шарда – вы рискуете столкнуться с неожиданностями. Например, можно получить ситуацию, когда данные на одном шарде уже обновились, а на другом – ещё нет. И тогда тот, кто читает эти данные, может увидеть нечто странное. Как в примере из статьи: Вася проверяет семейный счёт и видит, что на нём 150 рублей, хотя на самом деле должно быть 200. Просто один из шардов уже принял изменения, а второй ещё не успел. Это происходит потому что двухфазный коммит даёт только атомарность, а не изоляцию. Распределённый снепшот тут не делается, и гарантии ACID превращаются в AC_D. В общем, если планируете делать широкие транзакции не забывайте об этом факте. #database

fd – удобная альтернатива find Если используете на практике find, то посмотрите на fd. Работает быстрее, флаги более лаконичные и поведение по умолчанию разумнее. Вот пару примеров: 🔹 fd сам ищет файлы в текущем каталоге (не нужно писать .) и не требует флага -name

fd txt # Найдет все файлы с "txt" в названии

В find пришлось бы писать:

find . -name "*.txt"

🔹по умолчанию игнорирует скрытые файлы. А еще игнорирует то, что у вас лежит в .gitignore. Очень удобно, избавляет от кучи лишних совпадений. В find же нужно указывать

-not -path ‘*/path/*’

🔹можно делать цветной, более наглядный вывод 🔹написан на Rust, ну, сами понимаете – всё работает быстро-быстро 🙂 В ридми у ребят ещё много примеров. #tools

Пятничное развлекательное Уходящей эпохе Stackoverflow посвящается. #fun

Как я провожу синки с тимлидами Недавно с коллегами заходил разговор за формат синков с тимлидами. Расскажу, как я провожу подобные встречи. Формат Обычно, такие встречи проходят раз в неделю. Цель – синхронизация по текущим задачам, проблемам и приоритетам. Каждый синк – отдельная повторяющаяся приватная таска в таск трекере (как я веду задачи писал тут), либо приватная страничка в вики (в нашем случае конфлюенсе), где фиксируется повестка. Важно, что повестку наполняют оба: руководитель и подчиненный. Структура Повестка состоит из трёх частей: 1️⃣ Обязательная часть Фиксированный список тем, которые обсуждаются на каждой встрече. Этот раздел редко меняется. Как правило это: – Посмотреть action points с предыдущего синка – Общий статус по задачам в работе Для разных лидов обязательная часть может отличаться. Например, с некоторыми лидами у нас есть пункт по тайм менеджменту, потому что с этим часто бывают вопросы. 2️⃣ Опциональная часть Эта такой живой раздел. Сюда каждый из участников записывает темы/вопросы, накапливающиеся в течение недели. Темы могут быть самыми разными: какой формат перфоманс ревью в этом полугодии, обсудить новую идею по изменению шаблонного сервиса, внедрение новых метрик и т.д. 3️⃣ Action points Самый важный раздел. Здесь фиксируем договоренности с синка с указанием дедлайнов и ответственных. Соответственно, такой скелет повестки с пояснениями по каждому разделу создается для каждой встречи и наполняется в течение недели. Почему именно так? Кому-то может показаться, что такой формат слишком бюрократичен. И в целом, когда у тебя пара подчиненных, действительно можно держать многое в голове, но когда их становится больше, то подобный формат мне дает: ✅ прозрачное отслеживание всех вопросов и договоренностей ✅ возможность накидывать темы заранее, не теряя их ✅ отсутствие стихийных созвонов, когда появляется какой-то вопрос. Всегда есть понятное место, куда его можно припарковать ✅ наличие повестки заранее, что позволяет лучше подготовиться к встрече ✅ лучше работает на асинхронное взаимодействие – если какая-то тема потеряла актуальность за неделю, можно просто её удалить, не тратя время на обсуждение О применении ТГ для асинхронной работы была отдельная статья. #teamwork #devfm

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

It's worth noting that Github Copilot doesn't understand DreamBerd, which means that Microsoft won't be able to steal your code. This is great for when you want to keep your open-sourced project closed-source.

#fun

Life Altering Postgresql Patterns Постгрю я, конечно, люблю не так сильно, как питон, но всё равно периодически посматриваю на хорошие практики. В статье автор дает несколько полезных советов при работе с постгрей. За некоторым исключением, во многом с ним согласен. 🔹 UUID вместо автоинкремента — если работаешь с распределёнными системами или API, лучше сразу использовать uuid DEFAULT gen_random_uuid(). Избавит от проблем с конфликтами ID 🔹 created_at / updated_at — каскадное удаление может привести к неожиданным потерям данных. Лучше контролировать процесс вручную 🔹ON DELETE RESTRICT вместо CASCADE — защищает от случайного удаления связанных данных. Лучше удалять вручную при необходимости 🔹Используйте схемы — не нужно всё пихать в public, схемы помогают логически разделить данные 🔹Таблицы вместо ENUM — если нужно хранить фиксированный набор значений, лучше делать это в отдельной таблице. Всегда так делал, а ещё удивляюсь, что иногда енамки хранятся на уровне кода 🔹Таблицы в единственном числе — user вместо users. Логичнее: одна строка = один объект. Хотя наверняка найдутся сторонники другого подхода 🔹Soft delete вместо удаления — автор убеждён, что хранение дешевле, чем восстановление данных, и почти всегда рекомендует soft delete (deleted_at TIMESTAMP NULL) 🔹 JSONB вместо сложных JOIN'ов — удобно для метаданных и настроек, если структура может меняться. Но я бы тут осторожно подходил к такому решению. Например, что будет со старыми данными, если формат json поменяется? А не будет ли проблем с TOAST? На эти темы у нас были отдельные посты: раз, два 🔹Понятные имена join-таблиц — просто объединяйте имена связываемых таблиц и не городите чего-то этакое #database

Diagrams Нравится мне python, а если с его помощью ещё и архитектурные диаграммы рисовать — вообще красота. Поэтому принес ещё один инструмент, позволяющий кодом на питоне создавать архитектурные схемы. В примерах можно посмотреть как это выглядит: тут и тут. Затащить в полноценное использование командами такой инструмент у меня, конечно, не получится (да и смысла большого нет), но развернуть локально и потыкать интересно. На практике мы используем Structurizer. А ранее у нас был пост, зачем мы документируем архитектуру. #tools

Получил рассылку от Postgres с интересным докладом: Механизмы секционирования больших таблиц, который будет проводиться 25 марта, то есть завтра. Записался, надеюсь, что это не маркетинговый доклад, а то среди тем заявлен pgpro_autopart, а это уже часть Postgres Pro. Посмотрим, что расскажут.

Markwhen — для построения роадмапов Обычно построением роадмапов занимаются руководители проектов, но иногда это нужно и тимлидам или другим техническим руководителям. Хочу поделиться гиковским опенсорсным инструментом — Markwhen. Markwhen позволяет строить роадмапы с использованием синтаксиса Markdown и хранить их в git. Из минусов обнаружил невозможность выставлять зависимости между колбасками. Вот тут можно потыкать инструмент, посмотреть на его возможности, синтаксис и способы визуализации. А тут документация. Также у ребят есть всевозможные расширения в том числе для Obsidian и VSCode. #tools

Postgres — как делать не надо В вики Postgres есть отличный гайд с десятками полезных советов о том, как не стоит делать — и, самое главное, объяснениями, почему так делать плохо и как делать правильно. Вот несколько интересных моментов: — Не используйте char(n) — у нас был отдельный пост о разнице между char, varchar и text. — Не используйте serial — Не используйте NOT IN — Не используйте timestamp без timezone #database

Backup: архитектура систем Про system design часто пишут в контексте подготовки к собеседованиям. Мы же в первую очередь пишем про практический аспект — зачем архитектура вообще, как её описывать, какими инструментами мы пользуемся, как вообще процесс можно организовать. — Для чего нужны архитектурные схемы — Как документировать архитектуру — Google design docs — C4 model для документирования архитектуры — Анализ источника багов как начало улучшения процессов работы в команде — Фиксируем зоны ответственности проекта — визуализируем работу с помощью Value Stream Mapping Это продолжение цикла тематических подборок. Предыдущая подборка материалов по базам данных. #backup #systemdesign

Value Stream Mapping В рамках анализа затыков в процессе поставки релизов наткнулся на статью, рассказывающую о Value Stream Mapping (VSM). Value Stream Mapping — метод визуализации процесса работы. Он помогает увидеть весь процесс от начала написания кода до деплоя в прод, выявить узкие места и наметить улучшения. Но, прежде чем строить карту потока, важно понять, зачем мы это делаем. Здесь помогает Outcome Mapping: 1. Собираем ключевых участников. 2. Формулируем, какую стратегическую задачу мы хотим решить. 3. Записываем проблемы, вопросы, идеи. 4. Группируем их, выбираем главную область для улучшения. 5. Формулируем конкретный и измеримый результат. В статье ещё приводится несколько конкретных примеров Outcome mapping. Теперь можно перейти к построению VSM. Что нужно отразить на карте: — Ключевые шаги — от написания кода до деплоя, тут важно выбрать для себя достаточный уровень детализации процесса, но это можно сделать только эмпирическим путем. — Задержки — проанализировать и отразить места, где работа простаивает. — Хенд-оффы — уделить особое внимание на передачу задачи между командами, например, между анализом и разработкой. — Время ожидания — время, когда кто-то на каком-то этапе кого-то ждет В целом и раньше подобное делали, но не использовали какую-то конкретную практику. Теперь попробуем применить. Расскажите, применяете ли вы что-то подобное на практике? Как ищете узкие места? На тему ускорения процесса доставки у нас был пост, где мы анализировали источники багов. А сократить путь бага нам помогает табличка с зонами ответственности. #systemdesign

"All you need is Postgres" – наверняка слышали этот боевой клич Недавно наткнулся на целый репозиторий, где собрали кучу интересных задач и способов их решения прямо в Postgres. Репозиторий оказалася очень залипательным, можно походить по ссылочкам, узнать какие штуки бывают. Так, например, узнал про PGlite — Postgres in WASM. Просто берёшь и запускаешь базу прямо в браузере. Без всяких линуксовых виртуальных машин. Ну очень интересно! Конечно, не стоит пытаться решать все проблемы с помощью Postgres, но ситуации бывают разные и знать о таких штуках может быть полезно. #database