Pull to refresh

Comments 96

PinnedPinned comments

"Увольняем джуниора" - статья начала 2025. Современные LLM достигли такого уровня, что уже можно писать статью "Увольняем Analytics Lead в Ton Foundation" :)

  1. По факту не плюс x10 к продуктивности аналитика, а минус x2 к продуктивности. Потому что аналитику нужно будет всё проверить за ai и разобраться - а это всегда сложнее делать, чем с 0 копать тему.

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

  3. Аналитик данных ≠ знание sql(sql один из инструментов извлечения информации)

Звучите как человек, который так и не попробовал Claude Code или Codex этой зимой. Ваши тезисы верны при малом опыте работы с агентами.

Что изменилось? Какие кейсы у вас делает ИИ?

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

Вот конкретный пример из недавнего, использующий скилл, описанный в статье выше:

"""
В TON Believers Fund начались разлоки в ноябре 2025. Проанализируй, кто и куда выводит TON: стейкинг, в стакан, вывод на CEX или другое. Результат в html с графом. Перепроверь данные через tonapi.
"""

Это отнюдь не продуктовая разработка. Если у вас codex за дизайнера-фронтовика - соболезную. Ну либо восхищаюсь, у меня не получилось любыми скиллами и скриншотами заставить его сделать то что прошу с первого, а иногда и с десятого, раза. Ради теста пробовал, разумеется, причем в течение месяца так пробовал делать. В процессе тот же месяц потратил на изучение angular + material и за две недели склепал то что нужно. Для чистоты эксперимента попробовал заново с нуля собрать то что нужно но уже с более точными указаниями, терминами и пониманием, которое я получил за время обучения. О чудо, пришлось переделывать не 10 раз, а всего 2-3. Иногда даже с первого раза начало получаться. Итого вывод - без подходящих навыков у человека и корректной постановки задачи, LLM будет пытаться угадать его намерения. Общими формулировками вы не построить production-ready продукт, яркий пример - molt-кто то там, который был а-ля reddit для ИИ. Там в открытом доступе лежали все ключи, можно было зайти под любой учеткой, писать что угодно, делать ферму по разгонке лайков итд итп.

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

По факту не плюс x10 к продуктивности аналитика, а минус x2 к продуктивности.

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

Приходит девушка устраиваться на работу секретаршей
- А с какой скоростью вы можете печатать на машинке?
- Ну... 1000-1200 знаков в минуту..
- Разве можно с такой скоростью печатать?
- Печатать-то можно, но такая херня получается

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

В итоге дороже. Потому что если джуна у вас нет, из него не вырастет мидл

Не каждому Папе Карло нужен Папа Карло Младший) достаточно токарный станок поумнее

про это концовка фильма https://www.kinopoisk.ru/film/484791/

Купили как-то суровым сибирским лесорубам японскую бензопилу.

Собрались в кружок лесорубы, решили ее испытать.Завели ее, подсунули ей деревце.

«Вжик» — сказала японская пила.

«У, б...» — сказали лесорубы.

Подсунули ей деревце потолще.

«Вж-ж-жик!» — сказала пила.

«Ух, б...!» — сказали лесорубы.

Подсунули ей толстенный кедр.

«ВЖ-Ж-Ж-Ж-Ж-Ж-Ж-ЖИК!!!» — сказала пила.

«Ух ты, б..!!» — сказали лесорубы.

Подсунули ей железный лом.

«КРЯК!» — сказала пила.

«Ага, б...!!!» — укоризненно сказали суровые сибирские лесорубы!

И ушли рубить лес топорами…

именно! Мораль яснее ясного :)

Все верно, яснее ясного. Какой ты станок Папе Карло не давай, он все равно останется Папой Карло и не сможет избежать поломки станка.

Вы же об этом? Об этом же, да?

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

Именно! Поэтому я считаю критически важным инвестировать в себя и в свою практику работы с совеременным AI, пока он такой дешевый.

ИИ никогда не попросит платить ему больше 

да ну? а как же подписки, которые ВНЕЗАПНО подросли с 20 до 200 баксов?
А как же введение лимитов? С чего этот тезис вообще был взят?

