AI Product | Igor Akimov

Сын скинул частушек про вайбкодинг от новой Лиры внутри Gemini. Ржал :) Хотя с рифмой и смыслом проколы, но дух передает верно :)))

Anthropic выкатили Claude Code Security — по сути AI-аудитор безопасности кода. https://youtu.be/sDpkV_iEnck Мы постепенно приходим к моменту, когда модели уже не просто пишут код, а читают его как security-исследователь. Claude теперь может прогонять репозиторий, находить не только типовые баги, а именно логические уязвимости, объяснять проблему и предлагать патч. При этом он не коммитит автоматически - разработчик подтверждает изменения. Главное отличие от классических SAST и линтеров - это не поиск по шаблонам. Модель проходит по потокам данных и взаимодействию компонентов, фактически делает manual security review, только масштабируемо. Во внутренних тестах Opus 4.6 нашёл больше 500 реальных уязвимостей в open-source проектах, причём часть существовала много лет. Что это меняет: раньше безопасность была дорогой экспертизой, теперь любой репозиторий сможет постоянно проверяться ИИ. Фактически AI-security становится обязательным слоем, потому что одновременно растёт и скорость разработки, и скорость атак. DevOps без AI-проверок скоро будет выглядеть как сервер без HTTPS. Круто, молодцы. https://www.anthropic.com/news/claude-code-security

📌Насколько Skills реально помогают LLM-агентам. SkillsBench — исследование и первый бенчмарк, где Agent Skills тестируются как самостоятельный артефакт. Авторы из 15+ топовых университетов взяли 84 задачи из 11 доменов, запустили 7 конфигураций моделей (Claude Code с Opus/Sonnet/Haiku 4.5 и 4.6, Gemini CLI с Gemini 3 Pro/Flash, Codex с GPT-5.2) и проверили 3 условия: без Skills, с готовыми Skills и с самостоятельно сгенерированными Skills. Итого: 7 308 траекторий с детерминированными верификаторами на pytest. Готовые Skills в среднем поднимают pass rate на 16,2 процентных пункта: с 24,3% до 40,6%. Но картина неоднородная: в медицине прирост составил +51,9%, для производства — +41,9%, тогда как в разработке ПО всего +4,5%. Это объяснимо: там, где модели плохо покрыты обучением (клинические протоколы, промышленные воркфлоу), Skills дают максимальный эффект. Там, где модель и так знает домен - почти ничего. 🟡Главный и неожиданный результат: самогенерация Skills не работает. Когда моделям предлагали сначала написать нужные гайды, а потом решать задачу, средний результат упал на 1,3% по сравнению с работой вообще без Skills. Только Claude Opus 4.6 показал скромный плюс (+1,4%), а GPT-5.2 просел на 5,6%. Иными словами - модели не умеют надежно создавать то знание, которым умеют пользоваться. 🟡Еще один интересный момент - это объем Skills. Оптимальный вариант: 2–3 модуля, прирост +18,6%. При 4 и более - всего +5,9%. Подробная документация вообще дает отрицательный эффект: –2,9%, с ней агент буквально тонет в контексте. Показательна и стоимость решения задач: Haiku 4.5 со Skills обходит Opus 4.5 без Skills — меньшая и более дешевая модель с готовыми Skills бьет старшую модель без них. Gemini 3 Flash при этом показал лучший абсолютный результат среди всех конфигураций - 48,7% со Skills при цене $0,57 за одну задачу против $1,06 у Gemini 3 Pro. 🟡Страница проекта 🟡Arxiv @ai_machinelearning_big_data #AI #ML #LLM #Benchmark #Skills

