Проблема ИИ - проблема удара молотком...
От: Shmj Ниоткуда  
Дата: 16.02.26 17:49
Оценка:
Байка становится действительностью:

  Скрытый текст

История про «1 доллар за удар и 9999 за знание»

На крупном заводе вышел из строя мощный генератор. Никто не мог понять причину. Пригласили Штейнмеца.

Он осмотрел машину, послушал её работу, что-то измерил, затем взял мел, поставил отметку на корпусе и сказал:

— Ударьте молотком вот здесь.

После удара генератор заработал.

Позже владелец получил счёт на 10 000 долларов. Возмутился:

— За один удар молотком — 10 000?

Инженер прислал детализацию:

  • Удар молотком — 1 доллар
  • Знание, куда ударить — 9 999 долларов



Вроде ИИ должно удешевлять процесс разработки, т.к. делает до состояния "80% готово". И далее — вроде мелкий баг остался... Но! Код плохо читаемый, ну то ладно. Более важно что код никто не знает, никто его не писал, нужно банально запомнить где что написано (а структурой ИИ себя не утруждает, ему и так ОК).

И вот получается что мелочь — но ИИ пустил по кругу, т.е. когда уже весь круг ада прошел и попаболь — все-равно зараза ничего не решил — приходится сдаваться и думать как решить кожаному.

Но кожаного такого нет кто бы раз — и быстро все решил. Найти куда "ударить" — это значит как-то разобраться с кодом, привести в порядок. А это время и те же якобы необоснованные деньги, которые не ясно как бы как можно брать за 1 удар.
Re: Проблема ИИ - проблема удара молотком...
От: Doom100500 Израиль  
Дата: 17.02.26 06:24
Оценка: :)
Здравствуйте, Shmj, Вы писали:

S>Байка становится действительностью:

Недавно, по-моему, на хабре видел заметку, что стали появляться вакансии на разгребание ИИ слопа.
Спасибо за внимание
Re[2]: Проблема ИИ - проблема удара молотком...
От: Shmj Ниоткуда  
Дата: 17.02.26 09:07
Оценка:
Здравствуйте, Doom100500, Вы писали:

S>>Байка становится действительностью:

D>Недавно, по-моему, на хабре видел заметку, что стали появляться вакансии на разгребание ИИ слопа.

Беда вот в чем. Теперь простят много денег за один "удар". Ты возмущаешься, говоришь — да как можно, ты же только одну строчку исправил. А тебе в ответ приводят эту байку.
Re: Проблема ИИ - проблема удара молотком...
От: Qulac Россия  
Дата: 17.02.26 09:13
Оценка: +1
Здравствуйте, Shmj, Вы писали:

S>Байка становится действительностью:


S>
  Скрытый текст
S>

S>История про «1 доллар за удар и 9999 за знание»

S>На крупном заводе вышел из строя мощный генератор. Никто не мог понять причину. Пригласили Штейнмеца.

S>Он осмотрел машину, послушал её работу, что-то измерил, затем взял мел, поставил отметку на корпусе и сказал:

S>— Ударьте молотком вот здесь.

S>После удара генератор заработал.

S>Позже владелец получил счёт на 10 000 долларов. Возмутился:

S>— За один удар молотком — 10 000?

S>Инженер прислал детализацию:

S>

    S>
  • Удар молотком — 1 доллар
    S>
  • Знание, куда ударить — 9 999 долларов
    S>



S>Вроде ИИ должно удешевлять процесс разработки, т.к. делает до состояния "80% готово". И далее — вроде мелкий баг остался... Но! Код плохо читаемый, ну то ладно. Более важно что код никто не знает, никто его не писал, нужно банально запомнить где что написано (а структурой ИИ себя не утруждает, ему и так ОК).


Первый опыт который я получил занимаясь программированием, это то что по от состояния "почти готово" до состояния "готово" очень часто расстояние не меньше чем между состояниями "ни чего не готово" до "почти готово".
Программа – это мысли спрессованные в код
Re: Проблема ИИ - проблема удара молотком...
От: L_G Россия  
Дата: 17.02.26 10:00
Оценка: 3 (1) +2
S>Код плохо читаемый, ну то ладно. Более важно что код никто не знает, никто его не писал, нужно банально запомнить где что написано (а структурой ИИ себя не утруждает, ему и так ОК).

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

