Организованное программирование https://xitter.cf/t.co/skoSrBBSLX Ютуб https://xitter.cf/t.co/G3UTcLSXeQ AI.Клуб https://xitter.cf/t.co/w1AIREnh1G | AI в SDLC https://xitter.cf/t.co/gsthM0pO8u

Sunny Isles Beach, FL
Joined January 2010
Запилил страничку со всеми (пока не всеми) своими выступлениями, вебинарами, статьями: mokevnin.github.io/ Смотрите, наслаждайтесь)
9
32
2
225
Добавил инструкцию для агента. Чем дальше, тем меньше надо участвовать в процессе
Гардрейлсы всем и пусть никто не уйдет обиженным Помимо обычных линтеров языков, существует тьма дополнительных, которые смотрят все начиная от ошибок в Markdown-файлах и контроля обратной совместимости в openapi до рекомендации лучших практик при использовании github acitons. Мне всегда нравилось улучшать обвязку проекта, поэтому я довольно давно и регулярно обкатывал и внедрял разные чекеры в проекты Хекслета. И сейчас, как будто бы накопилось достаточно много классных штук, которыми уже можно поделиться. В общем я сделал репозиторий, в котором собраны как самые продвинутые линтеры по языкам так и по всему остальному. Готов поспорить что большинство с ними не знакомо. Как с этим работать? Открываете вашего агента, даете ссылку на репу и пишите: Сопоставь инструменты из этого списка с тем что есть проекты. Предложи дополнения и улучшения в проект на базе этого списка с объяснением почему стоит использовать тот или иной инструмент И все, вы махом получаете кучку улучшений и дополнительного контроля для вашего процесса разработки. Пожалуйста 🙂 github.com/mokevnin/dev-guar…
2
74
9,354
Гардрейлсы всем и пусть никто не уйдет обиженным Помимо обычных линтеров языков, существует тьма дополнительных, которые смотрят все начиная от ошибок в Markdown-файлах и контроля обратной совместимости в openapi до рекомендации лучших практик при использовании github acitons. Мне всегда нравилось улучшать обвязку проекта, поэтому я довольно давно и регулярно обкатывал и внедрял разные чекеры в проекты Хекслета. И сейчас, как будто бы накопилось достаточно много классных штук, которыми уже можно поделиться. В общем я сделал репозиторий, в котором собраны как самые продвинутые линтеры по языкам так и по всему остальному. Готов поспорить что большинство с ними не знакомо. Как с этим работать? Открываете вашего агента, даете ссылку на репу и пишите: Сопоставь инструменты из этого списка с тем что есть проекты. Предложи дополнения и улучшения в проект на базе этого списка с объяснением почему стоит использовать тот или иной инструмент И все, вы махом получаете кучку улучшений и дополнительного контроля для вашего процесса разработки. Пожалуйста 🙂 github.com/mokevnin/dev-guar…
13
5
1
130
16,882
Это я попросил показать гпт как монорепа помогает в агентном программировании
24
4
2
160
14,423
Я чего угодно ожидал, кроме того что он реальную репу мне сюда воткнет
1
50
1,384
Планирую следующие подкасты и предлагаю такой заход. Напишите в реплаях почему вас стоит позвать (я знаю что у меня в подписчиках много крутых ребят) и о чем бы вы могли рассказать. Лайк шер
8
1
26
4,030
Последнее время активно переписываю/пишу на go. Тут же понеслись форки реп с багами и создание новых либ, которые почему-то никто не сделал (а надо было бы)
2
27
7,083
Сегодня в выпуске рассказываю про автоматизацию бизнеса за рамками разработки. Как мы в Хекслете сделали общий контекст, перестроили аналитику, автоматизировали сбор и исправление обратной связи, дали команде mcp для управления Хекслетом и сервисами youtube.com/watch?v=TBYAavvu…
23
3,424
Welcome to Vice City!
1
33
2,698
Когда вы последний раз мержили и ребейзили ручками (с разбором конфликтов)?
119
2
89
19,697
Коварная память кодинговых агентов. Быстрый рекап. В современных агентах по дефолту включена память, которая работает конкретно для вас. Поэтому со временем появляется ощущение, что оно работает все лучше и лучше. Иногда это приводит к казусам, когда что-то сильно меняется и агент работает по старинке, но если следить за чистотой и регулярно вызывать что-то типа /doctor в клод коде, то все будет норм. Такая схема хорошо работает для конкретного человека, но работает плохо и даже вредит при работе в команде. У каждого человека начинает копиться свой набор правил, который во многом дублируется, но при этом не распространяется на команду и не меняется синхронно при изменении чего-либо. В итоге мы получаем ситуацию, когда у новых людей все работает не так хорошо, а хорошие практики перестают распространятся или делают это медленно и не равномерно. Я в какой-то момент, когда увидел очередное "я понял, сохраню в память", психанул и запретил ему это делать. Он этот запрет тоже положил в память :) Поэтому пришлось закатать рукава и проработать схему запрета в AGENTS.md. Можно сказать, а почему бы не выключить ее совсем? Есть таки таки вещи, где она нужна и где я не хочу сильно думать. Возможно там есть настройка которая позволяет память менять по проектно (щас пост опубликую и проверю) и тогда вопрос может быть решен кардинально. Какой у вас опыт с памятью?
20
1
40
9,753
Когда узнал что бд бекапилась на тот же сервер где хранилась
6
43
2,263
Я как в новиград зашел, так что ни сцена, то хочется заскринить
4
513
Выпуск про переход от инженера к предпринимателю, созданию компании express42 и последующему поглощению Флантом уже в сети. Мы встретились с моим старым другом Сашей Титовым, где поговорили про его путь, про девопс и будущее инфраструктуры youtube.com/watch?v=LUytWE_N…
2
1,956
Гитхаб что-то знает про клод, чего не знаем мы
5
22
10,589
Утро сегодня началось не с кофе. Пока мы переезжаем (с разной степенью успешности) в другой дц, расскажу про недавнее интересное открытие, связанное с тем как сделать улучшить работу агентов и сделать больше надежных автоматических проверок разных архитектурных правил. Понятно что со временем появляется все больше и больше правил, которые описываются в AGENTS.md (или что лучше в CODING_STANDARDS.md). Но хотелось бы чтобы они чекались автоматом. Клод нам сам постоянно предлагал и в какой-то момент начал писать скрипты допом к линтингу, которые, в основном, регулярками, проверяли что-то. Кушать не просит и ладно, я не сопротивлялся, но видел что это решение на тоненького, хотя и лучше чем ничего. Когда эти скрипты начали копиться, я подумал, хм, а ведь мне ничего не стоит попросить его переписать правила как плагины к линтерам на конкретных языках. Кое что мы так действительно переписали, но в какой-то момент сам клод говорит, а давай заюзаем ast-grep. Я посмотрел и понял что проспал очень логичную штуку. Еще в 22 году, когда полетел treesitter, кто-то замутил инструмент, который грепает не исходники, а AST. Причем что важно, независимо от языка, оно все языки превращает AST и грепает по его нодам. Это резко повышает точность рабатываний, потому что вместо регулярок, которые ловят ненадежно, плюс херово работают с вложенностью, мы имеем по сути универсальный способ представить весь код (и все форматы) в виде единого AST пространства, по которому идет поиск. Ну и естессно переписали все проверки, потому что у этой штуки еще есть sdk для ноды. А все подобные скрипты у нас агент фигачит на TypeScript. Пара примеров: 1. no-unknown-in-generated-types: в сгенерированных фронт-типах (app/javascript/types/serializers/) не должно быть unknown. Typelizer пишет unknown, когда не смог вывести тип поля. Это бывает у атрибута поверх T::Struct или у вычисляемого атрибута без typelize. Тип нужно объявить явно в ресурсе. 2. no-untyped-resource-dsl: в сгенерированных RBI-сигнатурах DSL ресурсов не должно быть T.untyped. Чинить надо в ресурсе или в компиляторе typelizer.rb, а не в RBI. Но это еще оказалось не все. ast-grep в принципе полезен даже вместо обычного грепа, особенно для самих агентов, которые постоянно ищут какие-то символы в исходниках. У ast-grep есть дока с инструкцией, как подключить его к агенту, чтобы агент начал использовать его вместо grep там где это имеет смысл. ast-grep.github.io/
6
112
13,649
Кто-нибудь уже пользовался Microsoft APM? Это пакетный менеджер для харнеса, через него можно универсально ставить скилы и mcp под все ассистенты с версионированием и другими ништяками microsoft.github.io/apm/
4
23
5,381
Почему нам нужны визионеры. Недавно DHH выступил на Rails World и по полной прошелся по привычному программированию. Сказал, что писать код руками становится экономически бессмысленно, что сам почти перестал писать на Ruby, а часть нового HEY они делают на Rust, который он сам не знает и воспринимает как черный ящик для агентов (но уверен что он тут специально нагнетает). Этим он подорвал столько пердаков, что из космоса было видно зарево. Мой твиттер на неделю превратился в бесконечный срач. На Reddit появились треды в духе "уберите DHH из Rails", Aaron Patterson посвятил значительную часть своего закрывающего доклада ответу DHH. Как вообще создатель Rails может выйти на Rails-конференцию и рассказывать людям, что язык, фреймворк и даже понимание собственного кода скоро могут перестать иметь прежнее значение? DHH самый настоящий визионер, не в смысле что он умеет и хорошо предсказывает будущее, такие люди вообще довольно часто ошибаются. Визионерство это способность увидеть большой сдвиг раньше большинства, построить вокруг него цельную картину будущего и начать действовать так, как будто эта картина уже становится реальностью. Поэтому визионеры почти всегда выглядят слишком радикальными. Когда их идеи становятся очевидными, никакого визионерства уже не требуется, тут уже можно строить планы, выделять деньги, нанимать команду и вперед на галеру. Практически любой большой технологический переход требует от кого-то сделать ставку раньше остальных. Apple много раз отказывалась от вещей, которые рынок считал обязательными. Стив Джобс убирал флопи диски, отказывался от физической клавиатуры в смартфоне, воевал с флешом. Каждое отдельное решение можно было критиковать, но за ними стояла цельная картина того, что ПК должен стать ближе к бытовому устройству, чем к набору технологий. Амазон годами инвестировал в инфраструктуру и рост вместо прибыли. AWS поначалу вообще выглядел почти побочным направлением интернет-магазина. Сегодня идея покупать вычисления как электричество кажется естественной, но кто-то должен был вложить в эту модель миллиарды до того, как она стала естественной. Netflix сам начал уничтожать свой успешный dvd-бизнес ради стриминга. Это особенно важный пример, потому что проблема больших компаний обычно не в том, что они не замечают новые технологии. Они часто прекрасно их видят. Проблема в том, что новое направление угрожает существующему бизнесу, который прямо сейчас приносит деньги. NVIDIA десятилетиями инвестировала в программируемые GPU и CUDA задолго до нынешнего бума генеративного AI. Дженсен Хуанг не мог знать, какой именно вид примет сегодняшний рынок, но у него была достаточно сильная картина будущего вычислений, чтобы продолжать ставить на нее, когда рынок видел прежде всего видеокарты для игр. И обратных примеров тоже полно. Компании редко погибают потому, что вообще не знали о новой технологии. Kodak одной из первых разработала цифровую камеру. Nokia прекрасно видела развитие смартфонов. Большие корпорации обычно располагают огромным количеством исследований, аналитики и талантливых людей. Знать недостаточно. Нужно быть готовым сделать из знания ставку, которая может навредить сегодняшнему успешному бизнесу. В этом и состоит одна из главных особенностей визионеров. Они не просто придумывают новые продукты. Они способны поставить под сомнение то, благодаря чему сами стали успешными. Причем важно не превращать это в культ великих людей. Визионер вполне может завести компанию не туда. Чем сильнее убеждение, тем опаснее ошибка. Стив Джобс ошибался. Безос ошибался. DHH ошибался и еще много раз ошибется. Большинство людей и организаций хорошо умеют оптимизировать существующую реальность. Улучшать продукт на несколько процентов, уменьшать затраты, отвечать на запросы клиентов, следить за конкурентами. Для работающего бизнеса все это критически важно. Но переход из одной реальности в другую почти никогда не получается как результат такой оптимизации. Для него нужен кто-то, кто в какой-то момент скажет: то, что сегодня составляет основу нашего бизнеса, завтра может вообще перестать иметь значение. И начать действовать исходя из этого раньше, чем это станет очевидно всем остальным.
I've had agents implement and optimize the Campfire web app in Elixir, Go, and Rust. Yes, Ruby is the slowest. I didn't care about that when the pay-off was huge in terms of productivity and developer joy. But if you're no longer reading the code? github.com/basecamp/once-cam…
Readers added context they thought people might want to know
The shown benchmarks use non-equivalent implementations: Elixir routes all DB queries through a single GenServer with Redis for jobs (retained from Rails), while Rust uses in-process queues, omits CSRF tags/fields, and applies other caching changes. github.com/basecamp/once-… raw.githubusercontent.com/basecamp/once-… github.com/basecamp/once-… github.com/basecamp/once-… x.com/zachsdaniel1/s…
15
3
1
101
12,578
Сегодня в подкасте про принятие решений в компаниях. Насколько менеджеры понимают что делают и почему от этого страдает разработка: youtu.be/-XAWWoxHfpo?is=gMrf…
1
8
1,972