Последние года два ловлю себя на мысли, что ИИ это не причина увольнений, а отличное оправдание. Как ковид.
Как будто компании дико режут косты и всегда раньше это означало - "у нас всё фигово" надо
продавать акции
ключевым мотрудникам рассматривать запасные варианты
поставщикам и банкам пересматривать условия обеспечения
А тут "у нас ИИ" прям индульгенция и вроде, как даже положительный знак.
Учитывая, что так же очень умногих - вывод, индустрия в кризисе невероятных масштабов, который в ней похоже обгоняет кризис во всех остальных индустриях.
Так же наверняка уволенных нужных можно сильно дешевле приглашать обратно, и они сами не будут об этом "хвастаться".
Так же в новостях мало говорят об странах в которых уволенные работали и подразделения не часто упоминают.
Да это не исключает, что где-то действительно дураки решили пересесть на ИИ, но как будто это не может быть причиной из первой пятерки.
Я уже молчу, что работники амазона конкретно еще и являются клиентами амазона, до тех пор пока получали там зарплату.
Нытьё - оно и правда есть. И большинство идей ничего не стоят.
И более того те, кто именно на идеях получил возможность хорошего старта, больше всего этот тезис защищают.
И они же бессовестно идеи воруют.
Про идею фейсбука даже фильм сняли, и да дальнейшая релизация имела значение, но именно первоначальная идея позволила получить ресурсы для реализации.
Лари с пейджем тоже вас поддержат ибо гугл, как любая корпорация идеи и ворует и покупает, но именно идея алгоритма позволила найти ресурсы под реализацию.
О том, что y combinator давно пылесосит прежде всего идеи, слухи холят давно.
В общем "если у вас паранойя, это не значит, что за тобой не следят.
Методика сворована из одного секретного НИИ, который разработал всесоюзную программу "Порядо на столе - порядок в голове" и то, что сейчас стол стали называть порочащим слух строителя комунизма "дэсктоп" не меняет сути подхода.
Программа не была внедрена повсеместно по причине вражеской подрывной деятельности. В общем это и послкжило причиной развала советского союза.
Из того с чем сталкивается автоматизация, это адовый процесс подключение любого стороннего софта. Без отдела 1с спецов ты не можешь прикрутить. это всё ни в црм , ни в маркетинговые сервисы. Буквально со старта начинаются костыли. Где снаружи 1с ты городишь ещё одну бд, парсер того, что выплёвывает 1с в форматы, которые можно использоваать во всём остальном.
Дебажить это всё это отдельный вызов.
Названия полей, какая-то отдельная извращенская логика, и их несколь штук - в интерфейсе, в запросах, в commerceml.
Документация "только для сертифицированных разработчиков" или как там они называются.
И все это непозволительно бесяще медленно работает.
Но можно говорят построить свой космолет, все и строят..
Я не просто так написал. Я очень хреновый программист - ллмки слелали жизнь легче.
Выгрузку данных из кабинета яндекса по апи в битрикс24 делал пару лет назад, без ллм - умудохался знатно.
Да и с ллм приходится сильно помучатся - в основном проверкой "то ли я получил, что хотел" и вот эта часть не работает без понимания, как оно тут появилось и если вы не уверены, что получили, что надо и ограничения при этом возникающие - вы не можете доверять данным и от этого они даже не бессмысленны, а даже вредны.
Именно в этом ключевая проблема использования нейронок в целом, они дают буст в местах, которые ты и сам мог бы сделать т.к. только в этом случае ты видишь косяки.
Поэтому если вы от "руками" перешли к автоматизации через клешню, вы пропустили шаг просто автоматизации в котором должно наступить понимание - мое личное мнение, основанное на десятках мелких автоматизашек через апи. в которых чего только не встречалось.
Кривая документация, ошибки в самих апи или том, что их дергает - при этом данные выглядели "валидно". Не столкнувшись с этим ваши автоматизторы не попросят делать кросс-чеки.
В этом проблема ноукод, зерокод, ллмкод, вайбкод и просто клешня безкод - оно как-то решает все более похоже на правду, но без экспертизы минимальной хотя бы "что должно быть внутри" подучается "наукообразная фигня".
вопрос не в инструментарии, вопрос в том почему у вас не было до сих пор ввгрузки из кабинетов метрек, если это ваша основная деятельность.
какой-то опять я токсичный - но нет, со всей душой. занимаюсь местами тем же ;)
но расстраиваюсь, что все равно потом приходется лезть руками в код.
Я прочел мы дергаем 5 апи питоном и складываем в гуглотабличку - ок я тоже так делаю и ничего против не имею "набросать все это" llmкой
Еще мы юзаем плэйрайт, чтобы собрать из dom все тем же питоном. таак и это тоже зачем в компании нужен был "автоматизатор" или немножко программист.
Где тут необходимость в переплате за токены для опенкло я не вижу.
Почему у вас сотрудники, если вы открылись не осенью хотя бы нокод какими-то штуками не автоматизировали свою рутину - вопрос к управленьческим решениям.
Я тут звучу "токсично" что ли. Но, как старый дед в своё оправдание скажу, что каждые полгода вижу восторги новой штукой, с которой все носятся. А по факту в 90% случаев "неофиты открыли, что в экселе есть формулы" ;).
я уж совсем злобным побуду, вдруг про conditional formating в эксельках еще кто-то не знает - это же чудо, как без всякого ии и дашбордов со свистоперделками можно данные визуально выделять ;)
Короче тема не раскрыта, как будто llm тут закодить помогло, не самым оптимальным способом. ну ок.
Исследование пользовательского опыта часть моей работы. В специфических проектах, когда точка 0 - не было автоматизации, точка 1 - есть автоматизация, мало кто пиняет на интерфейс :) Не мне вам рассказывать скриптики "для себя" обходятся вовсе без него годами.
Делать сразу чуть лучше и учитывать базовое помогает насмотренность и прочесть что-то по проектированию интерфейсов - условно "как не надо делать" уже даёт хорошее понимание.
Есть базовые вещи:
вёрстка табличных данных
иерархия объектов
групировка объектов
цветовое кодирование и подсветка
как наш взгляд сканирует интерфейсы
К сожалению прям конкретные материалы не вспоминаются. Если вспомню - напишу.
Вопрос не в мощности железа, а в том какие задачи решаешь, и насколько тебя интересует "налог на эффективность" в виде обязательных но не ключевых действий. Я несколько лет работал в фотолаборатории во времена, когда люди еще приходили распечатать 200 фоток и таких в августе было десятки в день. Скорость работы с файлами - это ключевой параметр эффективности в приеме заказов, учитывая, что клиенты просто приносили компакт диск или флешку, естественно в не отсортированном виде.
Сейчас ничего не изменилось. Как только есть необходимость работы с десятками или сотнями файлов (я не беру кейсы работы с серверами) человек с мышкой выигрывает только у человека с айфонов, и оба крайне удивляются, что задачу - разгребсти сотни файлов 1. можно решить 2. можно решить крайне быстро
Статья отличная. NC VC DN в сердце. TC - до сих пор пользуюсь :)
Перевод и генерация текста. Плюс категоризатор. На глаз 10к+ запросов уже никаких проблем с json не было. Его формат и инструкция "отдавай только json в конце промпта"
2/3 этих запросов это текст с html вёрсткой ограниченной определённым набором тегов, и я ожидал, что могут возникнуть проблемы, но пока не было.
Гуглинг, реверс-инженирнг чужик поделок, просмотр доков на другие языки. :)
Кто подбирал нужную версию .dll с компакт дисков пиратских почитав предварительно .inf файлы тот на такой фигне не пасуют. Интернеты есть, llm есть (не редко врёт, но и на мысли может натолкнуть :)
Не касаемо Битрикс апи, а в целом: Про структуру запроса - обычно подобные косяки с добавлением информации по API POST/PUT и т.д. - Если не получилось с копипэйста из документации, как правило имеет смысл GET и уже по полученной структуре разгребать. - не редко всё настолько непонятно, что приходится заполнить все поля в UI сначала данными типа field_name и цифрами/датами остальное :))
- бывает нужна магия, например в Zoho CRM был глюк один их методов работал только со строчной переменной, хотя и в документации и в том, что приходило по GET был массив. Как я догадался? естественно случайно :) - с другой стороны это то почему я не верю в скорую победу ИИ над кожанными мешками :)
Расстраивает, что в нашей части мира (не претендую на объектиность) реже на это обращают внимание. Справедливости ради, плохая документация много у кого, и если сейчас появились объективные причины (весь мир не дружит с нами и риски по opensource), то почему раньше не использовался софт для представления документации в приличном и удобном виде - не понятно.
Для меня критерий простой, возможность очень быстро набросать на python/powershell тестовые запросы и понять, что надо на вход и что получаем на выходе.
Я когда-то был приятно поражен документацие stripe с тех пор видел массу примеров западных сервисов ничуть не хуже.
Наличие песочниц (понятно, что это мега дорого) это вообще какая-то запредельная технология - видел только у Яндекса из РУ сегмента.
Гугл документацию по API тоже не назовешь удобной, не врёт но пользоваться ей - боль.
Столкновение с 1с всегда боль. Зашел посмотреть "а вдруг!". а вдруг например апи какое приличное, с понятной документацей
нет. нифига. ;) .
всегда когда можно 1с не касаться - очень стараюсь делать так.
вот в очередной раз, нужен банальный флоу - взяли номенклатуру, добавили переводом с помощью ллм. запихали в тильду и обратно в 1с. тут дальше кроме матов нельзя описать процесс. тупо проще выгружать в таличку/бд и в ней все сделать и хранить. и быстрен. и вероятно надежнее. и да "бог 1с" быстро сделал мега метод "брать айди номенклатуры и показывать в отчете", ведь сука по нему синхронизируются остатки потом с сайтом, но блять почему это так через жопу?... не знаю можно ли матами ругаться тут. но похер. тупо убита куча времени. и так вот чего не коснись. а оно ещё и тупит а товаров всего 2к..
хотя недавно вот заглянул в документацию битрикс24 по апи - наконец-то стало возможно пользоваться без крови из глаз. может давно. прошлый подход заставил страдать, хотя есть вопросики "а почему бы питон еще не добавить в примеры", но к счастью llm'ки для быстро переводят с curl.
нет кейса когда мне помог бот, и еще со времен телефонных автоответчиков всё это раздражало ;)
тут на хабре большинстао включая меня, не являемся теми, кто стучится в поддержку не проверив возможности других интерфейсов. поэтому мы можем быть нерелевантны для оценки полезности ;)
хуже ботов, операторы поддержки работающие по скрипту - сталкивался с таким в Британии очень давно. Без матов не описать ;)
вы затронули прекрасный вопрос, который не затронут в обзоре. Это возможности и улобство api.
Нагуглить 100 акрвисов проблемы нет и все это парсится каким-то перпоексити. А когда действительно ищешь решение для конкретной команды смтришь, как оно встанет с другими штуками, какие у тебя уже есть или будут. Поэтому api и интеграции это очень важный элемент.
И да, по моему небольшому опыту с api и документациями к нему в Ру нетете очень так себе, пока не имею опыта, который записал бы, как положительный. Прежде всего из-за отсутствия стандарта документации с примерами на нескольких языках и возможностью протестировать прямо в документации простые запросы, что очень радует в глобальных вервисах, хоть и не всех.
Узнаю в вас 1Сника "это не у нас работате не как у всех, а у всех не как у нас".
Последние года два ловлю себя на мысли, что ИИ это не причина увольнений, а отличное оправдание. Как ковид.
Как будто компании дико режут косты и всегда раньше это означало - "у нас всё фигово" надо
продавать акции
ключевым мотрудникам рассматривать запасные варианты
поставщикам и банкам пересматривать условия обеспечения
А тут "у нас ИИ" прям индульгенция и вроде, как даже положительный знак.
Учитывая, что так же очень умногих - вывод, индустрия в кризисе невероятных масштабов, который в ней похоже обгоняет кризис во всех остальных индустриях.
Так же наверняка уволенных нужных можно сильно дешевле приглашать обратно, и они сами не будут об этом "хвастаться".
Так же в новостях мало говорят об странах в которых уволенные работали и подразделения не часто упоминают.
Да это не исключает, что где-то действительно дураки решили пересесть на ИИ, но как будто это не может быть причиной из первой пятерки.
Я уже молчу, что работники амазона конкретно еще и являются клиентами амазона, до тех пор пока получали там зарплату.
Нытьё - оно и правда есть. И большинство идей ничего не стоят.
И более того те, кто именно на идеях получил возможность хорошего старта, больше всего этот тезис защищают.
И они же бессовестно идеи воруют.
Про идею фейсбука даже фильм сняли, и да дальнейшая релизация имела значение, но именно первоначальная идея позволила получить ресурсы для реализации.
Лари с пейджем тоже вас поддержат ибо гугл, как любая корпорация идеи и ворует и покупает, но именно идея алгоритма позволила найти ресурсы под реализацию.
О том, что y combinator давно пылесосит прежде всего идеи, слухи холят давно.
В общем "если у вас паранойя, это не значит, что за тобой не следят.
Методика сворована из одного секретного НИИ, который разработал всесоюзную программу "Порядо на столе - порядок в голове" и то, что сейчас стол стали называть порочащим слух строителя комунизма "дэсктоп" не меняет сути подхода.
Программа не была внедрена повсеместно по причине вражеской подрывной деятельности. В общем это и послкжило причиной развала советского союза.
Спасибо за пост.
Из того с чем сталкивается автоматизация, это адовый процесс подключение любого стороннего софта. Без отдела 1с спецов ты не можешь прикрутить. это всё ни в црм , ни в маркетинговые сервисы. Буквально со старта начинаются костыли. Где снаружи 1с ты городишь ещё одну бд, парсер того, что выплёвывает 1с в форматы, которые можно использоваать во всём остальном.
Дебажить это всё это отдельный вызов.
Названия полей, какая-то отдельная извращенская логика, и их несколь штук - в интерфейсе, в запросах, в commerceml.
Документация "только для сертифицированных разработчиков" или как там они называются.
И все это непозволительно бесяще медленно работает.
Но можно говорят построить свой космолет, все и строят..
Звучит интересно, но хочется больше деталей.
Что за модели? Тех стек реализации?
Если детали по тому чем занимается компания секретный секрет, то хотя бы b2b или b2c (вроде второе).
по процессам претензии на маркетплейсах, почта, форма на сайте?
А то - мы молодцы! на 300 тонн удоев чугуна больше в два раза быстрее, чем у лучших сабоководов.
Я не просто так написал. Я очень хреновый программист - ллмки слелали жизнь легче.
Выгрузку данных из кабинета яндекса по апи в битрикс24 делал пару лет назад, без ллм - умудохался знатно.
Да и с ллм приходится сильно помучатся - в основном проверкой "то ли я получил, что хотел" и вот эта часть не работает без понимания, как оно тут появилось и если вы не уверены, что получили, что надо и ограничения при этом возникающие - вы не можете доверять данным и от этого они даже не бессмысленны, а даже вредны.
Именно в этом ключевая проблема использования нейронок в целом, они дают буст в местах, которые ты и сам мог бы сделать т.к. только в этом случае ты видишь косяки.
Поэтому если вы от "руками" перешли к автоматизации через клешню, вы пропустили шаг просто автоматизации в котором должно наступить понимание - мое личное мнение, основанное на десятках мелких автоматизашек через апи. в которых чего только не встречалось.
Кривая документация, ошибки в самих апи или том, что их дергает - при этом данные выглядели "валидно". Не столкнувшись с этим ваши автоматизторы не попросят делать кросс-чеки.
В этом проблема ноукод, зерокод, ллмкод, вайбкод и просто клешня безкод - оно как-то решает все более похоже на правду, но без экспертизы минимальной хотя бы "что должно быть внутри" подучается "наукообразная фигня".
вопрос не в инструментарии, вопрос в том почему у вас не было до сих пор ввгрузки из кабинетов метрек, если это ваша основная деятельность.
какой-то опять я токсичный - но нет, со всей душой. занимаюсь местами тем же ;)
но расстраиваюсь, что все равно потом приходется лезть руками в код.
Из вашего кейса не понятно за чем вам "клешня".
Я прочел мы дергаем 5 апи питоном и складываем в гуглотабличку - ок я тоже так делаю и ничего против не имею "набросать все это" llmкой
Еще мы юзаем плэйрайт, чтобы собрать из dom все тем же питоном. таак и это тоже зачем в компании нужен был "автоматизатор" или немножко программист.
Где тут необходимость в переплате за токены для опенкло я не вижу.
Почему у вас сотрудники, если вы открылись не осенью хотя бы нокод какими-то штуками не автоматизировали свою рутину - вопрос к управленьческим решениям.
Я тут звучу "токсично" что ли. Но, как старый дед в своё оправдание скажу, что каждые полгода вижу восторги новой штукой, с которой все носятся. А по факту в 90% случаев "неофиты открыли, что в экселе есть формулы" ;).
я уж совсем злобным побуду, вдруг про conditional formating в эксельках еще кто-то не знает - это же чудо, как без всякого ии и дашбордов со свистоперделками можно данные визуально выделять ;)
Короче тема не раскрыта, как будто llm тут закодить помогло, не самым оптимальным способом. ну ок.
Исследование пользовательского опыта часть моей работы. В специфических проектах, когда точка 0 - не было автоматизации, точка 1 - есть автоматизация, мало кто пиняет на интерфейс :)
Не мне вам рассказывать скриптики "для себя" обходятся вовсе без него годами.
Делать сразу чуть лучше и учитывать базовое помогает насмотренность и прочесть что-то по проектированию интерфейсов - условно "как не надо делать" уже даёт хорошее понимание.
Есть базовые вещи:
вёрстка табличных данных
иерархия объектов
групировка объектов
цветовое кодирование и подсветка
как наш взгляд сканирует интерфейсы
К сожалению прям конкретные материалы не вспоминаются. Если вспомню - напишу.
Вопрос не в мощности железа, а в том какие задачи решаешь, и насколько тебя интересует "налог на эффективность" в виде обязательных но не ключевых действий.
Я несколько лет работал в фотолаборатории во времена, когда люди еще приходили распечатать 200 фоток и таких в августе было десятки в день. Скорость работы с файлами - это ключевой параметр эффективности в приеме заказов, учитывая, что клиенты просто приносили компакт диск или флешку, естественно в не отсортированном виде.
Сейчас ничего не изменилось. Как только есть необходимость работы с десятками или сотнями файлов (я не беру кейсы работы с серверами) человек с мышкой выигрывает только у человека с айфонов, и оба крайне удивляются, что задачу - разгребсти сотни файлов
1. можно решить
2. можно решить крайне быстро
Статья отличная. NC VC DN в сердце.
TC - до сих пор пользуюсь :)
И в метрическую систему переход..
Использую deepseek по api, дергаю питоном.
Перевод и генерация текста. Плюс категоризатор. На глаз 10к+ запросов уже никаких проблем с json не было. Его формат и инструкция "отдавай только json в конце промпта"
2/3 этих запросов это текст с html вёрсткой ограниченной определённым набором тегов, и я ожидал, что могут возникнуть проблемы, но пока не было.
Решение подобных задач это круто.
Но как интерфейс это очень плохо, прежде всего тем, что очень большая когнитивная нагрузках в попытках считать:
из-за отсутсвия вёрстки, хотя бы банального выравнивания элементов цифр, независимость его от -/+ значений
красные рамки частично прилипают к именованиям объектов, отчего те не читаемы до конца
плохо просматривается или отсутствует иерархия объектов и их значений
на примере со слайдером не понятен ни шаг, ни границы значений
Про то, что утилитарное не должно быть уродливым, упомяну, но в отличии от вышеописанного, согласен обозвать вкусовщиной.
Средней руки дизайнер, пожелавший вникнуть в проблему способен очень сильно улучшить функциональность вашего продукта.
Даже чисто текстовыми средствами достигнуть можно шикарнейших результатов.
Гуглинг, реверс-инженирнг чужик поделок, просмотр доков на другие языки. :)
Кто подбирал нужную версию .dll с компакт дисков пиратских почитав предварительно .inf файлы тот на такой фигне не пасуют. Интернеты есть, llm есть (не редко врёт, но и на мысли может натолкнуть :)
Не касаемо Битрикс апи, а в целом:
Про структуру запроса - обычно подобные косяки с добавлением информации по API POST/PUT и т.д.
- Если не получилось с копипэйста из документации, как правило имеет смысл GET и уже по полученной структуре разгребать.
- не редко всё настолько непонятно, что приходится заполнить все поля в UI сначала данными типа field_name и цифрами/датами остальное :))
- бывает нужна магия, например в Zoho CRM был глюк один их методов работал только со строчной переменной, хотя и в документации и в том, что приходило по GET был массив. Как я догадался? естественно случайно :)
- с другой стороны это то почему я не верю в скорую победу ИИ над кожанными мешками :)
Спасибо.
Вопросы и по документации и по песочницам..
Расстраивает, что в нашей части мира (не претендую на объектиность) реже на это обращают внимание.
Справедливости ради, плохая документация много у кого, и если сейчас появились объективные причины (весь мир не дружит с нами и риски по opensource), то почему раньше не использовался софт для представления документации в приличном и удобном виде - не понятно.
Для меня критерий простой, возможность очень быстро набросать на python/powershell тестовые запросы и понять, что надо на вход и что получаем на выходе.
Я когда-то был приятно поражен документацие stripe с тех пор видел массу примеров западных сервисов ничуть не хуже.
Наличие песочниц (понятно, что это мега дорого) это вообще какая-то запредельная технология - видел только у Яндекса из РУ сегмента.
Гугл документацию по API тоже не назовешь удобной, не врёт но пользоваться ей - боль.
Столкновение с 1с всегда боль. Зашел посмотреть "а вдруг!". а вдруг например апи какое приличное, с понятной документацей
нет. нифига. ;) .
всегда когда можно 1с не касаться - очень стараюсь делать так.
вот в очередной раз, нужен банальный флоу - взяли номенклатуру, добавили переводом с помощью ллм. запихали в тильду и обратно в 1с. тут дальше кроме матов нельзя описать процесс. тупо проще выгружать в таличку/бд и в ней все сделать и хранить. и быстрен. и вероятно надежнее. и да "бог 1с" быстро сделал мега метод "брать айди номенклатуры и показывать в отчете", ведь сука по нему синхронизируются остатки потом с сайтом, но блять почему это так через жопу?... не знаю можно ли матами ругаться тут. но похер. тупо убита куча времени. и так вот чего не коснись. а оно ещё и тупит а товаров всего 2к..
хотя недавно вот заглянул в документацию битрикс24 по апи - наконец-то стало возможно пользоваться без крови из глаз. может давно. прошлый подход заставил страдать, хотя есть вопросики "а почему бы питон еще не добавить в примеры", но к счастью llm'ки для быстро переводят с curl.
TL:DR конечно и слог черезчур одухотворённый и пафосный, но суть местами докидала элементов в мой пазл о LLM. Спасибо.
Два момента:
нет кейса когда мне помог бот, и еще со времен телефонных автоответчиков всё это раздражало ;)
тут на хабре большинстао включая меня, не являемся теми, кто стучится в поддержку не проверив возможности других интерфейсов. поэтому мы можем быть нерелевантны для оценки полезности ;)
хуже ботов, операторы поддержки работающие по скрипту - сталкивался с таким в Британии очень давно. Без матов не описать ;)
вы затронули прекрасный вопрос, который не затронут в обзоре. Это возможности и улобство api.
Нагуглить 100 акрвисов проблемы нет и все это парсится каким-то перпоексити. А когда действительно ищешь решение для конкретной команды смтришь, как оно встанет с другими штуками, какие у тебя уже есть или будут. Поэтому api и интеграции это очень важный элемент.
И да, по моему небольшому опыту с api и документациями к нему в Ру нетете очень так себе, пока не имею опыта, который записал бы, как положительный. Прежде всего из-за отсутствия стандарта документации с примерами на нескольких языках и возможностью протестировать прямо в документации простые запросы, что очень радует в глобальных вервисах, хоть и не всех.