Вспомним, как переходили с ассемблера на языки "высокого уровня" (ЯВУ):
1) все пишут программы на коде ассемблера (машинный код забыт)
2) появились ЯВУ — транслируют в код ассемблера (можно читать и править, исправленное становится основными исходниками)
3) основная часть исходников — на ЯВУ, в коде ассемблера — "ручные оптимизации" или аппаратно-зависимые части (как часть исходников)
4) все исходники — на ЯВУ, при отладке есть режим кода ассемблера (можно посмотреть, что сгенерилось и оптимизировать через ЯВУ-исходник)
5) все пишут программы на ЯВУ (код ассемблера забыт: компилятор ЯВУ оптимизирует лучше человека, кодирующего на ассемблере)

Аналогичный переход, вероятно, будет происходить и с ИИ-программированием (с заменой "ассемблера" на "ЯВУ", а "ЯВУ" — на промпты или новый язык ТЗ).
И сейчас в ИИ-переходе мы условно на стадии, соответствующей второй в этом списке — код генерирует ИИ, но исходниками по прежнему считается этот сгенерированный код на ЯВУ. Ждем перехода к стадии, соответствующей третьей — "исходники 4.0"

BTW, стадия 2 в списке (ЯВУ уже есть, но исходниками по прежнему выступает ассемблер) введена условно — если она и была, то проскочили её очень быстро и незаметно, а вот на 3 и 4 оставались долго. Переходы от 3 к 4 и от 4 к 5 — вообще "асимптотические" и до конца не завершаются.
Каша в голове — пища для ума (с)
Re: Проблема ИИ - проблема удара молотком...
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.02.26 10:40
Оценка: +1
Здравствуйте, Shmj, Вы писали:

S>Вроде ИИ должно удешевлять процесс разработки, т.к. делает до состояния "80% готово". И далее — вроде мелкий баг остался... Но! Код плохо читаемый, ну то ладно. Более важно что код никто не знает, никто его не писал, нужно банально запомнить где что написано (а структурой ИИ себя не утруждает, ему и так ОК).

С чего вы взяли, что это так?
S>И вот получается что мелочь — но ИИ пустил по кругу, т.е. когда уже весь круг ада прошел и попаболь — все-равно зараза ничего не решил — приходится сдаваться и думать как решить кожаному.
Пока что описанное вами больше всего похоже на луддизм. Типа — смотрите, какое говно получается, если мою работу отдать ИИ.
Говно получается потому, что вы делаете говно. ИИ — это инструмент. Очень эффективный инструмент, если применять его по назначению.
1. Почему ИИ у вас делает до состояния 80%, а не 100%?
2. Почему вы принимаете у него плохо читаемый код? Представьте себе, что вы пишете не код а, скажем, роман. Вы что, будете на ИИ пенять за то, что там нечитаемая графомания? Типа "ну я всего лишь написал ему двухстрочный промпт, а потом нажимал Да во всех диалогах"? Нет, роман — это ваш продукт. Вы можете использовать пруфридеры для проверки орфорграфии, автодополнение фраз для ускорения набора текста, можете карточки персонажей вести в Екселе. Можете майнд-мэпы использовать, чтобы не забыть, кто из персонажей с какими событиями связан. Можете карты с пометками рисовать, чтобы ничего не перепутать — это всё ваши инструменты. Они за вас не напишут текст. ИИ тут — точно такой же инструмент. Если вас не устраивает написанный им текст — идёте и правите. А не говорите "ну мне он вот так написал, а если издателю что-то не нравится — пусть редактор правит".

