Согласно опросам, больше половины Go-разработчиков используют AI-кодогенерацию через тот или иной инструмент (https://devcrowd.ru/go-2024/skills_06/)

при этом я видел еще такой любопытный график по США (не смог найти, может позже найду), где видно, что с момента появления chatGPT вакансий entry level специалистов всё меньше и меньше в процентах к общему их количеству, уже где-то на треть меньше стало за эти пару лет. Там не только программеры, а в целом.

Какие тут можно сделать выводы. Прогнозы оправдываются: чем объяснять джуниору, как делать простую задачу, иногда проще сгенерить код гопчатом и чуток поправить.

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

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

Алхимия промпт-инжиниринга

Если рассматривать GenAI решения с точки зрения детерминизма результатов (а именно стабильности результатов нам и хочется в большинстве случаев), то
1) В общем случае детерминизм в LLM/LVM не достижим.
2) Всегда стоит рассматривать промпт и языковую модель как одно целое.

Про недетерминизм:

100% точности и воспроизводимости результатов инференса не будет даже при нулевой температуре, фиксированном seed параметре и других рандомных параметрах ввиду особенностей работы GPU вычислений (операции с плавающей точкой и квантизации). Тем не менее, обеспечить точность в три девятки можно. А это уже что-то.

Про систему "промпт + модель":

Prompt Engineering — это алхимия. А LLM — "черный ящик". С этим важно свыкнуться, особенно если вы любите one-shot prompting для принятия сложных логических решений внутри одного запроса. Одно небольшое изменение в промпте или изменение модели (даже простой переход с неквантизованной на квантизованную версию) приводит к тому, что отлаженная функциональность перестаёт работать и нужно начинать всё сначала. А уж если использовать облачные версии типа ChatGPT и Claude, то там вообще под капотом целые подсистемы роутеров и всяких "улучшайзеров ваших промптов", после которых даже сами разработчики этих решений, скорее всего, не угадают, какой будет результат. И они постоянно что-то в этих подсистемах подкручивают.

Какие выводы я сделал к текущему моменту для себя:

🔹 Выбор языковой модели для прода — это как выбор жены. Тестить как можно на большем кол-ве моделей до релиза, а в релиз выбирать и фиксироваться на какой-то конкретной, лучшей. На ней и "жениться" ;) Потом поменять уже сложнее.

🔹 Облачным моделям доверять нельзя, они имеют неприятное свойство меняться, ухудшаться. Кажется, что каждый новый релиз ChatGPT должен быть только лучше, но для конкретных задач может оказаться совсем наоборот. Например, в одном моём решении gpt\-4 (которая уже почти на пенсии) работает в плане генерации кода по инструкции значительно лучше gpt\-4o\-2024\-11\-20. Значит ли это, что модели становятся в целом хуже? Нет. Но мне не нужно "в целом", мне нужно решать конкретные задачи.

🔹 Принимать решения или делать обработку нужно как можно больше в коде, и как можно меньше в LLM. Если есть возможность что-то сделать без LLM, нужно делать без LLM, так достигается детерминизм. Если вытаскиваются ключевые сущности: максимально очистите данные до LLM, и всякие операции сортировки, ранжирования, нормализации делайте уже в python, а модели оставьте только работу с неструктурированными данными. У меня есть решение по отслеживанию трендов, там вытаскивают определенные классы тегов, имен компаний и продуктов из текста. Эти сущности извлекаются как получится, а нормализуются по словарю уже в коде, потому что модель это делает плохо.

🔹 Большой и сложный промпт — скорее зло. Простой промпт позволяет мигрировать между моделями без особой деградации качества. А сложный промпт приколочен гвоздями к конкретной модели, для которой писался и тестился. Эффективнее делать мелкие, несложные запросы.

