ITипичные аспекты Артёма

Предыдущее тут
3/5 пост =)

Среда-Четверг, 10+11=21ч
Был получен минимальный рабочий сценарий с файлами. Весь день посвящён структурированию бэка, разделению логики web бэкенда и аналитического бэкенда на разные сервисы, devops активностям, закладыванию моделей БД. Затянуты Mongo - основная БД, Minio - локальный S3 и Redis как БД коммуникации и шеринга состояний между сервисами

Моей ошибкой, унёсшей ~4 часа времени стала попытка сделать по-быстрому локальное хранилище вместо S3. ИИ запутался в папках и роутинг раздачи файликов не взлетел.
Нужно было сразу брать minio и на лету перепиливать S3 на S3 по сути. Пришлось отбросить/вырезать некоторое количество кода. Слава Git

Переработал LLM суммаризацию. Основная работа заключалась в вынесении конфига и ограждению курсора от попыток сменить схему SO с рабочей на нерабочую. В исходной кодбазе с неё всё было хорошо

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

Инсайты
- ИИ имеет свойство плодить кривые конфиги в разных местах. Это должно подвергаться контролю за счёт Rules, темплейтов проекта

- Нельзя вайбкодить сложную задачу. (вайбкод - не вдумываясь принимать изменения ИИ). С каждой следующей итерацией и уточнением, особенно если что-то не получается, ИИ заходит всё дальше в дебри и пишет всё более локальноориентированный структурно хреновый код
И это как будто бы базовое правило coding with AI. Ты должен вмешаться, проанализировать и выбрать корректный подход прежде чем ИИ затронет слишком многое. Возможно принять решение запустить всё с самого начала.

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

- ИИ затрагивает широкий набор изменений в рамках своей работы, часто работаешь над 2-3 параллельными задачами/направлениями изменений. Это осложняет классическую историю ведения гита. Очень важно регулярно уделять внимание регрессу и делать отсечки, которые пойдут коммитом в гит.
В курсоре можно откатываться на чекпоинты чатиков, но это не всегда работает и неудобно.
Уверенность, что я могу надёжно откатиться на рабочую версию - залог спокойной работы

Как итог, считаю, что мастхэв должен быть шаблон проекта, адаптированный под ИИ, где уже организована и тщательно описана желаемая организация проекта:
* Конфиги и их место
* Лучшие практики инфры вплоть до шаблонов докеров,
* Заложены примеры привычных схем, ролей, моделей.
* Подключены на уровне низкоуровневых адаптеров человекописные базовые внешние модули типа БД, web-сессий, сокетов и т.д.
* Продумана и заложена механика проброса зависимостей и централизованной инициализации модулей.
* Оно позволяет вносить изменения уже отсраиваясь от лучших практик, более точечно

ИИ склонен тупо херачить глобальные объекты и начинает творить лютую дичь как только ловит от этого сложности


На конец четверга, четвёртый физический день работы, уже проходили все базовые сценарии проекта, завязанные непосредственно на ЛК и обработку звуковых файлов. UI принял околофинальные очертания, вырисовалась более стройная организация и инфраструктурная обвязка. Проект билдился в докер и запускался на сервере

Начало

Продолжу описывать процесс работы длиной в (предыдущую) неделю,мысли подходы в формате:
* Затраченное время
* Какие изменения вносил
* Какие выводы сделаны/инсайты получены


пнд-втр, 10+14=24ч.
- Загружен проект, проведена первичная оценка имеющейся кодбазы. У меня есть целый гуглдокумент на 9 страниц с говной, где я выписывал как на ревью все проблемы исходника.
Мы хотели во имя науки скормить его в таком виде ИИ чтоб он составил себе подробное ТЗ и по нему прошёлся, закрыв дыры
Эксперимент признан неудачным