2.1. Ладно, вам лень читать этот код самостоятельно. Что вам мешает добавить фазу проверки или даже отдельного агента-критика? Спросить его "а не говнокод ли получился"?
3. Почему у вас ИИ "не утруждает себя структурой"? Точнее, почему вы не утруждаете его структурой? Что вам мешает перед тем, как нейрослопить код, попросить спроектировать структуру кода? Покритиковать её, пока она не превратилась в нечитаемые тыщи строк? Обсудили с ИИ варианты структуры, достоинства и недостатки разных решений — зафиксировали в документах, и только потом начали порождение кода.
3.1. Ладно, на первом этапе не подумали — но что вам мешает раз в иногда останавливаться и просить ИИ поревьювить код на предмет best practices и code smells?
4. Ок, всё равно код написан не вами, его много, сходу непонятно, где что отъехало. Что мешает тупо спросить ИИ что тут и где? Он же прекрасно анализирует чужой код — стало быть, разберется и в "вашем". Тем более, что код-то написан ИИ, понятными ИИ паттернами и шаблонными ходами. Даже если он видит код в первый раз, он вполне разбирается с тем, что, зачем, и где делается. Ну так и спросите его — а этот класс зачем нужен? А почему здесь так написано?
А уж если вы не пренебрегали предыдущими пунктами, то ИИ очень быстро обучит вас разбираться в этом коде. Быстрее, чем это сделал бы живой человек.
А, ну да, и ешё — в процессе сеанса вопросов "а что это за фигня" ИИ может запросто набрести на "а, ну да, эта штука вообще не нужна, это наверное артефакт от нейрослопа, и бага возникает как раз из-за неё".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Проблема ИИ - проблема удара молотком...
От: so5team https://stiffstream.com
Дата: 17.02.26 11:31
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>3. Почему у вас ИИ "не утруждает себя структурой"? Точнее, почему вы не утруждаете его структурой? Что вам мешает перед тем, как нейрослопить код, попросить спроектировать структуру кода? Покритиковать её, пока она не превратилась в нечитаемые тыщи строк? Обсудили с ИИ варианты структуры, достоинства и недостатки разных решений — зафиксировали в документах, и только потом начали порождение кода.


А кто и как гарантирует, что ИИ не пошлет все, что вы с ним зафиксировали, в пешее эротическое и не сгенерирует то, что ему захочется?

Ведь был случай, когда ИИ указывали, что удалять из БД ничего нельзя, но это не остановило ИИ от удаления данных в БД.

S>3.1. Ладно, на первом этапе не подумали — но что вам мешает раз в иногда останавливаться и просить ИИ поревьювить код на предмет best practices и code smells?


Чьи это будут best practices и кто будет определять, что smells, а что не очень?

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

Компиляторы из ЯВУ в машинный код специально тестируют, чтобы они мусор не производили. А некоторые компиляторы так еще и специально сертифицируют, чтобы иметь гарантии, что конкретные языковые конструкции трансформируется в то, что полагается.
Re: Проблема ИИ - проблема удара молотком...
От: Silver_S Ниоткуда  
Дата: 17.02.26 11:39
Оценка:
Здравствуйте, Shmj, Вы писали:

S>... Найти куда "ударить" — это значит как-то разобраться с кодом, привести в порядок. А это время и те же якобы необоснованные деньги, которые не ясно как бы как можно брать за 1 удар.


В програмиировании есть моножество разных видов работ, в том числе, работа в роли следователя — расследовать "странную необъяснимую хрень" по уликам/симптомам. ИИ пока освоил не все виды работ, поэтому массовых увольнений в IT пока нет.
Re[2]: Проблема ИИ - проблема удара молотком...
От: Doom100500 Израиль  
Дата: 17.02.26 12:11
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Shmj, Вы писали:


S>1. Почему, Почему, Почему, Почему...


Потому что ни в случае с романом, ни с картинками, ни с музыкой, и ни с кодом, он никогда не выдаёт то, что тебе нужно. А тебе надо выбирать из всего неподходящего наименее неподходящее, и потом мириться с этим, либо сразу переписать.
Спасибо за внимание
Re[3]: Проблема ИИ - проблема удара молотком...
От: Doom100500 Израиль  
Дата: 17.02.26 12:12
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Doom100500, Вы писали:


S>>>Байка становится действительностью:

D>>Недавно, по-моему, на хабре видел заметку, что стали появляться вакансии на разгребание ИИ слопа.

S>Беда вот в чем. Теперь простят много денег за один "удар". Ты возмущаешься, говоришь — да как можно, ты же только одну строчку исправил. А тебе в ответ приводят эту байку.


Это не беда, а новый хлеб с икрой.
Спасибо за внимание
Re[3]: Проблема ИИ - проблема удара молотком...
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.02.26 13:01
Оценка: 2 (1)
Здравствуйте, so5team, Вы писали:

S>А кто и как гарантирует, что ИИ не пошлет все, что вы с ним зафиксировали, в пешее эротическое и не сгенерирует то, что ему захочется?

Хозяин и гарантирует.
S>Ведь был случай, когда ИИ указывали, что удалять из БД ничего нельзя, но это не остановило ИИ от удаления данных в БД.
Был. Из этого мы извлекаем следующую идею: нельзя давать агенту доступ к необратимым действиям.
С исходниками он мог бы напороть то же самое, если бы поколения разработчиков не приучились держать код в системах контроля версий.
Так что либо мы вовсе не даём ему доступа к базе, либо делаем базу таким же воспроизводимым артефактом CI/CD, как и бинарный код приложения.
Кстати, это именно то, что я пытаюсь сделать в своём проекте.

