Nano Banana can be prompt engineered for nuanced AI image generation 🔥 Горячее 💬 Длинная дискуссия
Несмотря на кажущуюся стагнацию, область генерации изображений ИИ активно развивается с появлением моделей вроде FLUX.1-dev, Seedream, Ideogram и Google Imagen 4. Однако ChatGPT с бесплатной генерацией изображений стал новым эталоном после вирусного успеха с промптом "Make me into Studio Ghibli". Его модель gpt-image-1 работает авторегрессивно, генерируя токены как текст, что делает её медленной (30 секунд на изображение), но доступной бесплатно.
В августе 2025 года загадочная модель "nano-banana" появилась на LMArena и позже была выпущена Google как Gemini 2.5 Flash Image. Её популярность вывела приложение Gemini на вершину App Store. Автор подчёркивает выдающуюся точность следования промптам Nano Banana, что делает её особенно ценной для сложных запросов. Пользователи могут генерировать изображения бесплатно через веб-версию Gemini или приложение, а разработчики - использовать API за $0.04 за изображение. Для упрощения работы с API автор создал Python-пакет gemimg.
Комментарии (214)
- Пользователи успешно используют Nano Banana для создания последовательных визуальных историй (сториборды, комиксы) с контролем персонажей, окружения и времени суток через многослойные промпты.
- Модель демонстрирует ограничения: проблемы с точным рендерингом текста, стилизацией (особенно сложных персонажей), непредсказуемыми изменениями деталей при редактировании и путаницей в интерпретации направлений (лево/право).
- Технические решения включают использование Python-библиотек (gemimg), API (Google AI Studio), маскирование для удаления водяных знаков и интеграцию с LLM (Mistral) для генерации вариаций промптов.
- Обсуждаются сложности достижения точных результатов (например, стиль-трансфер, удаление отражений) и необходимость тщательного промпт-инжиниринга для контроля вывода.
Комментарии (74)
- Fine-tuning is making a comeback as a niche tool for specific tasks, but the debate is whether it's worth the effort vs. using larger models with better prompting.
- The community is split: some see it as essential for control, IP ownership and cost savings, while others argue that frontier models have made it redundant for most use cases.
- Key friction points: cost-benefit of training vs. inference, data-labeling overhead, and whether the juice is worth the squeeze when prompt-engineering can achieve similar results.
- OpenAI, Anthropic and others are quietly re-opening fine-tuning APIs, while simultaneously pushing the narrative that "you don't need it anymore"—a tension that may be more about GPU budgets than user needs.
- The open-source community is rallying around LoRA and QLoRA as a compromise, but the real question is whether the economics of serving a custom model will ever make sense versus just paying per-token for a larger model.
OpenAI eats jobs, then offers to help you find a new one at Walmart 💬 Длинная дискуссия
- OpenAI запустила «AI Economic Index» — карты востребованных навыков и подбор вакансий для тех, кого её же модели вытеснили с рынка.
- Сервис анализирует миллионы объявлений, показывает, какие знания (например, промпт-инженерия) сейчас ценятся, и подсказывает, где учиться.
- Критики: компания сначала разрушает рабочие места, а теперь продаёт «палку-выручалочку»; данных о реальном числе потерянных профессий всё ещё нет.
Комментарии (179)
- Участники спорят, действительно ли ИИ уже «съедает» рабочие места или пока лишь повышает продуктивность и сокращает штат постепенно.
- Крупные ИИ-компании, проповедуя «этику», одновременно разрабатывают замену самим же пользователям, используя их бесплатные данные для обучения моделей.
- Примеры реального вытеснения: OCR-переводчики, редакторы новостей, тех-поддержка 1-го уровня, джуниор-разработчики и рутинные офисные задачи.
- Walmart упоминается как крупнейший работодатель, но речь идёт о розничных, а не инженерных позициях; собственные IT-команды компании уже подвергались сокращениям.
- OpenAI предлагает «сертифицировать» 10 млн американцев к 2030-му и матчить их с корпорациями, что многие воспринимают как попытку монетизировать созданную ею же дезинформацию и дисбаланс рынка труда.
Don't Build Multi-Agents
Не создавайте мульти-агентов
Фреймворки для LLM-агентов разочаровывают. Ниже — выжимка из нашего опыта и почему популярные идеи работают плохо.
Принципы контекст-инжиниринга
- Делитесь контекстом целиком
- Действия несут скрытые решения
Пока в мире LLM мы как в 1993-м с HTML: нет стандарта. Библиотеки вроде OpenAI Swarm и Microsoft Autogen продвигают мульти-агентов, но это, по нашему опыту, ошибка.
Почему мульти-агенты хрупки
Классическая схема:
- разбить задачу на подзадачи,
- запустить под-агентов,
- собрать результат.
Проблема: каждый уровень теряет детали. Пример: «сделай Flappy Bird» → под-агенты делают фон Mario и птицу, не похожую на оригинал. Сводить такие части — головная боль.
Принцип 1
Передавайте не сообщения, а полные трейсы агента.
Даже если дать всем под-агентам исходный промпт, в реальном диалоге уже были вызовы инструментов, уточнения, и контекст всё равно размывается.
Комментарии (61)
- Пользователи обсуждают, что «агенты» — это просто разные промпты к одному и тому же API, а не отдельные сущности.
- Основная проблема — «размывание» контекста: при ~50 k токенов агенты теряют цель, поэтому многие отказались от сложных мульти-агентных схем в пользу одного агента + умного управления контекстом.
- Предложено строить «компиляторы контекста» вместо ручной курирования и использовать фиксированные pipeline-ы вместо свободно общающихся агентов.
- Некоторые сравнивают подход с супервизорами Erlang, но большинство считает это переизобретением старых идей.
- Общий вывод: пока нет надёжности, мульти-агентные системы неэффективны; начинать стоит с простейших блоков и адаптировать под свою задачу.
Vibe coding as a coding veteran: from 8-bit assembly to English-as-code
Vibe-кодинг глазами ветерана
Эксперимент
2 недели, 40 часов, 5 k строк Python: AI-агент и я пишем микро-игру с алгоритмами A*, Minimax и пр. Цель — проверить, вытесняет ли LLM «искусство программирования».
Процесс
- Промптинг: описываю задачи естественным языком, AI генерирует код.
- Рефакторинг: «сделай класс короче», «добавь тесты» — срабатывает 80 %.
- Отладка: трассировка стека + «почему падает?» — LLM быстро находит баги.
- Архитектура: за меня выбирает структуру пакетов, но я корректирую.
Что понравилось
- Скорость: MVP за 3 вечера.
- Меньше рутины: никаких «import os.path.join».
- Новые идеи: AI предложил кэш-стратегию, которой я не планировал.
Что не так
- «Галлюцинации» API: методы, которых нет в библиотеке.
- Сложные баги: race condition LLM не видит без контекста.
- Читаемость: имена вроде
helper_utility_v2приходится переименовывать.
Выводы
- Junior-девелопер теперь = «человек, который умеет спрашивать».
- Сеньор нужен, чтобы фильтровать, тестировать и нести ответственность.
- Синтаксис умирает, зато растёт ценность системного мышления и prompt-инженерии.
Советы ветеранам
- Делайте микро-промпты: «добавь docstring» → «добавь пример вызова».
- Держи CI/CD: автотесты ловят ошибки, которые AI пропустил.
- Используй AI как пару, а не замену: «покажи diff» вместо «перепиши всё».
Итог
Vibe-кодинг не убивает профессию, а сдвигает фокус: от написания символов к управлению смыслом. Сборочная линия есть, но над ней всё ещё нужен человек с вкусом.
Комментарии (107)
- Участники сравнивают LLM с консалтинговой фирмой: 50 % шанс получить эксперта, 50 % — стажёра; приходится перечитывать каждую строку.
- «Vibe-coding» (генерация без чтения) вызывает опасения: сложно дебажить, нельзя защитить авторские права, а тонкие баги пролезают.
- Опыт показывает: AI полезен в известных языках и задачах (Python, CRUD), но почти бесполезен в нишевых (C/C++ gamedev, Prolog, Haskell).
- Старшие разработчики всё равно нужны: только они могут проверять, направлять и «владеть» кодом, созданным ИИ.
- Возникает вопрос: если не брать джунов, откуда возьмутся будущие сеньоры?
- Предлагают термины вместо «vibe-coding»: «pro-coding», «prompt-coding», «reviewing code».
How to build a coding agent 🔥 Горячее
Как собрать код-агента: бесплатный воркшоп
Материалы и исходники: GitHub
Суть
- Агент — это 300 строк кода, работающие в цикле, которому просто подаются токены LLM.
- Поняв принцип, вы перестанете быть потребителем ИИ и станете его продюсером, автоматизируя свою работу.
Зачем
- В 2025 г. знание, как создать агента, стало фундаментальным навыком, как понимание primary key.
- Работодатели ищут тех, кто может оркестрировать ИИ внутри компании.
- Во время Zoom-звонка ваш агент может уже писать код, который вы только обсуждаете.
Что будет на воркшопе
- Live-сборка агента прямо во время доклада.
- Объяснение внутреннего устройства: цикл, токены, промпты.
- Практика: агент строит агента под диктовку.
Дальше
- Если хотите, чтобы я провёл такой воркшоп у вас в компании — пишите.
Комментарии (110)
- Команда Princeton SWE-bench выложила компактный (~100 строк) агент для SWE-bench.
- Пользователи жалуются на перегруженный AI-слайд-стиль и избыточные картинки, которые мешают чтению.
- Спор о необходимости отдельных инструментов: многие действия можно делать через bash, но специализированные утилиты экономят токены и повышают надёжность.
- Обсуждают, что «токены = деньги» и что локальные модели могут изменить ситуацию.
- Критика: пост показывает лишь базовый подход, не раскрывая продвинутые темы (sandbox, snapshot, prompt-инженерия).
Building AI products in the probabilistic era
Строим продукты ИИ в эпоху вероятностей
Мы живём в момент, когда инструменты обогнали наши модели их понимания. ИИ изменил саму природу софта: вместо детерминированной функции F: X → Y мы получаем статистическое распределение.
Классическая эра
До ИИ продукты были предсказуемы: нажал «отправить» — сообщение ушло. Именно поэтому вся отрасль строилась на 100 % надёжности: SLO-дэшборды, тесты, аккуратные рефакторинги. PM и дизайн тоже сводились к прокачке воронок с заранее заданными входами и целями.
Новая реальность
С ИИ выход y стал вероятностным: один и тот же промпт может дать разные ответы. Это ломает привычные процессы:
- Инженерия перестаёт быть «написать код → проверить тесты». Теперь нужно управлять распределениями, подбирать промпты, валидировать выборки.
- Продукт больше не сводится к фиксированному набору фич. Модель сама генерирует новые пути ценности, а цели могут меняться по ходу использования.
- Организация требует новых ролей: «prompt engineer», «eval lead», «AI safety analyst».
Что делать
- Отказаться от 100 % SLO. Достаточно 95 % качества при 10× скорости релизов.
- Оценивать не функцию, а распределение. A/B тесты уступают место оценке статистических хвостов.
- Строить обратную связь в цикл. Пользовательские данные теперь не просто метрика, а способ «дообучать» поведение модели на лету.
Точно так же, как раньше победили те, кто принял «нулевую себестоимость» интернета, теперь выиграют команды, которые освоят вероятностное мышление.
Комментарии (97)
- Критики считают статью псевдонаучной: излишнее математическое оформление, «LinkedIn-философия» и игнорирование необходимости детерминизма в критичных системах.
- Автору вменяют ошибку: вероятностная система не является функцией, а «переход к квантовой теории» называют переходом к недетерминизму, а не «вероятностному детерминизму».
- Многие напоминают, что человечество всегда строило гибкие инструменты; жёсткая детерминированность ПО — скорее исключение, и будущее, вероятно, объединит детерминированные обвязки с вероятностными ядрами.
- Ряд участников подчёркивает: текущие LLM-агенты ненадёжны, «GPU-powered bullshit engine» не заменит проверенную инженерную практику, а «переписывать всё каждые три недели» — нереалистично.