Обновить
4
Олег Чулков@pilot114

web developer & researcher

0,1
Рейтинг
1
Подписчики
Отправить сообщение

Вы хорошо описали процесс, как он есть. Да, пожалуй надо разделять "думать над решением задачи, которая перед тобой изначально поставлена" и "думать над возникающими в процессе реализации проблемами". Отбрасывать вторые 90% работы пока излишне оптимистично, но надеюсь, только пока.

Нет, я имел в виду как раз программирование, не выдумывайте за меня. Почти все процессы в существенной степени автоматизируются. Вообще, заметил, многие программисты усилено продвигают идею, что большую часть времени они "думают". Что абсолютно не так и является когнитивным искажением - думать хоть и самая русурсоемкая, но в тоже время и самая быстрая операция.

А в чём тогда польза?

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

Речь же не про замену "код => ИИ", а про ""ручное программирование => автоматизированное программирование". Результат будет детерменированным ровно в той же степени, что и результат работы программиста

Статья правда крутая, очень интересно узнавать от первого лица как новые разработчики входят в профессию в условиях искушения нейросетями. Отдельное спасибо что написали сами, не считая абзаца с "И вот тут первый честный вывод", он сильно выбивается.

А, ну и второй момент - ок, есть у нас прорывная опенсорсная архитектура. А почему корпорации её не будут использовать?

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

закрывать задачи, на которые раньше уходил квартал

и

переписать стабильный, покрытый тестами проект, с одного ЯП на другой

Пахнет подменой

повышение количества низкокачественной рабочей силы породило невероятно неэффективный код

Такое уже было и были сделаны выводы. Если вам не нравится пользоваться неэффективным софтом - пользуйтесь эффективным. Если вам не нравится что кто-то другой пользуется неэффективным софтом - ну, во-первых, это не ваше дело, во-вторых, а в чем предложение? Вот сейчас половина современного софта написана поверх виртуальных машин, electron-ов и энтерпрайзных фрейморков. Это ИИ сделал? Да ИИ наш главный союзник в расчистке этих авгиевых конюшен.

что сделает повышение количества сгенерированного кода? 

Как минимум, больше кода значит больше выбора. Какие последствия того, что выбора больше - думайте сами.

В те стародавние времена, когда ИИ не использовалось в разработке) мы много раз были свидетелями маштабных факапов, когда разработчик перепутал терминалы, на автомате скопировал не ту команду, просто по усталости или запарке не протестировал новый код. Мы видели это в публичном поле, на примерах коллег и собственном опыте. То что вы рассчитали в статье как 4.5 критические ошибки на миллион программистов, которые пишут по 20 коммитов в день - это неимоверный, непостижимый уровень качества. Сравните с любыми открытыми отчётами по качеству кодовых баз.

Хватит пороть чушь про общую деградацию. Есть отдельно безответственность, которая вкупе с некомпетентностью является главной причиной ошибок ПО. И есть просто инструменты. ИИ это инструмент. Да, кода стало больше. Но я ответственно заявляю, что среднее качество этого кода ВЫШЕ среднего качества кода 10-20 лет назад. Именно среднего, раз уж мы берем общую температуру по индустрии.

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

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

p/s/ извиняюсь за излишнюю эмоциональность, я тут обращаюсь не лично к автору, а скорее к устоявшемуся мнению, которые расцениваю как в корне неверное

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

У меня ровно такие же ощущения были, когда пробовал писать своих агентов. (вот мои скромные эксперименты, для тех кому интересно почитать код https://github.com/600dc0de/ai_agents)

// Запуск одного агента в интерактивном режиме (никогда не завершается)
AgentRunner::interactive($agent, ['начальное сообщение']);

// Запуск нескольких агентов для сравнения
AgentRunner::pool([$agent1, $agent2], "Сравни эти два файла");

// Запуск агента несколько раз с одним и тем же запросом
AgentRunner::shot($agent, "Сгенерируй 5 креативных названий", 5);

// Запуск двух агентов в диалоге друг с другом
AgentRunner::polemic($agreeAgent, $disagreeAgent, "Кофе лучше, чем чай", 1);

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

Модульность и слияние нужно реализовать не как фичу самих конфигов, а в том месте где они подключаются, после декодирования - и при этом вообще не зависеть от формата - вот куда усилия приложить надо, а не в изобретение json диалекта

В том то и дело, что если доставка успешна (данные вернулись клиенту) - это 200.

Но HTTP же ещё много нетранспортных вещей кодирует и они в RPC на уровне отдельных запросов в батче. Т.е. внутри 1 HTTP запроса может быть 3 RPC запроса (условно bad request, access denied, server error) - в таком случае общий HTTP статус просто напросто сводится только к факту доставки, т.е. 200.

Это перевод, поэтому наврятли вы получите ответ.

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

Замечу, что "процент доверия" llm наверняка выше любой полученной в частной беседе информации (люди тоже "галлюционируют", но мы скромно называем это "заблуждаются"). У СМИ наверняка ниже, у википедии лишь чуть выше за счёт механизма модерации, но и он также подвержен эффекту правдивой лжи. Вообщем, llm в этом плане не сказать что сильно отличается от других источников информации. Было бы конечно интересно увидеть какие-то исследования данной темы.

Другой вопрос, как этот "процент доверия" повышать и надо ли. см. https://habr.com/ru/articles/947964/

вы пару раз критически упоминули json-rpc 2.0, но не раскрыли в чём его минусы.

Почему там всегда 200 понятно - изза батчинга. А что ещё?

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

Автор, перечитайте плиз свой список из 7 задач (в котором 8 пунктов, но вообще типа около 20 и из них многие дублируются). Это абсолютно бессистемное месиво.

Особого комментария заслуживает пункт с саммари созвонов. Вот бесплатный совет: всячески бойкотируйте бесполезные созвоны. Не допускайте их в свой рабочий процесс. А из действительно полезных вы и без автоматизаций вынесите все что нужно.

кстати, вроде как единственный профайлер, которой сейчас можно просто через PIE установить

pie install noisebynorthwest/php-spx

Все просто, нашёл запросом "php profiler", когда возникла потребность в профайлере) Сравнивал только с Xprof/Xdebug и Blackfire, это решение показалось существенно проще и наглядней.

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

Информация

В рейтинге
4 256-й
Откуда
Новосибирск, Новосибирская обл., Россия
Дата рождения
Зарегистрирован
Активность

Специализация

Фулстек разработчик
Старший
От 5 000 $
Git
SQL
ООП
Linux
Docker
PHP