How to keep enjoying programming in a world of LLMs

Автор делится личным опытом сохранения удовольствия от программирования в эпоху LLM, подчёркивая, что радость приходит не от результата, а от процесса написания кода — особенно на Haskell, где выразительность языка доставляет эстетическое удовольствие. Он предупреждает о риске превращения программиста в «шестёрню машины», когда спецификации просто передаются в LLM, а человек лишь проверяет вывод, теряя навыки и вовлечённость. Чтобы этого избежать, он предлагает продолжать писать код самостоятельно, даже если это замедляет работу, поскольку навыки атрофируются без практики, а чрезмерная зависимость от генерации ведёт к потере владения кодовой базой и ухудшению её качества. Особое внимание уделяется социальной стороне разработки: автор настаивает на том, что общение между людьми — через коммиты, issues и pull requests — остаётся основой качественной разработки, и полностью сгенерированные сообщения не заменяют человеческого взаимодействия, их лучше прилагать как вспомогательный материал, который коллеги могут игнорировать. В итоге он описывает свой подход как умеренное использование LLM — как «органическое удобрение» для садовода, а не химическое наводнение — позволяющее сохранить продуктивность без выгорания и потери удовольствия от труда. Его метод работает: он чувствует себя примерно вдвое продуктивнее, но главное — сохранил страсть к программированию.

Комментарии (335)

Удовольствие от программирования в эпоху LLM зависит не от инструментов, а от сохранения контроля над мышлением и архитектурным пониманием. Используйте LLM для сжатия расстояния между идеей и кодом, но не передавайте им понимание взаимодействия компонентов системы — это сохраняет глубину знаний. Для рутинных задач применяйте LLM; для приятных — пишите код вручную, чтобы сохранить мотивацию и эстетическое удовлетворение. Используйте LLM как инструмент обучения: генерируйте туториалы и шпаргалки под свой стиль восприятия, чтобы быстрее осваивать новые библиотеки. Пишите собственный язык программирования с нуля без LLM — это восстанавливает глубокое понимание конструкций и предотвращает атрофию навыков. Применяйте маленькие модели с низкой рассуждающей способностью, чтобы не терять контроль и не ждать долгих ответов — это сохраняет ощущение прямого взаимодействия с кодом. Не позволяйте LLM переписывать вашу архитектуру — это разрушает внутреннюю модель системы и делает код непредсказуемым. Используйте LLM для генерации и проверки юнит-тестов, а не для основной логики — это освобождает время для сложных задач и повышает качество тестирования. Применяйте LLM для анализа продакшн-данных и сравнения форматов — это позволяет находить скрытые несоответствия быстрее, чем ручной аудит. Чрезмерное использование LLM приводит к потере способности самостоятельно проектировать архитектуру, вызывая тревогу и дезориентацию. Некоторые считают, что LLM убивают удовольствие, превращая программиста в проверяющую шестерёнку; другие утверждают, что они освобождают от рутины и позволяют сосредоточиться на интересных задачах. Ручное программирование сравнивают с кузнечным ремеслом — ценность в процессе, даже если экономически неэффективно; отказ от автоматизации называют упрямством, как отказ от мощных инструментов в строительстве. Не принимайте результаты LLM как факты — всегда проверяйте их, иначе накопите технический долг, стоящий в десятки раз дороже профилактики. Используйте LLM для чтения и резюмирования чужого кода — это ускоряет понимание сложных кодбаз с устаревшей документацией. Если чувствуете потерю навыков, вернитесь к ручному написанию кода — даже на бумаге — чтобы восстановить интуитивное понимание, атрофирующееся при зависимости от LLM. Программирование становится хобби, где ценность в процессе, а не в результате или прибыли — как кузнечное дело или изготовление гитар.