OpenAPI: странности required

Недавно столкнулись с интересным моментом при работе по Api-first с OpenAPI. В спеке может присутствовать секция required, которая вроде бы должна строго указывать обязательные поля:

required:
  - field1
  - field2

Но если указать несуществующие поля — генератор всё равно сгенерирует клиент и сервер, без ошибок и предупреждений. Некоторые генераторы вообще позволяют писать required рядом с полем — и клиент всё равно учитывает семантику правильно (но при этом другие генераторы вообще отказываются работать с такой спекой, ибо не канон).

Ситуацию можно исправить Redoc CLI. С его линтером можно проверять спеку ещё до генерации и ловить такие моменты, как например required, который ссылается на несуществующие поля (есть даже набор рекомендованых правил). Вроде полезная штука

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

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

И вот читатель, наслушавшись нас (или не только нас), помня о той боли, которую он регулярно испытывает на работе, решает что-то внедрить: улучшить процесс, оптимизировать, хотя бы попробовать. Из лучших побуждений, конечно же. И очень часто это не находит отклика. Коллеги клеймят тебя умником, который книг начитался, начальство напрягается, иногда даже начинает видеть в тебе угрозу. Но отчаянный читатель не унимается, продолжает настаивать — и в итоге получает урон себе (прежде всего по нервам).

Так вот. Если не получается внедрить изменения через реакцию на реальную проблему и тем самым заработать себе авторитет для дальнейших действий (а как заработать авторитет — это вообще отдельная история), то дальше упираться бессмысленно. Это не про настойчивость и не про «дожать», это про то, что вы пытаетесь играть в дарк соулс с отключеной клавой. В таком случае лучше просто забить и смириться.

«Но как же так? Я же хочу нанести непоправимую пользу команде / компании!»

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

При этом важно не перепутать. Речь не про «плыть по течению» и не про «забить на всё». И уж точно не про отказ думать. Речь про то, чтобы не долбить стену головой.

Но ломать систему вообще-то можно. И не только когда вас для этого официально наняли. Иногда это просто внутренний зуд — хочется разнести всё к чёртовой матери и посмотреть, что выживет. Это нормальный режим, но это уже не про улучшения. В этот момент можно забыть про техники, инструменты и технологии — они тут вообще ни при чём. Игра идёт не в «сделать лучше», а во власть, конфликты, передел границ и проверку, кто тут на самом деле батя принимает решения. И главный вопрос здесь не как, а сколько вы готовы за это заплатить — репутацией, карьерой или хотя бы нервами.

Поэтому во всех остальных случаях лучшая стратегия — бережно выбирать, куда вкладывать усилие: спокойно делать свою работу чуть лучше, чем требуется, оптимизировать то, что находится в зоне контроля, кайфовать от процесса или неспешно подыскивать места, где действительно нужно всё то, что вам так нравится делать (или найти халтуру и на сэкономленое время лутануть чуть больше деняк). А энергию, азарт и желание чинить мир тратить там, где это не превращается в борьбу с бетонной стеной.

Тут один наш коллега по цеху c канала Intelligent Systems Architecture, который занимается прикладными исследованиями в ИИ, очень точно сформулировал различия между вайбкодингом и промышленным подходом:

1. Школа «Vibe Coding» (Вайбкодинг)

Это то, что нам активно продают сейчас: бесконечные контексты и идея «поговори с кодом».

Суть: разработка на основе нечеткого интента. «Сделай красиво», «поправь тут», «перепиши в другом стиле».

Результат: отлично подходит для прототипирования «на выброс». Но на длинной дистанции это путь к хаосу. Контекст размывается, энтропия растёт.

Аналогия: у вас есть 3D-принтер, и вы говорите ему: «Напечатай матрёшку». Он печатает. Потом вы говорите: «Сделай её повеселее». После сотни итераций матрёшка превращается во Франкенштейна, и никто не понимает, как вернуть её к нормальному виду.

2. Школа «Spec-Based Engineering» (инженерный подход)

