Не называйте себя artisanal-программистом

Запись в блоге purplesyringa от 13 сентября 2026 года. Автор не пользуется LLM, и объясняет это не удовольствием от процесса, а надёжностью. Проектируя программу с нуля и не торопясь, она уверена в её корректности, а любая ошибка оказывается простой опечаткой. Модульные тесты, ревью с помощью LLM и пруверы способны довести код до 99% правильности, но не дотянут оставшийся 1%: оптимальность, поддерживаемость, читаемость и независимость от недокументированного поведения. Ей нужны 100%, она убеждена, что для этого необходима глубокая связь с кодом, и отказывается от инструментов, которые изолируют её от низкоуровневых деталей.

Ярлык

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

За более взвешенным взглядом она обращается к кроссовер-проекту Хиллела Уэйна (Hillel Wayne) 2021 года - серии интервью с людьми, перешедшими в разработку ПО из традиционной инженерии (вторая часть описана в we-are-not-special). Его собеседники отмечали, что программная инженерия - это настоящая инженерия, но многие пишущие код ею не занимаются (подобно тому как не всякий работающий с электричеством является инженером-электриком), и что в этой области не хватает слов для обозначения такой разницы; "некоторые предлагают слово 'software craftsman'". Она трактует это так, что Уэйн относит аккуратных специалистов к инженерам, а остальных - к ремесленникам (craftsman), что прямо противоположно сегодняшнему словоупотреблению. И добавляет, что в составлении промптов, пожалуй, больше искусства, чем в ручном написании кода. Проекция на ИИ принадлежит самой purplesyringa: интервью Уэйна вышли до появления vibecoding, и его разграничение касалось инженерной практики в целом.

Принятие ярлыка "artisanal", по её мнению, освободило слово "инженер" и сдало без боя спор о том, является ли vibecoding инженерией. В итоге vibecoding стал нормой по умолчанию, а ручное написание кода - отклонением от нормы.

Качественный сдвиг

Она обращает внимание на то, как быстро сместились привычные представления. Раньше публикации разработчиков статического анализа воспринимались как реклама, а теперь инструментами автоматического ревью восхищаются; индустрия практически в одночасье перешла от споров о строгих системах типов к спецификациям в свободной форме. Прежние споры о системах типов или фреймворках велись вокруг того, какой вариант надёжнее или проще, и даже карикатурный фанатик Rust всё равно признавал разработчика на PHP коллегой-разработчиком. Нынешний же дискурс выставляет vibecoding единственным разумным выбором, а альтернативу низводит до уровня хобби, что она называет атакой на профессиональную идентичность.

Переопределение терминов таким образом, чтобы одна сторона выглядела разумной, а вторую даже не имело смысла рассматривать, для индустрии разработки в новинку, пишет она, добавляя, что раньше видела такое в арсенале фашистской пропаганды (хотя и оговаривается, что не считает происходящее спецоперацией). Её доказательства стремительности перемен основаны на отдельных наблюдениях: сначала люди шутили, что антоним к слову vibecoder - это инженер-программист, а уже через месяц спокойно называли себя artisanal-программистами. Композиторы ведь не называют себя композиторами-ремесленниками, а борьба за значение слова "программист" ещё толком и не состоялась. Многие геймеры, защищающие художников от ИИ, без малейших сомнений принимают код от LLM - это автор объясняет тем, что неспециалисты ориентируются на риторику, а не на факты.

Почему программисты проиграли первыми

Её объяснение - антиинтеллектуализм в сообществах программистов. До того как Rust стал популярным, от него отмахивались как от голой математики; от монад в Haskell отмахиваются до сих пор, хотя Rust показал, что понять их несложно; даже указатели считаются сложными просто потому, что сперва нужно чему-то научиться. Привычка копировать со StackOverflow переросла в привычку копировать из Claude. Отрасль, которая обесценивает образование, упорный труд и готовность тратить время, неизбежно должна была объявить вдумчивую работу баловством.

Что она предлагает

Не переворачивать риторику с ног на голову, утверждая, будто программирование без ИИ - единственный правильный путь: такая попытка обречена на провал. Цель в том, чтобы сохранить разработку без ИИ в публичном поле и не позволить приравнивать её к развлекательному программированию ради удовольствия. Она предлагает использовать термины "AI-assisted coding", когда применяется ИИ, и "AI-free software engineering", когда он не используется. Это сохраняет указание на используемые инструменты, но переносит статус инженерии на вторую половину названия и избавляет от слова, намекающего на игру. Помимо терминологии, она призывает программистов рассказывать о том, сколько заботы они вкладывают в софт, как они его проектируют, как взаимодействуют друг с другом и в чём проявляется их человеческий фактор. Если человек, не умеющий рисовать, способен почувствовать обман в сгенерированном ИИ арте, то же самое должно работать и в отношении программ.

Контекст

Фрейминг, против которого она выступает, почти дословно появился неделей ранее в programming-is-art-orchid, написанной автором, вполне готовым оставить ручное написание кода "художникам", пока сам он делает стартапы с помощью ИИ. Её предложение по терминологии переносит соглашение о раскрытии информации в название профессии - по аналогии с human-made-disclosure и no-ai-statements, и так же держится на честном слове автора. Заметка checking-for-human-writing утверждает прямо противоположное в отношении текстов: авторство заключается в суждении и отборе, а не в генерации каждого отдельного слова. У purplesyringa тезис уже - о корректности на этапе конструирования, однако читатель, согласный с Шеху (Shehu), потребует показать, что недостающий 1% действительно недостижим с помощью инструментов. На карте anti-llm-discourse эта статья представляет позицию защиты ремесла через риторику, а ближайшим примером категорического отказа выступает i-will-never-use-ai.