Посмотрел разбор Claude Opus 4.6 vs GPT-5.3 Codex от создателя OpenClaw (часть его интервью) https://youtu.be/j190mwiVlwA?si=1WSrMdrDw5I5mYhY Очень похожие мысли. Codex - как осторожный инженер-архитектор, который читает код - понимает систему - меняет минимально - почти не ломает Идеален для: продакшена, багов, рефакторинга, больших кодовых баз Opus - как креативный senior-разработчик сразу пишет - быстро делает фичи - иногда хаос - потом чистка Идеален для: прототипов, новых фич, UI, старта проекта Лучший workflow: Opus быстро построил Codex стабилизировал Opus расширил Codex довёл до прода Интересно ещё добавить туда новый Gemini Pro.

Мать моя женщина, Гугл всех порвал. Выпустили Gemini 3.1 Pro. На уровне или выше всех топовых моделей в знаниях, математике, кодинге, инструментах, визуальных размышлениях, длинном контексте. LiveCodeBench 2889 очков - мне кажется это уровень топ-разработчиков мира... Короче, такая конкуренция мне нравится :) И да, я тоже жду gemini-3.1flash https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-1-pro/

Gemini 3.1 Pro уже в AI Studio. Цены те же, но уверен все там поднялось по всем параметрам. Ждем анонса

И из интересного - у нас еще один лидер в опенсорсе. StepFun выкатили Step-3.5-Flash, такую попытку сделать локально-запускаемый агентный мозг, а не просто чатик Модель скорее про выполнить задачу через цикл действий: план → поиск → анализ → пересбор контекста → следующий шаг → итог 196B параметров но ~11B активных на токен (MoE sparse) Цель - заменить “дорогой облачный reasoning” на локально исполняемый reasoning-агент. Плюс они встроили в модель режим “параллельного мышления”. Не тот multi-agent, где ты оркестрируешь 5 вызовов API, а модель сама: - раскладывает гипотезы - ведёт несколько линий рассуждения - агрегирует Как раз об этом говорил на вебинаре, что раньше ты сам этих агентов создавал и прокидывал из стейджа в стейдж, а теперь все делается внутри модельки, Они отдельно подчёркивают context manager, модель сама решает, что забыть, что сжать, что оставить как рабочую память По бенчмаркам все близко к топовым моделям: LiveCodeBench ~86 SWE-bench verified ~74 Terminal-Bench ~51 BrowseComp ~69 tau2-bench ~88 Много пишут про локальное применение, специально заточились на Mac Studio, DGX Spark, AMD AIMax Короче, хороший вариант на корпоративного "сотрудника". Может разбираться, искать причины, читать документацию, делать исследования, запускать инструменты и все это внутри одной модельки на уровне архитектуры. https://static.stepfun.com/blog/step-3.5-flash/

О, в Codex CLI завезли multi-agent режим, можно реально “распараллелить мозги” на одну задачу. Может создавать несколько специализированных саб-агентов параллельно и потом собирать их вывод в один общий ответ. Особенно полезно для задач, которые легко делятся: explore кодовой базы, ревью, планирование фичи на шаги, поиск багов и т.д. Можно описать свои роли агентов и для каждой роли задать свою модель/инструкции/режим sandbox. Как включить: В CLI: /experimental → включить Multi-agents → перезапустить Codex Или флагом в конфиге ~/.codex/config.toml: [features] multi_agent = true Пока multi-agent активность видна именно в CLI. В Codex app / IDE extension “скоро”. Как это работает в процессе Codex сам делает оркестрацию: создает саб-агентов, прокидывает уточнения, ждёт результаты, закрывает треды. Когда агентов много – ждёт всех и отдаёт консолидированный ответ. Можно и вручную просить “spawn N agents”, и он сам решит когда надо. Пример из доки: задаёшь ревью PR и просишь по одному агенту на пункт: security code quality bugs race test flakiness maintainability Командой /agent переключаться между тредами, смотреть что происходит. Есть встроенные роли: default, worker, explorer. И можно на роль переопределять ключевые штуки: model, model_reasoning_effort, sandbox_mode, developer_instructions. Ссылка на доку: https://developers.openai.com/codex/multi-agent