Это направление, к которому неизбежно придут команды, создающие production-ready решения.

Суть: управляемая генерация на основе формализованных требований (спецификаций).

Результат: гарантированная воспроизводимость и трассируемость к требованиям.

(почитайте дальше, там целая серия постов на этот счет)

Но чтобы у нас действительно заработал инженерный подход, нужны две вещи: строгий пайплайн и архитектура агентов (инженерию знаний очень грубо определим в архитектуру).

С пайплайном всё более-менее понятно — мы плюс-минус умеем его строить и знаем, как оценивать код и результат.
А вот с архитектурой агентов всё заметно сложнее.

Я подписан на примерно 100500 блогов и каналов про ИИ, и в основном там одно и то же:
• «ВАААААУ, НОВАЯ МОДЕЛЬ, ЭТО ВАЩЕ КОСМОСССС!!!111»
• «ОООО, Я ПОДОБРАЛ ТАКОООООЙ ПРОМПТ!!!111»
• «А ВЫ УЖЕ ПОПРОБОВАЛИ ОБНОВЛЕНИЕ %TOOLNAME%? ОН МНЕ ПЕРЕПИСАЛ ВЕСЬ КОД ЗА 300 НАНОСЕК И НИЧЕГО НЕ РАБОТАЕТ!!!111».
Как будто снова попал в джаваскрипт образца ~2010 года, где каждый день выходило новое поколение фреймворка нового поколения.

Но почти нигде не обсуждаются принципы построения систем: почему это работает именно так, а не иначе, и сработает ли вообще в следующий раз? Пока здесь очень много тумана, но, имхо, именно в этом и кроется тот самый эффект, которого все так ждут — высадить на мороз всех разрабов и чтобы вареники сами в рот залетали

Как я за год перестал просто «писать код» и возглавил разработку Core-системы банка

Ситуация: Год назад, после сокращений в Thoughtworks, я пришел в Jago Bank. Позиция — Staff Engineer, команда пишет критически важный компонент.
Туда уже отрядили лучших из тех кого смогли найти.
• Всем заправляют два блестящих Principal-инженера (они правда крутые).
• Местные Staff-инженеры по сути просто пишут код, не влияя на решения.
• Вокруг — толпа рядовых разработчиков.
И тут появляюсь я. Человек, которому не нравится просто «кодить под диктовку», особенно когда к текущему решению есть вопросы.

Что я сделал, чтобы изменить расклад:
Сразу скажу: приходить к начальству с заявлением «вы всё делаете неправильно» — плохая тактика. Наша задача — снимать головную боль руководства, а не создавать новую. Я пошел другим путем:
1. Заработал авторитет «в полях» Сначала показал себя как толковый инженер. Закрывал задачи, рефакторил, внедрял лучшие практики где было возможно, улучшал поддержку на проде. Нужно было делом доказать, что моему мнению можно доверять.
2. При первой же возможности я себе отгородил небольшой огородик. Мы начинали новую интеграцию. Я не стал ждать указаний, а сам пошел к лидам смежной системы. В итоге я стал носителем уникальных знаний и человеком, к которому идут за ответами.
3. Внедрил лучшие практики Я спроектировал этот кусок системы, используя подходы, о которых мы с Женей рассказываем на курсе. Контраст был очевиден: мой модуль выглядел архитектурно стройнее, чем остальная система.
4. Стал «видимым» для начальства Поскольку у меня появилась своя зона ответственности, я начал напрямую держать руководство в курсе прогресса. Тут я показал что могу не только в лучшие практики, но и могу отвечать за Деливери в целом.

Итог: Когда стало понятно, что банку нужна своя собственная Core System и для неё нужен техлид, других кандидатов просто не осталось.

P.S. Забавно, но ту самую интеграцию, на которой я «вырос», в итоге закрыли из-за смены бизнес-приоритетов. Но кого это волнует? К тому моменту я уже ушел далеко вперед (с).

