Сейчас легко решить задачу, написав много-много кода с неадекватным подбором абстракций, как в примерах из предыдущего поста.
Но кодовая база разрастается и поддерживать ее становится дорого и по времени, и по когнитивной нагрузке, и — как следствие — по токенам.
Моя личная гордость за сегодня ☺️:
‣ удаление бесполезных абстракций
(+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, может, кому пригодится:
Резюмируя. 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-функциональностью.
Telegram
Артур Думчев
С выходом Fable и 5.6 Sol мне почему-то показалось, что эта статья уже устарела, но вот я решил активно повайбкодить, разбираясь с каждым предложенным решением LLM, и смело могу заверить, что если не контролировать выбор абстракций, получается раздутый из…
2👍17🔥4✍3
Forwarded from Откровения от Олега
Моменты истинного величия маркетологов, которые даже не нужно фальсифицировать на скриншотах
1😁32👍6💯4❤2
Наконец дошли руки поразбираться с https://codespeak.dev/
Удивило, что Бреслав взялся за проект с настолько очевидно слабой сутью.
Вкратце, CodeSpeak о том, чтобы писать спеки, которые, как ожидается, будут в 5-10 раз короче, чем код. А их “фреймворк” позаботится, чтобы ”скомпилировать” из этого исходный код, да еще и тестами покроет.
Фактически это просто перенос сложности из кода в спеку.
Если спека на естественном языке учитывает всё, она будет даже больше, чем код, потому что естественный язык двусмысленный в отличие от ЯП.
Если спека короче, остаётся пространство для решений LLM. Эти решения будут неявны и неоднозначны, т.е. повторный запуск может сгенерировать семантически не эквивалентный код.
Давайте возьмём простой пример с использованием piggy backing:
Чтобы пост не превратился в книгу, приведу в комментариях спеку, явно описывающую этот код. Пример скорее шуточный, но шутка хорошо раскрывает идею. Идею того, что точнее и короче именно кодом выражать идеи для компьютера.
Удивило, что Бреслав взялся за проект с настолько очевидно слабой сутью.
Вкратце, CodeSpeak о том, чтобы писать спеки, которые, как ожидается, будут в 5-10 раз короче, чем код. А их “фреймворк” позаботится, чтобы ”скомпилировать” из этого исходный код, да еще и тестами покроет.
Фактически это просто перенос сложности из кода в спеку.
Если спека на естественном языке учитывает всё, она будет даже больше, чем код, потому что естественный язык двусмысленный в отличие от ЯП.
Если спека короче, остаётся пространство для решений LLM. Эти решения будут неявны и неоднозначны, т.е. повторный запуск может сгенерировать семантически не эквивалентный код.
Давайте возьмём простой пример с использованием piggy backing:
@Volatile var a = 1
var b = 2
@ThreadSafe
fun change() {
b = 3
a = 4
}
Чтобы пост не превратился в книгу, приведу в комментариях спеку, явно описывающую этот код. Пример скорее шуточный, но шутка хорошо раскрывает идею. Идею того, что точнее и короче именно кодом выражать идеи для компьютера.
CodeSpeak
CodeSpeak: Software Engineering with AI
CodeSpeak is an Agentic Engineering Toolkit. Write programs in structured human language.
2✍8👍8🤔2🤝2
Артур Думчев
Сейчас легко решить задачу, написав много-много кода с неадекватным подбором абстракций, как в примерах из предыдущего поста. Но кодовая база разрастается и поддерживать ее становится дорого и по времени, и по когнитивной нагрузке, и — как следствие — по токенам.…
В продолжение поста про рефакторинг с ЛЛМ.
Переписал тесты на бекенде: стало в 4 раза меньше кода и всего на 1.5% меньше покрытие.
— Как такое получилось?
— Отказался от unit-тестов в пользую интеграционных.
— Зачем — есть же пирамида тестирования?
— Чтобы можно было рефакторить, не трогая тесты. Подробнее рассказывал в статье про заговор разработчиков: Запрещаем рефакторинг обилием Unit-тестов.
Переписал тесты на бекенде: стало в 4 раза меньше кода и всего на 1.5% меньше покрытие.
— Как такое получилось?
— Отказался от unit-тестов в пользую интеграционных.
— Зачем — есть же пирамида тестирования?
— Чтобы можно было рефакторить, не трогая тесты. Подробнее рассказывал в статье про заговор разработчиков: Запрещаем рефакторинг обилием Unit-тестов.
5🔥11✍5❤3🤯1
Давно не писал про бокс в VR, но сейчас нельзя не написать. Вышло обновление TOTF2 (Steam), и стало ну очень реалистично.
ИИ двигается, как один из спарринг-партнеров в зале, который постоянно доставляет мне неприятности. Теперь-то я с ним поквитаюсь в VR, — подумал я.Но нет, на сложности outclassed вообще без шансов.
Спарринговаться в реальной жизни даже раз в месяц не очень хочется из-за риска CTE. Но спорт мне нравится, и хочется в нем развиваться. Вот кажется, что бокс в VR впервые выходит на реалистичность, достаточную, чтобы действительно тренироваться. На максимальной сложности нокдаун можно получить и от джеба. Приходится держать повыше руки, выжидать возможности для контратаки, при ударах прикрываться другой рукой и смещать голову. Удары соперника «ощущаешь» через визуальные и аудиальные эффекты.
А физически кстати можно было тренироваться и того раньше. Когда я начинал пару лет назад, задыхался после 3 раундов. Даже рассказывал в статьях о проблемах с сердцем от бокса в VR. Теперь совсем другое дело: только вчера провел 15 раундов в боксерских эспандерах (писал о них тут), пропуская перерывы, — всё спокойно. Справедливости ради скажу, что помимо VR время от времени хожу бить грушу в фитнес-зале и захаживаю в боксерский зал в среднем раз в месяц.
Раньше VR-бокс для меня был в первую очередь кардио с элементами бокса. После обновления впервые кажется, что это уже бокс — в чем-то даже более требовательный к выносливости и технике, чем лёгкий спарринг в зале.
ИИ двигается, как один из спарринг-партнеров в зале, который постоянно доставляет мне неприятности. Теперь-то я с ним поквитаюсь в VR, — подумал я.
Спарринговаться в реальной жизни даже раз в месяц не очень хочется из-за риска CTE. Но спорт мне нравится, и хочется в нем развиваться. Вот кажется, что бокс в VR впервые выходит на реалистичность, достаточную, чтобы действительно тренироваться. На максимальной сложности нокдаун можно получить и от джеба. Приходится держать повыше руки, выжидать возможности для контратаки, при ударах прикрываться другой рукой и смещать голову. Удары соперника «ощущаешь» через визуальные и аудиальные эффекты.
А физически кстати можно было тренироваться и того раньше. Когда я начинал пару лет назад, задыхался после 3 раундов. Даже рассказывал в статьях о проблемах с сердцем от бокса в VR. Теперь совсем другое дело: только вчера провел 15 раундов в боксерских эспандерах (писал о них тут), пропуская перерывы, — всё спокойно. Справедливости ради скажу, что помимо VR время от времени хожу бить грушу в фитнес-зале и захаживаю в боксерский зал в среднем раз в месяц.
Раньше VR-бокс для меня был в первую очередь кардио с элементами бокса. После обновления впервые кажется, что это уже бокс — в чем-то даже более требовательный к выносливости и технике, чем лёгкий спарринг в зале.
The Thrill of the Fight 2
Jab, dodge, and sweat your way to the top of the boxing world! - Buy now on Meta Quest
👍10🔥7❤2🤔2
Наконец-то заполучил M9N — клавиатуру, которую присмотрел еще в 2024, но не смог тогда приобрести.
В мире кастомных клавиатур многие проекты запускаются через краудфандинг (group buy):
‣ Дизайнер готовит концепт, запускает рекламу (вот пример c M9N) и продает обещания экземпляров тем, кто успеет.
‣ Партия поставляется спустя несколько лунных месяцев, а иногда и лет.
‣ Покупатель получает кит — корпус, плату и прочие составляющие, но переключатели и клавиши докупает самостоятельно, иногда через отдельный group buy.
‣ Покупатель собирает клавиатуру. Можно посмотреть на youtube пример с M9N.
‣ Устраивает фотосессию и... продаёт клавиатуру на классифайде вроде авито или китайского goofish.
На последнем я и нашел M9N. Надо сказать, редкая была птица: group buy ограничился всего 35 экземплярами.
Откуда название M9N?
К объяснению логичнее всего подойти с форм-фактора. В 40% клавиатурах нет ряда с цифрами, поэтому цифры обычно размещают на дополнительном слове поверх QWERTY-ряда:
Q — 1
W — 2
...
O — 9
У меня цифры расположены иначе, но девятка всё равно оказалась на “О” (см. картинку в dotfiles/README).
M9N превращается в MON, то есть Monday. Этимологически Monday — это Moon day, день луны, а M9N — первая клавиатура в серии дней недели, Seven Luminaries, от дизайнера Jio.
Jio обыграл лунную тему в нескольких деталях. Один из вариантов корпуса идет в цвете moonlight. Именно он на фото. А внутри корпуса, словно в “лунном дворце”, изображен Юйту — лунный зайчик из китайской мифологии. В Истории стрелка И и его жены Чан-э так и говорится:
Больше всего мне понравилась идея воплощения двойственности луны. Jio пишет про неустойчивое состояние в визуальном восприятии и устойчивое — в тактильном, сравнивая это с противоположными интерпретациями луны с материнским началом и со смертью. Клавиатура выглядит такой элегантной и утонченной из-за искривлённого дна (видно на первой фотографии).
Я решил продолжить лунную тему и поставил переключатели HMX Moonlight, и сейчас набираю этот текст на них, а клавиши KBS Moonlight уже идут с goofish.
В общем, понедельник, которого я ждал два года, наступил. Фотосессию устроил, шаг с перепродажей сознательно пропускаю.
В мире кастомных клавиатур многие проекты запускаются через краудфандинг (group buy):
‣ Дизайнер готовит концепт, запускает рекламу (вот пример c M9N) и продает обещания экземпляров тем, кто успеет.
‣ Партия поставляется спустя несколько лунных месяцев, а иногда и лет.
‣ Покупатель получает кит — корпус, плату и прочие составляющие, но переключатели и клавиши докупает самостоятельно, иногда через отдельный group buy.
‣ Покупатель собирает клавиатуру. Можно посмотреть на youtube пример с M9N.
‣ Устраивает фотосессию и... продаёт клавиатуру на классифайде вроде авито или китайского goofish.
На последнем я и нашел M9N. Надо сказать, редкая была птица: group buy ограничился всего 35 экземплярами.
Откуда название M9N?
К объяснению логичнее всего подойти с форм-фактора. В 40% клавиатурах нет ряда с цифрами, поэтому цифры обычно размещают на дополнительном слове поверх QWERTY-ряда:
Q — 1
W — 2
...
O — 9
У меня цифры расположены иначе, но девятка всё равно оказалась на “О” (см. картинку в dotfiles/README).
M9N превращается в MON, то есть Monday. Этимологически Monday — это Moon day, день луны, а M9N — первая клавиатура в серии дней недели, Seven Luminaries, от дизайнера Jio.
Jio обыграл лунную тему в нескольких деталях. Один из вариантов корпуса идет в цвете moonlight. Именно он на фото. А внутри корпуса, словно в “лунном дворце”, изображен Юйту — лунный зайчик из китайской мифологии. В Истории стрелка И и его жены Чан-э так и говорится:
она не знала, что в лунном дворце окажется так пусто и безлюдно. Там был только белый заяц, который круглый год толок в ступке лекарство бессмертия.
Больше всего мне понравилась идея воплощения двойственности луны. Jio пишет про неустойчивое состояние в визуальном восприятии и устойчивое — в тактильном, сравнивая это с противоположными интерпретациями луны с материнским началом и со смертью. Клавиатура выглядит такой элегантной и утонченной из-за искривлённого дна (видно на первой фотографии).
Я решил продолжить лунную тему и поставил переключатели HMX Moonlight, и сейчас набираю этот текст на них, а клавиши KBS Moonlight уже идут с goofish.
В общем, понедельник, которого я ждал два года, наступил. Фотосессию устроил, шаг с перепродажей сознательно пропускаю.
🔥9❤8👾5👍2🤯2
Новый подход к code review в эру агентов
В далекие времена, где-то 1-2 месяца назад, когда приходил PR, я ревьюил код сам. Ревьюил агентами. Оставляя комментарии. Потом возвращался, смотрел на правки, ревьюил еще раз. И так несколько итераций. Вот пример, понадобилось 70 сообщений и 9 дней, прежде чем получилось влить.
Но кажется, что есть вариант получше: дать агенту готовый ПР и попросить переписать. Я использовал простой промпт на Astra XHigh:
Первый эксперимент, большой ПР, задача про интеграцию VK (меньше на 51% кода):
‣ Было +3200 -60
‣ Стало +1632 -105
Второй эксперимент, средний ПР, задача про композицию тулов в скиллах (меньше на 60% кода):
‣ Было +1353 -13
‣ Стало +624 -91
Третий эксперимент, маленький ПР, фикс блокирующих друг друга Tg/VK polling (меньше на 93% кода):
‣ Было +87 -10
‣ Стало +98 -93
Все три переписанных ПР-а лучше во всех важных для меня аспектах: безопаснее, идиоматичнее, проще для понимания, исправляют review findings из основного ПР-а, значительно меньше кода.
Качество оценивал сам и просил коллегу. Экспериментов всё еще мало, но очень хотелось поделиться опытом.
Итак, резюмируя: если использовать изначальный ПР как спецификацию для нового ПР, получается и быстрее, и токенов тратится меньше в сравнении с обычным code review.
В далекие времена, где-то 1-2 месяца назад, когда приходил PR, я ревьюил код сам. Ревьюил агентами. Оставляя комментарии. Потом возвращался, смотрел на правки, ревьюил еще раз. И так несколько итераций. Вот пример, понадобилось 70 сообщений и 9 дней, прежде чем получилось влить.
Но кажется, что есть вариант получше: дать агенту готовый ПР и попросить переписать. Я использовал простой промпт на Astra XHigh:
Let's implement the <task description> in <PR link>.
But simpler. Try to avoid unnecessary abstractions, get rid of bloated tests, simplify the logic where possible, remove code duplication, etc.
Первый эксперимент, большой ПР, задача про интеграцию VK (меньше на 51% кода):
‣ Было +3200 -60
‣ Стало +1632 -105
Второй эксперимент, средний ПР, задача про композицию тулов в скиллах (меньше на 60% кода):
‣ Было +1353 -13
‣ Стало +624 -91
Третий эксперимент, маленький ПР, фикс блокирующих друг друга Tg/VK polling (меньше на 93% кода):
‣ Было +87 -10
‣ Стало +98 -93
Все три переписанных ПР-а лучше во всех важных для меня аспектах: безопаснее, идиоматичнее, проще для понимания, исправляют review findings из основного ПР-а, значительно меньше кода.
Качество оценивал сам и просил коллегу. Экспериментов всё еще мало, но очень хотелось поделиться опытом.
Итак, резюмируя: если использовать изначальный ПР как спецификацию для нового ПР, получается и быстрее, и токенов тратится меньше в сравнении с обычным code review.
GitHub
OAuth skill service for obtaining, storing, refreshing, and using OAuth tokens by jilees · Pull Request #615 · D00mch/souz
…ic core)
Lets skills call third-party APIs that require OAuth (Yandex to start, others via the same standard authorization-code flow later) without a raw access token ever reaching a skill'...
Lets skills call third-party APIs that require OAuth (Yandex to start, others via the same standard authorization-code flow later) without a raw access token ever reaching a skill'...
🔥13👍8🤔5❤2😁1