NotebookLM наконец позволяет экспортировать в pptx (прикольно, что не в google slides). И редактировать слайды промптами. Отсюда: https://x.com/NotebookLM/status/2023851190102986970

Sonnet 4.6. Ваши затраты в безопасности :) Computer use прокачали — наконец-то работает как надо. 16 месяцев прогресса на бенчмарке OSWorld. Уже сейчас видят human-level результаты на реальных задачах: сложные таблицы, многошаговые веб-формы. Pace (страховые) тестировали - 94% точности на управлении компьютером (кажется все уже забыли про компьютер юз из-за медленноты и багов). Контекст 1M токенов — весь кодбейс, стопка контрактов или десятки статей в одном запросе. Хорошо бы посмотреть, насколько приседают результаты на большом контексте. В Claude Code пользователи выбирают Sonnet 4.6 вместо Sonnet 4.5 в 70% случаев. Что интересно — в 59% случаев предпочитают его даже старому Opus 4.5. Меньше overengineering, меньше "лени", лучше следование инструкциям. Цена та же, что у Sonnet 4.5: $3/$15 за миллион токенов, дешевле опуса в 1.7 раз. При этом производительность на уровне Opus. Курсор, GitHub, Replit, Zapier — все говорят одно: стало заметно лучше. Короче, можно пользоваться как базовой моделькой. https://www.anthropic.com/news/claude-sonnet-4-6

Вот это новости... Вчера как раз рассказывал про Manus, который очень классный универсальный агент (и презентации сделать, и мобильные приложения с сайтами, и аналитику), а сегодня он делает интеграцию с телеграммом :) Manus - уже 3 недели как часть Meta и поэтому странно, что не с whatsapp. Ну понятно, что Мета хочет свой OpenClaw и набор тулов "как у больших пацанов", но вот интеграция с телеграммом и правда интересна. И это уже посерьезнее, чем пока еще крайне сырой openclaw. То есть это полноценный Manus с полным набором инструментов – ресёрч, генерация документов, обработка данных, многошаговые задачи, но доступный через обычный чат в телеге. Настраивается за 10 секунд вместо бот-токенов и сервера. Что умеет: - Запускает сложные задачи прямо из чата – ресёрч, создание PDF, отчётов - Понимает голосовые сообщения – расшифровывает и выполняет запрос - Работает с фото и файлами – отправляешь картинку, получаешь результат обратно в чат - Можно настроить стиль ответов – коротко, структурированно или разговорно Выбор модели: Manus 1.6 Max (сложные задачи) или Manus 1.6 Lite (быстрые ответы). То есть все те рабочие сценарии многошаговые: - Отправил голосовое → агент настроил еженедельную подготовку к встречам на основе почты - Скинул фото → получил несколько вариантов аватарки в разных стилях - Отправил фото продукта с ТЗ → получил концепт промо-ролика Доступно на всех тарифах, включая бесплатный. Пока только Telegram, но обещают добавить другие мессенджеры. Подробности: https://manus.im/blog/manus-agents-telegram

Alibaba сегодня выкатили Qwen 3.5, бенчмарков навалили столько, что не влезает в экран. И кажется сделали всем подарок на китайский новый год :) MoE-архитектура: 397B параметров всего, но активных только 17B. То есть модель огромная по знаниям, но лёгкая при работе – классический подход, который DeepSeek популяризировал. Что нового по сравнению с Qwen 3: - Мультимодальность из коробки – текст и картинки учились вместе с самого начала, а не прикручивались отдельно потом - Новая архитектура – Gated Delta Networks + MoE, что даёт быстрый инференс при меньших затратах -201 язык (у Qwen 3 было 119), кажется скоро новый яндексЛЛМ-таки будет на ней. - Стоит на 60% дешевле предшественника, а нагрузки обрабатывает в 8 раз лучше Бенчмарки: По заявлениям Alibaba, обгоняет GPT-5.2, Claude Opus 4.5 и Gemini 3 Pro на нескольких тестах. Правда, сравнивают не с самыми свежими версиями этих моделей, так что с оговоркой. Интересно, что 397B open-source модель побила собственную Qwen-3-Max-Thinking, у которой больше триллиона параметров. Меньше → лучше – тренд продолжается. Умеет самостоятельно управлять мобильными и десктопными приложениями. Плюс обновили Qwen Code – аналог Claude Code для терминала. Есть ещё Qwen-3.5-Plus – закрытая модель с контекстным окном в 1M токенов. Короче, китайские модели отстают от лидеров реально уже на 1-2 месяца всего... Опенсорс: https://github.com/QwenLM/Qwen3.5 Блог: https://qwen.ai/blog?id=qwen3.5 И заходите обсудить сегодня - https://luma.com/nsab713l