Сейчас та изначальная команда — часть моего департамента. И теперь мой главный челлендж как лидера — вернуть им самостоятельность и научить работать без постоянной оглядки на «старших».

Тут Серёжа слегка проговорился о том, как подниматься наверх. У меня куча знакомых, которые выросли из обычных разработчиков в кабанычей менеджеров, архитекторов и директоров. Как же туда пролезть?

Побуду капитаном очевидностью: чтобы забраться на вершину корпоративного баобаба, одного навыка формошлёпства мало. Ключевая штука — умение брать на себя ответственность за результат. Не за «я попробовал», не за «я сделал свою часть», а за то, что проблема в итоге решена. И (важно!) в случае успеха не забывать стребовать за это ништяки. Ответственность без запроса награды — это просто бесплатная эксплуатация.

Как это работает? Давайте разберем механику процесса.

Представьте: я тимлид, у меня пару десятков балбесов. У тимлида куча головняка и проблем. И вдруг находится человек, который говорит: «Давай я решу эту проблему», — и делает её под ключ. То есть берёт ответственность за решение и доводит всё до результата (что-то согласовывая по пути), тем самым снимая нагрузку с тимлида.

При этом человек рискует — может не получиться, может пострадать репутация. И тут всё как в бизнесе: потенциальный профит соразмерен риску. Чем больше задач ты закрываешь «под ключ», тем выше к тебе доверие и тем больше тебе дают веса.

И кого потом руководитель будет держать в голове? Того, кому задачу надо по десять раз разжёвывать («я не требования читать пришёл, я код писать пришёл»), или того, кто сам организовал и довёл решение? Кому дадут более интересные задачи и кто будет первым в очереди на повышение?

Вот этот скилл — делать «под ключ» — довольно редкая штука. И это реальный шанс обскакать многих даже при недоборе хардскиллов.

Да, понятно, там есть ещё много всего: политота, лизание задниц, умение не дать на себе ездить и т.д. Но если вы просто пришли покодить, чтобы вас никто не трогал, — вероятность, что вас заметят и повысят, стремится к нулю (а вскоре и вообще заменят бездушным электронным болваном).

В очередной раз словил одну и ту же мысль: качество проекта решается в самом начале.

Если старт проходит под бодрое «давайте быстрее писать, потом отрефакторим» — это «потом» почти всегда либо очень дорогое, либо не происходит вообще. Об этом у нас даже отдельный ролик есть.

Пару месяцев назад запускали новый проект. И первое, что сделали — не фичи, а собрали шаблон проекта + определили практики:
• Clean Architecture, границы прибиты через gradle-сабмодули и ArchUnit
• тестовая пирамида с примерами: где мокать, где нет, как писать интеграционные
• нормальная доменная область с value objects — чтобы моделирование сразу шло в правильную сторону
• набор инструментов, который мы осознанно выбрали и зафиксировали в ADR — чтобы было понятно, что у нас «по умолчанию», а что нет

В целом — всё, о чём мы с Женей обычно рассказываем на курсах. И только потом запустили разработку.

И вот что интересно — у части ребят, вообще не было опыта в Java/Kotlin, но:
• все просто повторяют шаблон — смотрят, как сделано в соседнем сервисе
• никто не придумывает свою архитектуру
• никто не спорит про слои
• никто не пишет «как чувствует»
Потому что система уже задала рамки и даже автоматически бьет по жопе, если что-то не так.

В итоге:
• во всех сервисах — Clean Architecture
• тестовая пирамида соблюдается
• код выглядит одинаково и с ним приятно работать

А если бы первый сервис был написан в духе «классической слоёнки» — она бы и расползлась по всей системе. Что кстати справедливо если вы пользуетесь ИИ — откуда она будет брать примеры и правила для написания кода, если у вас неструктурированая лапша?

Ко мне уже несколько раз подходили разработчики с просьбой «включить их куда-то». И я заметил два паттерна поведения. Следуя одному, люди обычно добиваются того, чего хотят. Следуя второму — остаются тихонько проигнорированными.

