Признания программиста, создающего атмосферу
Делиться
Месяц назад я примерно за 25 часов разработал полноценную систему поиска с использованием эмбеддингов, гибридного поиска и графического интерфейса пользователя. В прошлые выходные я потратил два дня на исправление ошибки в ней — и понял, что понятия не имею, как работает мое собственное программное обеспечение.
Давайте будем честны: я загрузил репозиторий на GitHub, не написав ни строчки кода. Чувствую ли я себя из-за этого плохо? Отчасти. Меня сильно гнетут технические сомнения, гораздо сильнее, чем обычно. Пожалею ли я об этом? Возможно. А вы?
Я хотел поделиться своей историей здесь, потому что считаю, что с этим сейчас сталкиваются многие разработчики, и еще больше столкнутся с этим в ближайшие годы.
Потому что, давайте посмотрим правде в глаза: у вас может быть кодекс чести, и вы можете гордиться своим мастерством, но ничто не сравнится со скоростью GitHub Copilot и подобных сервисов. Если ваш коллега, словно на стероидах, выпускает новые функции и отправляет обновления в два раза быстрее (что сильно недооценивается), чем вы, то как вы думаете, кто окажется ближе к двери компании, когда бюджеты сократятся?
Повышение производительности реально, даже если вы используете эти инструменты только для документирования. И всего лишь небольшой шаг от:
«Напишите документацию для этой функции».
к
«Напишите функцию».
Этот крошечный шаг-подсказка мгновенно выводит вашу продуктивность на совершенно новый уровень.
Но вот моя личная история, то, чему я научился, и то, к чему, на мой взгляд, это нас, разработчиков, приводит.
Проект: создание собственной версии NotebookLM (но более строгой).
Для начала, я поставил перед собой задачу создать систему поиска текста в стиле RAG, аналогичную NotebookLM, но более строгую. Система берет частную библиотеку PDF-файлов, обрабатывает ее, а затем извлекает ответы дословно из этого корпуса. Никакого перефразирования, никаких выдуманных предложений, просто «дайте мне точный отрывок, который отвечает на мой вопрос, чтобы я мог снова найти его в исходном PDF-файле».
Признаю, это очень научный, слегка параноидальный способ использования литературы. Но, вероятно, я не единственный, кто устал проверять каждый ответ на магистерскую диссертацию по фактам, сверяя его с источником.
Архитектура программного обеспечения была довольно простой:
- Надежный конвейер обработки данных: обход древовидных каталогов, извлечение текста из PDF-файлов и его нормализация на абзацы и перекрывающиеся фрагменты.
- Гибридное хранение и поиск: уровень хранения, объединяющий стандартные таблицы SQL, систему полнотекстового поиска с инвертированным индексом (для точного совпадения ключевых слов) и векторную базу данных (для семантического понимания).
- Стратегия переранжирования: использование логики для отбора широкого круга кандидатов с помощью лексического поиска, а затем переранжирование результатов с использованием плотной векторной схожести для получения наилучшего результата от обоих подходов.
- Полноценный пользовательский интерфейс: панель управления для контроля библиотеки PDF-файлов, отслеживания процесса загрузки и отображения результатов с прямыми ссылками на исходный текст.
На бумаге всё довольно просто. Python, Streamlit, SQLite+FTS5, FAISS, модель преобразования предложений — всё это упаковано в контейнер Docker. Никаких экзотических облачных зависимостей, просто частный инструмент, похожий на NotebookLM, работающий на моей машине.
Подход, основанный на приоритете документации.
Я начал не с кода, а с документации. У меня уже был готовый шаблон проекта, так что структура была налицо: место для требований, для проектных решений, для развертывания и тестирования — все это аккуратно хранилось в папке docs, ожидая заполнения.
Я записал сценарий использования, набросал архитектуру, алгоритмы для реализации, требования. Я описал цели, ограничения и основные компоненты в нескольких пунктах, а затем позволил genAI помочь мне расширить более длинные разделы, когда у меня уже была общая идея. Таким образом, я постепенно перешел от базовой идеи к заполнению более подробных документов, описывающих инструмент. В результате получилась не самая лучшая документация, но она была достаточно понятной, чтобы теоретически я мог передать весь пакет начинающему разработчику, и он бы знал, что нужно создавать.
Внедряю своего коллегу-ИИ в кодовую базу.
Вместо этого я передал его автомату.
Я открыл двери и впустил своего коллегу из GitHub Copilot в кодовую базу. Я попросил его создать структуру проекта по своему усмотрению, а также заполнить необходимые скриптовые файлы. После того, как базовая структура была установлена и инструмент, казалось, работал с одним алгоритмом, я также попросил его сгенерировать набор тестов pytest, выполнить тест и повторять действия при возникновении ошибок. После этого я продолжил работу, попросив его реализовать дополнительные алгоритмы и охватить некоторые граничные случаи.
По сути, я следовал своему обычному подходу к разработке программного обеспечения: начинал с работающего ядра, затем расширял его дополнительными функциями и исправлял ошибки всякий раз, когда растущая структура сталкивалась с серьезными проблемами. Является ли это глобально оптимальной архитектурой? Вероятно, нет. Но это очень соответствует духу прагматичного программиста: упрощайте, итеративно совершенствуйтесь и часто выпускайте новые версии — даже если это происходит только внутри компании и только для меня самого.
И есть что-то глубоко удовлетворяющее в том, чтобы видеть, как твои идеи воплощаются в работающий инструмент за один день. Работа с моим коллегой-ИИ ощущалась как работа руководителем проекта, которым я всегда хотел быть: даже мои непродуманные пожелания были предвосхищены и реализованы за считанные секунды в виде в основном работающего кода.
Когда код не работал, я копировал и вставлял трассировку стека в чат и позволял агенту отлаживать его самостоятельно. Если же он застревал в какой-то собственной ловушке, я переключал модели с GPT5 на Grok или обратно, и они отлаживали друг друга, как соперничающие братья.
Было очень интересно наблюдать за ходом их мыслей и за тем, как быстро росла кодовая база. Я лишь приблизительно оценил время, затраченное на этот проект, поскольку это был побочный эксперимент, но на создание более 5000 строк кода ушло не более 25 часов. Это, безусловно, большое достижение для относительно сложного инструмента, который в противном случае мог бы занять у меня несколько месяцев. Он всё ещё далёк от совершенства, но делает то, что я задумал: я могу экспериментировать с различными моделями и алгоритмами суммирования поверх ядра поиска, которое возвращает дословные ответы из моей собственной библиотеки вместе с точным исходным кодом, так что я могу сразу перейти к работе с базовым документом.
А потом я оставил его в покое на месяц.
Похмелье от технического долга
Когда я вернулся, я не хотел добавлять какую-то важную функцию. Я просто хотел упаковать приложение в Docker, чтобы поделиться им с другом.
В моей голове это казалось простой задачей на субботнее утро. Вместо этого, она превратилась в настоящий кошмар на все выходные: проблемы с конфигурацией Docker, некорректное разрешение путей внутри контейнера, встраивание кэшей и индексов FAISS в места, которые я нечетко отделил от кода, и тесты, проходящие на моей локальной машине, но проваливающиеся (или вообще не запускающиеся) внутри CI/CD.
Некоторые из этих проблем полностью на моей совести. Я с радостью предположил, что мой конвейер CI/CD (также созданный с помощью ИИ) «сам справится» с этим, запуская тесты на GitHub, благодаря чему кроссплатформенные несоответствия будут выявляться на ранней стадии. Спойлер: этого не произошло.
Реальность настигла меня, когда Copilot предложил, казалось бы, простое решение: «Просто добавьте ссылку на рабочий каталог здесь». Вместо того чтобы позволить ему вмешиваться в код, я хотел сохранить контроль и запрашивать только указания. Я не хотел, чтобы он нанёс ущерб кодовой базе, которую я не просматривал неделями.
Тогда я и осознал, сколько всего я отдал на аутсорсинг.
Я не только не понимал, почему вообще возникла ошибка, но и не мог определить ни файл, ни фрагмент текста, в котором нужно было внести изменения. Я понятия не имел, что происходит.
Сравните это с другим проектом, который я делал с коллегой три года назад. Я до сих пор помню, как некоторые функции были взаимосвязаны, и ту глупую ошибку, которую мы часами искали, только чтобы обнаружить, что один из нас неправильно написал имя объекта.
Неприятная правда
Я сэкономил огромное количество времени на разработку, пропустив низкоуровневую реализацию. Я сохранил контроль над архитектурой, целями и проектными решениями.
Но не подробности.
По сути, я стал техническим руководителем проекта, единственным разработчиком которого был искусственный интеллект. В результате создаётся впечатление, что для меня это сделал очень быстрый и очень самоуверенный подрядчик. Код имеет необычайно хорошую документацию и неплохие тесты, но его ментальные модели так и не пришли мне в голову.
Смог бы я что-нибудь исправить, если бы мне понадобилось внести изменения, а интернет был бы отключен? Реалистично: нет. Или, по крайней мере, не быстрее, чем если бы я унаследовал этот код от коллеги, который ушел из компании год назад.
Несмотря на довольно хорошую документацию, я всё ещё натыкаюсь на непонятные фрагменты кода. Справедливости ради, это происходит и с кодом, написанным людьми, включая мой собственный, созданный несколько месяцев назад. Так GenAI ухудшает ситуацию? Или просто ускоряет её?
Итак… Vibe-кодирование — это хорошо или плохо?
Честно говоря: и то, и другое.
Скорость просто невероятная. Возможности для повышения эффективности реальны. Разрыв в производительности между теми, кто активно использует эти инструменты, и теми, кто этого не делает, будет только увеличиваться. Но вы меняете тесную связь с процессом внедрения на архитектурный контроль.
Вы переходите от мастера к руководителю. От строителя к руководителю проекта. От знания каждого винтика в механизме к доверию роботу, который собрал автомобиль. И, возможно, именно в это незаметно превращается разработка программного обеспечения.
Лично я теперь чувствую себя гораздо больше руководителем проекта или ведущим архитектором: я контролирую общую картину и уверен, что смогу продолжить проект через год и расширить его. Но в то же время, это не похоже на «мой» код. Точно так же, как в классической схеме ведущий архитектор не «владеет» каждой строкой кода, написанной его командой.
Это моя система, моя разработка, моя ответственность.
А что насчет кода? Код принадлежит машине.
Ссылки
- Эндрю Хант, Дэвид Томас, Уорд Каннингем (1999): Прагматичный программист. От подмастерья к мастеру.
- Сгенерированный репозиторий: https://github.com/ElenJ/PrivatePageQuery
- Мой шаблон CookieCutter с шаблонами документации: https://github.com/ElenJ/cookiecutter_streamlit_ml
Источник: towardsdatascience.com