Питера, создателя OpenClaw, наняли в OpenAI 😱 Ну кажется это довольно логично. И конечно сумасшедше быстрый Сэм, пока остальные жевали сопли.

8. Что ещё не знают пока Команда честно признаёт: пока непонятно, как архитектурная когерентность развивается в полностью ИИ-сгенерированной системе на горизонте лет. Они всё ещё учатся, где именно человеческая оценка даёт максимальный рычаг, а где вся надо отдавать ИИ. В общем, мне понравилось больше, чем рекламная методичка от Антропик (покупайте наш Клод Код). Это реальный опыт команды "на передовой". Разработчиков не увольняют (фух), а превращают в людей, которые проектируют среду для агентов. И это требует новых навыков: архитектурного мышления, умения формулировать ограничения, проектирования циклов обратной связи. Для тех, кто строит AI-процессы в командах, – must read. И конечно завтра, если будет время, обсудим - https://luma.com/nsab713l

Самый сейчас горячий вопрос - как внедрить ИИ-разработку больших систем и с учетом еще бОльшего улучшения качества работы ИИ каждый квартал 2026 год. Вот вам офигенная статья от OpenAI на эту тему: https://openai.com/index/harness-engineering/ Рассказали, как построили продукт на миллион строк кода. Ни одна строчка не написана человеком. Вот чему они научились. Абсолютно весь код – логика, тесты, CI, документация, observability, тулинг – написан агентами Codex на GPT-5. Люди не написали ни строчки. И это было осознанное ограничение. Первый коммит в пустой репозиторий – конец августа 2025 ~1 млн строк кода за 5 месяцев ~1,500 PR смержено Начинали с 3 инженеров, сейчас 7 3.5 PR на инженера в день (и скорость растёт с ростом команды!) Оценка: построили примерно в 10 раз быстрее, чем писали бы руками 1. Роль инженера полностью изменилась Инженеры больше не пишут код. Их работа – проектировать среду, формулировать intent и строить feedback loops, чтобы агенты могли делать полезную работу. На практике это подход от простого к сложному: разбиваешь большую цель на строительные блоки, промптишь агента собрать эти блоки, потом из них собираешь более сложные задачи. Ключевое: когда что-то ломалось, ответ никогда не был "попробуй ещё раз". Вместо этого инженер спрашивал: "какой возможности не хватает агенту и как сделать его понятным и управляемым?" 2. AGENTS.md как энциклопедия – провал Первый подход – один большой AGENTS.md файл со всеми инструкциями. Провалился предсказуемо: Контекст – дефицитный ресурс. Гигантский файл инструкций вытесняет саму задачу, код и релевантную документацию Когда всё "важно" – ничего не важно. Плюс монолитный мануал превращается в кладбище устаревших правил Решение: AGENTS.md ~100 строк работает как оглавление, не энциклопедия. Вся knowledge base живёт в структурированной docs/ директории как source of truth. Там же – архитектурная документация с картой доменов и пакетных слоёв, документ, который оценивает каждый домен и отслеживает деградацию. 3. Agent legibility – главная цель Всё знание должно быть внутри репозитория (вот это офигенный совет и я честно говоря к такому только подбирался) Агент не может погуглить, не может спросить коллегу. Всё, что ему нужно для работы, должно быть доступно в репозитории и понятно из контекста. То есть все ваши решения с созвонов и переписки по проекту в слак тоже должны быть в репо! Это меняет подход к архитектуре: код и документация пишутся не для людей, а для агентов (и людей заодно). Каждый дизайн-док, каждое архитектурное решение существует в repo и проверяется на актуальность. 4. Архитектура и "культура" закладываются с самого начала Как мы пишем код -фиксируется один раз, а потом требуется автоматически на каждую строчку кода. Архитектурные вариации проверяются не через code review, а через механические проверки – линтеры, CI, автоматические ревью. Это позволяет ловить плохие паттерны ежедневно, а не через недели, когда они уже расползлись по кодовой базе. Потому что потом этот кривой код уже будет считаться хорошим примером для последующих генераций 5. Скорость меняет философию merge Когда у тебя 3.5 PR в день на инженера, классический подход к code review не работает. Вместо ручного ревью каждого PR – Codex ревьюит свои собственные изменения, потом запрашивает дополнительные agent-ревью (локально и в cloud), отвечает на feedback и итерирует в цикле, пока все agent-ревьюеры не удовлетворены. Человек подключается к ревью по необходимости, а не по умолчанию. 6. Уровни автономии росли постепенно Не пытались сразу дать агенту полную автономию. Начинали с простых блоков, потом постепенно наращивали сложность. Каждый новый уровень автономии опирался на уже созданные абстрации и инструменты. 7. Техдолг и "сборка мусора" Техдолг – как кредит с высокой процентной ставкой. Лучше платить маленькими порциями постоянно, чем копить и разбираться болезненными спринтами. Команда запускает непрерывный автоматический рефакторинг каждую пятницу– это работает как garbage collection для кодовой базы.