Примеры:
• «Включи меня в ключевые митинги, я хочу быть в курсе архитектуры»
• «Зови меня на митинги по перформансу, мне это очень интересно»
• «Мне очень интересна big data, давай я буду связующим звеном между нами и ними»

Как думаете, кто в итоге добился своего?

В первых двух случаях ребята хотят закрыть какие-то свои хотелки. Но лично с меня это не снимает никакой головной боли. Скорее даже добавляет: придут, будут сидеть и задавать вопросы с важным видом.

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

В общем, будьте как в примере №3. Всегда ставьте себя на место человека, у которого просите

В комментариях к посту о том, как вливаться в важные митинги и начинать участвовать в принятии решений, мне предъявляют:

«Почему вы не даёте разработчикам расти? Они ведь тянутся к знаниям: хотят и в архитектуру, и в performance. А вы, Сергей, их игнорируете, код писать заставляете, на митинги не пускаете».

Поясняю, почему не пускаю.

Фраза «Включи меня в ключевые митинги, я хочу быть в курсе архитектуры» может означать что угодно:
• Я хочу больше узнать об архитектуре
• Я хочу тоже принимать ключевые решения
• Я хочу быть в компании крутых ребят
• Я хочу пощекотать своё ЧСВ
• Я хочу подняться по карьерной лестнице и начну с влияния на процессы

Все это валидные причины для самого человека, Но это не причина ломать рабочий процесс команды.

Почему ломать? У нас около 20 разработчиков. И мы регулярно принимаем решения, которые сильно влияют на проект. Самый худший вариант — собрать всех 20 человек и начать обсуждать что-то вроде: «Как будем хранить время в базе и как передавать его в API». Это ровно тот сценарий, после которого люди пишут: «Одни митинги, код писать некогда».

Поэтому у нас есть экспертные группы:
• одна принимает архитектурные решения
• другая следит за производительностью критичных частей системы
• третья проектирует e2e-тесты

Если просто добавлять людей в эти группы:
• их нужно вводить в контекст
• обсуждения становятся длиннее
• решения принимаются медленнее
• разработчики могут оказаться заблокированными

Поэтому правило простое:

Хотите в группу — покажите, чем вы будете ей полезны.

И тут обычно начинается ступор: «А как я узнаю, чем могу быть полезен, если меня там нет?»
Очень просто. Например:

• поговорите с одним из участников группы на кухне и узнайте, какие сейчас проблемы
• есть релевантный опыт? Например, скоро обсуждаем transactional outbox, а вы с этим работали — отлично, расскажите
• нет опыта — возьмите административные задачи: подготовка агенды, фиксация решений, рассылка итогов

И вот тут обычно появляется ещё один аргумент: «Это всё какая-то политика. Я честный разработчик. Я вырасту без этого».

Ну что ж. Тогда у меня для вас плохие новости о том, как на самом деле растут карьеры в компаниях.
Спойлер: без даже минимального понимания политики и того, как строятся отношения вам придется двигать таски в джире до второго пришествия (что само по себе неплохо, но только не в том случае, если хочется чего-то большего)

Моя личная боль: Микросервис == Entity

Третью неделю переносим одно «небольшое» приложение из примерно полусотни микросервисов (помогите) в новую инфру, со всеми пайплайнами, куберами, базами данными и прочим непотребством. И это настоящий музей антипаттернов.

Само по себе оно не слишком сложное: по сути обычный BFF/прокси к другим подсистемам + немного своей логики, но реализовано по классической схеме «одна сущность — один сервис».

В итоге:
— ~50 сервисов
— синхронные вызовы между ними, а это и увеличение latency и уменьшение надежности всей системы.
— циклические зависимости между сервисами
— невозможность остледить кто кого вызывает и зачем
— падает один сервис, 80% системы не работает. К примеру, сервису заявок понадобилось провалидировать адрес, которому выделен свой собственный микросервис и он то как-раз упал.
— тестирование всей системы (не отдельного сервиса, а именно всей) — отдельный вид мазохизма

