ИИ-ревью, или как я себя чуть не уволил

AI-ревьюер для GitLab, который проверяет не отдельный merge request, а всю задачу сразу, во всех сервисах, которые она задела. И почему для этого понадобился агент, а не анализ diff через API.

AI-ревьюер для GitLab, который проверяет не отдельный merge request, а всю задачу сразу, во всех сервисах, которые она задела. И почему для этого понадобился агент, а не анализ diff через API.

Недавно индустрия снова вздрогнула. Вся IT-тусовка обсуждала историю о том, как автономный ИИ-агент под управлением Claude за 9 секунд полностью уничтожил продакшен-базу данных компании PocketOS. Ирония в том, что в системном промпте модели было черным по белому написано: «НИКОГДА не запускай деструктивные команды без явного одобрения пользователя». Модель после «преступления» сама честно призналась в нарушении правил, но базу это не вернуло.
Если вы думали, что это единичный случай, то спешу огорчить. Вспомним еще несколько громких катастроф:

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

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

Когда начинаешь новый проект, то надо какое то время потратить чтобы подобрать подходящие библиотеки, подготовить структуру проекта, связать все воедино. Это занимает прилично времени. Целый день вполне может уйти. А экономить на этом шаге не стоит. Это ведь как фундамент. И вот, 5 лет назад я опубликовал каркас, который собрал для себя, чтобы делать с ним проекты на Go.
С тех пор мне обращались люди и с вопросами и с советами. Я менял компоненты, смотрел что получалось. Благо проектов было предостаточно. Вот и давайте подведем некий итог, что в заложенной структуре хорошо, а что не очень.
DI
По теме DI ко мне в чаще всего обращались с критикой, в том числе и коллеги. Поэтому с этого и начнем. В основном предлагали 2 идеи
Недавно в проекте на Laravel+Eloquent понадобилось сделать печатные формы документов — счетов, договоров в формате Word. Так как в системе много разных документов, то решил сделать универсально, чтобы можно было потом использовать и в других проектах.
В итоге получилась реализация, которая требует минимум затрат на интеграцию в проект.


Недавно понадобилось реализовать поиск по началу строки, по сути WHERE name LIKE 'начало%'. Это был поиск по названию биржевых символов (AAPL, AMZN, EUR/USD и пр.). Хотелось, чтобы поиск работал быстро, и не нагружал лишний раз БД. В итоге пришел к реализации поиска по дереву в памяти, об этом и расскажу.
В процессе знакомства с Golang я решил сделать каркас приложения, с которым мне в дальнейшем будет удобно работать. В результате получилась на мой взгляд хорошая заготовка, которой я решил поделиться, и заодно обсудить моменты, которые возникли по ходу создания каркаса.

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



dispatch(), примерно так:



Недавно я попробовал pthreads и был приятно удивлен — это расширение, которое добавляет в PHP возможность работать с несколькими самыми настоящими потоками. Никакой эмуляции, никакой магии, никаких фейков — все по-настоящему.

Я рассматриваю такую задачу. Есть пул заданий, которые надо побыстрее выполнить. В PHP есть и другие инструменты для решения этой задачи, тут они не упоминаются, статья именно про pthreads.
Стоит отметить, что автор расширения, Joe Watkins, в своих статьях предупреждает, что многопоточность — это всегда не просто и надо быть к этому готовым.
Кто не испугался, идем далее.