Сводка самых критичных моментов:
- отсутствие БД(!), консистентного хранилища состояния.
- Фронт на сырых HTML шаблонах
- ЯндексS3 как единственное хранилище файлов (я не планировал использовать внешнее S3)
- Также наблюдалось огромное количество дыр в безопасности и производительности: по моим подсчётам, оно не должно было вытягивать больше 2-3 человек одновременно
- Модели кэшировались очень частично и вызывали зависания на несколько минут из-за подгрузки гигабайтов весов каждый первый запуск
- В некоторых кейсах происходили очень неявные критические баги. К примеру, если первая задача в систему не была с флагом на разделение спикеров, то ни одна последующая эту функцию запустить уже не сможет

Я очень недооценил на старте сырость исходника.
Вместе с тем, и это очень важно, Оно работало! Легаси кодбаза уже выступала в роли технического концепта желаемого функционала, а значит все ответы и фичи, хоть и реализованные криво уже были в ней, и моей задачей стал перепил структуры и организации кодбазы


Инсайты
- Я долго пытался понять, с какого бока приступить, это было очень сложной задачей - найти точку входа для изменений на легаси в 2-3к строк. Начал с фронта, философски отнесясь к бэкенду как к чёрной коробке с публичным контрактом, и потом уже переходить к бэку

- Фронт перепилился в TS+Vite приложение на удивление спокойно. Я, как совсем не фронтендер, не догадываюсь, какие ужасы там творились. Оно и к лучшему.
Самый важный инсайт - если позаботиться о хороших подробных описаниях-промптах и приложить референсы - ИИ может осилить даже объёмные структурные изменения.

- Хорошо показал себя метод, где сначала ИИ переписывает всё в один более большой файл и потом уже разбивает на несколько маленьких отдельной цепочкой рефакторинг промпт-задач

- Бэк представлял собой зрелище, не самое страшное в моей практике, но опасное ввиду неявно заложеннных бомб

ИИ плохо справляется с уменьшением сложности/вложенности кода и не всегда понимает проблему асинхронности, организации IO/Heavy задач.
Фокус на локальном решении текущей мелкой проблемы осложняет использование общих абстракций, моделей. Это должно фокусироваться отдельно через Rules, промпты.

Ненужная вложенность кода (функция обращается к функции которая обращается к функции и на каждом этапе размазан какой-то минимум важного кода) - характерная особенность ИИ стиля

- Очень приятный момент, можно спокойно писать "форму с логином" или "таймер в главном окне рядом с окном загрузки" - ИИ прекрасно оцифровывает и меняет нужные компоненты

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

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

Никогда не спрашивайте ИИ напрямую, почему оно что-либо сделало, оно засчитает это за предъяву

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

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

Страх и ненависть в Cursor

Тренды идут, а я не в трендах. Да и кодинг навыки в бытность мою лидом начали практиковаться значительно меньше 4-6 часов в день, необходимых для поддержания формы.
Потому, вдохновлённый опытом Валеры, моего любимого соратника-затейника, я самоорганизовался в недельный хак-интенсив безудержного AI кодинга.

Центральная идея
Глобально - Возможно ли за счёт скорости и экспертизы AI написать качественный код в сроки демки?
Если так, AI кодинг при должных навыках способен открыть прямой и быстрый прыжок от демо-прототипа к MVP.
Почему это важно:
Сейчас демки собираются либо на коленке, либо на морально волевых. И потом, как правило, переписывается под 0, часто уже другой командой, ибо говнокод, противно и нерасширябельно.
MVP - уже достаточно развитая система с проработанным и зафиксированным наборов бизнес-фичей, пригодная для стабильного запуска на малой аудитории, достаточно качественная и корректно организованная технически для комфортной итерационной разработки/развития в будущем.

С чем стартовал:
Ящик энергетосов и репо мне на растерзание. Как здесь, только страшнее, с повышенным содержанием сенситивных данных, хардкода ссылок и невменяемого .env. Это результат ~30 часов ИИ кодинга специалиста, не занимающегося промышленным программированием. Буду далее называть его легаси кодбазой.

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

