Джун на фронте | IT Dev Log

Агентские фреймворки больше не нужны Мне стали часто попадаться видео автора Jake Van Clief, который в каждом видео говорит, что LangChain и прочие агентские фреймворки — это пустая трата времени, и что для разработки агента достаточно написать несколько .md-файлов. И я не смог не попасться на такой кликбейт, особенно если учесть, что я уже два года на LangChain разрабатываю. Вдруг я и правда зря время потратил)) Пришлось погрузиться в статью этого автора на arxiv.org, чтобы в этом разобраться. Оказалось, это был не совсем кликбейт. Interpretable Context Methodology Вообще это скорее маркетинговое название подхода, а не термин. А идея подхода состоит в том, что для построения поэтапного пайплайна работы агента достаточно воспользоваться пронумерованными папками, которые и будут являться шагами этого пайплайна. В каждой папке лежит свой промпт, которому агент должен следовать на текущем этапе, и описание контракта на вход и на выход. И какие-нибудь скрипты, которые на этом этапе нужно выполнить. Конечно, лучше всего это работает с Claude или чем-то похожим — для этого подхода нужен агент, способный ходить по папкам и читать .md-файлы с контекстом. Зато, во-первых, читать эти .md-файлы он будет не все сразу, а поэтапно, и только те из них, которые нужны на текущем шаге. Во-вторых, при переходе на каждый последующий этап контекст из нужного файла попадёт в конец контекстного окна, что должно исключать Lost in the Middle. В-третьих, если вдруг вам понадобится поменять шаги пайплайна местами, то достаточно просто переименовать папку с этим этапом. Не придётся заново инженирить обвязку, переносить тулы, менять схемы полей местами и т. д. Неким подобием observability будут служить те же .md-файлы, которые будут создаваться на выходе на каждом этапе. И их же при необходимости можно поправить руками в VS Code перед тем, как агент приступит к следующему этапу и загрузит их в контекст. В чём минусы, или почему агентские фреймворки всё-таки нужны В статье честно говорится, что у подхода есть ряд ограничений: например, ICM последовательный buy design, параллельные вызовы LLM в нем не настроить. В нём нет отказоустойчивости: ни ретраев, ни фоллбэков, только ручной перезапуск. Нет алгоритмических проверок structured_output, нет четкого роутинга, нет многопользовательскости. Энтерпрайз решение на .md-файлах пока что не построишь. Для чего тогда нужен ICM? Лично я использую этот подход как один из способов написания скиллов для Claude и гигакода. Он удобен в случаях, когда от скилла требуется поэтапное выполнение инструкций, когда нужна возможность валидировать и править промежуточные результаты, или если вам важно не подмешивать в LLM лишний контекст раньше времени. В репозитории ICM есть несколько примеров таких скиллов. Я для прикола решил по образу и подобию собрать пайплайн поиска инфы в интернете через гигакод. Ходит теперь, чейньжлоги с гитхаба собирает для меня, статьи с хабра и посты с реддита, агрегирует это всё, а потом собирает дайджест. На LangChain я бы точно поленился это писать))

«Контролируйте идеи, а не код» Сальваторе Санфилиппо (antirez) – создатель Redis, одной из самых популярных баз данных в мире, написал провокационную статью. 20+ лет пишет код руками и славится его качеством. И вот он публично заявляет: проверять код, написанный AI, больше почти не имеет смысла. Мысли на самом деле очень схожие с тем, что переживаю сам: Раньше главным продуктом программиста был код. Теперь AI пишет код быстрее и в таких объёмах, что человек физически не успевает его читать – тысячи строк в день. Рабочий день не резиновый. Поэтому роль разработчика меняется: вместо «писать и вычитывать код» – придумывать, как устроен продукт, какие в нём идеи, куда он развивается, и тщательно тестировать результат. Antirez называет это «контролировать идеи». Это не «вайб-кодинг», когда просто просишь AI «сделай мне приложение» и надеешься на лучшее. Нужно глубоко понимать, что ты строишь, и проверять именно замысел: «объясни, как работает эта часть?» – а не вычитывать каждую строчку. Сам он код для Redis всё ещё проверяет, но честно признаёт: современные модели (упоминает Claude Fable и GPT 5.6) находят больше ошибок, чем он сам. Продолжает по одной причине – из уважения к людям, которые будут открывать эти файлы руками. Вместо ревью он предпочёл бы тратить время на документ с описанием идей: как устроена каждая часть системы, какие в ней хитрости и почему так. Тогда следующий человек (или AI-агент) сможет менять код, понимая замысел Интересный контраргумент критикам AI: софт был полон мусора и ошибок задолго до нейросетей. Он сам находил в популярных инструментах тонкие баги, которые годами никто не замечал. Так что «раньше было качественно» – миф. Единственная оговорка – новички. Им всё равно нужно научиться программировать на практике, иначе не появится то самое понимание, без которого «контролировать идеи» невозможно. Короче, ценность смещается от «умею написать» к «понимаю, что и зачем строю». Это касается не только разработчиков – та же логика скоро доберётся до юристов, аналитиков, маркетологов. Но есть ловушка: отпустить рутину можно, только если экспертиза уже наработана. Остальным надо будет до этого уровня сначала дорасти. https://antirez.com/news/169