Хах :) Надеюсь, у вас было не так. Я период сна с ноутбуком и терминалом в телефоне, чтобы не пропадали лимиты, а надо было срочно наваливать работы, прожил в новогодние праздники. Больше не хочу. Семья и кукуха дороже.

Запостил вчера свою библиотеку проверки транспортных данных gtfs.guru в канал всяких инженеров транспортных. Напоминаю, что с помощью ИИ переписал практически 100.000 строк кода от гугла и контрибьюторов c Java на Rust и сделал все в 10-100 раз быстрее не притрагиваясь к коду вообще! В итоге получил жидкие комментарии в стиле "вот ходют тут всякие, мы все равно любим джава" :)))) Ну ок, пойдем тогда к бизнесу, они лучше умеют считать деньги. А сегодня попалась рекламная PDF-ка от Антропик, где они конечно же расхваливают свои инструменты, но делятся похожим подходом переписывания легаси кода. Зачем вообще трогать работающее, есть прям статистика: - 17.3 часа в неделю средний разработчик тратит на техдолг вместо фич, то есть половину рабочего времени (McKinsey) - 70% организаций называют техдолг главным блокером инноваций (Protiviti) - 250 млрд строк COBOL в продакшене, специалистов всё меньше - Legacy-системы не получают патчи безопасности → растущие риски Предлагают три направления модернизации: 1. Архитектура – монолит → микросервисы. Даёт независимый деплой компонентов, fault isolation (падение одного сервиса не роняет всё), автоскейлинг по нагрузке. 2. Стек – устаревшие языки → современные. Рекомендации: COBOL → Java, Perl → Python, VB6 → C#/.NET. Бонусом получаешь экосистему библиотек, нормальный тулинг и возможность нанимать людей. 3. Практики – waterfall → CI/CD. Автотесты, IaC, GitOps. Деплой из раза в квартал в несколько раз в день. Как начинать – пошаговый план: Сигналы что пора: команда тратит >40% времени на maintenance, найм на legacy-позиции занимает месяцы, новым людям нужно длительное обучение на устаревших языках. Недели 1-2: Выбрать low-risk изолированную систему – batch-отчёты, standalone калькуляторы, периферийные интеграции. Провести "code archaeology" – маппинг зависимостей, документирование бизнес-правил из старых подпрограмм. Недели 3-4: AI-анализ legacy-кода, извлечение бизнес-логики, генерация документации. Proof of concept – модернизация одной подпрограммы с side-by-side сравнением результатов. Недели 5-8: Полная миграция первой системы. Параллельный запуск – новый код работает рядом со старым, сравниваем выходные данные. К 8-й неделе – cutover на прод. Месяц 3+: Масштабирование. Параллельные команды на разных системах, переиспользование паттернов конвертации, общие библиотеки утилит. Четыре уровня зрелости: Ad hoc – легаси трогают только когда горит: уходит последний COBOL-разработчик или регулятор требует. Документации нет, знания в головах уходящих людей. Planned – ежегодные проекты миграции с бюджетами, но каждый проект изобретает велосипед заново. Базовый инвентарь кода есть, ROI-анализа нет. Systematic – выделенные команды, стандартные процессы, метрики. Плейбуки для типовых паттернов (batch→streaming, декомпозиция монолита). Каждая подпрограмма задокументирована, зависимости замаплены. Optimized – AI проактивно сканирует системы и предлагает модернизацию с ROI-анализом. Непрерывная фоновая модернизация: удаление мёртвого кода, оптимизация запросов, рефакторинг. Люди занимаются стратегией, рутинные трансформации автоматизированы. Критически важно перед стартом: Если есть юнит-тесты – отлично, можно валидировать что новый код делает то же самое. Если тестов нет – сначала пишем тесты для критичных модулей с помощью domain-экспертов, и только потом мигрируем. Иначе рискуете потерять бизнес-логику, которая нигде не документирована. Вот именно по такому процессу у меня работа и шла. Сначала максимум тестовых датасетов, потом юнит-тесты для Java, потом переписывание помодульно на Rust с проверкой, потом интеграционные вещи и проверка на реальных данных (мои любимые - это маршруты Германии, Швейцарии и США). Короче, все работает (и работало даже на прошлых версиях ИИ, сейчас вообще как по маслу пойдет). Так что не ссыте, делайте рефакторинг. Могу кстати эту историю осветить чуть подробнее на вебинаре, если останется время. https://luma.com/nsab713l Всяких легаси-систем вокруг просто гигантское количество.

