Прощай vibe coding. Здравствуй deep crafting

Андрей Бадин, основатель Product Lab, придумал название для подхода к работе с ИИ, которым занимался уже давно.

Он назвал его дипкрафтингом (deep crafting).

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

Андрей Бадин тоже экспериментировал с вайбкодингом, но понял, что его интересует другое.

Сначала он называл этот подход vibe creation, или вайб-творчеством, но название не прижилось.

Вайбкодинг, по определению Андрея Карпатого — это способ программирования, где человек может отдать часть работы ИИ и не разбираться в каждой детали. Для небольших проектов и быстрых экспериментов такой подход работает.

Но дипкрафтинг устроен иначе.

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

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

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

Само слово собрано из двух частей, и каждая отвечает за свою половину процесса. Deep – это про то, как глубоко ты разбираешь предмет, до самых его оснований. Craft – это про то, как ты собираешь его обратно, и здесь важно, что речь идет о ручной работе, а не о сборке из готовых блоков: ты снимаешь все лишнее до тех пор, пока не останется только то, что держит форму. По-русски все вместе и получается глубокое создание. За время практики схема сложилась в четыре режима.

Впервые я столкнулся с Лабораторией нейронаук и поведения человека буквально на этой неделе, прочитав статью на Хабре «ИИ может менять мнение человека. Мы проверили это на моральных дилеммах». Учитывая авторитет Сбера как разработчика лучшего в России ИИ, я отнесся к статье достаточно серьезно. Тем удивительнее было для меня то, что авторы (коллектив сотрудников Лаборатории нейронаук) отнеслись к своей статье менее серьезно.

Ошибки, которые я оптимистично классифицировал как опечатки, и крайне спорная интерпретация собственных экспериментов — всё это заставило меня попытаться проанализировать, что это за Лаборатория и какие цели она перед собой ставит.

В июле 2025 coding-агент в Replit проигнорировал явный запрет на изменения файлов (code-freeze) и удалил production-базу – данные примерно 1200 компаний, позже заявив, что «сделал катастрофическую ошибку». Operator от OpenAI, которого попросили всего лишь найти дешевые яйца, сам купил их на Instacart на $31.43 – в обход собственного подтверждения покупки. Официальный чатбот мэрии Нью-Йорка советовал предпринимателям нарушать закон: говорил, что можно забирать чаевые работников и отказывать арендаторам с жилищными ваучерами Section 8. Эти и другие инциденты сведены в обзоре «Towards a Science of AI Agent Reliability», где каждый разделен по характеру сбоя: тяжесть вреда, нарушение полномочий, плохая калибровка.

Ни один из этих случаев не всплыл бы в обычном демо. И ни один бенчмарк про них заранее бы не предупредил.

Публичные бенчмарки полезны – по ним видно, какая модель в целом сильнее и куда движется фронтир. Но они отвечают на другой вопрос. Высокий балл на лидерборде не говорит, справляется ли система с вашими задачами: для этого нужны собственные evals и бенчмарки под конкретные задачи. А часть аспектов – безопасность, устойчивость к злоупотреблениям, поведение под атакой – бенчмарком в принципе не измерить; в этих случаях работает red-teaming. Современная AI-система – это модель в симбиозе с retrieval, tools, memory, routing, prompts, state, permissions. Вы ответственны за всю систему и хотите понимать, как хорошо работает именно она, в то время как публичный бенчмарк измеряет только модель.

В одной из сессий Claude написал у меня 47 файлов. 1 892 строки. Два новых сценария, рефакторинг шести обработчиков, миграция конфига. 38 минут.

Каждый коммит — автоматический CPG-анализ. Каждый промпт — обогащение контекстом из графа. Каждый пул-реквест — радиус поражения и оценка риска.

Не потому что я не доверяю ИИ. А потому что я не доверяю никакому генератору кода без автоматической верификации. Включая себя.

