All streams
Search
Write a publication
Pull to refresh

Comments 157

Какие янтарные табулирования в монохроме маркетингов в 1997 году (28 лет назад, год выхода Фоллаута и Кваки 2)?

Кто здесь? Что вообще происходит? За что?

Вас только это в статье заинтересовало?
Я - ровесник автора оригинальной публикации, и, да, в моём 1997 году, тоже был монохром (только зелёный) на терминалах СМ ЭВМ. Не удивляет, что в Штатах, большие корпорации не спешили менять оборудование, в которое вложили значительные стредства в более раннии годы. Спецы по Cobol, ещё тоже актуальны до сих пор, не исключаю, что они до сих пор сидят за такими терминалами (надеюсь - нет).
Ну, а дома, в те годы, тоже был Fallout (где-то с 1998г).

По публикации: мне близка точка зрения. "Нейрошиза", как это теперь назавают, захватила умы больших начальников. Об этом уже тоже было на Хабре.
На нынешней работе, в большой "зелёной" конторе, недавно сказано было открытым текстом: "или применяйте ИИ, либо увольнять будем". А инструменты эти, реально сырые, к применению чего-либо, отличного от "Hello, world!".

У меня в 97 уже был дома личный вполне себе цветной SVGA Samsung 15`. Монохромом я пользовался в последнйи раз на серверах году этак в 2005, перед их списанием. А так то, это эпоха где то середина 80-х, начало 90-х (хотя и параллельно уже были всякие CGA, VGA мониторы которые правда стоили раза в 2-3 дороже). Потом, к 97 году, уже было вполне "нормально доступные" цветные ЭЛТ мониторы. Хотя так то да, начинал я на практикуме в 90м году именно с крохотных монохромных чб мониторов. Но и тогда это было чудо! Особенно когда получалось компилить и что то выводить по первой для меня серьезной книге Карнигана и Ричи по С++

<зануда mode> K&R писали про C </зануда mode>

Да, пардону прошу! Само собой что  Страуструпа!. Просто сперва захлебом прочел книгу у своего руководителя, а потом на сэкономленных на обедах деньгах (был студентом) удалось в позже в Ленингад купить первое советское еще издание. Давно это было, вот всё в голове уже и смешалось

в большой "зелёной" конторе, недавно сказано было открытым текстом: "или применяйте ИИ, либо увольнять будем".

Большая "зеленая" контора недавно заявила, что и нанимать на все ключевые позиции намерена только кандидатов с базовыми знаниями искусственного интеллекта (ИИ).

Осталось узнать, что такое "ключевые позиции" и "базовые знания".

Ну так и "внедрять". Сначала за счет компании самообучиться т.н. "промпту" запросам, продолжить в роли ML, а затем сказать адьос и грасиас за карьерный рост. (только если очень хочется, подумайте)

Ведь эта нейрошиза не закончится пока они, такие начальники, не доведут компании до спуска вниз, в пропасть. Или пузырь и хайп раньше схлопнется. Если закрывать своим сверхурочным временем понижение эффективности через внедряемые инструменты, то они будут думать, что всё отлично идет. Мы же понимаем, что не везде они применимы. А управленцы пребывают в мечтах, что работники противятся эффективнее благодаря "ИИ" работать. Это не так (за исключением случаев, которым всё новое чуждо). Тут либо идти напролом и самому собирать учетность об эффективности, либо использовать этот хаос с пользой только для себя.

Какие янтарные табулирования в монохроме маркетингов в 1997 году

В больших организациях в то время были легаси системы с янтарно-янтарными монохромными терминалами, подключенными к какому-нибудь мейнфрему. И это не было даже каким-то запредельным старьем, например серия терминалов DEC VT-5xx была анонсирована в 1993 году и производилась до конца нулевых, правда, эти уже не были такими вырвиглазно янтарными, но все равно оставались текстовыми и монохромными.

Году эдак в 2015м наблюдал работающий DEC PDP монитор на столе начальника большой организации. (Saudi Electro в Аравии)

Красивое. Есть что-то приятное в этих древних ручках, корпусах, обводах

Я уже давно уверен, что всё это супер многоходовочка по продаже курсов по написанию крутых промптов для несведущих. Зарабатывают во время кризиса очередным мировым разводом, классика уже.

Прежде чем создавать себе идола гиперпродуктивности, следует вспомнить, что софт не самоценен и в основном пишется под нужды человека. Если писать в N раз больше софта, то нужда в нем вырастет в N раз?

Скорее упадет в N раз. Сколько аналогов notepad уже существует? Если их число удвоится- много ли кто удалит gedit и ради чего?

Увы, меня годами мучает эта проблема, что нет нормальной альтернативы notepad и calc под Windows. Под Linux чуть лучше, но зато там нет аналога paint. Честно, за годы я перепробовал все, что мог найти, но увы. И платные приложения покупал, тщетно. Так и пользуюсь под windows geany и физическим научным калькулятором. Остается только сделать вывод, что простота данных программ немного обманчива, чтобы был поток любительских хобби-программ, плюс они плохо монетизируются, чтобы были профессионально сделанные альтернативы.

Чем плох noteoad++? Получше, чем notepad. Есть даже онлайн-редакторы от Google и MS.

Чем плох PAINT.NET? Получше, чем Paint.

Именно эту двойку использую уже очень давно. Notepad++ - шикарный.

К базовому текстовому редактору, на мой взгляд, основные требования такие: мгновенное открытие для редактирования конфигов и текстовых файлов, мгновенный отклик при работе с файлами произвольной длины, подсветка синтаксиса, навигация по файлам в дереве каталогов, поддержка разных кодировок. Требования не изменились со времён FAR :)

С этой точки зрения, notepad++ пробовал много раз (как и notepad2 и всё подобное). Конкретно у него недостатки: отсутствие внятного простого способа навигации по дереву файлов, очень перегруженный интерфейс кучей сомнительных функций, неприятное и хаотичное оформление UI, плохой UX/DX (user/developer experience).

Онлайн-редакторы эту задачу тоже, очевидно, не решают. Может быть, для других задач они неплохие (не знаю, я не нашёл им применения), но для быстрого distraction-free редактирования конфигов - явно нет.

Paint .NET, конечно, неплох. Но про Paint я говорил об отсутствии аналога в Linux. В Windows есть сам оригинальный Paint, который, на мой взгляд, идеален и совершенен, это как уаз буханка, или json - такие вещи, скорее, можно открыть (как научное открытие), а не разработать:)

FAR и сейчас живее всех живых. Постоянно пользуюсь. Свежие версии выходят. Есть его близнецы и для Линукса.

Навигация по дереву файлов - это не функция редактора, вообще-то. В Фаре это просто очень удачно сочетается.

Я думал, что Paint.NET работает и на Линуксе тоже. Есть вроде всякие инструкции, как его на Линуксе пускать. Ну и аналоги есть, конечно.

Увы, Sublime мне кажется не самой подходящей программой для "простого редактора". Без изучения возможностей (и как ими пользоваться) дальше стартового окна не уйти. Наполовину как [g]vim, про который ниже также писали.

На мой взгляд, это всё-таки недостаток программы, т.к. к 2025 году сложились удачные практики UI/UX, которые позволяют изучать программу по мере её использования, а не до первого запуска. Пример - тот же VS Code. А отдельно изучать текстовый редактор мне кажется немного притянутой задачей, если его роль - именно простой базовый редактор, не IDE и подобное. Для профессиональных задач я использую другие IDE, CAD, EDA программы, всеми из которых нужно уметь хорошо пользоваться, и с этой точки зрения изучать ещё и "простой текстовый редактор конфигов" кажется немного лишним.

Если кто-то использует sublime или gvim как основной рабочий инструмент, и хорошо его изучил, тогда нет вопросов. Они должны быть довольно круты в этом случае.

к 2025 году сложились удачные практики UI/UX, которые позволяют изучать программу по мере её использования

Все эти всплывающие подсказки "вот тут у нас панель инструментов, теперь нажми туда, потом сюда, а теперь ещё вот сюда" к десятой программе уже откровенно раздражают.

Если кто-то использует sublime или gvim как основной рабочий инструмент, и хорошо его изучил, тогда нет вопросов. Они должны быть довольно круты в этом случае.

Даже изучив vim на базовом уровне "замены блокнота" (что не так сложно, как кажется при его первом запуске) Вы уже обнаружите, что не нужно быть ни крутым, ни знающим наперечёт все комбинации кнопок, чтобы работа с текстом стала куда проще.

Я пробовал какое-то время пользоваться vim, научился худо-бедно навигации и редактированию, но мне всё время казалось, что я себя насилую на простейших задачах:) Видимо, не хватило до порога комфорта. В emacs, кстати, тоже какое-то время сидел, но после современных редакторов это всё кажется очень неудобным.

И платные приложения покупал

На что только не идут люди лишь бы не использовать [g]vim....

мгновенный отклик при работе с файлами произвольной длины

Вы же понимаете, что мгновенно в произвольном порядке прыгать по файлу размером в терабайт, хранящемуся на стриммерной ленте, физически невозможно?

навигация по файлам в дереве каталогов

https://github.com/preservim/nerdtree

прыгать по файлу размером в терабайт, хранящемуся на стриммерной ленте

Не просили такого. Просили для файлов на устройстве которое способно в произвольный доступ.

Просили для файлов на устройстве которое способно в произвольный доступ.

Если занудствовать, то я не вижу такого требования в предыдущих комментариях.
А если нет, то я предлагал задуматься над тем, что не только от самого редактора зависит скорость работы с файлом. SMB поддерживает произвольный доступ, смонтируйте каталог по SMB с сервера, до которого пинг 500 мс., и будет не менее весело, чем с лентой.

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

Аналог Paint в Linux: Pinta. Мне для обрезать-пересохранить хватает. Gwenview с чем-то там еще тоже умеет, но одновременно перегруженный и упрощенный интерфейс с банальной аннотацией картинки ужасно справляется. Хотя редактирование текста почти у всех слабое звено. Только редакторы с поддержкой слоев ещё как-то припособить можно.

У Notepad++ есть сейчас какой-то как раз distraction-free режим, где почти всё прячется.

И почему мне кажется, что вы описали Brief...

Чёт страннае, не очень репрезентативное исследование.

Для конфигов:

  • Sublime

  • Vs code

  • gEdit

Paint:

  • KolourPaint

  • Pinta (для минимализма можно версию старую взять)

  • Gpaint

  • Xpaint

Paint, который, на мой взгляд, идеален и совершенен

Какая версия? Начиная с Семёрки он забагован настолько, что плакать хочется. Выучил все баги и нашёл контрмеры.

Начиная с 11 он убит, пользоваться им невозможно. Поставил от Семёрки и облегчился, хотя добавился ещё один назойливый баг.

Эх, xpaint :) Задумка, очевидно, именно такая, но им невозможно пользоваться, он ужасен во всём. Как и его брат gpaint (GNU paint). При необходимости использовать "paint" на Linux я в итоге пришёл к Krita, хотя она, конечно, жирновата по сравнению с истинным Paint.

Хеллоуворлды на гитхабе не под какие нужды не пишутся, но даже их больше не стало.

Потому что сюрприз - собственно написание кода забирает меньше времени, чем все остальное в создании софта.

К примеру, есть ловушка рефакторинга - когда ты постоянно переписываешь код, хотя он уже работает

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

На нейросети хорошо учиться, проверять.

Но работать... Не всегда

Ну будешь же ты вечным джуном

"Новые фичи не появляются".
А они часто и не нужны. Нужно чтоб те что есть, работали хорошо и удобно.

Вы хотите сказать, что в MS Word не нужно добавлять новых фич? Что в нем не нужна работа с криптой и редактор видео?? /s

И встроенная нейронка, которая будет сама весь текст писать же! 🙃

А вот нейронка по работе с текстом была бы реально полезной. И зуб даю, она там будет)

Это же классика. Сделать код по красоте - простая и понятная задача с измеримым результатом, а сделать новую фичу - сложно, долго, и надо общаться с людьми

Конечно мозг выбирает первое, ИИ просто снизил порог входа в этот вид прокрастинации

Посмотрите на данные. Нет никаких новых 10x-инженеров. Если бы были — если бы 14 % тех, кто объявляет себя 10x-инженером за счёт ИИ, действительно были таковыми — это более чем вдвое увеличило бы мировую выработку нового софта. Этого не случилось.

Но ведь разработка из написания кода состоит процентов на 5-10. Изредка около 15-20%. А, кажется, "ИИ" ускоряет только эту часть (возможно, ошибаюсь).
Так вот: 0.1*10+0.9*1 = 1.9 раз ускорение работы было бы.
0.14 (которые якобы 10х программисты)*1.9+0.86*1 = 1.126.
То есть ускорение было бы процентов на 12 больше, если 10х-программистов 14% и если доля кода у них 10% от времени разработки.

Допустим они чисто кодеры, а вся остальная команда (обычно это человек 4-7) прекращает разрабатывать и подсказывает и согласует требования, тестирует (в т.ч. продакшн тестирования, типа производительности или стабильности), дебажит, готовит архитектуру и всё такое. То 10 (вся производительность ускорена)*1/5 (команда из 5 человек, один 10х кодер) + 1*4/5 = 2.8. Если такие 10х программисты распределены равномерно (то есть по одному на команду), а команды, допустим, везде в среднем из 5 человек, то, получается, 14/20 команд ускорятся в 2.8 раз, а 6/20 останутся х1. Считаем: 0,7*2,8+0,3*1= 2.26. И, если верить автору, если учесть, что ускорения релизов в 2 раза не случилось, значит команды устроены менее эффективно. Или опрос был на уровне "100% опрошенных на нашем сайте подтвердили, что пользуются интернетом".


Это я к чему: даже если эти лихие формулировки чуть развернуть (и в итоге придти к тем же цифрам; хотя я ожидал оспорить цифры, но получилось только подтвердить), то да - разработка эффективнее не стала, бум не случился.
В общем, серебрянной пули опять пока нет, как обычно)
Пока что "ИИ" выглядит как "лошадь быстрее", нежели ДВС. Если даже и быстрее, что не факт, как мы видим из статьи (если там было всё грамотно исследовано; не слишком внимательно вчитывался).

С другой стороны, если ускорять все этапы (сбор требований, аналитика, согласования, проектирование, программирование, дебаг, тестирование, приёмка, документации, доставка кода и продукта (CI/CD)), то может быть и случится ускорение на несколько процентов.
Но даже если ускорить каждого участника, то человеческий фактор всё равно останется: недопонимания, забывчивость, наложение графиков для обсуждений (люди однозадачны (если без потери качества)), болезни, отпуска, усталость и так далее. И итоговое ускорение всё равно будет процентов на 5, даже если в среднем каждого ускороили раза в 2. А сокращать кол-во людей (чтобы уменьшить проблемы коммуникаций) = увеличивать входные требования к компетенциям работников, а это экспоненциальный рост оплаты труда (полезность при этом может расти чуть больше линейной. В любом случае, не больше квадратичной (ИМХО, взял из головы/опыта)). А экспонента больше квадрата. То есть может это и будет быстрее, но при этом будет сильно дороже.

Короче, думаю, даже линейное ускорение каждого участника рынка всё равно не даст экономию или феноменальную скорость разработки. Обычно это происходит с внедрением скачкообразно меняющих что-то технологий. То есть когда множится профит, но не множатся ошибки). "ИИ" (ИНС/LLM) пока что больше множит ошибки (и плодит новые), чем ускоряет профит.

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

интересное обоснование но для его доказательства вы выкинули тот факт что и на github нет всплеска активности, а там почти все проекты на 100% состоят из кода.

Так всё, кроме написания кода, ускориться должно было ещё больше. Тесты за всех уже давно LLM-ки пишут. Деплойные конфиги генерятся ещё быстрее.

Уже писал это где-то, но ещё раз напишу - сила этих тулз в том, что они могут работать в бэкграунде, пока ты занят другими задачами.

В итоге ты можешь условно работать над основной задачей в форграунде без ИИ или с малой его помощью и делать 1, максимум 2 задачи в бэкграунде. Либо делать 4-5 задач параллельно все с помощью ИИ, постоянно между ними переключаясь.

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

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

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

Где же ваши тридцать приложений за год ?)

а вы их у меня купите?

Нет, конечно

На самом деле за тот десяток минут что выполняется задача полноценно переключаться на что-то другое просто не успеваешь. А вот залезть на какой-нибудь условный хабр, или реддит потупить это да, успеваешь. :) Так что в целом, я доволен. :)

Это, кстати, я замечал перед отпуском. Уже торопиться не хочется и в целом легче, когда можешь отвлекаться. И открытый вопрос тут как не потерять в производительности из-за этого.

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

В общем я пока имею успешный опыт этого, но признаю, что далеко не всё ещё изучил и с разными проблемами сталкивался уже. Но в целом я вижу в этом будущее. Условно работать 4 часа вместо 8, делать в 2-3 раза больше при этом при увеличенном в 2-3 раза рэйте выглядит как интересная цель для зоны комфорта.

Хотел бы я поработать 40 часов жонглируя 5 задачами постоянно? В каких-то случаях за х5 рейт - возможно. Но думаю, что отпуски от такого станут длиннее.

Но в целом я вижу в этом будущее. Условно работать 4 часа вместо 8, делать в 2-3 раза больше

История научно-технических революций у человечества насчитывает столетия. В сравнении с первыми земледельцами, оснащёнными палками-копалками, человечество продвинулось неимоверно и рабочий день должен составлять минуты так 3, ладно, пусть 5. Ну хотя бы в сельском хозяйстве. Однако почему-то до сих пор пашут от зари до зари. Почему Вы считаете, что теперь-то уж точно будет иначе?

Ну я в целом уже сейчас могу работать по 4 часа в день (спойлер: работаю по 6.5, выбрал сам) при почасовой ставке. Работаю больше 4 в основном потому, что пока мне нужно чуть больше денег на мои нужды (не краткосрочные). Поэтому для меня это уже иначе. Приду ли я к 4? Да, вероятнее всего, если налажу процессы, которые описал выше.

Поэтому и считаю иначе. Будет ли это для всех так? Маловероятно

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

Я частично с вами согласен насчёт комфорта. Поэтому важно их "выгружать" из головы и трекать прогресс где-то. Условный GTD нужен в каком-то виде.

Насчёт выгорания замечено верно, теоретически оно может наступать раньше. Но надо это изучить и поэкспериментировать.

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

С 4-5 пока что нет, но вижу в этом теоретический предел для себя. Успешно получалось с 2 задачами только, немного пробовал с 3мя, недостаточно для выводов, но успешно, но данных пока мало.

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

Ещё есть момент, что большую задачу можно декомпозировать. И условно можно заставить курсор писать тесты, пока ты делаешь реализацию. Ну или даже заставить его работать над двумя задачами, но каждая в 2 потока условно, один для реализации, один для тестов.

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

Лично для меня ассистенты вроде Github copilot не работают, только мешают. А вот OpenAI codex реально работает и повышает эффективность

Это похоже на историю со строительством домов. Многие люди, далекие от строительства, думают, что самая дорогая и сложная часть дома - это стены. Их все видят, они большие, объемные. Но в стоимости дома они хорошо если 10% времени и трудозатрат. Именно по этой причине, кстати, многие проекты по автоматизации строительства стен (печать из бетона и прочие) загибаются, руками сделать всё еще дешевле и быстрее. Также и с разработкой ПО - написание кода - это только часть приложения. Еще есть идея, проверка гипотез, юнит-экономика, архитектура, аналитика, тестирование, деплой, переписывание кода, борьба с техдолгом и много чего еще. И про это всё очень часто забывают, а без всех этих частей нормальное ПО (что-то сложнее примитивной игры или одностраничного лендинга) сделать достаточно сложно. Пока уровень работы ИИ - это помощь. Да, разработка поменялась, сегодня решение проблемы - это не 50 вкладок со stackoverflow, а разбор проблемы в чате с ИИ. Ревью предложенного кода в любом случае быстрее написания кода вручную. Ни о каких х10 ускорении конечно речи быть не может, но какой-то прирост все равно есть. Он на прикладном уровне, мы стали писать код лучше и быстрее, если до этого умели писать хороший код быстро. Но это лишь отдельный этап SDLC, написание кода также как и стены - большой и видимый объем, но далеко не весь дом.

Стены быстро? Не скажи... Вот недавно у нас в подъезде клали стенку в два кирпича толщиной, шириной в метр и высотой 2.20м. За сколько её сделает не то что каменщик, но просто профессионал-разнорабочий? За день, если не спешить. У нас её делали две (!) недели. Такое доступно только настоящим мастерам своего дела! Возможно, даже ИИ использовали.

— Степан! Степан, тут у гостя карета сломалась.
— Вижу, барин. Ось полетела. И спицы менять надо.
— За сколько сделаешь?
— За день сделаю.
— А за два?
— Ну... за два... Сделаем и за два.
— А за пять дней?
— Ну... ежели постараться, то можно и за пять.
— А за десять?
— Ну, барин, ты задачи ставишь. За десять дён одному не справиться! Тут помощник нужен — homo sapiens.
— Бери помощников, но чтоб не раньше!

(с)

Нельзя такую стенку сделать за день - верхние слои будут выдавливать раствор из нижних+ вертикальная деформация. Если условно взять толщину "кирпич + раствор = 75мм", то предельный максимум - около 10 рядов, то есть, около 3 дней. Если рекомендуемый оптимум - 5 рядов в день, то почти 6 дней. Не 2 недели, конечно.

Кажется, он делал по 2 ряда, потом 2 дня отдыхал, потом опять 2 ряда.. И так далее.

по 2 ряда на метровом отрезке, это сверхнадежно, конечно :)

Это сверхтрудно. Уверен, там ещё и помощник был)

Повторю свой вопрос к all из другой темы...

Давайте проведем блиц-опрос: Рост продуктивности при использовании LLM связан с более легким и быстрым выходом из прокастинации - согласны да/нет?

Да. Отличное примечание!

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

Думаю найдутся еще причины для прокрастинации, если устроить опрос.

в) код эволюционирует сам по себе и требует полного ревью 500 строк говнокода после каждого изменения.

Это, кстати, решается более мелкими задачами в промте. Но уменьшает возможность распараллеливания.

А вообще про прокрастинацию идея интересная, надо будет обдумать.

Кстати, да, порой ведь самое сложное - это начать, а ИИ помогает это сделать, пусть и написав неправильный код, зато хоть какой-то

пусть и написав неправильный код

неправильный код я и сам напишу ;)

Не всегда :) Мне DeepSeek помог дважды. Нужны были маленькие утилиты - один раз на Java, другой на PowerShell. Оба знаю на уровне "примерно понимаю, о чём пишут". Справился довольно быстро, за несколько итераций - работа ускорилась на 1-2 порядка точно. Наверное, в статистике я как раз принадлежу к тем 14% разработчиков :)

В моём основном инструменте разработки пробовал - полная фигня. Вплоть до использования в коде выдуманных имён стандартных функций, которые выглядят похожими на настоящие, но радости не приносят ;)

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

Вопрос к all был в том помогает ли вам код написанный общение с иишечкой въехать в эту рутину быстрее или нет. Пока что результаты 50/50 я бы сказал...

Оффтопик, но фраза "вопрос к all" меня вернула в фидонет 90-х 🤣 Спасибо за триггер из RU.*

В фидонете (FidoNet) в эхах часто писали 2All / To: All — обращение “ко всем”. Отсюда и привычка формулировать «вопрос к all».

многоуважаемый all :)

Прокрастинирую независимо от ИИ. Хотя, мне ИИ только помогает искать и исправлять ошибки по логам в консоли, код предпочитаю писать сам.

Крайне интересные графики.
Был уверен, что волна инди-разработки если не накатилась, то вот-вот накатится.
Типа соцсети для выпекателей пирожков или телеграмм-бота для страюающих от диабета.

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

Автор статьи (не перевода) заявлял что работает с ИИ довольно давно. Но при этом решил делить задачи "по монете“, то есть подкидывая нейронке с высокой вероятностью в том числе те задачи, в которых ИИ заведомо слабы.

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

Я думаю после броска монеты он решал задачу наиболее эффективным образом. Монета нужна чтобы разделить себя на две группы и сделать статистически чистый результат без предубеждений

Тут всё переведено верно: он действительно распределял задачи случайно. Половину он выполнял с ИИ, вторую половину — полностью самостоятельно. Это и есть суть эксперимента как у METR, так и у автора статьи.

Понятно. Нужно было собрать непредвзятую статистику.

Однако интересно было бы посмотреть на результат другого подхода, о котором я упомянул. Не давать AI задачи, в которых он не тянет (логика, вычисления), и наоборот, не отбирать у AI задачи, в которых он обойдёт человека по скорости (код простого класса).

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

За свою область могу сказать, что на задачах системного и бизнес-анализа LLM ведут себя неплохо. Слабые места и пропуски уверенно находят. Но это в основном в качестве инструмента ревью, а не основного аналитика. И выигрыш получается больше не во времени, а в качестве.

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

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

Мне кажется было бы полезно сопоставить с прибылью компаний. Быть может там есть какой-нибудь значительный рост? Тогда ожидания связанные с ростом продуктивности от технологий ИИ по-видимому насчёт именно прибыли, а не чего-либо другого. Если один программист с ИИ ассистентом может делать столько же, сколько два без него, то одного можно уволить, половину его зарплаты оставить себе, а половину отдать оставшемуся программисту. Отсюда же и объяснение почему нет никакого прироста конечной продукции - это и не нужно, перенасыщать рынок. Нужно (владельцам бизнеса) максимизировать прибыль.
Если же повышения продуктивности программистов действительно нет, то сокращение штата должно привести к падению темпов выпуска новой продукции и падению прибыли.

Мне кажется было бы полезно сопоставить с прибылью компаний. Быть может там есть какой-нибудь значительный рост?

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

Тогда 13%, заявивших о 10-кратном росте производительности вытеснили бы ВСЕХ остальных с рынка труда.

Ну, эти 13% скорее всего люди, любящие немного приукрашивать свой потенциал, просто потому что им нравится так себя видеть со стороны, или с расчётом что-то материально от этого выгадать. Но 1.5-2 раза рост производительности, мне кажется достичь за счёт ИИ реально. Только это может оказаться отложенными на потом проблемами. Т.к. имея такой мощный "процессор заклинаний" снижается стимул напрягаться самому чтобы что-то эдакое соорудить. А нет напряжения, нет и новых связей между нейронами - всё ведь получается итак с меньшими затратами энергии на мозг. Ещё одна проблема на будущее - разрыв в цепочке передачи опыта, т.к. под нож идут прежде всего новички, которые могли бы вырасти на решении реальных задач по мере роста их сложности и перенимая опыт у старших. Но в новой реальности старшим дали ИИ вместо джунов, и эта эстафета прерывается.

>Отсюда же и объяснение почему нет никакого прироста конечной продукции - это и не нужно, перенасыщать рынок.

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

А еще есть открытые проекты которые вообще на такую логику не завязаны - где бум открытого кода, написанного с десятикратным повышением производительности от ИИ?

Есть тут лукавства.

Claude Sonnet в качестве агента стал нормально кодить всего несколько месяцев назад.
Функция делегирования агенту в облака на сам GitHub скажем в GitHub Copilot появилось вообще пару дней назад.

А главное - агенты еще очень медленно работают. Ожидание в пару минут на простые запросы просто тормозит работу. Никогда не угадаеш когда он тормознет.
Да и сборщики еще очень медленные.

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

Я считаю что ускорение с агентами реально достигает 5-10 раз. Но при условии отлаженного рабочего процесса и дорогого плана.

Рабочий процесс при этом настраивается однократно или приходится всё делать с нуля под каждую новую версию агента?

Ну то есть сколько процентов рабочего времени на длинном плече планирования (год, скажем) будет отнимать настройка рабочего места?

Ну, и уже традиционный для этого обсуждения запрос: покажите ваши 30 проектов, сделанных за прошедший год.

Что вы, не 30, а "5-10"!

Но он же из пункта 2:

«Ну это новая технология, в неё так много вложено, и нужно время…»

Недавно выписал в csv и загрузил в эксел сотни наименований со скана. С перплексити это заняло минуты, перепечатка вручную заняла бы полчаса.

С кодом я бы предположил, что проблема в том, что копилот сможет сэкономить время на написание 80% кода, который занимал у вас 20% времени, сейчас займёт 5%. Но на написание 20% кода уходило 80% времени со стековерфлоу, и сейчас уходит сопоставимое количество, только с копилотом, вычитывая и ловя его ошибки...

Вы перплексити случаем используете не как микроскоп для забивания гвоздей? Мне кажется , пакеты OCR существуют давным давно как раз для этой задачи. Или у вас нечто большее, чем просто распознавание наименований?

Ни один из OSR [что я видел] не сравнится по возможностям с llm. Текст может быть сложным, в таблицах, плохо отсканирован, выдать его нужно в разных форматах, например, словарь python...

Если с помощью LLM это занимает минуты, вы уверены, что поиск подходящего инструмента длс OCR, его скачивание(покупка?) установка, настройка, изучение итд. займут меньше времени и будут целесообразны?

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

Агентское программирование пока что не работает

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

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

Еще в графиках нет резких падений, а ведь много народу было уволено. Может так и должно получиться?

Вот-вот, может вообще тот же уровень выпуска софта теперь поддерживает, допустим, в два раза меньше людей.

Ну вот у меня лежал петпроект и я не мог его доделать год, потому что ну нафиг после работы ещё работать. А с агентом довел за месяц. Потому что легко. Промпты описываешь, код почиываешь. И не надо на каждую мелочь мозг включать.

Или потому что было интересно тратить время на копание с агентом, а "традиционным способом" - уже было не интересно? Т.е. просто за счет увеличения времени?

Не сказал бы что это интересно, скорее легко. Я прихожу уделанный с работы, мозг отказывается напрочь даже от задач типа "найти этот класс и добавить поле". Но абстрактно мыслить я все ещё способен. Я описываю как новая фитча должна работать, через минуту получаю код. Смотрю, исправляю описание или дописываю замечания. Дебаг как правило даже не требуется. Конечно, сложные алгоритмы я описал раньше вручную, те доработки что сейчас это довольно простая обработка данных, фронт, добавление админки.

Экстаз помню ощутил когда добрался до локализации. Буквально за час получил полностью локализованное приложение на ангулар. Раньше за это время в лучшем случае успел бы почитать про фреймворки и получил первую переведенную строку.

Так это наркотик. После многочасовой лыжной прогулки многие люди испытывают эйфорию, сравнимую с той, что можно получить сразу — при помощи наркотика. Вопрос в последствиях. Не развращается ли мозг от таких лёгких побед?

Да, вот в этом и суть, другая когнитивная нагрузка. Всё таки читать код и писать это совсем разные вещи.

Что используете?

Я написал одно ширпотребное приложение для себя, которое не смог бы себе позволить без llm, доработал в другое немного фиксов и... я на 150% согласен с автором статьи) тоже очень хотел завалить софт сгенерированным софтом за 15 минут и в прод, но даже в самых простых кейсах (пустой проект, конкретная задача) - llm отнимают очень много времени и сил на себя.

Даже планировал написать на эту тему статью на хабр про возможное начало эпохи микроприложений - но эпоха так и не началась (

Что за агента и LLM вы использовали?

Пробовал курсор, но он мне для android вообще показался неудобным (модель встроенная).
Перешел на continue в android studio - подключал разные модели, gptchat-4o, локальные модели через ollama. В конце вообще "сдеградировал" до использования anythingLLM + deepseek, без всяких улучшайзеров для автоматической работы с файлами.
(наверное это ответ не про агентов, но тогда я их не использовал))

Так в этом возможно и дело. Я пробовал другие модели, кроме Sonet 4, но все они просто бесполезны. Это единственная которая не косячит нон-стоп в режиме агента.

Пробовал из интереса Sonnet 4, писать с ним приложения мобильные с нуля. Все таки в мобильной разработке там дикая печаль. Кроме того что используются устаревшие подходы и библиотеки - кошмар с т.з. как чистоты кода, так и его работоспособности. Даже если всякие md файлы с правилами писать. Даже если нужно внести какую нибудь мелкую правку, а не написать что-то крупное. Даже если ревьюить каждый шаг и пинать за ошибки.
При этом переводил хоумлабу свою на nixos, казалось бы куда менее распространенная штука, а все же справляется куда лучше с написанием nix конфигов. С вебом у моделей тоже относительно неплохо (ну, на моем уровне понимания, специализация не моя все таки). Я уж хз чего они так все поголовно в мобильную разработку не умеют, но вот как то так сложилось что не умеют LLM в мобилки.

Мне как-то привезли китайский прибор для поверки счётчиков энергии. Он подключается по последовательному интерфейсу к PC. Дали PDF с документацией и попросили написать консольную утилиту чтобы управлять этим прибором. Документация это 200 страниц китайского английского. В общем признал я вначале. Но потом загрузил PDF в Gemini и попросил написать на Go консольную утилиту. Сказал ему какие операции нужно реализовать. Ну и все, он за пару минут все нагенерил и оно с первого раза заработало. Я его ещё попросил разделить на файлы и немного порефакторить. В итоге потратил на все минут 30 и отдал на производство. Сам бы это я неделю писал.

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

Главного не сказал - эта утилита счётчик могла обратно откручивать? Нет?? Так нафик она нужна тогда)

Программисты существа ленивые. Вместо того что бы делать больше кода они могут больше отдыхать, кода в итоге столько же а человек пахал не 12 часов в день а всего 8.

Тот факт что любой желающий с околонулевой базой в нужном направлении теперь может сделать свой тетрис вовсе не означает что плей сторы должны немедленно наводниться бесчисленными тетрисами. Я вот например сделал крутейший калькулятор с фонариком для андроида и... удалил.

В написании инди игр роботы пока не рулят, кроме кода надо еще арт сделать, собрать всё, оттестировать, очень много разнообразной работы и почти 100% провал в итоге даже у живых людей.

Дэниэль ЛаРуссо — главный герой кинофраншизы «Парень-каратист» (The Karate Kid). <...> чем автор дополнительно ещё раз обозначает свой возраст.

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

Вайбы 80-х могут и нравиться, но в что-то конкретное это перевести сложно. Вызваны они медиафраншизами по типу «Очень странных дел» и общим трендом моды последних лет на 50-е и 80-е.

В 1984 году «Парень-каратист» попал на пятую строчку по кассовым сборам в США. Это далеко не самый популярный фильм восьмидесятых: на IMDb у него всего 264 тыс. оценок. Для сравнения: «Назад в будущее» 1985 года оценивали 1,4 млн раз. Рейтинги стримингов показывают, что смотрят обычно недавние семейные или просто детские фильмы и сериалы, а не что-то старое.

Но даже самые популярные старые американские блокбастеры не имеют особой популярности среди молодёжи. Свежий (май этого года) опрос Gallup показывает, что лишь 53 % молодых людей от 18–29 лет видели «Челюсти», в то время как у групп постарше этот показатель куда выше: 72 % для 30–49, 78 % для 50–64, 82 % у возрастной категории «старше 65».

Когда бренд The Karate Kid продвигают среди молодёжи, тяготеет он к ребуту, а не оригинальному фильму 1984 года. «Кобра Кай» собрал 16,7 млрд минут просмотра уже к 2023 году. Но это не оригинал, где была цитируемая сцена на пляже.

Ну а в сериале-ребуте конфликта на пляже у Джонни и Дэниэля попросту нет. Не припомню даже цитат во флэшбэках. Вот если бы речь про «удар журавля» — тогда да, это в сериале цитируется часто.

лишь 53 % молодых людей от 18–29 лет видели «Челюсти»

По-моему это нереально крутой показатель для фильма, вышедшего до рождения их родителей.

а если считать табулирование маркетинговых исследований на янтарных монохромных экранах

И, все-таки, мы живем в новом мире, в котором можно за несколько секунд закинуть оригинал в LLM-ку и получить правильный перевод вместе с объяснением:

" если считать обработку маркетинговых исследований на янтарных монохромных экранах "

<spoiler>

Фраза «market research tabulation» относится к одному из ключевых этапов в процессе проведения маркетинговых исследований.

"Tabulation" (табуляция, или составление таблиц) в данном контексте — это процесс систематической организации и подсчёта данных, полученных в ходе исследования (например, из анкет, опросов или интервью), и их представления в виде таблиц, графиков или диаграмм.

Если объяснять проще:

  1. Сбор данных: Компания проводит опрос, например, спрашивает у людей, какой их любимый бренд кофе.

  2. Табуляция: Ответы респондентов (например, "Якобс", "Нескафе", "Лавацца") вручную или с помощью программы (в те времена — с помощью специального софта на монохромных экранах) подсчитываются и сводятся в таблицу. Например, в одной колонке — названия брендов, в другой — количество людей, которые их назвали.

</spoiler> - опять не могу вспомнить, как сделать spoiler. Помню, какой-то тэг был, но не могу найти. А Firefox в WYSIWYS такого нет, если что. Подскажите тут.

Если вы намекаете на некорректность моего перевода, то в литературно-техническом русском обычно используется именно термин «табулирование», а не что-то разговорное типа «сведение в таблицы». Примеров много (1, 2, 3).

Хорошо хоть не табуирование.

Хм. Никогда не слышал в употреблении такой термин. Хоть и начинал даже с черно-белых телевизоров вместо янтарных монохромных экранов.

Всё верно, это из сленга маркетологов. Они, видимо, тянули термины как попало, без желания перефразировать.

в WYSIWYS такого нет

[+] перед началом строки, прокрутить вниз до "[*] Спойлер"

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

У меня время на разработу MVP уменьшилось примерно в 10-20 раз

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

Проблема с "ться" очень характерна. Да, учиться не хотят.

И минусуют еще. вы это заметьте. скоро блин обратный фильтр применять придется на habr.com, заминусовано - знач, годное что-то.
ХЗ, у меня не взлетает. (Никаких N*1000 строк в день) Модель, что-ли поменять. А чему вы научились? И сколько строк в день вы пишете? На каких ЯП? В Cursor или как?

В основном использую курсор с жпт-5 и клодом .

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

Чему научился, да просто привык к нему , как правильно подготавливать промпты и ТЗ , что писать в системном промпте, какие линтеры и плагины ставить. самое главное это как формулировать запросы на выполнение. что можно говорить что нельзя (но тут много меняется от времени и модели)

Цыганством не занимаюсь, никого не учу, темболее за деньги.

по количеству сток , бывает по 5-10 к строк в день. Свои деньги отрабатывает на 100%.

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

Извините что с задержкой. но могу писать только раз в сутки.

У меня пара замечаний по первому главному графику "Performance".

1) Не люблю неверные названия. Тут не производительность, а ее обратная величина (больше - хуже). Всегда режут глаз такие надписи "Скорость, больше - хуже".

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

Ну вот хз. У меня щас в проекте 300кб кода на си, которые бы писал мало того что в три раза дольше, так еще и кучу ошибок наделал (я плохо знаю си). И 90% кода сгенерировано. Узкое место в тестировании функционала, даже не том, правильно ли работает, а в "удобно ли с этим работать", в придумывании идей/путей решения проблемы и в ревью кода. В опенсорс этот код не попадает, потому что это мое ноу-хау, не имеет смысла отдавать в опенсорс то, на чем планируешь зарабатывать. Релизов тоже больше не стало, потому см. выше — узкое место в тестах на использование и в кастдеве, а не в скорости написания кода.

Меня очень сложно убедить в том, что нейросети ухудшают производительность. Да, возможно процентов 20 — это я захотел некоторую необязательную фичу, без которой можно было бы прожить, и зря потратил на нее время, и без LLM я бы просто на нее не отвлекался, а положил бы в беклог.

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

Это не мир свихнулся, это бизнес увидел потенциальную возможность здорово сэкономить на труде программистов. А там где возможность, там и угроза самому существованию бизнеса если конкуренты освоят её раньше. Поэтому бизнес не успокоится, пока дело не будет доведено до конца тем или иным образом.
Уровень и качество жизни обычного разработчика, равно как и любого другого человека на планете, в этой плоскости, увы, никого не волнуют. Станут разработчики работать и зарабатывать как работники складов амазона или водители убера - прекрасно. Исчезнут, замененные ИИ, совсем - ещё лучше.

Бизнес получает деньги с пользователей, затем распределяет их сотрудникам, так что смотреть надо с этой стороны. Если ИИ действительно будет давать приличный бонус к скорости (при таком же качестве) разработки, то компании его использующие смогут выпускать больше продуктов или более сложные продукты за то же самое время, или же обходиться меньшим количеством разработчиков при сохранении тех же планов релизов.

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

А вот оптимизировать расходы любят все. Если связка программист + ИИ полностью заменяет двух программистов, то вариантов немного: это просто увольнение половины программистов. Это если считать, что эффективное использование ИИ это заслуга только ИИ, а не каких-то навыков программиста. Только вот и здесь, бизнесу выгоднее будет поверить, что это строго так, а программистам выгоднее убеждать в обратном. И всегда будут находиться кадры, которые смогут убеждать, что со своими навыками промптинга они способны заменять не двух программистов, а целый отдел, за скромные х2 к окладу... В общем есть о чем пофантизировать.

в глобальном смысле улучшит ли это уровень или качество жизни обычного разработчика?

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

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

Не знаю где автор хочет увидеть еще больший поток ненужного софта. Зато в реальную проблему о которой стоит подумать он точно попал.

Может я далёк от разработки, но автор путает тёплое с мягким и сравнивает круглое с солёным, утверждая что левый совершенно не похож на 13.45.

Смотря какой код, смотря как ты его пишешь и ещё 100500 разных тонкостей. Разработка это же не копание ямы где 4 параметра - толщина, длина, глубина и время. Это ж больше про 2 часа плюёш в потолок, затем сопля отклеивается, падает на голову - эврика - 3 строчки кода, тест, прод. Ну или сутки что то колхозиш, три талмуда, две войны и мира, а затем неделю ищешь где б,ть запятая лишняя выскочила. В первом случае ИИ могут затянуть процесс, пока он поймёт что ты хочешь, пока посоветует что то дельное. Пока не окажется что это совершенно не то и он тупо что то выдумал, но вот в втором варианте сколько он может наэкономить времени?

ИИ-ассистенты это не первая серебряная пуля в разработке. Были и CASE-средства, и RAD, и No-Code, и каждый раз нам обещали революцию, а в итоге мы все так же сидим и руками правим конфиги. Похоже просто очередной виток цикла хайпа

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

если так много разработчиков стали экстраординарно продуктивными благодаря этим инструментам, где же поток ширпотребного софта? Нашему взору должны предстать приложения всех форм и размеров, видеоигры, новые сайты, мобильные приложения, SaaS — нас должно утопить в изобилии. Мы должны были бы жить в разгаре инди-революции в софте. Мы должны были бы видеть 10 000 клонов «Тетриса» в Steam.

Потому что мы и так уже живём в мире гиперизобилия софта. Куда ни плюнь, есть сотни платных программ, решающих конкретную проблему, десятки бесплатных, сотни обсуждений как добиться нужного результата и вовсе через скрипты. Уже года с 15го я понимал, если мне нужно сделать что-то, для чего нужен какой-то новый скрипт или программа, то не стоит даже тратить на это время - такая программа уже есть. И нет никакого шанса заработать денег вкладывая тысячный клон тетриса в стор, никакого, поэтому такой ерундой давно уже никто не занимается. Уже с сотого клона было понятно, что это тупиковая идея, хотя все равно раз в пару недель какой-либо недавний школьник пушит свой клон в стор в надежде "ничего не теряю, но вдруг повезёт".

Просто это никому не интересно. И ни с какой целью кроме спама маркетов - не нужно. И они с этим ещё и борятся вообще-то.

По поводу "крутого софта" вообще не понятно. Какие необходимые и достаточные критерии считать софт крутым? А вообще достойным огласки? Не понятно. Вот мой знакомый считает fallout 76 крутой игрой, а мне просто жаль, что это вообще случилось в мире, жаль потраченного на него пусть и небольшого времени. Для меня лучше, чтобы его вообще не издавали. А это делалось ещё до бума ИИ. Но то дело личных вкусов, а есть ещё рынок, который ясно показывает, что если компания выпускает одну за другой "плохую" игру, то она начинает получать только убытки. С ИИ можно делать это ещё быстрее, да, но, как бы зачем вообще?

Я не разраб, но
Последние годы особого хайпа ИИ(нейронок) я все жду когда же допилят всеми используемый софт (MS Word, excel или их аналоги), там есть море областей куда интеллектуальная обработка отлично бы помогла сократить трудозатраты, особенно в табличках с формулами и макросами можно было бы выти на новый уровень функциональности. Но нет. Буквально не слышал о готовых продуктах в этой теме. И ведь весь мир в основном работая на компах пользуются этим софтом, а новоявленное чудо даже не обещали в этой области.
Помощь в написании кода это хорошо, но чем оно в принципе лучше чем 10 индусов? говнокод он не важно откуда, все равно говнокод, который надо редактировать, встраивать в общую структуру и т.п.
ИИ не первый раз хайпит, потолок у новой технологии уже найден, но до тех пор пока пузырь(доткомы...я не намекаю, оно буквально доткомы-2) не лопнет, вменяемой адаптации этой технологии в нужные отрасли не случится, просто потому что технология дико переоценена и в деньгах и потенциальной широте применения и степени надежности.
Интуитивный ассистент в notepade++ который глядя на ваш код подскажет возможные варианты следующих строк на основе учебников(а не всей мировой помойки) -да!
Умный поиск с аналитикой по нормативной документации любого вида и рода- да!
Анализ изображения для определения наличия/отсутствия и решения возможных проблем(типа диагностика оборудования в VR среде для ремонтника) -да!
и еще море узких профильных тем.
Но уж точно не палочки-выручалочки на все случаи жизни, которые сейчас активно пытаются продать инвесторам.
Разработка софта это проект, а проект тем и специфичен, что уникален и не имеет однозначного, повторимого алгоритма для реализации, и

все это знали с самого начала, кто имеет отношение к управлению проектами.

Я все еще жду умных ассистентов, буквально с первых программ управления компьютером голосом, которые я с разочарованием пощупал лет 20 назад. Джарвеса помните? вот где такие ассистенты?

Насчёт умного поиска по нормативной документации - это очень больной вопрос.

До тех пор, пока не будут устранены базовые причины галлюцинаций LLM в виде "ответа любой ценой“, рассчитывать на такие агенты не стоит.

У меня тоже есть личный опыт использования ИИ. Я ИИ долго не пользовался, считая его игрушкой (на самом деле не умея с ним работать). Я не так давно пришёл на новое место работы: новая предметная область, новый язык, обширное легаси. Подумал, что надо подключить к этому ИИ. Сначала было сложно, он(я) тупил, давал нерелевантные результаты, кривой код и всё такое. Где-то месяц я мучился, потом нашёл человека, который в этом разбирается, и взял несколько уроков. Потом практика, практика и ещё раз практика. Я научился с ИИ эффективно решать все задачи цикла разработки: архитектурное моделирование, аналитику, проработку тз, генерацию кода (около 90%). Выросла ли моя производительность? — да, на порядок, а это значит, что я могу решить задачу быстрее, чем без ИИ, и заниматься своими делами. Хуже ли я знаю язык, чем узнал бы вручную? — да, но не критично. Много читаешь код, разбираешься в best practices, правишь мелочи, язык сам прилипает. Качество кода нормальное. А главное, меняется мышление. Становится более системным и аккуратным даже на маленьких задачах, иначе как ты объяснишь ИИ что делать?

И даже сами разработчики не лучше: 14% утверждают, что видят «десятикратный» рост производительности труда благодаря ИИ.

Чот слабенько. Стоматологи рекомендуют зубную пасту Colgate only в составе 95%!

но они всё ещё сосут

Всё же "suck" у нас принято переводить как "отстой"

Было бы интересно почитать подобные исследования про арт. Как появление моделей text-to-image сказалось на художниках, на количестве заказов изображений, упала/поднялась цена заказа и т. д.

Легко говорить о производительности, не имея никаких объективных способов измерения этой самой производительности. Тут нужен ИИ, чтобы измерить, чтобы разложить на атомы и правильно просуммировать.

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

BIAS. Кажется, это называется "bias".

Автор - высококвалифицированный специалист. Высококвалифицированному специалисту новые, не доведённые до зрелости инструменты не помогут. Пример - токарный станок. Первые токарные станки не могли сравниться качеством и сложностью с мастером-краснодеревщиком. Но существенно облегчали работу подмастерий. А потом оно развилось в станки с ЧПУ, лазерную резку и всё такое прочее. И много ли тех краснодеревщиков осталось? Есть, конечно, но индустрию деревообработки давно определяют не они.

Дайте время технологии созреть.

Ну дык. Я в нулевые, изучая Delphi и делая на нём простенькие игрушки тоже думал, мол, это мне сейчас тяжело и долго, а вот научусь - буду по игрушке в неделю делать. Столько ведь идей, столько хотелок.

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

Так что, вероятно, метрика не такая уж и релевантная.

Плюс, можно с уверенностью сказать, например, что хорошие IDE значительно повышают продуктивность и качество кода, но вряд ли получится отследить на подобном графике рост популярности того же VS Code.

ИИ для простых задач по форматированию хорош или для известных алгоритмов. Причём по многу за раз простых тоже плохо выходит. Но вот гуглит он изумительно) За 200$ не понятно за что, может тексты лучше составляет, не знаю, не пробовал.

Но вот гуглит он изумительно)

Ахаха

"В 1986 году в СССР ZX Spectrum стоил около 100 рублей, что для советского человека было довольно дорогой ценой, но устройство все равно пользовалось популярностью. Этот компьютер был очень востребован на советском рынке, несмотря на высокую стоимость."

Результатам гугления через АІ верить нельзя.

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

Где поток ненужного софта?


Зайди на продукт хант

Sign up to leave a comment.

Articles