Страшно представить, сколько денег было сожжено просто на поддержку инфраструктуры: серверы, пайплайны, окружения, клиентов для микросервисов, тестов и всё остальное. Самый кек— пользователей там не так много. Никаких миллионов, ради которых всё это могло бы иметь смысл (хотя и не всегда).

Из заявленных преимуществ микросервисной архитектуры, а именно scalability, reliability и легкости в поддержке достигнуто ровно 0.

Джеймса Гослинга (создателя нашей любимой джавы) бомбит от эффективных менеджеров в его linkedin.

Далее с его слов

Когда начался безумный хайп вокруг ИИ, а я ещё работал в AWS, меня поразило, насколько сильно перекроили бизнес и как просто сносили целые команды. Одно из самых грустных последствий — в руководстве оказалось слишком много людей, которые почти не понимали, как вообще работает AWS.

Понаехали толпы мастеров экселя, которым поручили решать, где оставить людей, а где порезать команды. И действовали они предельно тупо: при оценке сервиса их интересовал только ROI — сколько денег он напрямую приносит от клиентов. Если сервис по этой метрике выглядел слабо, команду просто резали. Все команды, с которыми я тогда работал, в итоге исчезли.

Иногда такая логика ещё могла иметь смысл. Но проблема в том, что у многих сервисов почти нет прямой выручки, хотя без них вся система просто не сможет нормально работать. Один из таких сервисов — внутренний DNS. Я не знаю точно, что произошло с той командой, но почти уверен, что по ней сильно ударили сокращения. А это означает меньше возможностей что-то улучшать, уменьшать техдолг и быстро реагировать на проблемы в проде.

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

Это был какой-то эпический бардак, и смотреть на него было тяжело. Я потратил много времени, пытаясь донести это до близоруких идиотов, но не продвинулся вообще ни на шаг.

Думаю, мы еще не раз увидим как внедрении ИИ в неподготовленный для этого проект ведет к веселым приключениям (кое-кто из толстых банков мне рассказывал по секрету, что количество дефектов после внедрения ИИ выросло в несколько раз).

Заставь дурака богу молиться ROI поднимать — так он полконторы разнесет.

Уже сейчас компании вроде Spotify и другие бигтехи двигаются в сторону разработки , где основную работу делает ИИ-агент (попутно собирая совещания на тему «как бы нам еще разок не обосраться из-за багов от ии ИИ»).

И отличие от существующего формата, когда мы сидим и ковыряемся в курсоре — это полная автономность. То есть ИИ сам берет задачу из Jira, пишет код, гоняет тесты и открывает MR, деплоит на продакшен (и срется потом с коллегами в MRах).

Есть мнение что, через некоторое время агентская разработка станет такой же нормой, как GitLab, CI и pull request’ы. Хотя конечно даже CI(!) еще не до всех дошел, так что останутся островки "безысходности и ручного лампового труда"….

Но есть маленькая проблемка. Если внедрить подобный подход, что называется с ноги, то 90% компаний просто утонут в тоннах говнокода.
Оставшиеся 10% получат кратный рост производительности с приемлемой просадкой по качеству.Главный вопрос: вы окажетесь в этих 10% или в 90%?

Вопрос в том к какой группе будут относится наши проекты?
Давайте проведем мысленный эксперимент. Представьте, что вам завтра выдают не одного AI-агента, а сразу 20 очень старательных джунов. Таких вот умниц: не тупых, не ленивых, мотивированных, исполнительных. Но все-таки джунов.

Вопрос к вас: что будет с вашим проектом?
- Код станет лучше?
- Скорость вырастет?
- Или через месяц все превратится в болото, где никто уже не понимает, что с чем связано?

Поделитесь результатами эксперимента в комментариях!

Что будет если прямо сейчас на мой проект придут 20 прилежных джунов?
Напоминаю, что это тест лакмусовой бумажки на готовность к ИИ агентам.