🔹 У меня лучше работает серия простых промптов + объединение результатов в коде, чем один огромный промпт со всеми агрегациями и принятиями финальных решений внутри LLM. Такой большой и сложный промпт невозможно дебажить. Внутри что-то "решилось", а вы гадаете, почему. Папример, как один абзац инструкций повлиял на другой абзац. Меняете что-то вверху, а оно аффектит то, что внизу. Получается этакая игра Wack-A-Mole (из рандомных дырок вылазит крот, а вы ему по голове стучите молотком).

🔹 Structured Output — не панацея. Иногда он делает хуже вывод или дороже решение. Например, я никогда не использую его в задачах генерации кода или там, где нужны "плоские" одноуровневые тексты, или где нужно обрабатывать большой массив данных. В последнем случае это просто экономически не выгодно. При большом числе запросов оцените, насколько увеличивается число токенов в OpenAI либе при structured output и сделайте вывод (можно включить logger.DEBUG и увидеть это в консоли). А ещё json универсальнее Pydantic.

Конец.

Работай или умри 😡****

«Раньше я работал с удовольствием и драйвом. А теперь нет сил, работаю на автомате, лишь бы деньги платили». Знакомо?

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

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

— Бесконечно страдать или что-то менять?
— Работать с удовольствием или постоянно себя пинать?
— Найти время на хобби и личную жизнь или залипать на ютубчике?
— Кратно расти в доходе или топтаться на одном месте?

👨🏻‍💻 Делай выбор, подписывайся на канал @vadimpetrovpsi и начинай с закрепа - там уже ждет бесплатный мини-курс по выходу из апатии.

Google выпустила новое API для Protocol Buffers в Go

Команда Go представила новое API для работы с Protocol Buffers, получившее название Opaque API. Это важное обновление, которое должно сделать работу с protobuf более эффективной и безопасной.

До сих пор в Go использовалось так называемое Open Struct API, где все поля структур были доступны напрямую. Например, так:

```

go
type LogEntry struct {
BackendServer string
RequestSize uint32
IPAddress *string
}

```

С новым Opaque API все поля становятся приватными, а доступ к ним осуществляется через методы:

```

type LogEntry struct {
xxx_hidden_BackendServer string
xxx_hidden_RequestSize uint32
xxx_hidden_IPAddress string
// …внутренние поля опущены
}

// Доступ через методы
func (l LogEntry) GetBackendServer() string
func (l LogEntry) HasBackendServer() bool
func (l LogEntry) SetBackendServer(string)
func (l LogEntry) ClearBackendServer()
//...

```

Зачем это сделано?

Новый подход значительно экономит память. Вместо использования указателей для хранения информации о наличии значения в поле (presence), теперь используются битовые поля. В некоторых случаях это позволяет сократить количество аллокаций памяти почти на 60%. (речь идет про элементарные типы, такие как целые числа, булевы и т.д)

Появилась возможность реализовать ленивое декодирование сообщений. Теперь вложенные сообщения декодируются только при первом обращении к ним, а не при общей десериализации. Для некоторых приложений это дает колоссальный прирост производительности и уменьшает аллокации

Новое API предотвращает некоторые ошибки. Например, раньше было легко случайно сравнить указатели вместо значений при работе с enum:

```

/
message LogEntry {
enum DeviceType {
DESKTOP = 0;
MOBILE = 1;
VR = 2;
};
DeviceType device_type = 1;
}
/

// Неправильно и незаметно:
if cv.DeviceType == logpb.LogEntry_DESKTOP.Enum()

// Правильно:
if cv.GetDeviceType() == logpb.LogEntry_DESKTOP

```

С новым API такая ошибка просто невозможна, так как прямого доступа к полям нет.

Еще одно улучшение касается работы с reflection. Раньше разработчики могли случайно использовать стандартный пакет reflect вместо специального protobuf-reflection, что приводило к неожиданным результатам. Теперь такие ошибки исключены.

Google предлагает постепенный путь миграции через "гибридное" API, которое поддерживает оба способа работы. Для новых проектов рекомендуется сразу использовать Opaque API. В 2024 году оно станет стандартным подходом в новой версии Protocol Buffers (Edition 2024).
Старое API никуда не исчезнет – принцип обратной совместимости.

