«Программировать легко — сложно понять, что именно требуется напрограммировать».
А я вот понял, что речь о более высоком уровне. Например, "нашему банковскому клиенту нужны сторис" или "пассажир должен мочь поменять конечную точку прямо во время движения".
Т.е. речь о том, что работа программиста не имеет смысла, если она не приносит ценности бизнесу, в конечном итоге. И не программист решает будут у нас сторис или нет.
В основном по happy-path и с помощью других программистов. А ещё с помощью нейронок, внезапно. Они могут объяснить, что тут наворочено без привлечения программистов.
А в чём же отличие меня от нейронки заказчика? Да фиг его знает (:
На вскидку: не нужно шарить в технине. Даже когда вайбкодю всплывают вопросы явно технического характера, с упоминание классов, шлюзов и т.п.
Здесь приходится полагаться на других, кто шарит. И бывает что годами в таком коде живут баги, которые никто не замечает. Но тут хотя бы есть шанс, что тот кто писал изначальную реализацию шарил в теме. А с нейронками как повезёт: может быть всё круто, а может быть правдоподобный результат.
А ещё мне нравится, что код накапливает знания. Т.е. чем старее алгоритм и чем чаще им пользуются, тем меньше вероятность, что в нём есть проблема. Чего не скажешь, о только что сгенеренном коде, который я даже понять не могу ):
Я к тому, что исчерпывающее тестирование невозможно и нам приходилось полагаться на модель в голове программиста, который писал код. А сейчас приходится полагаться на модели и агентов. Я использую агентов в работе и они по прежнему творят дичь, и чтобы понять это мне нужна квалификация.
Часто слышу: сделайте правильный пайплайн, держите агента в узде и всё будет хорошо. Только тут опять нужно умнее модели, чтобы увидеть проблемы и придумать как исправить их как класс.
Смотря где провести границу. Понимание может заканчиваться на "добавь переменную", тогда программировать легко, а может на "орг структура должна поддерживать до 100к человек", тогда сложно.
Откуда мы это знаем? Я знаю только 2 способа: ревью и тесты. Вот только объём тестов больше функции в несколько раз и... барабанная дробь... их тоже нужно ревьюить.
Настоящая проблема в том, что разработчик перекладывает свою работу на ревьюера, а сам делает 2 запрос: реализуй фичу и отработай замечания.
Поэтому вместо замечаний вопросы на понимание. Не только по коду, но и по сценариям использования (я бэкендер). Не будет же он отвечать: "да, ты верно подметил у меня здесь проблема, позволь мне это исправить"? :D
Примеры:
Внезапная сложная многопоточная функция, я понимаю, что тот разраб ни за что бы такую не написал и значит не может отвечать за то, что в ней нет проблем.
Нужно было добавить поле в 1 дто, это же поле добавлено ещё и в другое ДТО, и заполняется. Зачем? Хз. Но оно точно там не нужно.
Избыточные проверки, которые никогда не сработают по инвариантам проекта (а потом тесты на все эти ифы)
Не проработанные сценарии. Но это и раньше было.
В общем, моя задача, чтобы тот кто сделал отвечал за сделанный результат и вопросы для этого отлично подходят. А не просто: "похоже на правду".
Ещё раз прочитал статью и возник такой вопрос: благодаря правилам линтера мы будем получать "красивый" код, но как проверяется, что модель делает вообще то что нужно?
Судя по количеству удалённых строк, явно не ревью :)
Автоматическое ревью? Тесты?
У меня сейчас небольшой проект стартует, как раз возможность попробовать отпустить вожжи, но у меня до сих нет в голове понимания, почему это будет работать.
ИИ код палится только так. Задаю очень много вопросов на ревью "почему так?", "а зачем?". На понимание написанного. К счастью, кожаных мешков быстро задалбывает отвечать и они начинают лучше следить за выхлопом ИИшки
А у меня наоборот прорыв случился, когда я стал назначать дела на конкретные даты. Использую todoist.com, особенно радуют возможность сделать повторяющие дела. Будь то физкультура с ребёнком каждые 2 дня или смена фильтров воды каждые пол года.
Правда у меня почти нет системы планирования верхнего уровня, это всё оперативное. Новые дела я просто распихиваю по дням, потому что знаю сколько чего я могу сделать.
И мне хватает пока 2-х уровней: проект и задача. У проекта есть ДОД (как я пойму что проект сделан) и список задач, которые могут появляться по мере их выполнения, пока не добью ДОД.
Потому что за меня решили, что мне нужно знать, а что нет
Спасибо, конечно, но нет
Почему уже второй человек предлагает забить? Мне же интересно
В чём профит? Должен быть весомый, учитывая сколько на внедрение потрачено
Напиши в 101, если не сложно
Кто-нибудь знает, кому и зачем нужен цифровой рубль?
А я вот понял, что речь о более высоком уровне. Например, "нашему банковскому клиенту нужны сторис" или "пассажир должен мочь поменять конечную точку прямо во время движения".
Т.е. речь о том, что работа программиста не имеет смысла, если она не приносит ценности бизнесу, в конечном итоге. И не программист решает будут у нас сторис или нет.
Коллеги тоже замечали, что ИИ делает верный вывод о причинах проблемы и творит какую-то дичь для её устранения.
В основном по happy-path и с помощью других программистов.
А ещё с помощью нейронок, внезапно. Они могут объяснить, что тут наворочено без привлечения программистов.
А в чём же отличие меня от нейронки заказчика? Да фиг его знает (:
На вскидку: не нужно шарить в технине. Даже когда вайбкодю всплывают вопросы явно технического характера, с упоминание классов, шлюзов и т.п.
Здесь приходится полагаться на других, кто шарит. И бывает что годами в таком коде живут баги, которые никто не замечает. Но тут хотя бы есть шанс, что тот кто писал изначальную реализацию шарил в теме. А с нейронками как повезёт: может быть всё круто, а может быть правдоподобный результат.
А ещё мне нравится, что код накапливает знания. Т.е. чем старее алгоритм и чем чаще им пользуются, тем меньше вероятность, что в нём есть проблема. Чего не скажешь, о только что сгенеренном коде, который я даже понять не могу ):
Тесты корректности и производительности - это хорошо.
А если не так? Часто у нас вообще никакого теста нет для сравнения производительности. А тесты на корректность только те, что сама нейронка написала.
А потом попросили сделать побыстрее и теперь там ошибки переполнения буфера.
Я к тому, что исчерпывающее тестирование невозможно и нам приходилось полагаться на модель в голове программиста, который писал код. А сейчас приходится полагаться на модели и агентов. Я использую агентов в работе и они по прежнему творят дичь, и чтобы понять это мне нужна квалификация.
Часто слышу: сделайте правильный пайплайн, держите агента в узде и всё будет хорошо. Только тут опять нужно умнее модели, чтобы увидеть проблемы и придумать как исправить их как класс.
А понимание включает в себя системный анализ и изучение текущий реализации?
Смотря где провести границу. Понимание может заканчиваться на "добавь переменную", тогда программировать легко, а может на "орг структура должна поддерживать до 100к человек", тогда сложно.
Как она может быть на голову выше меня, если у меня не хватает квалификации проверить её работу? Ну реально, как я в этом могу быть уверен?
Откуда мы это знаем? Я знаю только 2 способа: ревью и тесты. Вот только объём тестов больше функции в несколько раз и... барабанная дробь... их тоже нужно ревьюить.
Настоящая проблема в том, что разработчик перекладывает свою работу на ревьюера, а сам делает 2 запрос: реализуй фичу и отработай замечания.
Поэтому вместо замечаний вопросы на понимание. Не только по коду, но и по сценариям использования (я бэкендер). Не будет же он отвечать: "да, ты верно подметил у меня здесь проблема, позволь мне это исправить"? :D
Примеры:
Внезапная сложная многопоточная функция, я понимаю, что тот разраб ни за что бы такую не написал и значит не может отвечать за то, что в ней нет проблем.
Нужно было добавить поле в 1 дто, это же поле добавлено ещё и в другое ДТО, и заполняется. Зачем? Хз. Но оно точно там не нужно.
Избыточные проверки, которые никогда не сработают по инвариантам проекта (а потом тесты на все эти ифы)
Не проработанные сценарии. Но это и раньше было.
В общем, моя задача, чтобы тот кто сделал отвечал за сделанный результат и вопросы для этого отлично подходят. А не просто: "похоже на правду".
Ещё раз прочитал статью и возник такой вопрос: благодаря правилам линтера мы будем получать "красивый" код, но как проверяется, что модель делает вообще то что нужно?
Судя по количеству удалённых строк, явно не ревью :)
Автоматическое ревью? Тесты?
У меня сейчас небольшой проект стартует, как раз возможность попробовать отпустить вожжи, но у меня до сих нет в голове понимания, почему это будет работать.
ИИ код палится только так. Задаю очень много вопросов на ревью "почему так?", "а зачем?". На понимание написанного.
К счастью, кожаных мешков быстро задалбывает отвечать и они начинают лучше следить за выхлопом ИИшки
А у меня наоборот прорыв случился, когда я стал назначать дела на конкретные даты. Использую todoist.com, особенно радуют возможность сделать повторяющие дела. Будь то физкультура с ребёнком каждые 2 дня или смена фильтров воды каждые пол года.
Правда у меня почти нет системы планирования верхнего уровня, это всё оперативное. Новые дела я просто распихиваю по дням, потому что знаю сколько чего я могу сделать.
И мне хватает пока 2-х уровней: проект и задача. У проекта есть ДОД (как я пойму что проект сделан) и список задач, которые могут появляться по мере их выполнения, пока не добью ДОД.
Да, было бы замечательно если бы проводки никогда не трогали.
Теоретически можно фиксировать сумму не на сегодня, а месяц назад, но даже это не спасёт :)
Понял, просто увидев про "Прошло три года, и к 2002" у меня первая мысль: ну делайте расчёт от начала года
GLM-4.7 в связи с kilo - тупой агент, но даже он грепает по коду и понимает, что метода нет. rag - скорее про смысловой поиск