Дак вот, они не смогут сильно навредить ибо проект устроен так, чтобы его было сложно сломать.
1. Структура проекта может выдержать удар
У нас hexagonal architecture и зависимости защищены тестами и правилами сборки. А именно
⁃ Нельзя просто так взять и воткнуть @Entity в доменный агрегат (о ужас).
⁃ Нельзя из контроллера напрямую дернуть репозиторий.
⁃ Нельзя незаметно протащить архитектурную грязь — сборка или тесты это остановят.

2. Доменка не живет в голове “самого опытного”
У нас описана доменная модель и зоны ответственности компонентов. То есть разработчику не нужно на каждый чих изобретать новую сущность, новый сервис и новый способ сделать побыстрее. Большая часть решений уже принята заранее, а шаринг знаний работает чуть сложнее, чем «посмотри MR Васяна, чтобы лучше понимать предметку»

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

4. Требования в автоматике
⁃ Хотим Google Coding Style — это проверяет линтер.
⁃ Хотим обязательное покрытие тестами — это проверяется автоматически.
⁃ Хотим убедиться, что тесты не декоративные — используем mutation testing.
То есть качество не держится на фразах вроде «ну мы вообще стараемся писать аккуратно», а встроено в пайпланы

Поэтому я довольно спокоен за свое будущее в мире разработки с AI. Если проект можно защитить от 20 джунов, то его можно защитить и от AI. Так что вопрос уже не в том, придет ли агентская разработка (можно сказать она уже отчасти здесь), а в том, сможем ли мы защитить его от цифровых джунов. И в этом кстати заключается отличие от модного нынче вайбкодинга.

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

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

Сказ о том, как мы обосрались

Не так давно мы писали, что запустили пилот — совместную работу над проектом, построенным по принципам чистой архитектуры и DDD. Причем проект не хелло ворлд, а вполне себе. Цель — походить по граблям и посмотреть, как они обходятся.

И… мы обосрались. По крайней мере поначалу. После пары месяцев группа развалилась. «Некогда, на работе завал» и тд. Но это было немного ожидаемо, так как пилот и все такое.

Далее немного подумали и пересобрались заново, уже с частично новой группой. Вот какие выводы можно сделать:

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

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

Больше поддержки: если что-то не получается — созваниваемся индивидуально. Но в разумных пределах. Постарались брать ребят с более-менее одинаковым уровнем.

Чередование нагрузки: на одной неделе подумать, на другой — покодить спинным мозгом.

Круговая порука: если кто-то бакланит, то группа за отведенный период узнает меньше.

Никаких «я сейчас меняю работу» — это огромная нагрузка на человека, и в итоге страдает вся команда.

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

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

1. Учись в свой час пик, а не по остаточному принципу. Уставший мозг не способен на сложное поэтому переноси обучение на утро или на то время, когда ты еще не утратил свежесть. Даже 30 минут в ресурсе дадут больше, чем два часа в режиме «дотупить и умереть».
2. Сделай так, чтобы бросать было невыгодно. Если ты учишься «просто так» — ты бросишь при первом завале на работе. Договорись с другом о штрафах, купи курс сразу на три месяца. Любая боль потери работает (хотя конечно и не на 100%)
3. Оценивай нагрузку с запасом, ибо твой энтузиазм врет. Перед стартом поживи неделю в новом режиме. Засеки часы и умножь на полтора, а потом оцени насколько это реалистично
4. Чередуй тяжелое и легкое. Одна неделя — врубить голову и разобраться в духоте,а следующая — покодить «спинным мозгом». Мозгу нужны передышки, а постоянное напряжение может испепелить его

Если придерживаться такого подхода длительное время, не перегружая и не насилуя себя, то спустя какое-то время вам не будет равных

Claude Opus 4,6 Extended, самая сильная модель в Мире. Ну что, уже приготовились к сокращению?

Не так давно я писал про борьбу с 100500 микросервисами. Продолжаем бороться: приступили к настройке и допилке. Естественно, нифига не работает, а документации толком нет (не будем же к каждому писать доку). А у каждого, между прочим, свои настройки.

