Саша Раковский

Привет!

Реклама

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

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

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

В чём мой секрет?
В тестах.

Мой подход к тестам имеет одну очень крутую в текущих условиях особенность — его можно внедрить ретроспективно практически в любой проект. При наличии политической воли и ресурсов.

Поэтому, если вы хотите вайб-кодить, но не хотите вайб-дебажить — приходите ко мне. Я научу вас лично или вашу компанию:

1. Писать быстрые, показательные и устойчивые к рефакторингу тесты;
2. Работать в цикле TDD;
3. Учить ИИ работать в цикле TDD.

На консультациях/тренингах в зависимости от вашего запроса или запроса вашей компании, я могу:

1. Помочь разобраться с теорией: TDD, проектирование тест-кейсов, архитектура кода тестов;
2. Показать на практике, как это всё работает в реальном проекте;
3. Помочь найти решение ваших конкретных проблем (подпишу NDA);
4. Помочь спланировать проект по внедрению тестов в вашу кодовую базу и спроектировать требуемую для них тестовую инфраструктуру.

Стоимость разовой часовой индивидуальной консультации — 4000 т.р.
Стоимость пакета из 4+ консультаций — 3000 т.р. за консультацию.

Стоимость для организаций — по договорённости.

Задать вопрос и обсудить план обучения можно в личке в Телеграме: @d_r_q. Или по старинке по почте: biz@azhidkov.pro.

Привет!

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

По моему опыту ии-скептики, когда видят такую новость, делают вывод о непригодности ии в разработке: ну вот опять тупая ллм прод снесла.

А вот для ситхов, перешедших на тёмную сторону силы, это очередной урок: ллм пока слишком непредсказуемы.

Поэтому:
1. Кредов к проду не должно быть в доступе агента.
2. Все должно быть забэкаплено так, что нарочно не снесёшь.
3. Должны быть подготовлены и проверены быстрые механизмы восстановления.

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

Как сэкономить на стоматологе

Смотрю на эти картинки про vibe debugging и понимаю, что мне не откликается.

Больше 5 лет назад TDD и маленькие green-green итерации с частыми коммитами практически полностью убрали дебаг из моей жизни. Уже давно моя работа построена так, что тесты всегда были зелёными 5 минут назад. Если я сделал изменение, а тесты красные, то я не разбираюсь, где я натупил, а просто откатываю изменения и делаю заново.

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

Сейчас с агентским программированием из моего инвентаря дебаг исчез совсем. И, честно говоря, я не скучаю.

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

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

А сейчас - спуллил репу, нажал

/continue

и, вуаля, ты как Дядя Боб, Мартин Фаулер и Кент Бек в одном флаконе. С оговорками, конечно, но не будем придираться.

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

А пока видео нет — в репе с примером появились три веточки, можно глянуть на историю коммитов. По заявкам наших телезрителей я специально прошёлся по 3 историям и нагенерил спеку для истории #3 в отдельной веточке, сделал кейс на бэке для истории #2 - в другой, и фронтовый кейс для истории #1 в третьей ветке.

PS:
Не обещаю, что видео все же выйдет, потому что получается у меня это дело из рук вон плохо. Если кто посоветует хорошего монтажёра за денюжку, буду очень благодарен.

Привет!

Саша Раковский наконец-то опубликовал обновленную версию своего ии-фреймворка /continue.

И меня этот фреймворк вверг в комплекс неполноценности.
Не столько размером и полнотой фреймворка, которые тоже впечатляют, сколько кристальной чёткостью процесса в Сашиной голове, которая стоит за этим фреймворком. Я сейчас буксую именно на процессной части, хотя мне казалось, что у меня процесс тоже хорошо отстроен и формализован. Но на деле - только лишь казалось.

☺️☺️☺️☺️

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

Итак. По просьбам трудящихся первая часть с гайдом по вайб-коду для начинающих готова. В ближайшие день-два постараюсь выдать вторую часть уже с самим фреймворком и примерчиком, чтобы потыкать.

Вот с этим тезисом я согласен.

На текущем этапе развития ИИ, мне видится, что в ближайшие год-два вся наша корпоративная разработка переедет на китайские модели, развёрнутые на инфраструктуре Яндекса, Селектела или Сбера.

Поэтому рекомендую готовиться к тому, что вайб-код все же войдёт в вашу жизнь так или иначе весьма скоро.

А пока статья с гайдом по вайб-коду на подходе. Бонусом к ней по просьбам трудящихся приложу свой /continue фреймворк. С описанием, инструкцией и даже небольшим примерчиком на джаве, чтобы можно было поиграться и за полчасика-часик ознакомиться с основными его идеями.

🚨 Anthropic случайно слили исходники Claude Code

В публичном доступе появился .map-файл с полным TypeScript-кодом на 512 000 строк. Ошибка при сборке, не взлом.