S>Чьи это будут best practices и кто будет определять, что smells, а что не очень?

Если честно — сложно сказать. В том смысле, что если отпустить вожжи и просто попросить "посмотри на предмет best practices и code smells", то оно попытается угадать — на основе своего предыдущего обучения.
Можно не отпускать вожжи, а детально написать "ищи вот такие-то признаки говнокода". Но я не дам гарантии, что оно сделает именно то, что предписано — потому что задача исходно нечёткая.
Вот с полгода тому мы в основном играли с claude; так вот она гораздо эффективнее порождала код, чем сокращала его. Типа я глазами вижу пачки однообразного бойлерплейта (а у нас там был процессинг AST и кодогенерация), и возникает острое желание всё это порефакторить. Ну, вот ставлю ей задачу — она полчаса пыхтит, жрёт пачку токенов, и выхлоп — из 655 строчек кода удалось сделать 641. Хотя, казалось бы, интеллект тут вовсе не нужен — чистый common subexpression elimination, применяй пока в коде не останется автокорреляций.

Но
1. Это была claude, которую мы в итоге уволили за некомпетентность
2. У нас не было опыта и практики систематической AI-assisted разработки, так что это больше было похоже на чат с улучшенным контекстом, чем на нормальный процесс
3. Это было полгода тому, а скорости развития передовиков производства таковы, что модели полугодовой давности сегодняшим моделям даже кофе приносить не годятся.

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

Тут есть три варианта:
1. Повторять итерации до полного удовлетворения (с вариацией: попробовать разобраться, почему промпт не сработал, и постараться улучшить свои навыки промптинга)
2. Сказать "ИИ тупой, дальше я сам" и доработать код руками
3. Сказать "и так сойдёт". ТС почему-то видит только этот вариант.

S>Компиляторы из ЯВУ в машинный код специально тестируют, чтобы они мусор не производили. А некоторые компиляторы так еще и специально сертифицируют, чтобы иметь гарантии, что конкретные языковые конструкции трансформируется в то, что полагается.

Да, это подход известный. Жалко, что малораспространённый. В ответственных местах мы, конечно, хотим иметь доказанную корректность кода. В менее ответственных мы полагаемся на результат тестирования.
Ну, и опять же, есть вариант пойти по пути ТС (или вот, по соседству на ту же тему Павел Дворкин выступал) — "и так сойдёт".
У меня пока опыта end-to-end применения ИИ к ответственным проектам нет. Схема как бы известна, и частично опробованная.
Например, корректность алгоритма мы доказываем при помощи TLAPS, причём исходник доказательства готовит ИИ. Если разработчик не в состоянии прочитать даже исходные посылки и проверяемые инварианты — то тут как бы совсем всё плохо, никакой ИИ не спасёт. А если в состоянии — то можно не вдаваться в подробности этих сотен лемм, которые ввёл ИИ для доказательства основного тезиса. Прувер доказал — всё, у нас есть "сертифицированный" алгоритм.
Следующий этап — проверка соответствия кода алгоритму. Тут немного хуже. Сам Лэмпорт честно об этом пишет у себя на странице. В идеале мы, опять же, формулируем требования, к примеру, к каждому из процессов, составляющих распределённую стейт-машину, в виде пред- и пост-условий, которые выведены из тех же предпосылок, что и теорема в модел чекере. И пропускаем это через алгоритмы Флойда/Хоара, чтобы получить формальную верификацию.
Интуитивно я ожидаю, что ИИ сможет нанейрослопить всё это, плюс варианты/инварианты для всех циклов, ничуть не хуже, чем он нейрослопит код TLA+. А после прогона кода через верификатор у нас будет (в идеале) строгое доказательство того, что реальный код соответствует спецификации алгоритма.
И тогда у нас по индукции есть сертификат того, что наша распределённая система удовлетворяет сформулированным на входе требованиям.

Подытоживая: способ, в общем-то, не сильно зависит от того, руками ли писался код или человеком. Верификация и сертификация кода — это не вопрос peer review, а вопрос применения формальных процессов.
Роль ИИ тут сводится ровно к той же роли, что и у IDE с автокомплитом — ускорять написание кода, который мы пропускаем через конвеер тестирования и верификации.