🔧 Вайбтокарь, блеать!

Как я ИП открывал 👨‍💻 Вот уже два месяца я работаю над проектом: мы вайбкодим CMS для музыкального лейбла. За всю работу мне обещали 600к. Срок с мая по сентябрь. Но как получать эти деньги легально? CЗ несёт риски. Если оформить ГПХ с ООО, ФНС может это завернуть в трудовые отношения. Зачем им такие проблемы? 😮 Согласившись с доводами бухгалтера я пошёл смотреть другие аббревиатуры на рынке. Их оказалось шесть (не семь): ОСНО, УСН, АУСН, ПСН, ЕСХН и НПД. Самым простым казалась ПСН (патент). Платишь фикс за возможный доход в IT. В моём регионе он стоит 60к. Плюс ещё 57к страховых взносов, из них 46к идут на пенсию. 🤨 Все пересчитав я расстроился: первый месяц придётся работать в минус. Пошёл дальше копать. И не зря. Самой выгодной оказалась АУСН. Она похожа на СЗ. Там не нужно платить огромные суммы или покупать что то. Просто платишь 8% с поступивших денег. Налоги приходят пушем в лк банка. 🤑 Дальше в ФНС за крипто-флешкой, суем её в Диадок и подписываем акты. Заказчик присылает их сам. Там расписанно сколько кнопок я покрасил, микросервисов развернул и миграций в БД накатил. В итоге открыл ИП на АУСН c ОКВЭД 62.01. Уже получил первый платёж за код. О самих процессах, команде и коммитах в три звена под Data-Driven UI расскажу позже. 📊 #статистика в IT 1691д | 5475ч

Anthropic изучили 400к сессий Claude Code Пользователи УЖЕ одобряют 93% всех запросов на действия. Human формально in-the-loop, но на деле уже выключен и просто жмёт «Approve». Ещё интересный факт: разница в успешных результатах между разработчиками и менеджерами оказалась не велика 34% против 29%. Это не значит, что экспертиза больше не нужна. Наоборот. Просто она теперь работает по-другому. Раньше эксперт ценился за то, что сам мог написать сложный код. Теперь за то, что формулирует задачу, задаёт рамки и контекст, вовремя замечает ошибки. Человеческое чутьё на уровне задачи, а не на уровне кода, сейчас даёт главный прирост. Сильнее выигрывают те, кто умеет превращать свои знания предметной области в инструкции и критерии качества. Они тратят время на планирование, а не на исправление кривого кода в конце. 📊 #статистика в IT 1689д | 5455ч

Как должен быть устроен мир без работы? Энди Спенс у себя в сабстеке опубликовал весьма интересный текст. В котором классно описывает и проблему, и область решений — что будет после схлопывания традиционных форматов занятости. Три ключевых факта, которые, вероятно, лучше всего иллюстрируют как меняется рынок труда: • Большая часть работы в мире выполняется вне стабильной формальной занятости. Из примерно 3.4 миллиарда человек, около 2 миллиардов работают в неформальной экономике, часто без контрактов, льгот и правовых гарантий. • Объём мировой экономики фриланса в 2024 году оценивался в 557 миллиардов долларов и, по прогнозам, утроится к 2032 году. Около 14,5% работников в ЕС являются самозанятыми. В Китае насчитывается около 200 миллионов «flexible workers». Некоторые люди вынуждены работать таким образом. • В UK почти семь из десяти трудоспособных взрослых, живущих за чертой бедности, проживают в семьях, где хотя бы один взрослый работает. Для большинства людей в мире наличие постоянной работы сейчас не гарантирует никакой реальной экономической безопасности. Главный экзистенциальный риск в том, что стабильная работа — это комплексный социальный феномен, куда входит распределение статуса, идентичности, жизненных целей, социальной организованности и согласованности, льгот, пенсий, безопасности, доступа к обучению, принадлежности к сообществам, и тд. Что делать, когда это распределение перестанет работать: 1. Финансовая безопасность Доходы и социальные гарантии должны стать «portable» и не зависеть от одного конкретного работодателя. Нужно найти способы сглаживать финансовые потери при переходах между проектами. 2. Доступ к интеллектуальным ресурсам и обучению Образование не может быть разовым событием. Энди Спенс приводит в пример Сингапур, где граждане получают государственные кредиты (от SkillsFuture) на обучение в течение всей жизни. 3. Распределение социального статуса В мире фриланса и проектной работы нам нужны новые эффективные способы подтверждения заслуг и экспертизы: цифровые портфолио, системы репутации, участие в сообществах, даже если за это не платят самую большую зарплату в самых красивых офисах. 4. Сообщества Постоянная формальная работа создавала тесные связи и ощущение принадлежности. Но теперь нам нужны новые формы объединений: профессиональные гильдии, локальные коворкинг-хабы и социальные сети. 5. Накопление капитала Необходима новая модель распределения богатства и доходов. Особенно в контексте вопроса, а кому достанутся все эти прибыли от AI: сотрудникам компаний, всем гражданам, фондам, государству или только акционерам. Перевод и аудио-саммари в комментариях. → https://wrk3.substack.com/p/what-comes-after-the-job