Для перехода на новое API Google предоставляет инструмент open2opaque, который помогает автоматически переписывать код. Внутри самого Google большинство protobuf-файлов уже переведено на новое API, и оно активно используется на проде.

подробнее здесь

Знакомые попросили продвинуть опрос ☝️

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

Среди программистов довольно часто встречаются перфекционисты. Чаще, чем в других профессиях.

А ты? Перфекционируешь небось?

Программа должна быть настолько гибкой и абстрактной, чтобы если что - можно было переделать паровоз в самолёт. С помощью напильника.

Импорты должны быть отсортированы по хитрым правилам. Перед return должен быть перевод строки, иначе мы все умрём. (Или что там у вас?)

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

Короче. Предлагаю лайфхак.

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

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

Баланс между читаемостью кода и скростью разработки. Разберитесь идеально, досконально, перфектно, что сильно влияет на читабельность , а что неидеально лишь тратит ресурсы.

А если при этом думать о системе в целом, то это будет вообще мегаидеально. Прям можно идти на международные соревнования по перфекционизму

Ответы на вопросы: один день из жизни CTO

Антон О. попросил написать сабж.

Когда я только-только стал engineering manager, я быстро понял, что вся муть про agile, власть команды и прочая скрам-ересь – это херня полная, потому что она приводит к тормозам, а скоростным компаниям нужна agility. Agility достигается менеджерами, которые херачат и культурой несидения на жопе ровно. Короче, главным навыком является управление, управление проектами, но в первую очередь - управление временем. Миллион людей будут с этим не согласны, будут находить тысячу причин не заниматься управлением даже своего времени, говорить что это стресс, что не для всех задач, и в этом канале уже неоднократно вспыхивали подобные срачики. Ну мне не надоедает в них участвовать и нести разумное-доброе-вечное, но пост не об этом, а о работе CTO.

Так вот, был я, значит, engineering manager и решил “потрекать свое время” - ну это натурально записать “один день из моей жизни”. Помечал всё, что делаю. К середине дня я понял, что поскольку я стараюсь не откладывать мелких дел - я на записи каких-то дел трачу время сравнимое с самим делом. Задумался, не херню ли я делаю, стал мелкие дела опускать. К концу дня я посмотрел на 3 листа A4 и решил, что там решительно нет ничего полезного для анализа, и что больше никогда такой фигней я заниматься не буду.

Мораль: один день даже у CTO (а у CTO тоже много сравнительно мелких дел) если он будет записан, состоит из такого количества “мусора”, что разбираться с ним будет бесполезно. Вот небольшой список того, что могло быть в таких записях. Тут нет хронологии - это просто пример, что могло бы оказаться в этом самом пресловутом “одном дне из жизни CTO”. Утро понедельника полет на работу в Лондон. Куча встреч по ongoing projects (10 встреч в день - легко, чем корпоративнее культура - тем больше встреч). Практика в пиццерии (у меня был онбординг в лондонской пиццерии - я работал там несколько дней, работал плохо и, мне кажется, сильно достал менеджера точки). Подготовка/апдейт презентаций по тех-стратегии. Обсуждение с командой продуктовой стратегии и hiring plan на год. Полет на встречу с акционерами, презентация hiring плана и бюджета на команду. Участие в партнерской конференции - встреча со студентами. Выступление в МФТИ на клубе выпускников. Выступление перед студентами МГУ/Бауманки. Вечер, чуваки из Макинзи позвали в караоке отмечать конец проекта. Intro-calls с кучей людей, не всегда полезных, но вдруг. Подготовка сложного увольнения - бриф с партнерами E&Y. 1:1 со всеми членами моей команды. Участие в ревью – финальные менеджерские оценки, калибрация. Подготовка/выступление на all hands. Понимате? Это я просто что-то написал более-менее интересно за три минуты, а сколько я упустил?

