Что такое код на самом деле? И почему он (не) нужен?

[All4DK]

Как давно программируете? Удалось ли реализовать что-то серьёзное без использования ИИ?

[KillWolfVlad]

Хороший вопрос - действительно, забыл представиться 🙂

В коммерческой разработке я более 7 лет. За это время участвовал и в создании систем с нуля, и в развитии существующих проектов со сложной бизнес-логикой и высокими требованиями к надежности.

Большую часть этого времени разработка велась без ИИ-инструментов в современном понимании. Поэтому мой интерес к этой теме не из позиции «ИИ пришел и теперь все напишет за нас», а скорее из желания понять, какие части инженерной работы действительно меняются, а какие становятся еще важнее.

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

[netricks]

Роль кода не тот, чтобы поменялся. Поменялась скорость, с которой мы его производим. Если художник пишет картину за день, она гораздо менее цена, чем если он пишет её за месяц. Когда произведение уже есть в голове, вторую версию романа можно написать буквально с колёс. В принципе, код раньше был не так уж ценен, если у тебя в голове была чёткая схема того, как система должна работать. Разве ж ценно то, что можно быстро воспроизвести?

[funca]

Разработка напоминает сборку конструктора Lego. Чтобы получить результат как на картинке, нужна не только сама картинка (требования), но и правильная последовательность сборки (инструкция по сборке).

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

С точки зрения программирования это означает, что объем спецификаций будет в несколько раз больше объёма кода. Это при том, что поддерживать такие спецификации в консистентном состоянии и проверять толком ни кто не умеет. В отличие от кода.

[Gromilo]

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

Проблема в том, что нейронкам сейчас доверять нельзя. Даже есть инструкции, она не умеет в индукцию и не умеет отличать важное от неважного, когда реализация требуют какого-то компромиса.

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

Я слежу за качеством кода, потому что:

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

2. Код - это тоже документация, или спецификация. При решении задачи нейронка читает его точно так же как и постановку. И если код хороший, то нейронке будет проще.

3. Проще ревьюить, а значит быстрее (например, нейронки любят добавлять ифчики, вместо того, чтобы посмотреть на функцию в целом и обощить)

[kamaz1]

ты противоречишь сам себе.

 понял странную вещь: сам код — не жалко.Страшно потерять другое: требования к системе и навыки агентов, которые умеют эти требования превращать в работающую систему.

то код потерять страшно, то код потерять нельзя, повзрослеешь придет понимание - не важно как называется компилятор gcc или llm