Сейчас легко решить задачу, написав много-много кода с неадекватным подбором абстракций, как в примерах из предыдущего поста.
Но кодовая база разрастается и поддерживать ее становится дорого и по времени, и по когнитивной нагрузке, и — как следствие — по токенам.
Моя личная гордость за сегодня ☺️:
‣ удаление бесполезных абстракций
(+44 -715)
‣ рефакторинг скиллов на бэкенде
(+1643 -2275)
Над рефакторингом работал гранулярно, шаг за шагом. И даже на ревью от кодекса ничего не нашлось. Что интересно, попытки сделать тот же рефакторинг в несколько промптов, с GPT Sol Ultra, обернулись потерей времени и токенов на неудачные PR.
‣ https://github.com/D00mch/souz/pull/613
(+449 -287)
‣ https://github.com/D00mch/souz/pull/622
(+689 -276)
Хотя с одним из ПР-ов предварительно просидел полдня, готовя промпт в режиме планирования. Что не так с этими ПР-ами? И подбор абстракций плохой, и упрощения как такового не получилось.
А вот еще один “плохой” пример: реализация публичного контракта для бэкенда (+7210 -2096). Над контрактом поработал сам, а вот реализацию доверил LLM. Понадобился 101 комментарий ревью от самого же кодекса, прежде чем получилось влить ПР.
Кстати, Codex иногда ошибается с подсчетом добавленных и удалённых строк, поэтому добавил alias в zshrc, может, кому пригодится:
alias lines="git add -N -- . && git diff HEAD --numstat | awk '{a+=\$1; d+=\$2} END {printf \"+%d -%d\\n\", a, d}'"
Резюмируя. LLM удешевляет производство кода, но делает дороже его сопровождение. Сложно ответить, когда это действительно выгодно. Но до сих пор имеет смысл работать гранулярно над важными участками кода. Например, над core-функциональностью.
Но кодовая база разрастается и поддерживать ее становится дорого и по времени, и по когнитивной нагрузке, и — как следствие — по токенам.
Моя личная гордость за сегодня ☺️:
‣ удаление бесполезных абстракций
(+44 -715)
‣ рефакторинг скиллов на бэкенде
(+1643 -2275)
Над рефакторингом работал гранулярно, шаг за шагом. И даже на ревью от кодекса ничего не нашлось. Что интересно, попытки сделать тот же рефакторинг в несколько промптов, с GPT Sol Ultra, обернулись потерей времени и токенов на неудачные PR.
‣ https://github.com/D00mch/souz/pull/613
(+449 -287)
‣ https://github.com/D00mch/souz/pull/622
(+689 -276)
Хотя с одним из ПР-ов предварительно просидел полдня, готовя промпт в режиме планирования. Что не так с этими ПР-ами? И подбор абстракций плохой, и упрощения как такового не получилось.
А вот еще один “плохой” пример: реализация публичного контракта для бэкенда (+7210 -2096). Над контрактом поработал сам, а вот реализацию доверил LLM. Понадобился 101 комментарий ревью от самого же кодекса, прежде чем получилось влить ПР.
Кстати, Codex иногда ошибается с подсчетом добавленных и удалённых строк, поэтому добавил alias в zshrc, может, кому пригодится:
alias lines="git add -N -- . && git diff HEAD --numstat | awk '{a+=\$1; d+=\$2} END {printf \"+%d -%d\\n\", a, d}'"
Резюмируя. LLM удешевляет производство кода, но делает дороже его сопровождение. Сложно ответить, когда это действительно выгодно. Но до сих пор имеет смысл работать гранулярно над важными участками кода. Например, над core-функциональностью.