У меня такое ощущение, что это всё игра. Все всё понимают, но распевать красивые сказки - единственный способ быстро продвинуть инновации в жизнь. И когда мы все в этом окажемся уже будем думать как теперь жить. Что с ИИ, что с элекроавтомобилями, что с NFT, что с блокчейнами, что микросервисами.
Модели отлично справляются с тем, чтобы разобраться с тем как всё устроено в коде, находят дыры, но вот решения предлагают какие-то идиотские. Но это сейчас, посмотрим что будет дальше
Мы находим в реальности ветке "В код при этом можно даже не заглядывать".
Не подскажешь как ловить такое? Нужно было по списку инн получить список ид регионов. Но нейронка использовала функцию, которая по списку инн возвращала эти же инн сгруппированные по регионам. А потом выворачивала список в трёх местах, чтобы получить словарь инн-регион. А стоило просто написать функцию, которая бы возвращало то что нужно.
А для этого, нужно понимать, что ты делаешь и где. А как появится это понимание, если мы не заглядываем в код? Код придётся чем-то заменять.
Из недавнего ревью:
Задача: получить региональных координаторов из соседнего сервиса, чтобы разослать им письма.
Проблема: в сервисе есть только публичный метод для списка региональных координаторов. А они могут управлять видимостью емейла.
Решение от нейронки: получить региональных координаторов и для тех, кто без емейла - запросить по одному информацию о пользователе и получить оттуда емейлы.
Решение от человека: сделать внутренний метод получения информации о региональных координаторах, тем более, что для других ролей они уже есть. Или, хотя бы, грузить батчём, а не по одному.
Шутка юмора: в рамках это задачи нейронка правила код обоих сервисов.
Как потомственный говночерпий заявляю: нейронки говнокодят по страшной силе. Сейчас ревьюю как раз большой ПР за нейронкой. С одной стороны - задача достигнута, с другой - это был вечный круг багов и исправлений.
Я смотрю в код и понимаю, что вместо нормального проектирования - попытки решить свои же проблемы. Вычищаю, выравниваю, с помощью нейронок :) но я знаю что хочу получить в итоге.
Никуда нормальное проектирование не девается. Хочешь хороший результат - будь добр понимать что происходит, иначе будет заклинать бога-машину
Вопрос в том, когда это наступит. Возможно 99% проектов не достигнуть этой стадии. А может начнём дробить, чтобы сервисы были поменьше. Где-то я это уже видел...
У нас тут шутят: микросервис - это сервис, который можно переписать за 1 контекстное окно.
заранее заложиться на то, что так будет, принять как должное и спланировать соответственно работу.
Однажды я соглашался на доделки от заказчика, т.к. в моменте было понятно, что так правильно и действительно так должно работать. В итоге, в конце срока, заказчик спросил за ТЗ, почему не всё сделано. Аргументы типа "делали ваши хотелки" не сработали. Пришлось поработать бесплатно.
Теперь на фикс прайсе так: либо "этого не было в ТЗ, давайте допник", либо "давайте подумаем, что можно убрать, чтобы сделать то что нужно и остаться в бюджете (и сделаем допник)". Бюджет и время - это почти одно и то же.
Можно подумать, что после такого у меня проблемы с заказчиками, но нет, после работы по фиксу переходим на ТМ, т.к. они получают то что хотят и им самим так же проще.
Я пока могу писать в стиле "человек в цикле", получается быстрее чем без ии. Но я постоянно обнаруживаю какую-то дичь в коде, которую не знаю как исправить на уровне промтинга. Например, нужно было сделать атомное обновление счётчка, аля Insert 1 on conflict count+1 , далее прошу нейронку написать как такое сделать без косяков, она пишет, всё правильно пишет, что характерно. Далее прошу закодить по этой спеке: кодит с косяком. Ну как так кто? Потом бы нашлось на ревью, но всё-равно.
У меня хорошо работает цикл, когда агент по шагам реализует задачу, я читаю что он там сделал и уточняю своё собственное понимание. И следующий шаг может быть уже не таким как я его планировал до этого.
А как писать не заглядывая в код - хз. Вайбкодишь, вроде всё хорошо, работает, заглядываешь в код - "мать моя женщина!". Может не заглядывать и нормально всё будет?
Не плохо, у меня полторы тысячи интеграционных тестов, как раз такие сценарии получаются, только в менее формализованном виде. Правда пишутся вместе с кодом, а не до. Если раньше тесты были способом проверить, что я написал то что хотел, то теперь это ещё один способ зафиксировать текущую реализацию.
И как, удобно в таком виде разрабатывать? Кажется, что сценарии довольно подробные и при изменении требований будут меняться пачками. Я к тому должны быть более высокоуровневые документы.
Главное чтобы уровень абстракции был соответствующий.
Я к тому что код - это тоже документация. И, по хорошему, не стоит дублировать её в документации. Спека должна быть более выгодной с точки зрения чтения: более короткой и понятной.
Сталкиваюсь с такими проблемами:
Автогенерённая спека где общие вещи переплетаются с деталями реализации, бывает сложно прорываться.
Спека не реализацию становится документацией. Содержит кучу деталей реализации.
Хз, видимо у меня проф деформация, но я хочу чтобы дока объяснила все важные моменты и объяснила в целом что происходит, а я с этим знанием мог бы дальше спокойно читать код, а не реверсить требованяи.
У меня такое ощущение, что это всё игра. Все всё понимают, но распевать красивые сказки - единственный способ быстро продвинуть инновации в жизнь. И когда мы все в этом окажемся уже будем думать как теперь жить. Что с ИИ, что с элекроавтомобилями, что с NFT, что с блокчейнами, что микросервисами.
Модели отлично справляются с тем, чтобы разобраться с тем как всё устроено в коде, находят дыры, но вот решения предлагают какие-то идиотские. Но это сейчас, посмотрим что будет дальше
Это был опус 5 ):
Мы находим в
реальностиветке "В код при этом можно даже не заглядывать".Не подскажешь как ловить такое? Нужно было по списку инн получить список ид регионов. Но нейронка использовала функцию, которая по списку инн возвращала эти же инн сгруппированные по регионам. А потом выворачивала список в трёх местах, чтобы получить словарь инн-регион. А стоило просто написать функцию, которая бы возвращало то что нужно.
Техножрец бинарным кодом заклинает дух машины
А для этого, нужно понимать, что ты делаешь и где. А как появится это понимание, если мы не заглядываем в код? Код придётся чем-то заменять.
Из недавнего ревью:
Задача: получить региональных координаторов из соседнего сервиса, чтобы разослать им письма.
Проблема: в сервисе есть только публичный метод для списка региональных координаторов. А они могут управлять видимостью емейла.
Решение от нейронки: получить региональных координаторов и для тех, кто без емейла - запросить по одному информацию о пользователе и получить оттуда емейлы.
Решение от человека: сделать внутренний метод получения информации о региональных координаторах, тем более, что для других ролей они уже есть. Или, хотя бы, грузить батчём, а не по одному.
Шутка юмора: в рамках это задачи нейронка правила код обоих сервисов.
В итоге кода куча, а что зачем - непонятно
Это если ты можешь в архитектуру и планирование.
Но есть разные подходы. Выше, например, пишут, что программисты не нужны, просто говори, что хочешь получить.
Делегирование, ты не масштабируешься, а нанятые программисты да
Понимание. Когда не хочется (и даже не можется) разбираться во всех этой технине
Как потомственный говночерпий заявляю: нейронки говнокодят по страшной силе. Сейчас ревьюю как раз большой ПР за нейронкой. С одной стороны - задача достигнута, с другой - это был вечный круг багов и исправлений.
Я смотрю в код и понимаю, что вместо нормального проектирования - попытки решить свои же проблемы. Вычищаю, выравниваю, с помощью нейронок :) но я знаю что хочу получить в итоге.
Никуда нормальное проектирование не девается. Хочешь хороший результат - будь добр понимать что происходит, иначе будет заклинать бога-машину
Не будет ли как с YAML, который править без редактора просто страшно, хз что и куда уедет или не так поймётся?
Вопрос в том, когда это наступит. Возможно 99% проектов не достигнуть этой стадии. А может начнём дробить, чтобы сервисы были поменьше. Где-то я это уже видел...
У нас тут шутят: микросервис - это сервис, который можно переписать за 1 контекстное окно.
Системный промт сдохнет.
Я каждый день правлю какое-то количество косяков и они не обобщаются. То что обобщалось - уже в правилах.
Однажды я соглашался на доделки от заказчика, т.к. в моменте было понятно, что так правильно и действительно так должно работать. В итоге, в конце срока, заказчик спросил за ТЗ, почему не всё сделано. Аргументы типа "делали ваши хотелки" не сработали. Пришлось поработать бесплатно.
Теперь на фикс прайсе так: либо "этого не было в ТЗ, давайте допник", либо "давайте подумаем, что можно убрать, чтобы сделать то что нужно и остаться в бюджете (и сделаем допник)". Бюджет и время - это почти одно и то же.
Можно подумать, что после такого у меня проблемы с заказчиками, но нет, после работы по фиксу переходим на ТМ, т.к. они получают то что хотят и им самим так же проще.
Вайбкодинг предполагает, что мы не смотрим в код.
Я пока могу писать в стиле "человек в цикле", получается быстрее чем без ии. Но я постоянно обнаруживаю какую-то дичь в коде, которую не знаю как исправить на уровне промтинга. Например, нужно было сделать атомное обновление счётчка, аля
Insert 1 on conflict count+1, далее прошу нейронку написать как такое сделать без косяков, она пишет, всё правильно пишет, что характерно. Далее прошу закодить по этой спеке: кодит с косяком. Ну как так кто? Потом бы нашлось на ревью, но всё-равно.У меня хорошо работает цикл, когда агент по шагам реализует задачу, я читаю что он там сделал и уточняю своё собственное понимание. И следующий шаг может быть уже не таким как я его планировал до этого.
А как писать не заглядывая в код - хз. Вайбкодишь, вроде всё хорошо, работает, заглядываешь в код - "мать моя женщина!". Может не заглядывать и нормально всё будет?
Что такое 300-500 IO?
Проблема понятная, а как красиво объединять коллекции?
Я как не пробовал, а в итоге всё равно получается "загружаем словарь и таскам по маперам".
Типичная реализация: получаем нужные ид (может быть больше 1 истончика), загружаем данные, складываем в словарь, используем в мапинге.
Типа такого
Делал что-то GraphQL подобное, но оказалось слишком сложно для использования и проще словари таскать :(
Возможно высадили батарею
Чтобы уменьшить массу робота батарею чисто под эту 100-метровку ставят, полегче
Не плохо, у меня полторы тысячи интеграционных тестов, как раз такие сценарии получаются, только в менее формализованном виде. Правда пишутся вместе с кодом, а не до. Если раньше тесты были способом проверить, что я написал то что хотел, то теперь это ещё один способ зафиксировать текущую реализацию.
И как, удобно в таком виде разрабатывать? Кажется, что сценарии довольно подробные и при изменении требований будут меняться пачками.
Я к тому должны быть более высокоуровневые документы.
Главное чтобы уровень абстракции был соответствующий.
Я к тому что код - это тоже документация. И, по хорошему, не стоит дублировать её в документации.
Спека должна быть более выгодной с точки зрения чтения: более короткой и понятной.
Сталкиваюсь с такими проблемами:
Автогенерённая спека где общие вещи переплетаются с деталями реализации, бывает сложно прорываться.
Спека не реализацию становится документацией. Содержит кучу деталей реализации.
Хз, видимо у меня проф деформация, но я хочу чтобы дока объяснила все важные моменты и объяснила в целом что происходит, а я с этим знанием мог бы дальше спокойно читать код, а не реверсить требованяи.
Сара Коннор недоумевает зачем мы это делаем