В данном контексте у ИИ все те же самые сложности, что и у любого облачного сервиса - если захотят - поднимут подписку/отключат/введут лимиты.
Со вторым тезисом - согласен.

Ну это уже владельцы ии будут диктовать цены, а сильно задирать они их не будут, чтоб не пришлось людей нанимать, вместо их продукта

а сильно задирать они их не будут,

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

Я думаю, что цены на AI сильно вырастут за год. Сейчас венчурные деньги инвеструются в рост, как, например, было с Uber. Но за это время вся индустрия вырастет, в том числе self-host и open-source. Так что, как обычно, все в плюсе. А текущими маленькими ценами имеет смысл пользоваться для собственного образования

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

вроде у веритасиума не так давно видел что-то про монсанто))

Тогда выгоднее будет в чём то отказаться от ии и нанять человека, что всё равно звучит сомнительно, ибо человек всегда будет дороже и менее выгоден, чем ии

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

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

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

"научиться с ними работать" это вы так называете метод перебора под конкретную задачу?

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

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

просто джунов нужно будет меньше при прочих равных

Джуниор аналитик когда бизнес-контекст недопонял подойдет и спросит. А ИИ так быстро додумает и никому не скажет, что офигеешь при приёмке.

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

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

А какой смысл задавать ему вопрос, ответ на который известен?

На прошлой неделе подключил к opencode с бесплатными Kimi K2.5 и MiniMax M2.5 MCP сервер для доступа к джире и конфлюенсу. Завел read-only учётку, выдал токен, доступ только на нужный проект.

Сказал ему — вот номер задачи, делай. Он сходил в задачу, нашел ссылку на ТЗ. Сходил туда. Написал код, тесты по аналогии написал. И пришел с вопросом о маппинге полей. Сложный, точно к аналитику. Я переслал аналитику. Он сперва сказал "всё ок". Потом я сам уже сел на 3й раз перечитывать вопрос от ИИ и понял, что его смутило. Подсветить аналитику. Тот сказал "Опа!" – и переделал, плюс ещё пару смущающих мест.

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

Получилась личная, показательная история.

Спасибо, что поделились этой историей.
Мне лично еще нравится интерактивные режимы, условно промтп "давай обсудим задачу вместе". Часто Агент сам задаст тебе важные вопросы, которые ты забыл дораскрыть в задача, а также может подсветить сторону проблемы, о который ты даже и не думал.

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

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

статья про замену джунов? Тогда зачем Вы смещаете контекст в комментарии?

Руки мастера у джуна?

писать код без дырок

Ну да, ну да... Делай хорошо, плохо не делай. "Не совершай ошибок, пиши безопасный код" как говорится.

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

А если человек участвует он всегда становится узким горлышком.

Никакие линтеры и TDD не спасут от того что ллм просто нагаллюцинирует себе "безопасный ранний return в best-effort функции", обходя проверку тестов. Причем на ревью то она найдет собственный баг, вот только сколько не найдет? А если в коде не 100 файлов, а 1000, 10000? И при плохой архитектуре (а ИИ не умеет в архитектуру сложных приложений ещё) добавление фичи перерастает в глобальный рефакторинг.

UPD: отличный пример вспомнил. Все кипятком нужду справляли когда вышел Sonnet 3.5. Сейчас его даже рядом с опенсорсом нет в лидербордах. Новые модели которые выходят смотрят на код старых моделей и начинают бубнить типо "кто это писал" (не прямым текстом, но там забавные перлы выдают). И новое поколение будет так же про старое. Но при этом даже сейчас добиться грамотной архитектуры которая не только здесь и сейчас будет корректна практически нереально. Спустя пару фичей модель уже пишет следующую пачку функций в файл в котором уже 6000 строк. Хотя изначально все было "ну вроде хорошо".

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

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

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

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

Не говорите пожалуйста что LLM разумны и могут кого то там заменить или писать код без багов. Даже с режимом "размышлений" они не могут писать код без багов, вы просто эти баги не замечаете. Ради эксперимента прямо сейчас код составленный лучшей моделью в котором как вам кажется нет багов, возьмите и заснапшотте. Прям весь проект целиком, хотя бы тыщ 30 строк кода. В котором все работает и кажется идеальным. Вот его возьмите и спустя год проверьте новой SOTA моделью. Получите пачку critical/high (p0/p1) замечаний и скажете "точно, это же очевидно", а модель не заметила. А вы бы, обладай вы навыками, могли бы заметить ещё год назад.

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