В коде нашли скрытые фичи за feature-флагами: автономный daemon-режим, голосовые команды, триггеры для агентов и режим мониторинга.

Anthropic быстро удалила source map и старые версии с npm, но интернет всё помнит)

Такой вот вайбкодинг от Anthropic ☕️

@ai_for_devs

Про событийный дизайн

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

Про проблему

Любая сложная логика изменения объекта, которая подразумевает возможность конкурентного доступа к данным (гонок) из разных потоков или зависит надёжности внешней системы - это всегда больно. 

По классике мы должны решать это так: садимся и считаем, что будет, если это случилось раньше, чем вот это. Что будет, если вот это начало обработку, но сломалось на полпути. Это нормальный подход, рабочий вариант, можно и так, но, в итоге, может получиться сложно, ненадёжно и, со временем, есть вероятность, что оно начнёт ломаться и требовать все больших усложнений.

Пример

Для тех, кто пока не понял, про что речь. Вот у вас есть ресурс какой-то. Не знаю, товар на складе в вашем маркетплейсе. И вот его могут покупать десятки и сотни человек в день. Как сделать так, чтобы из-за гонки кто-то не купил закончившийся товар? 

Или что делать, если надо отправить заказ на доставку, списать деньги, списать товар из остатков, а где-то посредине что-то сломалось? Денег нет, например, или апи логистов сдохло и не получило запрос. Или приложуха умерла на полпути, потому что новый релиз начал накатываться. Или какой-то вайбкодер всю базу выгрузил в оперативку и наступил OME.

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

События

Короче, все это пипец нетривиально, задачка со звёздочкой. Но это все пока вы не начинаете относиться ко всем вышеописанным вещам в системе, как к событиям, и оперировать не просто объектами, а объектами, агрегирующими события. Не "товар такой-то в таком-то статусе, на складе 57 штук", а "товар такой-то; поставки: 1 февраля 50 штук, 1 марта 100 штук; списания: 29 марта в 14:02 2 покупки, 29 марта в 12:22 1 покупка, 22 марта в 23:59 100 покупок". Тот самый event sourcing. 

И то же со взаимодействиями: не дернул десять апишек, когда пользак нажал кнопку купить, а сохранил его намерение купить. И дальше шедуллеры побежали деньги списывать, логистам заказ передавать, остатки минусовать, баллы лояльности начислять и вот это все. Это вы, скорее всего, знаете под соусом transaction outbox. 

Вот все это, на самом деле, про одно и то же: событийные архитектуры, реактивные системы. Тут работает чисто парадигменная идея из функционального программирования: вы не управляете состоянием, вы просто записываете события, представляя коду возможность самостоятельно разобраться с тем, что же всё-таки произошло.

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

Минусы

1. На очень простых моделях это безусловно оверкилл.
2. При большой нагрузке база забивается очень быстро, что требует внимательной работы с запросами, партиционированием, архивированием и слепками данных.
3. Это не общепринятый подход, поэтому частенько можно встретить сопротивление предложениям решить проблему таким образом. 

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

В начале февраля писал в статье на хабре:
"Я лично ожидаю в ближайшее время взрыв мини-продуктов от одиночек и микро-коллективов — приложений, которые раньше никто не делал, потому что выигрыш не стоил затрат. А теперь такого будет полно"

В комментариях был скепсис, но, смотря на этот график, вижу, что я опоздал с прогнозами: взрыв к тому моменту уже произошёл.

Долгие годы я считал, что наша индустрия глубоко больна.

Повальный карго-культ практически во всем: Agile, CI, CD, микросервисы, архитектура и дизайн, тесты. Отвратное качество кода - big ball of mud, как архитектурный стандарт. Автоматическое тестирование - не массовая практика, а, скорее, исключение, удел топ 1% команд. Все это, конечно, угнетает.

Но то, что происходит сейчас - это уже совсем за гранью. Крупные биг-тех игроки, которые, по идее, должны были быть технологическими локомотивами, ориентирами, и показывать, как оно должно делаться, один за другим сбрасывают девятки со своих uptime счётчиков.

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

И вот последняя аналогия - самая полезная. Я уже писал, ИИ - это не self-driving car, как многие сейчас стали считать. ИИ - это гоночный болид Формулы 1. Чтобы не разложиться, надо не просто уметь водить. 20 лет стажа вождения тут не помогут. Тут нужен совсем другой уровень.

Anthropic: Coding is largely sovled
Также Anthropic каждую неделю:

PS: на картинке то, как выглядят сейчас где-то 80% моих промптов

Люди очень торопятся избавиться от необходимости ревью и пытаются спихнуть его на модели.

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

Моё предварительное мнение - ещё очень-очень рано исключать человека из циклов обратной связи.