На всякий случай ещё раз оговорюсь: кусочки вышеописанной схемы мы опробовали, фатальных проблем не нашли. Но полного end-to-end решения я пока не видел, не получал, и похвастаться нечем.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Проблема ИИ - проблема удара молотком...
От: so5team https://stiffstream.com
Дата: 17.02.26 13:31
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>>А кто и как гарантирует, что ИИ не пошлет все, что вы с ним зафиксировали, в пешее эротическое и не сгенерирует то, что ему захочется?

S>Хозяин и гарантирует.

Т.е. Antropic или OpenAI?

S>>Ведь был случай, когда ИИ указывали, что удалять из БД ничего нельзя, но это не остановило ИИ от удаления данных в БД.

S>Был. Из этого мы извлекаем следующую идею: нельзя давать агенту доступ к необратимым действиям.

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

S>>Чьи это будут best practices и кто будет определять, что smells, а что не очень?

S>Если честно — сложно сказать.

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

S>3. Сказать "и так сойдёт". ТС почему-то видит только этот вариант.


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

S>Роль ИИ тут сводится ровно к той же роли, что и у IDE с автокомплитом — ускорять написание кода, который мы пропускаем через конвеер тестирования и верификации.


По моему субъективному мнению, появление очень уж умных IDE с автокомплитом и автоматическими рефакторингами очень сильно снизило и качество кода и средний уровень программистов. Если ИИ произведет подобный эффект, то итог можно будет ожидать еще хуже.
Re[5]: Проблема ИИ - проблема удара молотком...
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.02.26 14:05
Оценка:
Здравствуйте, so5team, Вы писали:
S>Т.е. Antropic или OpenAI?
Нет, тот, кто его эксплуатирует.

S>Речь не об этом. Речь о том, что у ИИ могут быть проявления своеволия, скажем так. Когда он игнорирует пожелания пользователя.

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

S>Т.е. по факту пока что получается как будто общение с магическим кристаллом: ты ему одно, он тебе что-то в ответ. А ответ может либо понравится, либо остается пожать плечами и понадеятся, что дальше будет лучше.

Примерно так, да.

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

Из этого мы делаем вывод: если важно качество кода (в том числе и развиваемость, и отлаживаемость), то не стоит просить ИИ писать код, который нет возможности прочитать.
Впрочем, я уверен, что вы себя недооцениваете: JS не так уж далёк от привычных вам C и С++. Те же скобки вокруг аргументов функций, те же циклы, те же ветвления.

Да, идиоматика там другая — но обычно она мешает именно писать код. Я вот учусь писать на TS примерно года три, и всё ещё регулярно натыкаюсь на то, что написанный мной код можно переписать ещё идиоматичнее.
А вот читать — да без проблем. Ну встретите вы какую-то непонятную конструкцию — даже без помощи ИИ у вас минут пять уйдёт на то, чтобы нагуглить её смысл.
Методы структурирования кода там ровно те же самые. В общем, ревьювить JS-ный код вы будете готовы гораздо раньше, чем научитесь продуктивно на нём писать.

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

S>По моему субъективному мнению, появление очень уж умных IDE с автокомплитом и автоматическими рефакторингами очень сильно снизило и качество кода и средний уровень программистов. Если ИИ произведет подобный эффект, то итог можно будет ожидать еще хуже.

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

Так и тут — тыщи людей, которых раньше сдерживал от входа в профессию неумолимый Syntax error, теперь делают по пять тыщ коммитов в месяц. Правда, судя по моему фейсбуку, их основные продукты почему-то все про ИИ.
То есть всё, что им приходит в голову — это использовать ИИ для написания кода по продаже ИИ.
Ничего полезного их решения не делают .
Я так понимаю, ровно из-за того же эффекта: те, кто применяют ИИ по делу — молчат. Им некогда разговаривать с праздношатающимися и незачем помогать конкурентам.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Проблема ИИ - проблема удара молотком...
От: so5team https://stiffstream.com
Дата: 17.02.26 15:17
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>>Т.е. Antropic или OpenAI?

S>Нет, тот, кто его эксплуатирует.

Ага, понятно.

Тут, правда, есть вопрос насколько тот, кто эксплуатирует, владеет своим инструментом. Ведь, по сути, сейчас все это работает в режиме аренды.

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


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

У ИИ-ассистентов, как я понимаю, память гораздо более короткая.

S>Впрочем, я уверен, что вы себя недооцениваете: JS не так уж далёк от привычных вам C и С++. Те же скобки вокруг аргументов функций, те же циклы, те же ветвления.