Вы не пишете код — вы проверяете и направляете того, кто пишет его лучше, быстрее и точнее вас.

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

А тут мы имеем:

-Как ты это сделал?

-Э... Оно само.

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

закажет ещё сделать ручной отчет

В 2021-2023 мы только и делали что занимались перепроверкой. Это нас так бесило, что мы начали называть это "отчеты для отчетов по отчетам"

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

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

Попробуйте свежие модели, появившиеся этой зимой. При достаточно полном описании данных и таблиц, SQL пишется на ура.

Много столбцов или связей != Сложная реализация. Одноуровневые и двух уровневые group by и все виды join-ов это простейшая реализация. Муторная из за количества связей или столбцов, но логика все ещё простейшая

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

SELECT a.id, b.id, c.id, d.id
FROM t1 AS a
JOIN t2 AS b ON b.id_a = a.id_b
JOIN t3 AS c ON c.id_a = a.id_c
JOIN t4 AS d ON d.id_b = b.id_d AND d.id_c = c.id_d
WHERE a.l1 = ? AND a.l2 = ? AND b.l1 = ? AND b.l2 = ?
  AND c.l1 = ? AND c.l2 = ? AND d.l1 = ? AND d.l2 = ?

При достаточно высокой кардинальности полей l1, l2 и id_* оптимизатор на таких запросах часто ломается. Ключевой вопрос - с какой таблицы нужно заставить оптимизатор начинать выборку и в каком порядке соединять таблицы дальше.

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

Это всё ради рекламы тгшки, можно даже не сотрясать воздух. Пусть автор обмазывается своими агентами, если у него такой фетиш.

Эх ребята! Рубите сук на котором сидите, да еще с песней! Вау, клод все пишет, как классно джуны не нужны. Сам и напишет, сам и протестит и баги найдёт и устранит. О дивный новый мир, всех джунов на выход. А из кого будут расти миддлы и сеньоры, когда всех джунов выпрут??

Сейчас присядете на быстрое программирование за копейки, а потом оно будет стоить не копейки. Оно и сейчас уже не копейки. А будет еще дороже.

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

Сначала все инфоцыганскими курсами ушатали, нагнали в профессию бариста и таксистов, а теперь предлагаете им не грустить и кодить с сетками.

Аплодисменты!

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

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

И когда этот произойдёт? Лет через 30?

Вы сейчас с каких позиций беспокоитесь, с позиций бизнеса? Так выращивайте себе кадры кто же вам мешает)

Ох уж этот Джун. И всё то его хотят уволить...

Раньше миддлы и сеньоры ревьюили код джунов. А сейчас будут ревьюить ревью джунов на код нейронки.

Одни пишут статьи про то, что джуниору для приёма на работу нужны знания программирования и т.д., без использования AI, а другие пишут статьи про замену джуниора на нейросеть. 🤕

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

AI-агент может быть умнее

Это как? К ai уже можно применить эпитет "умный"?

Да! Примерно с зимы этого года

Ошибаетесь, к уму это не имеет никакого отношения

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

Эффекты на выгорание от новой технологии нам еще предстоит измерить :) "Нормальному" AI, с которым можно действительно продуктивно работать, где-то всего полгода.

Я не буду оспаривать, что LLM способна написать запрос на SQL. Но когда мне приходится писать постановки, нередко мне в разы быстрее и проще написать SQL запрос, чем описывать тоже самое словами. Причем словами часто получается императивный алгоритм, который имеет весьма косвенное отношение к декларативному SQL. Поэтому для меня загадочно, чем же тут мне может помочь LLM?

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

я бы сохранил пару "задание + правильный SQL"

С чего Вы вообще решили, что оправдано каждый раз тратить дополнительно час своего времени на текстовое описание запроса, написанного за пять-десять минут? А если подобный запрос в git уже где-то есть, то я оттуда его и возьму за основу.

В следущий раз он в вашем стиле напишет

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