Отладка и поиск причин падений — отдельный прикол. Даже если есть traceId и все логи аккуратно стекаются в какой-нибудь ELK — не спешите радоваться. На 20-м повторении одного и того же запроса через 10-й шлюз вы уже теряете нить происходящего. Справляться помогают только опыт поедания микросервисной субстанции, понимание паттернов говнокода и навыки реверс-инжиниринга (а так же ведро сожженых мозгов).

К концу второго месяца работы команды из нескольких человек + задолбанные представители заказчика — всё же позволили приблизиться к рабочему состоянию (но это неточно).

Дополнительное веселье — сбор нужных данных от соседей. Одно лежит в одном сервисе, другое — в другом, а что-то продублировано. Какие данные актуальнее? Сколько клиентов к сервисам нужно поднять, чтобы получить три сраных поля?

Зато всё масштабируемое, гибкое и модульное — аж ппц. Продолжаем наблюдения.

В Cursor тихой сапой меняют правила игры. Старый режим Privacy (без отправки кода на сервер) пометили как Legacy. Похоже, передача кода в облако скоро станет обязательной для всех новых функций (вроде фоновых агентов). Теперь можно только запретить обучение моделей на вашем коде, но сам факт его хранения на серверах становится обязательным.

Все детали по сбору данных и отказу от обучения собраны в их доке.

Интересно, а когда вообще Legacy-режим исчезнет совсем?

Намедни общались с архитекторами банка (те самые, у которых щеки по 2 кубометра — от постоянного раздувания, а просыпаются строго с фразой «доброе утро, коллеги»).

Делали небольшой модуль: на входе — информация о счёте (номер и т.д.), на выходе — шуршание купюр. Заметил, что в параметрах запроса на проведение платежа вместе с идентификатором счета передаётся тип счёта, хотя по некоторым типам операция запрещена. Уже выглядит стрёмно: тип можно перепутать при передаче, подменить намеренно, плюс логика фрагментируется. Это тоже самое, если бы в аэропорту в посадочном талоне указывали номер рейса, а дальше сам пассажир вписывал куда летит этот рейс, хотя направление и так известно. Если данные расходятся — кому верить?

Говорю: «Так мы ж обосраться можем». Ответ: «А вы тестируйте лучше» (при том что потребителей этого сервиса может быть много, что из них лучше тестировать?). Прям из разряда: «пишите код без багов».

Мораль: прежде чем делать программный интерфейс и не получить ведро геморроя — подумайте, что вы можете НЕ передавать.

Печальное постапокалиптическое будущее: разработчиков будут нанимать потому, что они обходятся дешевле, чем ИИ.

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

Вице-президент Nvidia по прикладному глубокому обучению Брайан Катанзаро признал: «У моей команды затраты на вычисления намного превышают расходы на сотрудников».

В общем, экономия денег на ИИ-токенах скоро станет новым трендом среди разработчиков.

а вы уже готовы оценивать задачи не в человеко-днях, а в тысячах токенов? 🙂

Продолжаем бодаться с электронным болваном.

Коллега недавно писал про «спираль энтропии». Как это выгдядит на практике: делаю прототип на Spring. Есть обычный класс LLMProvider, который отвечает за доступ к LLM. Вместо того чтобы подключить его через IoC-контейнер, ИИ просто создает экземпляр прямо в контроллере. Или вместо того, чтобы повторяющиеся куски промпта вынести в отдельный файл, мы получаем копипасту. И таких мелочей набегает целое ведро: нечитабельные тесты, кривое управление зависимостями, утечки ресурсов, да и просто какой-то мусор. Здесь хотя бы спасает то, что я понимаю, как должно быть устроено.

А вот другой пример, когда я сам не до конца понимаю, что делаю. Нужно было развернуть небольшой набор приложений в кубере. Сначала всё выглядело нормально, потом система постепенно обросла костылями. Что-то не заработало — ИИ в попытках починить начал накидывать всё более странные решения, причем на первый взгляд даже рабочие. Но после пересоздания подов всё снова разваливалось.

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

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