Дело не в синтаксисе. Дело в идиомах и потенциально проблемных приемах/шаблонах. Типа того, что я сходу вижу потенциальные проблемы с надежностью или производительностью C++ного кода. Но вот такого же уровня распознавания потенциальных проблем для других языков нет. Они должны приобретаться с опытом.

S>>По моему субъективному мнению, появление очень уж умных IDE с автокомплитом и автоматическими рефакторингами очень сильно снизило и качество кода и средний уровень программистов. Если ИИ произведет подобный эффект, то итог можно будет ожидать еще хуже.

S>А, тут я с вами склонен согласиться. Любое снижение барьеров влияет именно так: работа профессионалов ускоряется и становится эффективнее, но те, кто раньше вообще не мог попасть в индустрию, начинают разбавлять статистику.
S>Вот, вы в параллельном топике ностальгически вспоминали библиотеки контролов. Ну и к чему это привело? К поколению дельфи-программистов, над которыми только ленивый не смеялся. Их вообще за программистов-то не считали, пока не появилась 1С как поставщик ещё более удобной цели для насмешек.

Это одна сторона медали. Достаточно субъективная. Для нас, например, во время учебы в ВУЗе чем-то вроде касты отверженных были dBase/FoxBase/Clipper программисты. Которые затем во множестве переквалифицировались в 1С или Delphi-разработчиков. Только вот практика показала, что когда во второй половине 1990-х есть стало совсем нечего, именно эти самые dBase- и 1C-ники без работы-то и не сидели. Потом было много насмешек над PHP-шниками. Теперь вот в некоторых кругах и над Go-ферами посмеиваются.

Я больше про другую сторону. Когда у человека такой мощный подсказчик, как продвинутая IDE, то человек хуже знает код и хуже понимает что и как работает. Вот это, на мой субьективный взгляд, самое страшное. А не то, что Delphi или Ruby-on-Rails сделали разработку какого-то класса ПО совсем тривиальной.
Re[7]: Проблема ИИ - проблема удара молотком...
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.02.26 15:39
Оценка:
Здравствуйте, so5team, Вы писали:

S>Тут, правда, есть вопрос насколько тот, кто эксплуатирует, владеет своим инструментом. Ведь, по сути, сейчас все это работает в режиме аренды.

Точно также, как подписка на Office 365, или мейлбокс на gmail, или аккаунт на гитхабе
И точно так же, если OpenAI оборзеет, можно перейти к антропику. А если оборзеют оба — то в дипсик. Или в гигачат, или в алису.
Ну, или по старинке — вычерпывать код вручную. В любом случае без работы мы не останемся.

S>С точки зрения менеджмента уже давно понятен механизм "прокачки" неопытных сотрудников с опцией их замены в случае необучаемости.

+1.
S>Ну и плюс любого живого человека, что пока он на проекте, у него всегда можно попросить объяснить мотивацию.
У неживого тоже.
S>Практика показывает, что если дать человеку достаточно времени, то он может вспомнить подробности своих решений годовой и более давности. Особенно если привить ему привычку документировать код.
А если привить практику документировать не только код, но и решения, то это помогает ещё лучше. Потому что я вот не так давно своими глазами наблюдал и своими устами участвовал в обсуждениях вида "да мы ещё два года назад договорились до X и Y — нет, мы договорились до X ИЛИ Y и я выбрал Y — вы оба неправы, мы договорились вообще до Z, а X из него получился из-за невнимательности".

S>У ИИ-ассистентов, как я понимаю, память гораздо более короткая.

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

S>Дело не в синтаксисе. Дело в идиомах и потенциально проблемных приемах/шаблонах. Типа того, что я сходу вижу потенциальные проблемы с надежностью или производительностью C++ного кода. Но вот такого же уровня распознавания потенциальных проблем для других языков нет. Они должны приобретаться с опытом.

Ну, тут вы правы. Сходу увидеть какую-нибудь нехорошую асимптотику или там рейс (или, наоборот, его отсутствие) — это требует именно опыта, причём опыта специфического.
Если к разрабатываемому коду есть требования по надёжности и производительности, которые вы не можете закрыть тестами и бенчмарками — то лучше выбирать более знакомые вам языки и платформы.
Впрочем, тут вас никто не ограничивает. Задача же не в том, чтобы заставить вас писать на чужеродном для вас языке. А в том, чтобы вы смогли писать код на языке вашего выбора, только в 10 раз быстрее, чем вручную.

