Планирование, отслеживание и контроль
Представлен открытый проект FacePlugin (Open Source Face Recognition SDK). который позволяет создать собственный Face ID и ставить систему распознавания лиц в своих проектах и приложениях:
можете создать пропуск в приложение, для умного дома или Face ID для ПК;
сервис будет находить лицо по фото или через камеру в режиме реального времени;
система работает локально.
В ИИ сейчас все джуны
ИИ уже меняет профессии, и реагируют на это по-разному. Одни боятся, что ИИ их заменит и обесценит знания, на которые ушли годы. Другие видят огромные возможности, но не уверены, что завтра ИИ не заберёт и их.
Каким будет будущее, не знает никто. Но направление уже видно. Искусственный интеллект — это инструмент, и выигрывает тот, кто умеет им пользоваться.
Специалистов с многолетним опытом работы с ИИ пока нет, технология молодая. Но кто-то начал раньше, разобрался в принципах и уже умеет применять ИИ по-настоящему эффективно. Представьте пешего курьера без навигатора, которому дали самокат 🛴 и навигатор 🗺️. Ими тоже надо научиться пользоваться. Но усилий на это нужно немного, а преимущество огромное.
Пользуюсь LLM с выхода ChatGPT и выработал процесс, который на подписке за $20 позволяет совмещать сложные инженерные проекты, участвовать в хакатонах и делать пет-проекты.
А какой основной воркфлоу с ИИ-агентами у вас? Вы даёте агенту задачу целиком и проверяете результат? Сначала составляете с ним план, потом просите сразу все реализовать? Доверяете только точечные правки? Или вообще не пускаете агента в свой код?
Уже в этот понедельник, 26 октября в 14:00 мск проведём онлайн-подкаст с Димой Шестерниным, CTO Флаувау. Поговорим о том, как компания внедряет ИИ в рабочие процессы, как сотрудники без технического образования создают приложения и какие изменения ИИ приносит на рынок маркетплейсов.
Разберём две стороны внедрения: что меняется для покупателей и как перестраивается работа внутри компании.
В программе:
как ИИ меняет путь пользователя от поиска товара до покупки;
становится ли ИИ конкурентом маркетплейсов или открывает новые каналы продаж;
как выстроить зрелую ИИ-инфраструктуру;
как дать нетехническим специалистам возможность создавать приложения;
как меняются роли тимлидов, CTO и менеджеров.
Ведущие — Сергей Кожемякин, исполнительный директор AGIMA, и Андрей Непряхин, CTO AGIMA.
В прямом эфире можно будет задать вопросы гостю и ведущим.
Когда: 26 октября 2026 года, 14:00–15:00 мск. Где: онлайн, на странице подкаста.
Представлен открытый браузерный движок Lightpanda 1.0, написанный на Zig с нуля. Решение предназначено для использования в задачах браузерной автоматизации в интеграции с Puppeteer, Playwright, Selenium, ChromeDP и ПО, поддерживающим Chrome DevTools Protocol (CDP). Компания-разработчик проекта поддерживает список интеграций Lightpanda в стиле awesome.
Lightpanda не занимается отрисовкой контента веб-страниц. Решение только выполняет веб-запросы (в том числе поддерживаются куки, CORS), строит DOM-дерево и выполняет Javascript через движок v8. Благодаря этому удалось добиться значительного сокращения потребляемых ресурсов: выполнение тестовых сценариев в 9 раз быстрее при в 16 раз меньшем потреблении памяти по сравнению с Chromium (ссылка на репозиторий разработчиков с техническими деталями бенчмарков).
ИИ-поезд мчится дальше. И, кажется, мы начинаем иначе смотреть на сам процесс разработки.
Доверие к генерируемому коду растёт. И вместе с ним на первый план постепенно выходит намерение, а не сам код.
На этот пост меня натолкнула недавняя статья инженеров Anthropic. За четыре месяца количество изменений, вливаемых в основную ветку, выросло с 2 500 до 30 000 в день. Им даже пришлось переизобрести Git. Но особенно меня зацепила другая мысль: теперь на ревью они оценивают прежде всего смысл изменений, а не каждую строчку кода.
И я поймал себя на том же.
В моих чатах с агентами всё чаще звучат вопросы: "Почему ты выбрал именно такой подход? Какие были альтернативы? Что мы потеряем, если сделаем иначе?". Мне постепенно становится менее интересно, как именно написана конкретная ручка. Гораздо важнее понять, почему она устроена именно так и насколько обоснованно это решение.
При этом я замечаю, что всё чаще доверяю ИИ не только написание кода, но и отдельные архитектурные решения. Это позволяет буквально на ходу жонглировать реализациями, пробовать разные подходы и выбирать наиболее подходящий. И вот когда появляется такое базовое доверие, меняется сама единица контроля. Мы всё меньше управляем отдельными строчками и всё больше архитектурными решениями, ограничениями и результатами.
Конечно, это не отменяет тестирования, ревью и личной ответственности. Доверяй, но проверяй, как говорится. Хотя проверка ИИ-кода - это вообще отдельный мир, о котором мы ещё поговорим.
Начал меняться сам характер работы с ИИ. Это куда более фундаментальная перемена, чем очередной прирост качества генерации.
Разработчик XScreenSaver (стандартного набора экранных заставок, который поставляется с большинством систем Linux и Unix, использующих графическую систему X11; первая версия этого продукта вышла еще в 1992 году) сообщил и напомнил, что официального репозитория XScreenSaver на GitHub не существует.
«Я — jwz, автор XScreenSaver, и я не веду публичный репозиторий с исходным кодом. Я публикую релизы в виде tar‑архивов на официальном веб‑сайте — и только там. Если вы встретите какой‑либо другой репозиторий XScreenSaver (на GitHub или где‑либо еще), знайте: он не имеет ко мне никакого отношения, и доверять ему не стоит. Я принимаю предложения и запросы на внесение изменений по электронной почте. Это вполне нормальный подход. Переживёте», — пояснил разработчик проекта.
В открытом доступе опубликован исходный код низкоуровневого фреймоворка BRUTAL, написанного на языке C#. Решение предоставляет прямой доступ к нативным API и Vulkan. Фреймворк сфокусирован на максимальной производительности, работе с неуправляемой памятью и разработан специально для симуляторов со сложной архитектурой.
Это решение является основой для движка Waylith в популярной игре RimWorld от Ludeon, на замену Unity. Кроме того проект BRUTAL использовался в разработке игры Kitten Space Agency (KSA) - наследнике легендарной Kerbal Space Program.
Проект выложен на GitHub под собственной лицензией.
Представлен монорепозиторий everything со списком из более чем 50 бесплатных открытых приложений (офисные программы, совместная работа, инструменты для творчества, инженерное ПО, продуктивность, финансы, бизнес, инструменты для разработчиков, игры), созданных с помощью ИИ или без нейросетей, которые заменяют многие популярные и платные проекты. Для работы онлайн требуется Node.js версии 22.12 или новее.
«Проект „Everything“ (The Everything Project) — это инициатива по воссозданию программного обеспечения, используемого в мире, в формате открытого исходного кода. Мы разрабатываем бесплатные аналоги с открытым кодом для самых разных проприетарных программ — от пакетов офисных приложений и мессенджеров (вроде Slack) до графических редакторов (Photoshop) и систем автоматизированного проектирования (AutoCAD). Данный репозиторий является монорепозиторием, в котором собраны все приложения и инструменты, созданные в рамках этого проекта», — пояснили автора репозитория.
Офисное ПО:
Spreadsheet - Microsoft Excel, Google Sheets, Apple Numbers
Documents - Microsoft Word, Google Docs, Apple Pages
Presentation - Microsoft PowerPoint, Google Slides, Apple Keynote
Whiteboard - Miro, Microsoft Whiteboard, FigJam
PDF - Adobe Acrobat, PDF Expert
Notes - Microsoft OneNote, Evernote, Apple Notes
Records - Airtable, Microsoft Access, Baserow
Совместная работа:
Meetings - Zoom, Google Meet, Microsoft Teams
Teamchat - Slack, Microsoft Teams, Google Chat
Email - Gmail, Microsoft Outlook, Apple Mail
Contacts - Google Contacts, Apple Contacts
Calendar - Google Calendar, Apple Calendar, Outlook Calendar
Signatures - DocuSign, Adobe Acrobat Sign, Dropbox Sign
Инструменты для творчества:
Photo Studio - Adobe Photoshop, Pixelmator
Video Studio - CapCut, Adobe Premiere Pro, Final Cut Pro, DaVinci Resolve
Vector Studio - Adobe Illustrator, CorelDRAW, Affinity Designer
Audio Studio - Adobe Audition, Sound Forge
Music Studio - FL Studio, Ableton Live, Logic Pro
3D Studio - Autodesk Maya, SketchUp
Инженерное ПО:
CAD - AutoCAD, DraftSight, BricsCAD
Parametric - SolidWorks, Autodesk Fusion, Autodesk Inventor
Circuits - Altium Designer, Autodesk Eagle, OrCAD
Building Design - Autodesk Revit, ArchiCAD, Vectorworks
Продуктивность:
Tasks - Todoist, Microsoft To Do, TickTick
Projects - Trello, Asana, monday.com
Wiki - Notion, Confluence, Coda
Time Tracking - Toggl Track, Harvest, Clockify
Surveys - SurveyMonkey, Google Forms, Typeform
Финансы:
Accounting - QuickBooks Online, Xero, Wave Accounting
Invoicing - FreshBooks, Zoho Invoice, Wave Invoicing
Expenses - Expensify, SAP Concur, Zoho Expense
Cap Table - Carta, Pulley
Бизнес:
CRM - Salesforce, HubSpot CRM, Pipedrive
Help Desk - Zendesk, Freshdesk, Intercom, Help Scout
Contracts - ContractSafe, Juro
Point of Sale - Square POS, Shopify POS, Lightspeed
Inventory - Zoho Inventory, Sortly, inFlow Inventory
Assets - Asset Panda, EZOfficeInventory
Hiring - Greenhouse, Lever, Workable
Shifts - Deputy, When I Work, Homebase
Childcare - brightwheel, Procare, HiMama
Field Service - Jobber, Housecall Pro, ServiceTitan
Legal - Clio, MyCase, PracticePanther
Fleet - Fleetio, Samsara Fleet Maintenance, Whip Around
Property Management - Buildium, AppFolio, Rent Manager
Инструменты для разработчиков:
API Client - Postman, Insomnia, Hoppscotch
Как кастомное правило SAST остановило security pipeline и усложнило выход релизов
Ситуация: в компании есть отдел DevSecOps и отдел AppSec. За работу security pipeline отвечает DevSecOps. Но, кастомные правила для SAST (используется в security pipeline) могут создавать оба отдела.
Однажды руководитель AppSec случайно увидел в доступных сетях Wi-Fi точку с провокационно-политическим названием. При чём тут SAST? А при том, что это привело его к мысли: "а вдруг в код кто-то добавит такие же лозунги? Нужно сделать кастомное правило на SAST!" Сказано-сделано. Руководитель центра на планёрке идею поддержал: "он действует проактивно, чего я ожидаю и от других".
Не прошло и дня как security pipeline перестал работать. Сначала работа security pipeline стала занимать уйму времени. Потом хорошенько так забилась база ASOC. Причиной стало кастомное правило SAST. Какое именно "нехорошее" слово вкладывалось в логику правила сейчас станет ясно. Правило реагировало на putIn (чаще всего это было на название функции). И таких сработок было - тысячи. Я не знаю всех подробностей работы security pipeline. Но, знаю: он не работал в блокирующем режиме (есть история когда при блокирующем режиме вообще останавливалась разработка и бизнес терял деньги). При этом он перестал завершаться успешно (со слов отдела DevSecOps). Т.е. по сути для проектов не было готового отчёта безопасности, создаваемого на основе работы security pipeline. Поэтому мы не могли согласовать такие проекты для размещения в продакшене. В итоге правило пришлось удалить, а базу ASOC - чистить. Ну, а создатель того правила - до сих пор эталон проактивности.
P.S. Оба действующих лица (руководитель AppSec и руководитель центра) - это те же лица, которых я указывал в статье А ты точно работал 2 месяца назад в этот день? А чем докажешь?
Даже опытные и закоренелые разработчики подсели на вайбкодинг
Забавно, что ещё пару лет назад опытный корпоративный разработчик, пишущий на C#, Java или C++ не думал, что будет объяснять нейросети, какой код ему нужен и какой итог он хочет видеть. От себя скажу, мало кто ожидал, что нейросети станут частью повседневной разработки. Причём экспериментируют с ними не только новички, но и специалисты, хорошо понимающие, как устроены сложные корпоративные системы. Но зачем?
Для начала стоит разделить два подхода, которые сегодня часто называют одним, уже надоевшим словом, вайбкодинг:
Когда человек формулирует запрос, получает работающую программу и практически не пытается разобраться, что находится внутри. Пока всё работает, вопросов нет. Если появляются ошибки - отправляет их обратно нейросети и надеется на исправление. Узнали кого-то среди своих знакомых? :)
Осознанное использование ИИ опытным разработчиком, который понимает архитектуру, ограничения и требования к качеству. Строго говоря, это уже не вайбкодинг в первоначальном понимании, а AI-assisted development. И вот такой подход все чаще начинает встречаться в зрелых ИТ-компаниях сегодня.
Например, заказчик приходит с идеей, но сам пока толком не понимает, чего хочет. Раньше на прототип могли уйти дни, а то и недели. Теперь с помощью ИИ можно довольно быстро собрать интерфейс, накидать базовую логику, прогнать несколько сценариев и показать заказчику хоть что-то работающее. Заодно сгенерировать тесты, поискать ошибки и попробовать их исправить. И всё это без необходимости сразу разворачивать полноценную разработку. По-моему, отличный способ проверить идею до того, как в неё закопают бюджет. Сколько у вас на это уйдет? Один вечер и банка чего-нибудь хмельного?
Но если нейросеть собрала работающий прототип, ещё не значит, что это можно выкатывать в прод. Особенно если речь о корпоративных системах, тем более уровня Enterprise, где за красивой кнопкой могут скрываться десятки интеграций и требований к безопасности. ИИ вполне способен написать код, который отлично работает на демо, а потом превращает сопровождение в отдельный вид экстремального спорта.
Поэтому после проверки гипотезы всё равно придётся подключать инженерную голову: разбираться с архитектурой, тестировать, проверять безопасность, а иногда и переписывать всё с нуля. Поэтому быстро проверить гипотезу, найти слабые места, показать результат заказчику - отличный сценарий. А вот доверять нейросети ответственность за конечный продукт я бы пока не спешил.
Есть ли у SRE продукты? Разбираем с руководителем Developer Experience Авито
В гостях у подкаста «В SREду на кухне» Артём Арюткин, руководитель направления Developer Experience в Авито. Разбираемся, как продуктовый подход меняет работу инженерных команд и платформ.
Начнём с главного: в какой момент инженерный инструмент превращается в продукт и зачем платформенным командам продуктовое мышление?
Еще обсудили, как измерять adoption, зачем каждому инженерному продукту нужны контрметрики и как не потерять баланс между надёжностью и удобством. А в финале отвечаем на краеугольный вопрос: что важнее, надёжность или Developer Experience?
Этот выпуск будет полезен всем, кто создаёт внутренние инструменты, исследует потребности инженеров или если вы просто хотите понять, как продуктовый подход работает за пределами классического продакт-менеджмента.
Смотрите и слушайте на площадках:
🔵 VK Видео
📺 YouTube
📌 RuTube
Ⓜ️ Mave
Представлен открытый аналог AutoCAD - проект CADCraft, который работает на ПК с macOS, Windows, Linux, FreeBSD и даже в браузере через WebAssembly. Возможности решения:
инструментарий для 3D-принтеров, планировок квартиры и любых чертежей.
можно подключить ИИ. Агенты станут инженерами и начнут проверять чертежи и писать их сами.
Весь функционал как в AutoCAD — чертежи, привязки, слои, штриховки, командная строка.
Проект только вышел, но внутри уже есть русский интерфейс.
Представлен открытй учебный курс Claude Code: Everything You Need to Know по ИИ‑помощнику Claude Code:
в проекте есть основные темы от базы, написания промптов и работы с Git до создания обвязок, запуска субагентов, кодинга кастомных скиллов и плагинов.
рассказывается об оркестрации сотнями агентов.
весь курс снабжён практическими задачами и лабораторными тестами с проверкой.
авторы постоянно обновляют материал ресурса.
Дешёвая модель в агентном стеке имеет неприятный режим отказа: на сложных многошаговых задачах она тихо отвечает из контекста беседы вместо реального вызова инструментов. Не падает с ошибкой, не жалуется на лимиты, а просто симулирует знание.
Мы внутри агентства гоняем собственного агента поверх боевой CRM. У него около 40 кастомных инструментов: чтение таблиц, выборка лидов, проверка оплат, парсинг логов активности. Когда выбирали постоянную модель под рутинные запросы команды, я устроил прямое A/B-сравнение трёх вариантов на базе DeepSeek: v4-pro, v4-flash:hight и reasoning-версии.
На простых запросах разницы не было никакой. Задачу вроде «посчитай количество входящих лидов и сумму оплат за прошлую неделю» все три модели решили как под копирку: вызвали нужный тулз, забрали данные, отдали абсолютно одинаковые цифры. На таких операциях flash-модель кажется идеальной: отвечает мгновенно, стоит копейки.
Разница вскрылась на цепочке шагов. Задача: обойти несколько клиентских проектов, по каждому поднять ленту действий менеджеров, проверить незакрытые задачи и свести общий статус.
Старшие модели (pro и reasoner) честно пошли по цепочке: запросили список проектов, циклом собрали задачи, сверили логи и сошлись на одном результате. А вот flash-модель в базу вообще не пошла. Она просто взяла контекст из обсуждения в чате получасовой давности и выдала ответ в духе «я уже отвечал на этот вопрос выше, вот сводка».
Внешне ответ выглядел убедительно: ровный текст, знакомые фамилии, аккуратные списки. Если не смотреть лог вызова функций (tool calls trace), никогда не поймёшь, что модель схалтурила. Но за полчаса в базе сменились статусы двух сделок и добавился десяток комментариев. В итоге агент выдал устаревшие данные с железобетонной уверенностью.
При этом у старших моделей вылезла своя проблема. Reasoning-модель на первой попытке банально улетела в таймаут API: пока она размышляла над логикой выборки и последовательно дёргала методы, соединение разорвалось. Пришлось поднимать таймаут ожидания до двух минут. Дорогая модель умнее, но требует совсем других сетевых настроек.
Для себя я вынес простое правило: дешёвые flash-модели отлично справляются с одиночными операциями, где есть ровно один понятный вызов функции. Но если в промпте заложена цепочка из нескольких шагов с зависимостями, доверять им нельзя. Либо сразу пускать задачу через старшую модель с увеличенным таймаутом, либо на уровне бэкенда проверять трейс и отбрасывать ответ, если модель не сделала обязательные вызовы API.
Когда «надо управлять» уже недостаточно: 4 задачи, которые требуют системы
Запустить новую инициативу, перестроить процесс, договориться со стейкхолдерами, выбрать метрики, оценить риски — чем выше уровень ответственности, тем больше решений приходится принимать одновременно.
И здесь опыта и интуиции уже мало. Нужна система: понимать, где искать точку влияния, на какие данные опираться, что автоматизировать и как оценивать результат.
Собрали бесплатные открытые уроки для тех, кто управляет продуктами, процессами, командами и технологическими направлениями.
1. Запускать продукты и оценивать их результат
8 октября, 20:00. «Как запустить ИИ‑продукт: от бизнес‑гипотезы до первых измеримых результатов». Записаться
12 октября, 20:00. «Сколько стоит один ответ вашего AI‑агента — и почему он думал 40 секунд?». Записаться
21 октября, 20:00. «Как посчитать ценность ИИ: метрики и ROI, которые нужны менеджеру». Записаться
2. Выстраивать процессы и автоматизировать работу
12 октября, 20:00. «Промпты без случайного результата: как проектировать устойчивые сценарии работы с LLM». Записаться
14 октября, 20:00. «ИИ‑агент как супероружие системного аналитика: составляем ТЗ за 10 минут». Записаться
19 октября, 20:00. «Как наладить процессы без вложений: никаких бюджетов, систем и выделенных команд». Записаться
3. Принимать решения на основе данных, целей и рисков
13 октября, 20:00. «Технологии и принципы построения DQaaS (Data Quality as a Service) в современных системах управления данными». Записаться
14 октября, 20:00. «Математика на службе у CISO: как принимать решения на основе данных». Записаться
15 октября, 20:00. «Цели и метрики как одно целое». Записаться
15 октября, 20:00. «ИИ в управлении рисками: предиктивная аналитика для тестировщика». Записаться
4. Управлять ролью, командой и взаимодействием
19 октября, 19:00. «CIO в эпоху ИИ». Записаться
19 октября, 20:00. «Как понять, что вы уже выполняете роль COO — даже если должность называется иначе». Записаться
20 октября, 19:00. «Стабильность команды и взаимозаменяемость людей». Записаться
21 октября, 20:00. «Анатомия сопротивления: превращаем токсичных стейкхолдеров в союзников проекта». Записаться
Выбирайте задачу, которая сейчас требует больше всего внимания: запуск нового продукта, процессы, решения на основе данных или работа с командой.
📖 Что почитать по теме управления
Если хочется разобрать управленческие ситуации подробнее — читайте наши недавние статьи про команды, архитектуру и влияние ИИ на работу специалистов:
«Когда сотрудник тормозит команду: как говорить с ним прямо, но без давления»
о сложных разговорах, обратной связи и том, как разбирать проблемы в работе без лишнего давления.
«10 типовых ошибок при внедрении управления корпоративной архитектурой (Enterprise Architecture) и как их исправить»
о системных ошибках при внедрении Enterprise Architecture и способах их избежать.
«Кто платит за ИИ‑продуктивность: почему выгорают middle‑инженеры»
о скрытой нагрузке, которую AI‑инструменты могут создавать внутри команды, и о том, что важно учитывать руководителю.
Как относитесь к разрабам, которые постоянно пилят что-то своё (это я)?
Пугает ли вас данный факт, несет ли угрозу вашему бизнесу?
Анонсировано приложение, которое помогает убрать под ковёр ненужный хлам на рабочем столе. Разработчик пообещал доделать проект и выпустить решение для всех желающих.
Вышел открытый проект REA: Reverse Engineer Anything, который воспроизводит механики сторонних проектов. Никаких исходников и дополнительных данных не нужно, ИИ-агент сам исследует нужное приложение и соберёт его копию. На выходе получается декомпилированное ПО с возможностью полностью повторить конкретные фичи или вообще приложение целиком.
В открытом доступе появился открытый проект Visual Basic Browser Studio — классическая среда разработки (IDE) Visual Basic 6 (VB6), работающая непосредственно в браузере.
Примечательно, у разработчика этого проекта Веслава Шолтеса есть также решение SharpForge — браузерная IDE для C#, вдохновленная современной Visual Studio.
Стиль управления
Я работал в стартапах с разным стилем управления и создания продуктов.
С обязательными отчётами и без них.
С таск-трекерами и без них.
С обязательным офисом и полной удалёнкой.
С длинным планированием и решениями по ходу.
Часто процессы складываются под представление руководителя о том, как должна выглядеть нормальная работа. Кто-то считает естественным офис, отчеты и постоянные синхронизации. Кто-то принципиально выбирает удалёнку, свободный график и асинхронное общение. Микросервисы могут казаться правильным решением даже на этапе MVP, а монолит — единственным способом двигаться быстро. Эти убеждения подпитаны прошлыми проектами, удачными кейсами и историями успеха тех, за кем они наблюдали. Каждый искренне считает свой формат нормой и может привести десятки причин, почему именно его подход правильный. Поэтому изменить эти представления почти невозможно.
Но ни один стиль управления и создания продукта не определяет, выживет проект или нет.