Я довольно быстро понял, что проблема не в модели. Проблема в отсутствии конвейера верификации. Линтеры ловят синтаксис. Тесты ловят поведение. Но никто не ловит структурную деградацию — рост цикломатической сложности, расширение радиуса поражения, дрейф числовых утверждений в документации.

На сцене Conversations в этот раз собрались эксперты из SberAI, Авито, Т-Банка и Raft, чтобы вместе с Just AI обсудить автономных агентов с суперпамятью, вызовы vibe-coding и новую эру кибербезопасности. Вашему вниманию — расшифровка интереснейшей дискуссии!

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

В чём-то сочинение стихов похоже на написание кода — имеет значение только "чистый" текст — и этот текст, как и код, подчиняется определенным правилам. Поэту могли бы пригодиться те самые "автоподсказки" и подсветка кода стихов. Может, даже с какой-то поддержкой рефакторинга, помочь поэту найти слабое место. Но найти что-то подобное (особенно на русском языке) у меня не вышло. Например, на запрос poetry editor в основном выпадают сервисы по найму редакторов-людей. Проекты, конечно, есть, но они либо слабые, либо мёртвые (поправьте меня, если я неправ).

Значит, задумал я на коленках склепать IDE для поэтов…

Привет! Я Иван Антипин, заместитель директора департамента разработки в AGIMA. За свою карьеру я поработал с десятками команд. Где-то был разработчиком, где-то тимлидом, где-то помогал извне. У меня был миллион возможностей разобраться, как люди ведут себя в коллективе. Но всё же не на все вопросы существуют четкие ответы: что такое команда, как она работает, как ей управлять. В этой статье я попробую описать те методы и подходы, которые лично мне кажутся полезными и правильными.

Простой способ, на который решится каждый. 

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

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

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

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

Меня часто просят рассказать о работе с legacy-монолитами. Про микросервисную архитектуру и переход на нее говорят много, но редко упоминают о том, что проекты приходят ней после многих лет роста с монолитным приложением. Учебники по решению проблем не пишут. Чтобы поменять архитектуру живого решения, надо пройти через несколько этапов. Автор работал с разными проектами - и с полноценным multitenancy service-oriented REST architecture, и с огромным монолитом, в репозитории которого были коммиты за десять лет. Эта статья - о темной стороне, о legacy-коде, и практических решениях проблем с монолитным кодом на PHP.

Интернет наводнен статьями о том, как похудеть "просто съедая меньше чем потратил" и отчетами об успешном опыте некоторых везунчиков. Чего нету (ну или очень мало) в интернете — это отчетов о том, как миллионы людей безрезультатно пытаются просто "съесть меньше", садясь на все новомодные диеты и неизменно возвращаясь к тому, с чего начинали, а иногда и скатываясь по шкале индекса массы тела в еще более красную зону.

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

Расшифровка доклада 2015 года Алексея Лесовского "Deep dive into PostgreSQL internal statistics"

Disclaimer от автора доклада: Замечу что доклад этот датирован ноябрем 2015 года — прошло больше 4 лет и прошло много времени. Рассматриваемая в докладе версия 9.4 уже не поддерживается. За прошедшие 4 года вышло 5 новых релизов в которых появилась масса новшеств, улучшений и изменений относительно статистики и часть материала устарела и не актуальна. По мере ревью я постарался отметить эти места чтобы не вводить тебя читатель в заблуждения. Переписывать же эти места я не стал, их очень много и получится в итоге совсем другой доклад.

СУБД PostgreSQL — это огромный механизм, при этом состоит этот механизм из множества подсистем, от слаженной работы которых напрямую зависит производительность СУБД. В процессе эксплуатации обеспечивается сбор статистики и информации о работе компонентов, что позволяет оценить эффективность PostgreSQL и принять меры для повышения производительности. Однако, этой информации очень много и представлена она в достаточно упрощенном виде. Обработка этой информации и ее интерпретация порой совсем нетривиальная задача, а "зоопарк" инструментов и утилит запросто поставит в тупик даже продвинутого DBA.