S>Я больше про другую сторону. Когда у человека такой мощный подсказчик, как продвинутая IDE, то человек хуже знает код и хуже понимает что и как работает. Вот это, на мой субьективный взгляд, самое страшное. А не то, что Delphi или Ruby-on-Rails сделали разработку какого-то класса ПО совсем тривиальной.

А, вы боитесь размякнуть? Мне кажется, что это всё же больше зависит от человека, а не инструмента. Вам же, наверное, MFC не помешали разобраться, как там под капотом устроены очереди сообщений и функции WinAPI.

Вот когда я в магистратуре учился, задания по курсу на clojure писал из принципа только в нотепаде. Безо всяких там IDE и интерактивной отладки.
Но это же ради искусства; типа — clojure создали для тех, кому java причиняла недостаточные страдания. Ну так значит надо не избегать боли, а погрузиться в неё.
Пытливому уму никогда не будет достаточно готовой кнопки "сделай". Скорее наоборот — инструменты продуктивности позволяют поставить больше экспериментов, и сделать всё как следует — на что никогда не хватало времени.

Правда, есть риск, что это окошко быстро закроется. Это ещё бизнес не освоился с тем, что MVP теперь можно делать не полусотней человек два года, а одним и за месяц.
Как освоится — сразу начнётся "хватит глюкало полировать, лей в продакшн. Ты на этой неделе ещё четыре продукта релизишь".

Тут у меня одна надежда — попробовать довести bandwidth до такой, чтобы можно было пилить продукты самостоятельно. Не оглядываясь на весь этот корпоративный цирк.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Проблема ИИ - проблема удара молотком...
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.02.26 15:45
Оценка:
Здравствуйте, so5team, Вы писали:


S>Я больше про другую сторону. Когда у человека такой мощный подсказчик, как продвинутая IDE, то человек хуже знает код и хуже понимает что и как работает. Вот это, на мой субьективный взгляд, самое страшное. А не то, что Delphi или Ruby-on-Rails сделали разработку какого-то класса ПО совсем тривиальной.

З.Ы. ИИ просто усиливает в человеке всё. Вот все ваши сильные стороны он и усилит. Возможно — вместе с недостатками.
Примеры усиления в, гм, неожиданных аспектах, можно посмотреть по соседству
Автор: xma
Дата: 13.02 21:55
. Это не единственный пример, просто самый яркий.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Проблема ИИ - проблема удара молотком...
От: so5team https://stiffstream.com
Дата: 17.02.26 16:01
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>>Тут, правда, есть вопрос насколько тот, кто эксплуатирует, владеет своим инструментом. Ведь, по сути, сейчас все это работает в режиме аренды.

S>Точно также, как подписка на Office 365, или мейлбокс на gmail, или аккаунт на гитхабе

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

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

S>Впрочем, тут вас никто не ограничивает. Задача же не в том, чтобы заставить вас писать на чужеродном для вас языке. А в том, чтобы вы смогли писать код на языке вашего выбора, только в 10 раз быстрее, чем вручную.


Как раз очень много положительных отзывов по поводу ИИ-ассистентов в духе того, что можно сходу сделать что-то на технологиях, к которым не имеешь отношения. Типа того, что С-шник железячник может слепить Web-морду к своей железяке посредством ИИ-ассистента.

S>>Я больше про другую сторону. Когда у человека такой мощный подсказчик, как продвинутая IDE, то человек хуже знает код и хуже понимает что и как работает. Вот это, на мой субьективный взгляд, самое страшное. А не то, что Delphi или Ruby-on-Rails сделали разработку какого-то класса ПО совсем тривиальной.

S>А, вы боитесь размякнуть?

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

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

Да, я понимаю, что IDE всего лишь инструмент и тут все зависит от того, в чьих он руках. Но я как раз про ситуацию "по больнице в среднем" говорю.

S>Вам же, наверное, MFC не помешали разобраться, как там под капотом устроены очереди сообщений и функции WinAPI.


У меня была другая траектория. Я начинал программировать под Windows на чистом WinAPI, а уже потом, спустя много лет в одном из проектов использовал MFC. И смог это сделать как раз потому, что понимал на что эти абстракции ложаться. Потому что тогдашние книги по MFC были откровенным мусором и написаны в стиле "нажмите вот на эту копку в Visual Studio, затем на эту, потом на эту и у вас будет сгенерирована вот такая заглушка". При этом ни слова о том, как же MFC работает. Местами приходилось в исходники MFC погружаться, чтобы разобраться как и что работает.