Мне кажется, вы преувеличиваете: я никогда не тратил "час времени" на текстовое описание запроса. Возможно, мы говорим немного о разном. Я имел виду верхнеуровневую бизнес постановку задачи + SQL как результат. Собрали несколько таких примеров -- и AI сможет сам писать SQL не хуже.

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

> без глубокого знания проблемной части всё равно не получится

возможно вы правы. Однако не стоит недооценивать интеллект и кругозор последних моделей :)

я никогда не тратил "час времени" на текстовое описание запроса

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

верхнеуровневую бизнес постановку задачи + SQL как результат

Если ограничиться общедоступной информацией и максимально упростить задачу, попробуйте написать SQL запрос, вычисляющей тариф на заданную дату на перевозку только собственных порожних полувагонов (ЕТСНГ 42103) и только в пределах РФ. Зависимость тарифа от предыдущего груза можете не учитывать. Все необходимые для этого нормативные документы найдёте тут. А вот архив тарифного руководства N4 проще загрузить отсюда.

Я понимаю, что это бизнес-задача низкого уровня, но сразу перейти к формированию ПСДЦ потребовало бы слишком объёмного описания бизнес-задачи.

не стоит недооценивать интеллект и кругозор последних моделей

Кругозор тут значения не имеет, а интеллекта у моделей нет и быть не может. В английском языке словосочетание "artificial intelligence" не имеет антропоморфной окраски, которую оно приобрело в традиционном русском переводе: слово intelligence в используемом контексте скорее означает «умение рассуждать разумно», а вовсе не «интеллект» (для которого есть английский аналог intellect).

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

Насчет вашего запроса: я вам искренне советую взять последнюю доступную версию ChatGPT Codex или Claude Code (а не опенсорс модели или агенты, которых зачастую нужно чуть больше тюнить для вау эффекта), просто скопировать свой запрос туда и посмотреть на результат. Жизнь многих знакомых программистов с большим стажем разделилась на до и после.

Сначала Вы мне докажите, что Ваш подход тут сработает. Обсуждается Ваша статья, а не моя.

спасибо, что оставляете свои комментарии, привлекая к статье еще больше читателей и комментаторов.

Все, что я хотел показать, я показал в статье.

Не вижу смысла объяснять конюху, что ездить будут все на машинах: если 3 (!) сообщений не хватило, штош, боюсь и полное доказательство не сработает -- а мне это особо и не нужно, ikyk or ngmi.

Так вы в этих трех сообщениях никакой доказательной базы не подвезли. Машина намного превосходит лошадь. LLM даже не может сравниться с человеком.

Вот да. Если мне надо потратить 20 минут на описание задачи для ИИ или 20 минут на написание кода - зачем мне пользоваться «ии»? Для рутинных задач вроде создания 20 шаблонных страниц верстки для веб-приложения (что решается промптом из 5-8 слов), чтоб они были в одном стиле (ибо я и дизайн живем на противоположных берегах) - это ладно. А убирать погружение в задачу непонятно ради чего - сомнительная затея.

Логика тут в том, что объяснив один раз, Агент будет всегда в контексте.

А если это одноразовая задача, то конечно же ее не нужно автоматизировать :)

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

А теперь, вопрос на бис, пожалуйста.

Вот всё то прекрасное, что вы описали в статье - на локальных мощностях офисных серверов.

Справитесь?))) с конкретными ттх серверов, пожалуйста, их стоимостью и счетами за электричество в месяц.

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

... когда, ИИ-провайдеры поймут признают, что у них нет внятной модели монетизации, а ваши 200+ буказоидов за доступ к "американскому гпт" ни разу не позволят им выйти в ноль, и они взвинтят цены раз в 10, вставят вам "непроматываемую рекламу" (кстати, чатгпт такое уже начал делать), начнут постить вам в комменты бд рекламные баннеры в ascii-арте....

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

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

что вы будете делать ?

с вашими прекрасными процессами и джуном-недо-менеджером страдающим даннингом-крюгером?...

что с этим всем делать, см выше, если ии-шка на которую у тебя "всё завязано" - развернута не у тебя в офисе?

вы получили минуту славы, а потом катись оно всё медным тазом?))

спасибо большое за комментарий))