class DatabaseService:
    """Сервис для работы с JSON базой данных"""
    
    def __init__(self):
        self.lock = threading.Lock()
    
    def load_database(self) -> Dict:
        """Загрузка базы данных из JSON файла"""
        with self.lock:
            if DATABASE_FILE.exists():
                try:
                    with open(DATABASE_FILE, 'r', encoding='utf-8') as f:
                        data = json.load(f)
                        # Обеспечиваем структуру базы данных
                        if 'transcriptions' not in data:
                            data['transcriptions'] = {}
                        if 'users' not in data:
                            data['users'] = {}
                        if 'sessions' not in data:
                            data['sessions'] = {}
                        return data

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


Задачи интенсива
- Разработать систему транскрибации, как можно ближе сходящуюся к уровню MVP по зрелости и качеству кода и технической архитектуры.
Небходимые целевые фичи:
* Гугл авторизация
* Получение транскрипта файла (в базу взяли WhisperX)
* Получение разбиения по спикерам (pyannote)
* Аналитический отчёт по содержанию файла ( LLM + proдуманный prompt)
* Запись встреч (ввиду сжатых сроков пришли к идее google extension - запись вкладка+микро, что мне кажется гениальным в своей универсальности)
* Развёртывание на сервере, Docker базовая инфра

- Посчитать выигрыш в своей скорости относительно плана реализации вручную.
- Выявить для себя правила оптимального использования ИИ
- Разобрать кейс доработки "легаси" кодбазы.

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

VectorDB и актуальность третьего пункта предыдущего поста
Для иллюстрации - один несуразный кейс из личного опыта

В запрошлогодние времена было очень модно собирать RAG, чьим необходимым компонентом являлась векторная БД. Путём некоторого сёрча было решено выбрать FAISS+MongoDB между ChromaDB и Milvus. Хрома в тот момент была совсем свеженькой вундервафлиной с понятным интерфейсом и юзкейсами, ну и в целом хорошим быстродействием при своей простоте. И эмбеддер ещё кастомный можно было легко запихнуть.

Меня особенно привлекла роадмапа и обсуждение на gh, где активно стояла повестка добавления BM25 -> FTS и Hybrid search. Из всего этого мне вырисовывалась интересная идея легковесного тулза, заточенного под нужды нарастающего тренда GenAI/агентных систем. А такое надо бы пробовать и брать на вооружение

Именно этот RAG-проект из чего-то экспериментального решил вырасти до более солидных размеров, а chroma так и оставалась основной векторной БД. Надо отдать должное, вытягивала нагрузку.
Но мои ожидания, как водится, остались только моими. Команда сфокусировалась на создании managed инфры, что, имхо, видится немного странным решением при присутствии гораздо более развитых в т.ч. технологически систем с внушительной базой комьюнити.

И всё. Это не история пожара или какого-то былинного проёба.
При этом смысла выбирать/оставаться именно Chroma на перспективу - принимать риски использования ранних версий и возможного свитча в будущем - не оказалось.

Стремящийся к идеальному интерфейс
Немного идеологии к которой я хочу апеллировать в дальнейшем.

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

Если сузить: Оценивая что-то свеженькое и достаточно сырое, как прикинуть потенциал?
Кратко вывел для себя
0) насколько это тебя возбуждает
1 )Насколько предложенная технологией идея/интерфейс решает существующую проблему/облегчает жизнь.
2) Насколько интуитивно она это делает. Если начать ей пользоваться - будет оно ощущаться на кончиках пальцев или скорее как успех вопреки.
3) Насколько стабильно она развивается, есть ли шанс дойти до сколько-то зрелого состояния в обозримые сроки?

Ну, почти всё как у людей.

Разрабатывали сервис выгрузки эвентов под кафку, а потом выяснилось, что эвент не эвент, в кафку нам нельзя, документации под неё не будет. Надо что-то более классическое

заметки, кейсы, Личные Базы Знаний и что с ними не так

