Очередная битва творцов и продавцов
В русскоязычном геймдев телеграме небольшое бурление (раз, два + комменты) в виде срача между творцами игр и продавцами игр.
Каждая группа доблестно стоит на своём «без нас вы никто».
Поскольку я был по обе стороны и меня подобные тексты тригерят печалят, то выскажусь.
Во-первых, научитесь, блин, уважать друг друга. Если ваш оппонент не прав, это не всегда значит, что он глуп и жизни не знает. Это может значить, что у него другие критерии правоты. Не всё в жизни меряется баблом, не всё в жизни меряется творчеством. Два человека одно и то же могут оценивать по разным критериям и в этом случае нет смысла спорить, так как вы будете сравнивать зелёное с квадратным — со стороны это выглядит очень тоскливо и непрофессионально.
Во-вторых, будьте честными с собой. Если вы продаёте игры, признайтесь что ваше KPI — бабло и вы оптимизируете его за счёт всего остального (например, за счёт творческой уникальности). Если вы создаёте качественно уникальные игры, признайтесь, что это ваше KPI и вы оптимизируете его за счёт всего остального (например, за счёт объёма продаж и бабла).
В-третьих, для выживания творцы и продавцы нужны друг другу. Когда вы работаете вместе с уважением друг к другу, вы находите баланс который создаёт крутые и популярные игры. Когда вы этого не делаете, вы производите говно: либо жвачку, либо абстрактное искусство.
Вот тут надо бы закончить, но я добавлю.
Взгляд на управление: Научные практики для инженерии — публичные артефакты
Инженер демонстрирует свою работу сообществу (с) ChatGPT, Leonardo da Vinci
- Точки зрения на продукт
- Цикл проверки гипотез
- Что почитать, когда и почему
- Нет инструкций для инженерии
- Инженерия — это наука — это инженерия
- Научные практики для инженерии — публичные артефакты
В прошлом эссе мы обсудили, что инженерия и наука близки, а значит, могут заимствовать практики друг у друга.
Давайте поговорим об этих практиках. Поскольку я заинтересован в инженерной стороне вопроса, то будем обсуждать практики, которые инженерия может заимствовать у науки.
Здесь и далее под инженерией имеется в виду инженерия в IT / разработке ПО. Я уверен, что идеи из поста применимы и к инженерии в целом, но это эпически разнообразная и обширная область. Формат блога и врождённая скромность не позволяет мне высказывать столь смелые утверждения.
Это эссе — первое из нескольких запланированных текстов о практиках — посвящено практике создания публичных артефактов (например, научных статей); силе, которую эта практика даёт науке; и потенциальным выигрышам инженерии при её переходе на схожую модель.
Под публичностью в данном тексте я имею в виду глобальную публичность, то есть доступность артефакта для всех, кто может быть заинтересован в нём. Это не обязательно предполагает открытую лицензию (например, open-source лицензирование), хотя открытая лицензия часто — естественный выбор, который упрощает многие вещи.
Мы обсудим следующие темы:
- что такое публичный артефакт;
- верифицируемость артефактов;
- публичные артефакты как свидетельство компетенции;
- публичные артефакты как критерий квалификации;
- публичные артефакты как ось оценки сотрудников;
- публичные артефакты как метрики здоровья;
- сложности перевода разработки на публичные артефакты;
- с чего начать.
Этот текст — не рекомендация, а приглашение к дискуссии. Он полон идеализма и спорных утверждений. Надеюсь на ваше понимание и комментарии.
LLM мыслят вширь, люди мыслят вглубь
Сформулировал свою главную концептуальную претензию к LLM на текущий момент. На основе моего личного опыта.
В чатах эта проблема заметна меньше — она стирается тем, что идёт постоянное общение с человеком, который направляет и корректирует LLM.
Зато очень заметна при vibe coding или когда спрашиваешь LLM что-то что предполагает абстрактный и большой ответ.
Donna — предсказуемость и управляемость для ваших агентов
Ищу early adopters для своей агентной утилиты.
Назвал Donna — https://github.com/Tiendil/donna
С её помощью ваши агенты будут генерировать стейт-машины, пока выполняют стейт-машины, созданные другими стейт-машинами.
Donna позволяет агентам выполнять сотни последовательных операций без отклонения от заданного потока исполнения. Ветвления, циклы, вложенные вызовы, рекурсия — всё возможно.
Большинство прочих инструментов просто шлют мета-инструкции агентам и надеются, что те не ошибутся. Конечно, агенты ошибаются: путают шаги, пропускают операции, несут отсебятину. Donna честно выполняет стейт-машины: хранит состояние, стек вызовов, контролирует поток исполнения. Агенты выполняют только конкретные команды от Donna.
При этом Donna — не оркестратор, а просто утилита, поэтому её можно подключить куда угодно, не нужно API ключей, паролей, etc.
Концепцию можно описать в двух утверждениях:
- Большинство высокоуровневой работы алгоритмизируется значительно лучше, чем это кажется.
- Большинство низкоуровневой работы алгоритмизируется значительно хуже, чем это кажется.
Ценообразование на старте монетизации Feeds Fun
Начал рассчитывать цены для пользователей Feeds Fun и понял, что надо это делать в блоге: работы почти столько же, идеологически верно и, что важно, должно быть интересно. Всё равно бы писал RFC — вопрос сугубо в публичности. Заодно проведу для себя некоторую ретроспективу по проекту.
Что такое Feeds Fun
Feeds Fun — это моя читалка новостей, которая с помощью LLM прикрепляет теги к каждой новости, а пользователи могут создавать правила в духе elon-musk + mars => -100, nasa + mars => +100. Это позволяет очень эффективно фильтровать поток новостей, сокращая его процентов на 80-90% (мой личный опыт) и при этом никаких секретных алгоритмов Google или Facebook — всё прозрачно и под вашим контролем.
Поэтому встречайте вольное сочинение на тему монетизации B2C SaaS, зависимого от LLM, — актуальнее некуда :-D