Про любовь к "лучшим инструментам" и "лучшим моделям" вместо того, чтобы разобраться в инструментах. Can Bölük (security researcher, автор oh-my-pi) за один день улучшил результаты 15 LLM в кодинге. Не менял модель. Не менял промпт. Поменял только edit tool — инструмент, через который модель вносит изменения в файлы. Мне кажется большинство срачей живет потому, что люди до сих пор живут в "магическом мышлении" по поводу ИИ (вот сыну вчера объяснял, как с логами и примерами пофиксить его плагин, сегодня выложил, довольный как слон). Мало кто говорит про harness — обвязку вокруг модели, которая отвечает за то, как модель читает файлы и записывает изменения. А именно там ломается большинство реальных задач. Что сейчас используется: 1) apply_patch (Codex/OpenAI) — модель генерирует diff в специальном формате. Проблема: другие модели этот формат не знают. У Grok 4 failure rate патчей — 50.7%, у GLM-4.7 — 46.2%. Модели нормальные, просто "не говорят на этом языке". 2) str_replace (Claude Code и большинство остальных) — найди точную строку, замени на новую. Модель должна воспроизвести каждый символ включая пробелы. Ошибка "String to replace not found in file" настолько частая, что у неё свой мегатред на GitHub. 3) Cursor вообще обучил отдельную 70B модель, чья единственная задача — правильно применять правки. И даже при этом для файлов до 400 строк полная перезапись файла работает лучше. Что предложил автор — Hashline: Каждая строка файла при чтении получает короткий хеш (2-3 символа): 11:a3|function hello() { 22:f1| return "world"; 33:0e|} Модель ссылается на эти теги при редактировании — "замени строку 2:f1", "вставь после 3:0e". Не нужно воспроизводить старый текст. Если файл изменился — хеши не совпадут, правка отклоняется до того, как что-то сломается. Результаты бенчмарка (16 моделей, 180 задач, 3 прогона): — Grok Code Fast 1: с 6.7% до 68.3% (десятикратный рост!) — MiniMax: больше чем удвоение — Grok 4 Fast: output tokens упали на 61% (перестал сжигать токены на retry loops) — Gemini: +8% к success rate — это больше, чем дают большинство апгрейдов самих моделей — Общий вывод: patch — худший формат почти для всех моделей, hashline матчит или бьёт str_replace А общем, прежде чем менять модель на более дорогую — посмотрите, как устроены инструменты. Часто модель прекрасно понимает задачу, но не может нормально выразить правки через инструмент, который ей дали. https://blog.can.ac/2026/02/12/the-harness-problem/