В 100500-й раз наступаем на одни и те же грабли. Может, вам не придется

Вероятно, кому-то из вас все нижесказанное покажется капитанством, но в моей практике история повторяется раз за разом.

Есть фронтенд-приложение, которое в собранном виде — просто js/html-статика, отдаваемая nginx’ом напрямую в браузер пользователя (SPA). И тут возникает главный вопрос: а как прописывать URL до API бекенда?

Какие вообще есть варианты?

Первый (и самый часто встречающийся) — захардкодить URL при сборке фронта. Главный минус: при переносе на другой домен или развороте на новом стенде фронт придется пересобирать под новый адрес. Админы в восторге, конечно. А потом начинается: «ооой, а отключите нам пожалуйста CORS, у нас ничего не работает». Ну вообще-то CORS как раз для того и придумали, чтобы ничего не работало, когда не надо.

Второй вариант — как-то передавать URL через настройки. Но как? В статику особо ничего не передашь: это же скомпиленный в жс тупескрипт без собственного поведения на сервере.

Как обычно выкручиваются: веб-приложение ходит по относительному адресу без хоста. То есть берет текущий домен и к нему уже приделывает все остальное.

А на стороне nginx настраивается proxy_pass, который проксирует запросы с определенным префиксом (например, /api/v1) дальше на бекенд.

В итоге:
— не нужно отключать CORS;
— фронт всегда ходит на тот же хост и порт;
— URL автоматически валиден на любом стенде и домене;
— фронт не нужно пересобирать под каждый environment.

У самого nginx тоже нет нормального механизма передачи параметров внутрь конфига (я тоже удивился, когда узнал, может сейчас уже что-то прикрутили), но и тут обычно выкручиваются через subst/envsubst.

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

Я случайно открыл новый (или давно забытый) способ писать промпты.

Летел я из Джакарты домой в Сингапур. Как обычно:
- на Netflix ничего не скачано
- Wi-Fi в самолёте стоит как крыло от него самого
В общем, надо чем-то себя занять.

Решил пописать код. Тем более была вполне интересная задача: написать небольшой rule engine для банка. Но есть нюанс:
- интернета нет
- локальных LLM нет
- писать всё руками, как наши деды в 2022-м, тоже не хотелось

И тут мне пришла идея: а что если поиграть с LLM в TDD ping-pong? То есть я руками пишу самое важное — спецификацию в виде тестов.
А модель потом сама генерирует реализацию под этот контракт.

Получалось примерно так:

@Test
fun `when term deposit created allow only deposit`() {
    val awaitFundingTd =
        accountRuleSet {
            withdrawal {
                default { denyAny() }
            }
            deposit {
                allowAny() { balances("funded") }
            }
        }

    awaitFundingTd
        .makeDecision(Withdrawal, "ATM Withdrawal")
        .shouldBeDenied()
}

Сразу захотелось сделать красивый DSL для правил. Потому что если делать DSL — то обязательно универсальный, расширяемый, чтобы потом переиспользовать для всех продуктов (да-да, конечно). Иначе зачем вообще начинать 😄

В итоге за полтора часа полёта я написал 7 тестов, 0 строк реализации и абсолютно ничего не компилировалось. То есть классический успешный TDD session. А уже дома вместо огромного промпта на 3 экрана с объяснениями что я вообще хочу я просто сказал Cursor "Сделай так, чтобы тесты проходили"

И получилось… идеально. С первого раза все тесты зазеленели, классы получились маленькими, интерфейсы аккуратные и никакой магической лапши. И тут до меня дошла довольно простая мысль: спецификацию можно задать не словами, используя расплывчатые формулировки вида "гибко, красиво и удобно", а сразу запердолить контракт в виде тестов.

Выходит, что LLM намного проще быть хорошим инженером, когда ты перестаёшь разговаривать с ней как продакт и начинаешь как разработчик