если честно, на каждый ваш пункт есть конструктивный ответ и понятное решение.

Закиньте ваши тезисы в ChatGPT, в отечественные или self-hosted open-weight аналоги и спросите сами) но боюсь, вам ответы не нужны, а ваши вопросы были скорее риторическими.

на каждый ваш пункт есть конструктивный ответ и понятное решение.

Отлично! ну значит и покажите, пожалуйста, эти решения.

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

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

Мы ходили, потратили денег на железо, и (пока) не нашли пригодного рабочего варианта. Может быть "пока не нашли". А может быть и так, что "у нас лапки".

Но вы же.. у вас же получилось, вы же говорите что конструктивные решения есть, и они понятны. Значит, вы знаете как это сделать. Расскажите пожалуйста ?

Не надо нас отсылать "на деревню дедушке" (тем более, на ресурс не доступной в России "официально"). Тем более, если это всё, с ваших слов, так "понятно, просто и конструктивно" ?)))

Статью про то как круто использовать ИИ хостящийся в облаке - вы смогли написать.
А статью, про то как круто локально развернуть и использовать в тех-же сценариях sels-hosted ИИ - вы не сможете?

Ждем от вас статью.

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

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

Какие выводы напрашиваются?

Опытный пользователь Claude Code просто пришлет ссылку на статью с комментарием "сделай также" -- и он сделает. В тексте статьи достаточно обяснений что и как.

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

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

так есть же примеры -- я даже ссылку на репо с кодом (маркдаун файлы) прикрепил

Не вижу ни одного примера с генерацией SQL запросов и анализом их плана выполнения. Так что Вы явно что-то не то прикрепили.

в репозитории есть примеры SQL и описания таблиц :) Если запрос почему-то работает не ожидаемо долго, агент сам догадывается переписать его по-другому.

в репозитории есть примеры SQL и описания таблиц

Есть, но нет запросов к LLM, которые привели к их формированию и нет анализа их плана выполнения. Так что толку от них - ноль.

Если запрос почему-то работает не ожидаемо долго

То есть агент намного глупей джуна и вообще не оценивает план запроса?

Я признаюсь честно -- я не пользовался локальными или self-hosted LLM. Лично мне не было никакой в этом необходимости. Я понимаю, что требования некоторых компаний сильно ограничивают спектр используемых инструментов, да и качество опенсорс моделей заметно уступает старшим аналогам, хотя тут я могу быть не прав, так как опять же не было необходимости ими пользоваться. Если уже вышла опенсорс llm по бенчам сопоставимая с Opus-4.5 или Chatgpt-5.1, то советую посмотреть в их сторону, а более слабые модели возможно не стоит пытаться развернуть, ведь заметная "магия" случилась именно после выхода этих моделей.

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

да для их типичных пользовательских юзкейсов их достаточно

Типичный юзкейс - это пообщаться с потенциальным клиентом на уровне «ваш звонок очень важен для нас»?

В телеграмме очень популярны сейчас обертки поверх ChatGPT и других текстовых моделей, так как интерфейс Телеграма (чат) очень подходит под диалог с AI. К тому же у многих пользователей из СНГ есть проблемы с доступом на такие сервисы -- а тут удобно: за рубли и в телеге. Это уже достаточно насыщенный бизнес суммарно на 50M+ MAU.

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

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

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

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

Можно направить представление, а не оформить. Вот только в Приказе Роскомнадзора от 05.08.2022 N 128, например, даже США нет.

Тогда как внутри РФ достаточно согласия владельца персональных данных на их обработку указанным оператором.

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

"Увольняем джуниора" - статья начала 2025. Современные LLM достигли такого уровня, что уже можно писать статью "Увольняем Analytics Lead в Ton Foundation" :)

лучший комментарий! Спасибо, что сделали мне этот день.

Ха-ха, пока что формулировки "увольняем джуниора" в ряде компаний привели к проблемам с ИИ кодом и "возвращению джуниора" в двойном размере.

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

В каких компаниях? Да его ещё нигде нет толком, только в этом году появились агенты на что-то более менее способные.

А есть у вас какие-то тесты или процесс ревью на эти аналитические репорты?

Sign up to leave a comment.

Articles