Google явно рубит фишку. Запустил WebMCP — стандарт для взаимодействия AI-агентов с сайтами. Пока в early preview. Сейчас AI-агенты (типа Gemini computer use, Claude computer use, Operator) взаимодействуют с сайтами через DOM — кликают кнопки, заполняют формы, скроллят. Это медленно, ненадёжно и ломается при любом изменении вёрстки. WebMCP предлагает другой подход — сайт сам описывает, что агент может с ним делать, через структурированные API. Анонсировали 2: - Declarative — стандартные действия прямо через HTML-формы. Простой путь для типовых сценариев. - Imperative — сложные динамические взаимодействия через JavaScript. Для кейсов, где нужна логика. Для чего использовать, например: - Ecommerce — агент ищет товар, настраивает опции, проходит чекаут без гадания по DOM-элементам - Тревел — поиск рейсов, фильтрация, бронирование через структурированные данные - Саппорт — автоматическое создание тикетов с заполнением всех технических деталей Это по сути переход от "агент пытается быть человеком и тыкать в кнопки" к "сайт говорит агенту, что можно делать программно". Как переход от скрейпинга к нормальному API. Надёжнее, быстрее, предсказуемее. И все меньше зависит от человека :) Подробности: https://developer.chrome.com/blog/webmcp-epp

В общем, в этот понедельник поделюсь всем, что знаю про разработку с помощью ИИ, в том числе (и в первую очередь) для неразработчиков. От выбора идеи до разработки. Запись будет Обещал за 50 евро, но для тех, кто сообразит сегодня, даже за 40: https://luma.com/nsab713l Очень хочется, чтобы смогли уже прям на следующий день сделать первую версию, потому что... Думать о деле – это не делать дело. Мечтать о деле – это не делать дело. Представлять себе успех от сделанного дела – это не делать дело. Ждать, когда почувствуешь себя готовым – это не делать дело. Разговаривать о деле – это не делать дело. Объяснять суть дела другим – это не делать дело. Спорить о деле в интернете – это не делать дело. Всем объявлять, что вот-вот начнешь – это не делать дело. Слушать подкасты о том, как делать дело – это не делать дело. Смотреть туториалы о том, как делать дело – это не делать дело. Читать треды о том, как это дело делали другие – это не делать дело. Выстраивать идеальную систему для дела – это не делать дело. Покупать для него инструменты – это не делать дело. Наводить порядок на рабочем столе ради дела – это не делать дело. Чувствовать вину за то, что не делаешь дело – это не делать дело. Быть «очень занятым» вместо того, чтобы делать дело – это не делать дело. Обещать себе начать завтра – это не делать дело. Ошибаться в процессе – это делать дело. Делать криво – это делать дело. Делать неуверенно – это делать дело. Сделать хоть малую часть – это делать дело (с) Давайте делать!