Короче, Антон, прости - но по-моему ты не должен этого хотеть. Тебе нужен не один день из жизни СТО, а один год из жизни CTO - но тебе его никто не напишет ? Впрочем, я думаю, что предыдущий абзац твое любопытство хотя бы частично удовлетворил.

Если же подходить системно о том, из чего состоит работа CTO/CIO, в чем отличие от CIO, например - то я об этому уже писал:
https://t.me/rybakalexey/5 - CTO не CTO I
https://t.me/rybakalexey/7 - CTO не CTO II
https://t.me/rybakalexey/8 - CTO vs CIO
https://t.me/rybakalexey/9 - CTO vs CIO (продолжение)

Enjoy.

Telegram

Alexey Rybak

CTO не CTO - I Нанять CTO непросто, устроиться CTO - тоже. Как оценить, что человек подходит на эту роль? Как понять, насколько ты подходишь сам? Как выстроить свой карьерный план? Хочу написать серию постов, посвященных роли CTO, какие бенчмарки бывают…

Не учи меня как жить
Как работать с мотивацией команды? Я знаю. А вы знаете? Руководители, которые упарываются в мотивацию, как по мне, не шарят за жизь. Я понимаю, как [пере]собрать мотивированную команду, но не имею ни малейшего представления, как мотивировать команду. Какую из задач все решают, а какую из них целесообразно решать?

Мотивация
Исходит из личных потребностей, желаний, целей и ценностей. Долговременная и устойчивая, она связанна с внутренними убеждениями и стремлениями человека. Поэтому, как правило, не требует внешних стимулов. Как и внешние стимулы, мотивация – это фактор, влияющий на поведение человека.

Стимул
Стимулы в большинстве своём вредны. Вносят сумбур и негативно влияют на социальные динамики в команде. Есть море исследований и книг на тему премий, перфоманс ревью и прочей дребедени с морковками, без которой мы все прям жить не можем. Почему это есть? Ну потому что кое-как это всё-таки работает, иногда устраивает, мол «и так сойдёт». Так и живём: я заплачу тебе х2, если сделаешь прямщас и лучше всех.

Почитать на тему:
Punished by Rewards
Why We Work

Способности
Принято разделять способности и навыки. Если упростить, можно сказать и софты с хардами, но способности точнее отражают суть. А суть в том, что ценность человека в способностях, а не в навыках. С первыми работать практически невозможно, а вторые развиваются на раз-два. Ну то есть работать то, конечно, можно, чем (чуть не сказал «успешно») тщетно и занимаются руководители, естественно, занятие это бестолковое.

Мотивация как раз относится к способностям человека. Это характеристика – мотивированный, как любопытный, интересный, токсичный, циничный или сумасшедший (тут желательна справка).

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

Не учи меня как жить
Единственное, что можно сделать – это понять мотивацию команды, не мешать и в поте лица работать над тем, чтобы система, в которой существует команда, не влияла негативно на мотивацию. А если вы вдруг надеялись научить меня как жить, привить новые ценности или пошатать парадигмы, то расслабьтесь, вам на работе тоже работать надо, а это вы ерундой занимаетесь, ресурсы почём зря расходуете. Лучше б прямо на собеседовании спрашивали: «Ты кто по жизни?».

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

Короче
Будьте классным, здоровым и богатым. Как это сделать разберётесь, иначе вы не такой уж и классный, чтоб кого-то там ещё и учить. Возвращаясь к вопросу – никак. Никак работать с мотивацией.

Репостну еще раз Программистику. Важная тема.

Я бы не сказал, что мотивировать совсем невозможно, но это скорее тонкое искусство, что-то схожее с созданием секты. В менджменте же имхо важнее убрать демотиваторы. Любит, например, человек программировать. Но его заставляют делать вещи, противоречащие здравому смыслу, мало платят, задалбывают бюрократией, не дают принимать решения - и всё. Вот уже вся любовь к программированию сошла на нет: никакой инициативы не ждите, всё исключительно по инерции, на отъебись.