S>Правда, есть риск, что это окошко быстро закроется. Это ещё бизнес не освоился с тем, что MVP теперь можно делать не полусотней человек два года, а одним и за месяц.

S>Как освоится — сразу начнётся "хватит глюкало полировать, лей в продакшн. Ты на этой неделе ещё четыре продукта релизишь".
S>Тут у меня одна надежда — попробовать довести bandwidth до такой, чтобы можно было пилить продукты самостоятельно. Не оглядываясь на весь этот корпоративный цирк.

Для меня самый интересный вопрос в том, сколько в итоге это будет стоить. Т.к. сейчас все эти ИИ-конторы, насколько понимаю, сжигают деньги инвесторов со страшной силой и еще очень далеки о точки безубыточности.
Re[9]: Проблема ИИ - проблема удара молотком...
От: Vzhyk2  
Дата: 17.02.26 17:13
Оценка:
Здравствуйте, so5team, Вы писали:

S>Вот если бы этот самый ИИ можно было приобретать и ставить у себя, да еще и избавившись от риска утечки твоих исходников куда-то. Может со временем к такому варианту монетизации тоже придут.

Не придут. Будет или бабах пузыря или медленное сдувание и забывание о нем.

S>Как раз очень много положительных отзывов по поводу ИИ-ассистентов в духе того, что можно сходу сделать что-то на технологиях, к которым не имеешь отношения. Типа того, что С-шник железячник может слепить Web-морду к своей железяке посредством ИИ-ассистента.

Это он кстати может, проверено, но именно в "железячном стиле" — кривенькую и очень-очень простую.

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

Толпа лохов обанкротится, кто-то бабла на лохах поднимет. Всё, как обычно.
Re[2]: Проблема ИИ - проблема удара молотком...
От: Shmj Ниоткуда  
Дата: 17.02.26 17:33
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>1. Почему ИИ у вас делает до состояния 80%, а не 100%?


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

Для меня очевидно — т.к. 80% видимого результата — это именно то что нужно для хайпа. А довести до ума — требует в 4 раза больше усилий, но при этом такие усилия LLM уже не может применить — не дотягивает. По этому проекты просто закрывают и после хайпа — ни одного коммита нет, они не переходят на уровень, когда тот же браузер можно реально скачать и юзать.
Re[9]: Проблема ИИ - проблема удара молотком...
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.02.26 17:36
Оценка:
Здравствуйте, so5team, Вы писали:

S>С такими же рисками отключения по щелчку. Или потому, что владельцу сервиса какое-то направление больше не выгодно (впоминается Атлассиан с БитБакетом и Mercurial-репозиториями).

Именно, вы всё верно понимаете.
S>Вот если бы этот самый ИИ можно было приобретать и ставить у себя, да еще и избавившись от риска утечки твоих исходников куда-то. Может со временем к такому варианту монетизации тоже придут.
Ну вот прямо "этот самый" — нет. Но анархисты активно копают направление локального запуска всяких опенсорсных моделек. Впрочем, примерно тем же занимаются и Яндекс со Сбером

S>Как раз очень много положительных отзывов по поводу ИИ-ассистентов в духе того, что можно сходу сделать что-то на технологиях, к которым не имеешь отношения. Типа того, что С-шник железячник может слепить Web-морду к своей железяке посредством ИИ-ассистента.

Это ещё у О'Генри было: "слепые начинают говорить, а немые — бегать".

S>Нет, мне просто надоело копаться в посредственном коде, который был бы сильно лучше, если бы человек больше думал. А IDE для многих как раз позволяет думать меньше.

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

S>У меня была другая траектория. Я начинал программировать под Windows на чистом WinAPI, а уже потом, спустя много лет в одном из проектов использовал MFC. И смог это сделать как раз потому, что понимал на что эти абстракции ложаться. Потому что тогдашние книги по MFC были откровенным мусором и написаны в стиле "нажмите вот на эту копку в Visual Studio, затем на эту, потом на эту и у вас будет сгенерирована вот такая заглушка". При этом ни слова о том, как же MFC работает. Местами приходилось в исходники MFC погружаться, чтобы разобраться как и что работает.

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

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

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

Вот, скажем, гитхаб: что остановило Микрософт от закрытия бесплатной программы и назначения произвольных цен на коммерческие подписки? А ведь они тоже "жгли деньги инвесторов".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.