Продолжаю тему эволюции разрабов Нашёл разбор поста Бориса Черни (создателя Claude Code). Он рассказывает, как сейчас выглядят роли в его команде и куда всё идёт. По его словам, инженер, PM, дизайнер и дата-сайентист сливаются в одну роль. Теперь все они — просто люди, которые управляют одними и теми же AI-агентами. Функции вроде «я пишу код» или «я рисую макеты» больше не разделяют людей. В Anthropic у всех один тайтл — Member of Technical Staff. Там PM пишет код, дизайнер пишет код, даже финансист пишет код. Когда такие различия стёрлись, что остаётся? Только фаза жизненного цикла продукта, в которой человеку комфортнее всего работать. Отсюда пять архетипов: 1️⃣ Prototyper — генерит идеи и прототипы. Мало доживает до прода. 2️⃣ Builder — превращает прототип в настоящий продукт. 3️⃣ Sweeper — упрощает интерфейс и код, убирает лишнее, оптимизирует. 4️⃣ Grower — дорабатывает готовый продукт до product-market fit. 5️⃣ Maintainer — поддерживает зрелую систему: делает её безопасной, надёжной и быстрой на большом масштабе. Видно, что чистый фронтендер превращается в узкую специализацию. Ценность уходит от конкретных навыков (React, CSS) к хорошему суждению: что стоит строить, что выкинуть и когда прототип уже готов стать продуктом. Этакий новый барьер для входа в IT, который джунам предстоит преодолеть после синтаксиса. 📊 #статистика в IT 1685д | 5435ч

Сейчас многие переживают, что если остаться в разработке, то через некоторое время можно остаться совсем без работы, поэтому рассматривают два варианта. Первый: сидеть в инженерии, но уже не как программист, а как человек, который использует ИИ как инструмент. Второй: двинуться в сторону от программирования. Сейчас очень популярна идея массово переходить в аналитику. Потому что "не надо так много кодить", "там проще", "можно быстро вкатиться". Между тем, аналитика - это область в которой ясности еще меньше, чем в разработке. На входе гора данных, половина из которых - мусор, который никак не влияет на результат. По этим данным бизнес ожидает конкретный ответ на свои вопросы (желательно еще вчера), а не абстрактное "наверное сезонность". Нужно иметь профессиональную интуицию и аналитический склад ума, чтобы генерировать качественные гипотезы, искать закономерности, находить решение для поставленных задач. И если ты ошибся - ответственность на тебе, тут не получится выехать на "программирование - это сложно, баги неизбежны". В конечном итоге хороший аналитик - это точно такая же редкость, как хороший инженер, а плохие аналитики никому не нужны. Так что не надо бежать туда, потому что "а куда еще?". Легче не станет. Просто сложность будет другой. Если нет любви именно к анализу данных, то разбираться в сомнительных данных, выяснять, почему одна цифра не бьется с другой, и объяснять менеджерам, что два плюс два не всегда четыре - это прямой путь к выгоранию. На мой взгляд куда лучше остаться в разработке и сместиться в архитектуру. Это понятный и рабочий вариант, который является логичным продолжением развития для разработчика.

Не успел мой ахуй отойти от 3000 токенов в секунду по API Cerebras, как из-за угла выскочил новый стартап Taalas. Пока одни делают огромные чипы под разные модели, Taalas физически впаивают веса прямо в схему чипа. Модель буквально «отлита в кремний», как ПЗУ. Их подход называется Hardwired AI. Модель больше не исполняется как софт во время работы, а встроена прямо в транзисторы ещё на этапе производства. Похожим путём когда-то пошла крипта: для майнинга начали делать ASIC. Это чипы, которые умеют только хешировать SHA-256 быстрее и дешевле любого GPU. Вот первая демонстрация скорости инференса от Taalas: chatjimmy.ai. Увы, но весь API раскупили. Под капотом Meta Llama 3.1 8B со скоростью 16 000 t/s. Она конечно не сравнится с Claude или GPT с их 80 t/s, но давайте подождем ещё пару лет и посмотрим, что ещё получится скукожить в железо. 📊 #статистика в IT 1681д | 5403ч

Знания Принцип простой: надо делиться знаниями и приемами. Все люди, которые зажимают знания, не делятся открытиями, прячут профессиональные секреты - все они проигрывают. Если не прямо сразу, то через пару лет. Информация - это единственный ресурс, которого не становится меньше, когда им делишься. Это надо помнить всегда. Важны не сама информация, не идея, не знание - важны умения все это вовремя и по делу применить.