Я какое-то время думал/пробовал профессиональные заметки вести. Всё упёрлось что в нужное время их фиг достанешь - даже свои для себя -и надо либо очень тщательно оформлять в конкретные (оптимизированные под дальнейший поиск, извлечение данных) кейсы с кучей сопровождающего кода и комментов, либо оставлять в формате минидока-кодекса со ссылками + оглавлением, к которым вернёшься практически никогда.

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

так и забил пытаться что-то полезное в формат ЛБЗ преобразовать.

Тут есть ещё идеологические вопросы - для себя поддерживать ЛБЗ как будто бы зачастую и не всралось, не хватает дисциплины. Вся инфа или уже у тебя в голове или устарело или рольнёт только через полгода.

Шитпостить в канал как-то благодарнее получается

Существенное о себе

Активно практикующий, почти не выгорающий широкопрофильный специалист

Успел поработать в крайне разных по зрелости процессов, скорости разработки и опыту людей командах. От минихалтурок до вполне себе масштабных систем. Разве что до MANGA пока не добрался
Что-то успел позапускать прям со старта, прям с нуля. Часть оного до сих пор умудряется работать

На текущем этапе карьеры выполняю спектр работ между техническим архитектором тимлидом и python backend.
И на этом поле ещё существенно стоит подрасти

Подход к работе в двух словах: "Было бы хорошо - меня бы не позвали"



Чем занимался и что умею:
Robotics - Еще в студенческие времена потрогал роботов за манипуляторы.
Знал что-то про кинематику и еë задачи. Немного задротил графы и алгоритмы.

Python backend - практически основное и регулярное моё занятие во всех его проявлениях
Покатался Django->aiohttp->fastapi

Computer Vision - писал аналитику под данные с радаров, лидаров, стерео камер, веб-камер, специализированных CV камер.

Самое сложное и наукозависимое чем я занимался ever - как раз было из этой области.
Как запихнуть целый каскад разнообразной аналитики в небольшую автономную камеру.
Как связать 8 таких камер в единую систему и не поехать крышей

Боты/парсеры - писал маленьких, писал больших и нагруженных, владею хорошим арсеналом способов не палиться (что ты бот) в интернетах. Вряд ли сейчас этим кого-то удивишь. Много работал с платформой telegram

GenAI/LLM - побывал СТО исследовательской лаборатории, Активно ресёрчил и проводил кучу экспериментов с LLM, их бенчмаркингом, поведением в условиях ограниченного контекста. Собрал и довёл до релиза полноценный RAG.

Технологии поиска/биометрии - что-то знаю про поисковые системы, алгоритмы поиска и индексации на больших объемах данных
Возможно причастен к созданию некоторых СКУД(не государственных)


Текущая занятость:
TeamLead, full time. Команда 8 человек. + sides
Проект: система интерактивного голосового общения/опроса абонентов под крайне разные языки, Voice/VoIP/GenAI технологии


Сферы интересов:
- Python и вся его экосистема
- Web, backend и сопутствующие технологии
- GenAI, LLM, agents
- Собесы/техскрининг, и как проводить их так, чтобы после никому не было слишком стыдно или слишком больно
- Организация рабочего контекста и его паттерны

Лично-профессиональный канал

Я долго прикидывал, насколько мне всё это вообще надо.
Канал, да ещё и профессиональный, да ещё и с которого происходят попытки авторитетно вещать - есть у каждого третьего-встречного-поперечного.
При этом контент такого уровня, что не пролистываю и слежу с интересом у ~4/30 техноканалов из всех подписанных

Одна мысль о вливании в подобную суету вызывает приступы тлетворности бытия. Но и несколько любопытных гипотез напопробовать призывает тоже

Как я представляю себе контент?
- Относительная краткость 70% контента, 3-7 абзацев без растекания мыслью по теме.
- Содержит некоторую техническую ценность, связанную с моей профессиональной деятельностью
- Неструктурированные заметки, кодсемплы, скрины
- Дозволительно иметь явный эмоциональный окрас/личностную субъективную оценку, куски поверхностных и поспешных суждений в моменте
- Часть контента может быть самозабвенно стянута извне и вольно интерпретирована

Channel created