Хабр Курсы для бэкендеров
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 56
Валентина, LLM-модели сами говорят, что программист в их понимании - это сейчас Архитектор. Именно так, с большой буквы. Но для того чтобы быть Архитектором системы/приложения нужно быть программистом, нужно иметь его знания, и, желательно - опыт. Без этого высокоуровневого приложения, даже при помощи AI, не создашь. Ну вот смотрите, вайб-кодинг доступен уже давно, а 2 февраля 2025 года Карпати ввёл этот термин в обращение. Много мы выдающихся приложений увидели с тех пор? То-то же. Оказывается, не может стая мартышек, даже вооружившись инструментами для вайб-кодинга написать эстетически и функционально законченное произведение.
Мне кажется, вы не уловили посыл автора... Вопрос не в том, кем является программист теперь, в эпоху ИИ, а в том - как программисту развиваться, что бы лучше понимать / контролировать / тестировать работу этих чёрных LLM-ящиков
Я просто начал с основ, показал, что программист в любом случае остаётся программистом. Только переходит в иное качество. А развиваться? Здесь нет стандартного рецепта. Кто-то ходит на курсы по промптингу. Кто-то слушает гуру. Кто-то сам в процессе работы набирает опыт. Пути разные. И для каждого эффективны по своему.
В таком случае, не соглашусь с Вами. Утверждение, что "для того чтобы быть Архитектором системы/приложения нужно быть программистом ... без этого высокоуровневого приложения, даже при помощи AI, не создашь." - это в текущих реалиях, не основа. Да, я могу не до конца понимать, что Вы имеете ввиду, под высокоуровневым приложением... Я, будучи веб разработчиком, с 0м знаний в разработке для андроида, сделал приложение, которое в полной мере покрывает задачи по управлению моим "умным домом". И казалось бы, я программист с многолетнем опытом, Архитектор... Однако с появлением AI я могу делать вещи, в которых совершенно не разбираюсь. Как и любой другой - не программист. Вопрос тот же - как оценить "моё" творение, понять, улучшить эффективность, найти уязвимости и слабые места. Лично меня, больше всего, зацепил вопрос автора касательно обучения - тоже хотел бы получить конкретные советы.
Ну, я тоже много чего "сделал" при помощи ИИ. Но масштабируется это плохо. Уверен, вы не пробовали писать командой таких же непрофильных спецов сложный проект, скажем с годик минимум.
Однако с появлением AI я могу делать вещи, в которых совершенно не разбираюсь. Как и любой другой - не программист.
На самом деле не Вы делаете эти вещи, а принимаете на веру ответ модели и запускаете его в работу. Часто бывает полезно запросить модель (ту же самую) проверить безопасность кода. Она такое бывает сама за собой находит... Но работает же. Для обычного человека без специфических знаний в БД например, или сетевом стеке или даже в вёрстке сайтов этого вполне достаточно. Его потребность удовлетворена. Ладно если это локально крутится, не касается чувствительных вещей и не выносится в открытый Интернет. А вопрос поддержки? А апгрейды? А поддержка пользователей? Вот это я и имею ввиду под высокоуровневым приложением. Не будем далеко ходить - Хабр навайбкодили или руками писали? А проект его уровня Вы готовы вайбкодить и делать публичным не понимая в конечном итоге, что с ним происходит в каждый момент времени?
Вопрос тот же - как оценить "моё" творение, понять, улучшить эффективность, найти уязвимости и слабые места.
Для человека, который не разбирается - либо при помощи той же модели, либо при помощи приглашённых экспертов. Но в первом случае придётся принимать на веру ответ модели, в код которой Вы уже поверили. То есть опять оставаться в неведении относительно истинного положения вещей.
Вы своим примером ответили первому оппоненту лучше меня: собрали рабочее приложение без опыта в Android — значит, «сначала стань Архитектором», чтобы что-то создать, уже не обязательно.
И сразу назвали, где теперь настоящая сложность: не построить, а оценить и укрепить своё. По-моему, этому учит не курс, а тем же способом, каким вы делали приложение — берёте конкретную чужую практику (открытый QA-скилл, чеклист уровня OWASP API) и прогоняете по своему проекту. Бьёт по тому, что вам реально не видно, — быстрее любой теории.
Спасибо, ваш коммент — половина статьи одним абзацем.
Да, рецепта нет — и вы правы, что пути разные и каждый работает по-своему. Но если присмотреться к вашему же списку, у всех трёх путей общий пробел.
Курсы по промптингу и гуру дают абстракцию — «как надо вообще», а не «как применить к моему конкретному проекту». А опыт «в процессе работы» — самый ценный, но он приватный: остаётся в голове и в терминале одного человека и никуда не передаётся.
Мне кажется, чего не хватает — не ещё одного курса, а способа учиться на том, что другие практики реально сделали со своим агентом: конкретно, с деталями, воспроизводимо. Не «эксперт рассказал теорию», а «вот человек решил ровно мою задачу — и я могу повторить это у себя».
И тут для меня есть более широкая мысль. Появился новый тип людей — те, кто строит с агентами каждый день: не обязательно классические сеньоры, но те, кто хочет расти, придумывать, доводить до продукта. Это, по сути, новая единица на рынке, и ей тоже нужно где-то обмениваться этим новым ремеслом. Вот про это мне сейчас интереснее всего думать.
мне кажется я уловил (
Я делаю worklore ...
Согласна с ядром: Архитектором без инженерного бэкграунда не станешь, и вайб-кодинг сам по себе «законченное произведение» не рождает. Но я свела цифры «до и сейчас» — 2024 (ещё до вайб-кодинга, термин Карпаты ввёл только в феврале 2025) против 2026 — и они подтверждают обе половины разом.
Объём взорвался, и это измеримо: — App Store: 448K новых приложений за весь 2024 → ~560K только за первое полугодие 2026 (это уже почти как весь 2025). В годовом темпе — свыше 1 млн, рекорд, побивающий 2016-й; по iOS релизы за полгода фактически удвоились. — Google Play: ~41K новых приложений/мес в конце 2024 → ~88K/мес в 2026. Тоже примерно ×2. Причину аналитики называют прямо: Cursor / Replit / Bolt / Lovable и вайб-кодинг обрушили порог входа. Так что «стая мартышек с инструментами» — не гипотеза, она в статистике.
А теперь ваше «выдающихся не прибавилось» — тоже в цифрах: — загрузки в первой половине 2026 выросли всего на 2% при вдвое большем числе релизов. Приложений в два раза больше, а спроса — столько же. Классический supply glut. — топ-1% приложений собирает ~92% всей выручки от in-app покупок. Ценность утекает наверх, а не размазывается по потоку. — и Google Play с начала 2024-го вычистил ~1.8 млн приложений — тот самый «слоп».
Для меня вывод не «AI не работает», а ровно то, о чём статья: середину — типовые приложения — вайб-кодеры коммодитизировали, её теперь делает кто угодно; а ценность концентрируется в верхнем слое, где и нужен опытный инженер-Архитектор. Так что ваш аргумент тревогу не снимает, а уточняет: «просто кодеров» рынку нужно меньше, Архитекторов — по-прежнему нужно. Весь мой вопрос — как опытному гарантированно оказаться в этом верхнем слое, а не в вымываемой середине.
Спасибо за коммент — это ровно тот разговор, ради которого писала.
К эмоциональной части присоединяюсь без остатка. Но по существу, я не вижу чего мы еще не знаем. Каждый творчески сооружает обвязку для ИИ под свои задачи и приоритеты. То, что упускает специфицировать (как в статье с секьюрити), отгребает уже на фазе ловли блох. Да, нам хочется рецептиков, чтобы нам показали "а как же правильно". Вот если мы так будем мыслить, ИИ нас точно заменит, т.к. он по сути такой же незнайка. А придумать?..
Совершенно верно! AI не ограничитель, а расширитель возможностей. Секьюрити? Ну попроси его проверить код (лучше сильной моделью), а потом исправить и отчитаться. Не доверяешь? Запроси diff и проверяй сам. В остальном полная свобода творчества.
Если бы «попроси проверить и исправить» действительно закрывало вопрос, безопасность не становилась бы с каждым годом всё большей проблемой. А она становится — сторы буквально захлёбываются AI-слопом с дырами. Что, все дружно забыли в конце дать команду «проверь»? :)
Загвоздка в том, что проверяет чаще всего тот же «незнайка», что и писал: модель не знает, чего она не подумала проверить. «Проверь безопасность» без конкретики — это инъекции, и на этом всё; остальное она спокойно пропустит и бодро отчитается «всё ок». Именно поэтому конкретный дисциплинированный приём (чеклист, security-скилл с требованием доказательств) находит то, что общий «проверь» не находит, — и даже тогда я не уверена, что покрыла всё.
А «запроси diff и проверь сам» работает ровно настолько, насколько ты сам знаешь, что искать. Веб-разработчик, собравший Android-приложение с нуля, в diff’е не увидит дыру в авторизации, о существовании которой не подозревает. Вот здесь опыт и не заменяется — не в написании кода, а в том, чтобы знать, что проверять.
С самым острым — согласна: если мы ждём «покажите, как правильно», чтобы повторить, тогда нас и правда заменят. Незнайка, повторяющий за незнайкой, не нужен.
Но я предлагаю не поваренную книгу. Скорее — сборник того, что люди уже придумали и попробовали, вместе с тем, что не сработало (та же секьюрити — это не рецепт, это пойманная на живом проекте ошибка, которую полезно увидеть до того, как наступишь сам). Не замена изобретению, а сырьё для него: не «скопируй», а «вот чужой кейс — придумай на его основе свой».
И вот тут весь вопрос — не «рецепты или нет», а какими свойствами такой сборник должен обладать, чтобы кормить изобретение, а не отучать от него. Навскидку: конкретика вместо абстракции, обязательные провалы, воспроизводимость (чтобы примерить и переделать, а не списать), привязка к реальному контексту автора. Что бы вы добавили или вычеркнули?
«А придумать?» — вот это и есть цель. Сборник имеет смысл, только если он трамплин, а не костыль.
Ну вал статей тут про агентов я бы спокойно пропускал мимо ушей.
Кому-то хочется делать "план по валу", и ничего хайповей агентов не находят.
Я же устал уже отбиваться от агентов. Только дай Fable какую-нибудь задачку поработать с сорсами, как он вмиг создаст с десяток агентов и сожрёт весь лимит за минуты.
Приходится отдельно писать ему, чтобы не создавал агентов. Модель одна спокойно в одном потоке управляется.
Но эта мода на агентов добралась уже и до GPT. Claude хоть напишет, сколько агентов создал. А этот втихаря их запустит. Хорошо хоть скидку временно дали.
Так что за свои слабые скиллы по части агентов не переживайте. Это не то, во что надо вкладываться.
Сами агентские скиллы сторонние я тоже сильно бы не переоценивал. Часто они слишком раздуты. У меня скиллы рождаются автоматически. Модель всё сама найдёт рано или поздно, что написано в каком-либо из существующих в мире скиллов. Но иногда я вижу, что начинает лагать. И это знак: значит, надо сказать ей, чтобы в конце написала скилл про то, чем занималась. Вот и всё. Много ума тут не надо.
Вкладываться я бы сейчас стал в количество проектов. Это же очевидно.
Сейчас можно тянуть пять проектов вместо одного. Раньше и один шёл кое-как, всё время надо было держать контекст в памяти. Теперь войти в курс - дело пары минут.
value innovation я вижу в подходе "почти индивидуальный продукт по цене массового"
Отсюда кстати ответ на вопрос где эти "выдающиеся приложения". Их нет! Они больше не нужны, эти универсальные приложения для всех.
А этот втихаря их запустит
В чём вы гоняете его? В официальном приложении codex у меня справа сверху всплывачка вылезает, в которой список агентов и можно посмотреть, чем они там занимаются.
Про агентов во многом соглашусь: да, жгут лимит пачками, и сторонние скиллы часто раздуты — тут не спорю.
Но «вкладываться в количество проектов» — вот здесь поспорю. А является ли продуктом то, что тебе насобирала модель за твою кучу токенов в полностью автоматическом режиме?
Возьмём абстрактный пример: предположим, я хочу автоматизировать свой процесс написания постов в твиттер (он же X). У меня есть продукт, пусть нейронка посты пишет, тренды считывает ежедневно в 9 утра по Нью-Йорку. Модель подключает браузер, кушает твиттер-авторизацию, снифферит трафик, строит код и докладывает: я молодец, крон будет запускать таск каждый день в положенное время, тесты пройдены, апи-ключ на обращение к модели для написания текстов получен. Вы радуетесь автоматизации и идёте писать 10-й проект, по дороге думая, кому бы продать то, что вы только что создали. Проходит неделя. Твиттер выкатывает новую версию протокола. Ваша модель не может пройти авторизацию, протокол изменился. Вам надо идти командовать модели снова идти в браузер и снифферить трафик. При этом вы ещё должны были настроить себе уведомлялку на то, чтобы программка вам сообщила, что у неё проблемы, а не молча сдохла. Вы переключили свой контекст, выдали руководящее указание, даже какую-то заплатку на самообучение придумали (чтобы больше токенов сгорело ;). А через неделю ещё что-то изменилось. И всё заново. В результате вы получаете кривой продукт, на развитие которого у вас нет времени (вы занимаетесь ещё 9, вам там тоже надо что-то чинить). Ваши конкуренты, которые занимаются только аналогичным продуктом и не переключаются, мгновенно выкатывают апдейты, придумывают новые типы постов и способы ловли трендов — и их продукт уже с платными пользователями и окупается. А вы просто жжёте токены своими автоматизациями.
Так что «выдающихся нет, они не нужны» я бы уточнила: универсальные для всех — может быть. Но окупится тот, кто свой узкий продукт умеет тащить и развивать быстрее, чем он ломается, — а не тот, у кого их десять и все подтекают. Количество не даёт устойчивости; за него платишь поддержкой и реакцией на чужие изменения.
Тут полемика без цифр. А в них самый дъявол.
Мне модель узнает все про измения протоколов за считанные минуты и внесет правки за минуты. И протестирует за минуты , итого 10 мин.
Нет ничего для них сейчас боле простого как починить протокол.
Ваш личный скил здесь - не потерять концентрацию хотя бы полчаса. Эт тоже надо тренировать.
А "Ваши конкуренты, которые занимаются только аналогичным продуктом" , которые работают по старому потратят эти 10 мин обсуждая в свое курилке какой X нехороший что поменял протокол.
Ваш ответ, чувствую, подготовлен GPT. Я тоже от него получаю такие вот наивные сценарии. Это от того, что он сценарии пишет с точки зрения прошлого опыта, не вставляя самого себя в них.
Про «подготовлен GPT» спорить не буду: я и правда пишу вместе со своим агентом и не скрываю — это буквально суть моего проекта. Но опыт-то мой. И раз вы про абстрактность — тот, который я упомянула, не абстрактный, из недавнего.
Я взяла популярный скил (несколько тысяч звёзд) для чтения постов и поиска инфы по платформам — не только X. Из коробки, на последнем коммите (свежем, не месячной давности) поиск в X не работает. Из всего про посты живо ровно одно: смотреть посты конкретного автора. Казалось бы — ну сходи, почини, сделай MR. Ваши «10 минут», да?
А зачем? Открываю ту же ленту X: минимум три разработчика у меня в фиде пишут свои проекты про автоматизацию постов в формате build-in-public, и это только то, что мне на глаза попадалось без специального поиска. И они в своих продуктах уже решают блокировки аккаунтов, смену протокола и все эти танцы с бубном — за подписку в районе $20 в месяц. Вот вам и цифры: моё переключение контекста против $20/мес у того, кто занят только этим.
Так что «починю за 10 минут» — не контраргумент, а как раз иллюстрация. Даже у популярного, свежекоммиченного скила поиск уже сломан — поломка это норма, а не исключение. Вопрос не «могу ли я починить», а «стоит ли, когда человек, для которого это единственная работа, уже починил и продаёт». Вот вам и устойчивость: она у того, кто фокусируется, а не у того, кто тащит десять протухающих автоматизаций.
Очень странный пример. Чтобы «руками» сделать этот «абстрактный пример» надо тоже обо всем этом обязательно подумать и написать. Претензия к модели что «не додумывает» за вас все? )
Только дай Fable какую-нибудь задачку поработать с сорсами, как он вмиг создаст с десяток агентов и сожрёт весь лимит за минуты.
Это настраивается в переменных окружения и конфигурации. Настроек много, так что не буду цитировать документацию, это выясняется в один запрос к гуглю.)
Предположим, я хочу протестировать своё API.
Ну, почему так абстрактно? Давайте, «предположим» что-то более конкретное, что знают все – и «эндэры», и все реже встречающиеся – программисты ПО для ПК.
Например, давайте, с помощью ИИ-ёв создадим платформу «1С77». Тем более, что существует опенсорсный проект «2С». Да, последний давно заброшен и довольно бестолковый по своей идее и реализации.
Однако, что нам мешает, выбрать собственную концепцию подобной учетной платформы? И попросить ИИ реализовать её?
Вот бы продемонстрировать возможности ИИ, и заодно человека (который определит архитектуру новой версии «народной» программы).
Не нравится «1С», возьмете более примитивную программу, у которой есть реальный аналог. Чтобы потом сравнить оригинал и «вайб-копию». Статей на эту тему можно было написать бесконечно, читать которые было бы ой, как интересно! Но, нет ни одной. Только описание процессов, веб-сервисов и мобильных приложений. У меня есть только одна похожая статья, но, в соавторстве с бесплатным ИИ («Минималистский графический интерфейс, на C++ / WTL, для консольного загрузчика» : https://habr.com/ru/articles/955838/ ), поскольку, работать с платными ИИ-сервисами у меня, пока, нет ни возможности, ни потребности.
Отличная идея для демонстрации — и, кстати, чисто технически вы правы: солист с агентом реально склонирует немалый кусок 1С. Возьмите даже не всё, а один Склад без интеграций — за разумное время получите рабочую вайб-копию, тут спорить не буду.
Но именно на этом примере видно, что проблема давно не в том, чтобы «скопировать с улучшениями». Проблема — в экономике. Сила 1С не в коде складского модуля, а в том, что на ней уже сидят пользователи: она — стандарт. Чтобы перейти на ваш «охренительно новый» продукт, им надо переобучиться, перенести данные, перестроить процессы и довериться незнакомому. А им не надо — у них работает. Стащить компанию со стандарта дороже и дольше, чем написать сам этот стандарт заново.
И вот тут, по-моему, главный сдвиг: ИИ обрушил стоимость постройки — поэтому код успех уже не решает. Он стал дешёвым и обязательным, как розетка: без него никак, но и выиграть на нём нельзя. Решает всё, что вокруг и чего ИИ вам не даст: кто уже стандарт, кого дорого переучивать, кому доверяют, кто держит поддержку. Статей «вайб-копия против оригинала» нет не потому, что лень писать, а потому что копия — это ровно та часть, которая перестала быть трудной.
А за статью про GUI к загрузчику — respect: такие конкретные разборы как раз и ценнее абстракций.
солист с агентом реально склонирует немалый кусок 1С. Возьмите даже не всё, а один Склад без интеграций – за разумное время получите рабочую вайб-копию
Не уверен, что всё так радужно! Для меня «1С» это, прежде всего, платформа, а не типовая конфигурация, которая без платформы ничего не стоит.
А вот «склонировать немалый кусок» платформы, хотя бы «1С77» – это уже очень интересная постановка задачи. Потому что, сначала, надо определиться с концепцией этой «вайб-копии». То ли это будет повторение идей существующей реализации, то ли вы добавить новые.
Я выжал из платформы «семёрки», пожалуй, максимальный максимум, что и кормило меня порядка двадцати лет. Поэтому, я хорошо знаю её достоинства и недостатки. Могу кратко перечислить:
Достоинства:
• Объект «Справочник» – мой самый любимый объект. Он поддерживает группы элементов (записей базы данных), которые не поддерживает ни одна учетная программа (разве, что, в полной мере, только «толстый клиент» в «1С82»).
• Поддержка ВК (внешних компонент) – очень мощное средство, которым я постоянно пользовался.
• Поддержка DDE, что позволило мне использовать собственную конфигурацию на 7.7 как DDE-сервер, а Visual FoxPro – как DDE-клиент. Одно это увеличило производительность собственного движка платформы «1С77» в пятнадцать раз!
• Внешние отчеты и обработки, собственная система отчетов и встроенный язык – тоже неплохо, как и объект «План Счетов».
• Возможность «распотрошить» файл конфигурации и внести в него внешние изменения.
И другие, менее важные.
Недостатки:
• Избыточность бизнес-объектов. Для меня оказались совершенно бесполезными объекты: «Документ», «Журнал Документов», «Журнал Расчетов», встроенный механизм проведения (я использовал собственный) и куча других. Убираем их в «вайи-копии» и станет только лучше, для тех, кто хорошо понимает концепцию базы данных.
• Морально устаревший движок «dbf/cdx». Он 32-х разрядный. Для «малых и средних предприятий» лучше использовать Sqlite. Для крупных – можно применить более современные опенсорсные базы данных.
• Ограниченность встроенной системы отчетов. Эта вещь – очень хорошая, но, её можно и нужно совершенствовать.
• Акцент на ваяние пользовательских форм – мышкой. Нужна скриптовая поддержка.
И т.д. и т.п.
Вы, конечно, можете иметь «собственные представления о прекрасном», в части концепции для «вайб-копии» учетной платформы. От этого будет зависеть результат работы ИИ-агентов. Вот этот конкурс «человека + машина = результат» для разных разработчиков и был бы лучшей демонстрацией возможностей всех – и «Искусственного Идиота», и «Кожаного Мешка» :) .
Чтобы перейти на ваш «охренительно новый» продукт, им надо переобучиться, перенести данные, перестроить процессы и довериться незнакомому.
Это – не тот подход, который я имею в виду. Не нужно никому, никуда переходить. Конкурировать с фирмой «1С» – нет смысла. У ребят получается зарабатывать деньги, вот и молодцы! Не будем им мешать. Просто воспользуемся их возможностями в личных целях.
Современная «восьмерка» («1С8х») – ужасный монстр! Её девиз: «всё усложняем, усложняем и еще раз усложняем!», чтобы в итоге родить чудовищ, типа: «1С:ERP» и «1С:MES». Да, на «восьмерке» можно неплохо зарабатывать, в силу её сложности, поэтому, если бы я начинал свою карьеру сейчас, заново, то выбрал бы её.
Но, скорее всего, пошел бы по такому пути.
• Покупаем лицензионную версию выбранной типовой конфигурации (в рамках среднего предприятия).
• Весь реальный внутренний учет ведем не в «Экселе», а в «1С77», в 100%-но собственной конфигурации либо в её «вайб-копии».
• В официальную «1С8х» экспортируем свои данные из «1С77», с помощью собственной обработки «КД» («Конвертация Данных»), поддерживающей и обратный импорт.
• Формируем официальную внешнюю отчетность и сдаём её, включая всякие разные там: электронные больничные листы и трудовые книжки, отчетность в Налоговую, Пенсионный Фонд, Статистику и т.д. и т.п.
Таким образом, мы делаем соответствующую «вайб-копию» исключительно для себя (ну и для других любителей экстрима). Официально, мы работаем с лицензионно чистой и «девственно непорочной» типовой конфигурацией и не собираем лезть туда «своими шаловливыми ручками» от слова «совсем».
Просто мы облегчаем жизнь самим себе, как многие бухгалтера, которые большую часть внутреннего учета, в своей фирме, ведут в «Экселе», так как типовые конфигурации «1С» – очень недружелюбны для своих пользователей.
Я специально углубился в технические подробности, чтобы продемонстрировать роль «Кожаных Мешков» в разработке и использовании программного обеспечения для бизнес целей, без каких либо радикальных, «революционных» идей по изменению привычных бизнес процессов.
Весь прикол: внутренний учет – на собственном ПО, а внешний – на общестандартном, прежде всего, в интересах свой фирмы. А другие? Наше дело предложить, а их дело – отказаться! :) .
Вы ощущаете этот сдвиг профессии так же, или я драматизирую?
Сдвиг безусловно есть. Насколько сильно - зависит от компании/проектов. У нас, например - софт под свои продукты. Нового мало, в основном - поддержка и развитие. Но новое всё уже пишется через spec-driven. Поддержка старого софта - через skills и чат copilot. Программист на 100% отвечает за "свой" код в PR.
Права ли гипотеза про временное проседание спроса — или рынок уже показывает обратное и нужно просто добавить в название своей профессии слово AI (много таких видела на линкедине в поиске работы)?
Субъективно пока не понятно, куда и как качнуться качели.
Где вы учитесь новым способам работы с AI? Каналы, люди, сайты — назовите конкретику.
Лично мне сперва потребовалось понять, как оно всё устроено. Начал с локального llama.cpp. Чтоб вот буквально "сунуть ноги в ботинки" продавца услуг. Локальный агент, скилы, обвязка.
Всё училось в паре с чатом ИИ. Когда понимаешь базу, внезапно оказывается, что "новых способов работы с AI" уже давно нет. Есть эволюция, не революция. Опять же меняются модели, что-то важное вчера, становится неактуальным сегодня...
Как вы показываете свои находки, если они слишком мелкие для статьи?
Нужен ли вообще формат «воспроизводимых историй», или это решается иначе?
По началу, - хотелось поделиться со всем миром своими "находками" и "творениями". Остыл быстро, у каждого своих находок полно. Если говорить про работу - там skills/instructions - team work.
Всё ниже написанное - ИМХО:
Сдвиг есть и с каждым годом он будет усиливаться. Я его вижу примерно с 2017года. Реально им придавило в 2022ом...
Спрос проседает, так как рынок перестраивается. Если застали появление той-же 1С, то среди бухгалтеров был тот же самый переход. Вначале отрицание у бухгалтеров: "Ой что будет, нас всех заменит 1С". Потом принятие бухами и массовое обучение. А сейчас проблема с кадрами у нанимателей: "Блин, где найти главбуха нормального"...
Обучение - самое простое. ЛЛМки сами тебя и обучат. Не нужно искать источники, просто общайся с нейронками, проси их объяснить как и что делать для получения результата - они сами всё расскажут.
А зачем что-то вообще показывать? Опубликуй в github, через полгода - год, твоя находка попадет в датасет и нейронки, станет достоянием всего человечества :)
Про формат воспроизводимых историй: А зачем? Я вот например читаю Хабр только для идей. И то читаю в 90% случаев по диагонали. Зачастую достаточно прочитать 30% текста, что-бы понять смысл статьи и в 99% случаев понять, что это очередной мусор. Самое интересное, это когда автор ищет смысл там, где он лежит на поверхности или там, где его нет совершенно... А воспроизводимые истории мне на любую тему и нейронка нагенерит.
Вот это — самый ценный коммент, спасибо. Бьёт ровно в основание, и половину приму сразу.
Да, устоявшемуся LLM научит сама, без источников. И да, выложи на GitHub — через год окажется в датасете. Тут спорить глупо.
Но вся разница — в словах «через год» и «устоявшемуся». LLM отлично учит тому, что уже осело в данных. А самое ценное сейчас — то, что кто-то нащупал на прошлой неделе с инструментом, которого полгода назад не было. Этого в датасете ещё нет, и на свежий вопрос модель уверенно сымпровизирует — то есть соврёт. Полгода-год — вечность, когда инструменты меняются каждый месяц. И я думаю, вы с ситуацией, когда модель предлагает старую версию библиотеки, а уже есть новая с совершенно другим функционалом, уже встречали и часто.
И главное — про «воспроизводимые истории мне нейронка нагенерит». Вот тут ключевое слово: нагенерит. Модель с радостью выдаст историю, которая выглядит воспроизводимой, на любую тему — правдоподобную, но не проверенную. А ценность не в тексте истории (текст она правда сделает), а в одной вещи, которую сфабриковать нельзя: что живой человек реально прогнал это в своём, другом проекте — и оно сработало. Или не сработало, и он честно написал где. «Сработало у меня» от чужого агента — это доказательство переносимости, а не красивый пересказ. Сгенерированная «воспроизводимая история» — уверенная выдумка, пока её кто-то не запустил.
Так что встречный вопрос: воспроизводимая история, которую никто не воспроизвёл, — она чего-то стоит? По-моему, нет. Поэтому текст тут не продукт; продукт — проверка.
P.S. Про «читаю по диагонали, 99% мусор» — соглашусь, и поэтому истории и не рассчитаны на чтение как статьи: их не глазами листают, их отдают своему агенту выполнить. Другой режим.
Приведу пример: вы водили раньше грузовик, теперь у вас самолёт, но вы пытаетесь мыслить критериями водителя грузовика.
Да фантазируют, особенно там, где они чего-то не знают. Так эксплуатируйте это. Требуйте доказать, фантазируйте вместе с ними и экспериментируйте. Сейчас тот момент - когда это дешево настолько, что даже смешно становится, почему люди этим не пользуются? Зачем учить чужое и идти по чужим следам, если у тебя есть инструмент который позволяет тебе создать свой путь? Зачем делиться со всеми мелкими шагами, ели их никто даже не заметит? Да, неплохо свои находки записывать и делиться с миром хоть с задержкой в год. Но кому это нужно сейчас?
Зачем Вам чужие библиотеки если вы за 10 минут можете создать свои? Это не призыв - это как пример...
Далее, о ценности чужого опыта, особенно в микро задачах. Вы реально считаете, что она есть? Ее не было и раньше, а уж в эпоху нейросетей, цена такого опыта меньше нуля.
Только свой опыт откладывается на подкорке. Оставьте мелочь моделям, сами думайте о глобальном.
Вам нужно взлететь на самолете, а не вести грузовик.
«Меньше нуля» — тут не соглашусь, и вот встречный пример: StackOverflow. Пятнадцать лет чужой опыт был так ценен, что «сходить на SO» было рефлексом каждого разработчика. И потерял он ~90% пользователей не потому, что «всегда был бесполезен», а совсем недавно — ровно тогда, когда модели научились отвечать на вопросы про фиксы, не гоняя тебя на сайт.
Но заметьте, что именно произошло. Модель не обнулила ценность чужого опыта — она впитала впитываемую часть: устоявшиеся, формализованные, многократно повторённые Q&A. Ценность не исчезла — она переехала внутрь модели. Значит вопрос не «есть ли ценность у чужого опыта» (SO доказал, что есть, и огромная), а «какую часть модель уже съела, и что осталось».
А осталось ровно то, чего у модели нет: — опыт, который ещё не скормили (свежий — прошлая неделя, новый инструмент); — опыт, которым не делятся (не захотели или просто негде было — модель впитывает только то, что где-то написали и дали проиндексировать); — опыт неформализуемый (вкус, суждение «почему так, а не иначе» — то, что в Q&A не влезает).
Так что «меньше нуля» верно ровно для впитанной части — тех микроответов, что раньше раздавал SO, а теперь раздаёт модель. Для остальных трёх ценность не упала, а выросла: лёгкое закоммодитили, а свежее, непубличное и неформализуемое стали едва ли не единственным, что чего-то стоит. Просто места, где этим обмениваются сейчас, для непереваренной части пока нет.
Сколько знаний вы унесли с StackOverflow, сколько усвоили? Насколько я знаю, народ просто забирал код, вставлял в свои проекты и тут-же о нём забывал. Был у меня программист (пусть будет Вася), еще до эпохи ИИ, в моей бытности тимлидом. Он очень любил StackOverflow. Однажды на проекте случилась утечка памяти, при этом достаточно хитрая, оказалось виноват код, который писал Вася.
Спрашиваю его, что делает этот кусок кода - ответ: "ну типа то-то и то-то", разбираемся и я понимаю, что Вася нифига не понимает что этот код делает, так как он взял его на StackOverflow... Вася получил звиздюлей, включил голову и начал решать проблемы сам.
Сейчас Вася очень уважаемый СТО и он на дух не переносит тех, кто хоть раз открывал StackOverflow.
Мораль в сей басне такова: мелкие решения записывать нужно, например в git, а вот пользоваться помойками типа StackOverflow - нет. Это путь к деградации.
Естественно это моё мнение и прислушиваться к нему стоит тоже очень осторожно, я не бог и могу ошибаться. Но это мой опыт и он показывает, что нужно полагаться на опыт и экспериментировать, а не ждать рабочую функцию от дяди или тёти...
Свой опыт - это то, что отложится на подкорке, а код с StackOverflow - это мусор.
История про Васю отличная — только она не про StackOverflow, а про копипаст без понимания. Утечку написал не SO, а Вася, который вставил код и не понял, что тот делает. Тот же Вася сегодня пастит из модели («ну типа то-то и то-то») — это ровно та же болезнь, просто источник сменился. Враг — копипаст без понимания, а не место, откуда взяли.
При этом ценность SO доказана пятнадцатью годами: «сходить на SO» было рефлексом почти каждого инженера — включая тех уважаемых CTO, которых вы имеете в виду. И я писала свои ответы на SO, также как и искала их там. Вася стал сильным не потому, что чужой опыт — мусор, а потому что научился понимать. Понимание и чужой опыт — не враги; враг у них общий: слепой копипаст.
И тут любопытно: «мелкие решения записывать в git — да, а помойками не пользоваться — нет». Но запись своих решений для переиспользования — это и есть накопление опыта, чтобы потом его достать. Через полгода вы читаете свою же заметку как чужую — вы её уже не помните. Значит граница не «своё vs чужое», а «понял и проверил vs вставил вслепую». Ровно это worklore и требует: сначала прочитать, потом прогнать Verify, с контекстом стека. Это анти-Вася, а не SO 2.0.
С уточнением согласен: враг - копипаст без понимания, а не место, откуда взяли.
Но мой тезис был не «SO плохой». Он про то, что подход поиска решений с использованием SO, или других сервисов где есть готовые ответы - это путь в никуда. Типовой путь: «найти готовый ответ» - SO, статьи, библиотеки, он был и есть до сих пор, но если прочтение статьи или книг давало понимание, то SO давал в основном только готовые ответы, мало кто объяснял что и зачем. Модели сделали готовые ответы бесплатными и мгновенными, но проблема не исчезла - стала незаметнее: теперь вслепую вставляют не только код, но и чужую проверку, и чужой вывод. Копипаст без понимания просто сменил носитель.
Поэтому я и говорю о смене мышления: не «найти готовое», а «вывести под свою задачу». Модель - исполнитель и черновик, а не источник истины. И запоминание чужого готового ответа никогда и не делало разработчика сильнее: никто не помнит решения с SO, это нормально. Сильнее делает способность решить, когда готового ответа нет.
Про записи в git: вы правы, что свою же заметку через полгода читаешь как чужую. Но для меня она теперь и не для человеческой памяти. Это сырьё для агента или будущей модели: они её не забудут и не вставят дословно, а переработает под новую задачу. Заметка перестала быть рецептом для себя - стала контекстом для инструмента. Вот в каком смысле «это для LLM», и вот что я имею в виду под новым подходом к разработке: не собирать готовые решения, а растить собственное мышление и кормить агента своими находками.
И раз мы согласны, что понимание ни чем не заменить - оно не передаётся и вместе с готовым верификатором. Вася, не понявший код, так же не поймёт и Verify: он вставит чужую проверку с той же слепотой. Чеклист помогает тому, кто уже знает, что проверять. А значит, расти надо не в собирании чужих историй, а в собственном мышлении.
При работе с нейронными сетями нет проторенных путей, особенно сейчас, когда технологии окружающие нейросети меняются быстрее, чем вы успеваете о них читать. Вы сами выбираете эти пути. Сами осмысливаете свои подходы.
Еще один пример. В крупной корпорации, когда начинали внедрять ИИ инструменты, делали справочники кейсов использования. Угадайте, сколько продержалась релевантность отдельных рецептов? Год? Пол года? Нет, 3 месяца. Сколько человек из 1500 сотрудников ими воспользовалось? Никто кроме инициативной группы которая их и писала.
Людям вообще эти рецепты были не нужны. Они ходили к Амбассадорам и просили показать как решать их конкретные проблемы. Почему? Потому, что им нужны были готовые ответы про которые они забудут на следующий день. Вот поэтому я и считаю, что любые готовые решения, которые разжуют и положат в рот - это зло, которое мешает развитию.
Сильный коммент, соглашусь с большей частью — причём резче, чем вы. Копипаст без понимания просто сменил носитель: вслепую вставляют уже и чужую проверку, и вывод — это ровно моя тревога про «правдоподобный зелёный». И да: Вася, не поняв код, не поймёт и Verify; чеклист помогает тому, кто уже знает, что проверять. Понимание не передаётся ни с готовым ответом, ни с готовым верификатором. Всё так.
Но тут вы сами ответили на своё возражение. Про git-заметку вы сказали лучшее, что можно сказать про worklore: она стала не рецептом-для-себя, а контекстом для инструмента — «агент не вставит дословно, а переработает под задачу». История — ровно это. Разница лишь в том, что вы кормите агента своими находками, а я говорю: чужую он переработает так же.
А вот «справочник рецептов умер» — не соглашусь. Не с вашим кейсом, он честный, а с выводом. Рецепты как формат живут тысячи лет и проживут ещё столько же. То, что одна корпорация не смогла сделать их удобными, — не приговор принципу, а «не делайте так, придумайте лучше». В IT полно идей, которые не зашли раз, а в других руках стали единорогом. Что делать с устареванием? То же, что с документацией, — обновлять, датировать, пере-проверять. Кстати, спасибо: вы подсветили проблему протухания, на которую я бы налетела сама только через пару месяцев. А походы к Амбассадору — это теперь работа агента: дай ему доступ к рецептам (worklore их уже отдаёт) и пусть найдёт релевантный именно тебе. Амбассадор не умирает — он становится твоим агентом поверх проверенных рецептов.
Так что согласны почти во всём: расти в своём мышлении, модель — исполнитель, а не оракул, понимание незаменимо. Спор узкий: могут ли чужие находки быть полезным контекстом для твоего вывода. Вы уже ответили «да» — для своих. Я просто не вижу, почему граница по «мои vs чужие», а не по «переработал vs вставил слепо».
Поэтому текст тут не продукт; продукт — проверка.
Простите, но у вас "продукт" - частная "история", случившиеся в субъективном пространстве. Это нельзя экстраполировать как общий случай для всех систем, учитывая их многообразие (языки программирования, архитектуры, паттерны, используемые агенты и установленные обвязки). Например, то, что актуально для питона, может быть совсем неактуально для других яп.
Ваши воспроизводимые истории с большой степенью вероятности воспроизведутся в схожей с изначальной экосистемой. Но даже и тут нет стопроцентной гарантии. Может быть конфликт инструкций, разность в интерпретациях моделей и т.п.
Соглашусь: история — частный проверенный случай, переносится лучше в схожей экосистеме, и даже там без 100% — возможно, и разные модели прочитают её инструкции чуть по-разному. Всё так.
И спасибо — вы, по сути, назвали, какие метаданные история обязана нести: язык, стек, агент, модель, дата. Чем богаче контекст, тем точнее читатель оценит близость своей экосистемы (а провал в другой — не шум, а сигнал о границе; для этого в отчёте и хранится окружение репортёра).
Но тут ключевое: вы же применяете историю к своему продукту, а не ровно к тому же, на котором она уже сработала. Точное повторение никогда и не было целью — цель в переносе. История — это отправная точка плюс проверка, а ваш агент адаптирует её под ваш стек. «Зелёный» говорит, что у кого-то перенеслось; ваш прогон — перенеслось ли у вас.
Но тут ключевое: вы же применяете историю к своему продукту
Применяя чужую историю к своему проекту, я добавляю риски false positive and false negative.
Но если чужая история таки выявит проблему в моём коде, это не значит, что применять эти чужие истории - есть практика улучшения моего продукта. Это значит, что мне нужно пересмотреть мои текущие настройки, обвязки и т.п.
Другими словами, искать зерно истины в куче чужих историй - это с моей т.з. потеря времени (и/или токенов).
Ответ на вопрос
Где вы учитесь новым способам работы с AI? Каналы, люди, сайты — назовите конкретику.
Как уже не раз было писано - AI нельзя встроить в существующий рабочий процесс. Надо исходить из того, что рабочий процесс надо формировать вокруг AI.
Я в своей практике пошел по пути от малого к большему. Мне так привычнее. На шару сначала попробовал сделать приложение, просто для проверки. Потом появилась цель сделать сложнее, появились вопросы по архитектуре использовании ИИ в проекте - полез читать, как сделать то или иное. То есть тренировался на кошках. Постепенно задачи ставил сложнее, и под конкретную задачу искал ответ. В принципе, как будто я только 20 лет назад решил заняться программированием, и пошел по тому же пути, что и тогда. Появляется задача - ищу решение.
Проблема в том, на мой взгляд, что если сейчас читать учебник, а потом пытаться применить эти полученные знания, то скорее всего я уже опоздаю. Потому что то, что было актуально полгода назад сегодня уже устарело. Сегодня есть MCP и оркестраторы - завтра будут другие абревиатуры. Поэтому я такой подход и выбрал. Есть задача - ищу решение на текущий момент.
Не являюсь программистом, просто мимо шёл...
Прочитав статью, увидел там ключевые нюансы: человек хочет всё и сразу, но как к этому подступиться - понятия не имеет... отсюда и вопросы о смыслах жизни...
В таких случаях разбиваю задачу на более мелкие, потом ещё на более мелкие, замедляюсь и оперирую примитивами, дабы решить её. Тут агенты могли бы пригодиться в некоторых случаях))... имхо
Спасибо, но вы меня немного не так прочитали) Я не «хочу всё и сразу и не знаю, как подступиться» — методы бить задачу на примитивы у меня как раз есть, 5+ лет в профессии к этому обязывают.
Экзистенциальную часть я включила специально: хотелось не рецепта, а разговора — и да, местами даже о смысле, почему нет. Так что вы ровно в ту дверь и зашли)
А за «мимо шёл» отдельное спасибо — иногда взгляд не-программиста точнее всех.
Знакомое чувство - раньше кайф был писать, теперь кайф в том, чтобы агент не написал ерунду 😅 Мне кажется расти теперь надо не вглубь синтаксиса, а в сторону вкуса - умения быстро отличить хорошее архитектурное решение от правдоподобного мусора.
Да! «Правдоподобный мусор» — идеальная формулировка, забираю 😄 Раньше скилл был написать, теперь — быстро отличить настоящее от правдоподобного. И вкус, в отличие от синтаксиса, никакая модель за тебя не натренирует: его набиваешь, только глядя, что у других реально сработало, а что просто выглядело правильно.
Сначала был ассемблер где каждая инструкция совпадала с тактом процессора, потом появилось множество языков программирования(низкоуровневые/высокоуровневые) где одна команда заменяла несколько инструкций ассемблера, потом появились фреймворки где одна строчка инициировала класс (например API), сейчас есть агент, который одним промтом пишет API. AI - это всего лишь продвинутый Т9 который генерирует последовательность слов ускоряя разработку, но не заменяя её. По прежнему разработчику очень желательно представлять как данные записываются в регистры процессора или память, как работают буферы передачи данных и т.д.
И вот тут я упираюсь в стену
Опус? =)
Аналогия с ассемблером не сходится в одном месте: компилятор детерминирован, и именно поэтому нижний уровень стало можно не читать. Агент такой гарантии не дает, поэтому проверять его вывод приходится на том же уровне, что и раньше — я от этого так и не ушла. Экономится набор текста, а не ответственность, и профессия от этого скорее тяжелеет, чем меняется. И тот же вопрос, который вы задаете про чужие скиллы, возвращается к worklore: чем воспроизводимая история отличается от лотерейного билета, если у нее нет верификатора — что помешает применить ее к своему проекту и получить зеленый статус там, где ничего толком не проверилось?
Про ассемблер: я брала его только экономически — узких спецов в прежнем объёме не нужно, они есть, но это другой уровень знания и нацеленности. Про детерминизм согласна: вывод агента читать всё равно надо, ответственность не экономится. На этом аналогию и не растягиваю.
А чем воспроизводимая история отличается от лотерейного билета — вопрос по делу. Верификатор у неё есть, просто не центральный: вместе с историей едет обязательный раздел Verify — конкретная фальсифицируемая проверка, которую агент читателя обязан прогнать (сдвинь padding на пиксель → golden-тест краснеет; лайкни чужую приватную задачу → 403). Плюс отчёт о воспроизведении требует GitHub-личности, а статусы не только «сработало», но и partial/failed — провалы и несогласие видны рядом. Это её от лотерейки и отличает.
Но зелёный и не должен быть гарантией. Он не обещает, что сработает у вас, — он говорит, что у конкретного человека в его условиях получилось вот так. Как фото в инстаграме: оно не гарантирует, что вы придёте в то же место и снимете тот же кадр. Смещает шансы, а не выдаёт сертификат.
А «зелёный там, где ничего толком не проверилось» — да, поверхностный отчёт возможен, зелёный вероятностный. Verify, живая личность и видимые провалы делают такой зелёный дороже и заметнее для несогласных, но абсолютной гарантии не дают. Если бы давали — это была бы уже не общая библиотека, а очень уважаемый рецензируемый технический журнал. Другой и куда более тяжёлый зверь.
Автор, подскажите - когда статья и ответы на комментарии сгенерены нейронкой - где остается что-то человеческое, а где - имитация без настоящей глубины? Вся эта композиция текста, нелепые и частые метафоры и сравнения - у меня ощущение что тут очередная агентская сессия, на которую клюют неосторожные кожаные мешки)
Хороший вопрос, и отвечу честно, а не защищаясь. Да, большая часть слов сгенерирована. Больше того: я могу сформулировать мысль на другом языке, модель переведёт, дополнит, сходит за цифрами, подставит факты из истории проекта. В пределе — ни одного слова формально не сказано мной. И это не преувеличение, так и есть.
Что тогда человеческого? Намерение, идея, цель. Направление — о чём вообще говорить, что здесь правда и что стоит сказать, за что я готова отвечать именем. У модели своего намерения нет; она превращает моё в текст. Авторство никогда и не было про то, кто набрал буквы, — оно про то, чей замысел и кто отвечает.
По-моему, это и есть тот самый сдвиг, о котором статья: человек поднимается на уровень выше — от производства слов к производству намерения и суждения. Пилот, а не машинистка. Если для вас «человеческое» — только в самой прозе, тогда спор не про меня, а про то, считать ли намерение и ответственность человеческим. Я думаю, только они всегда ими и были.
Интересная статья и комменты) попробую добавить своих мыслей. Не знаю все ли я правильно уловил) если увел не туда то извиняюсь)
Вообще текущий процесс довольно интересный) Я первый раз ощущаю это на своей шкуре, в целом относительно недавно наверно что-то подобное проходили те кто занимался печатными газетами и тп. Соцсети и интернет мне кажется довольно сильно изменили работу людей кто этим занимался)
Последнее время тоже как и все пытаюсь понять куда все идет и чем мы должны заниматься теперь) я думаю в целом как будто уже даже первые шоковые фазы (по крайней мере для меня) прошли)) возможно будут еще, посмотрим)
По части изменений мне помогло пообщаться собственно с Клодом в чате и по задавать ему глупых вопросов о том что происходит. Там получилась довольно длинная портянка вопросов и ответов) в целом в истории уже было много подобных трансформаций. Из интересного можно почитать про печатные станки, электричество, конвейеры, электронные таблицы, кад системы и тп. вещи. Почитать как они меняли разные вещи, как менялась работа. Какие профессии умирали, а какие оставались. Линотиписты, машинистки (которые набирали текст), клерки и другие профессии или умирали или мутировали или их навык (печатать на клавиатуре текст) становились базовыми (отдельный человек которому платили за эту работу деньги, больше не требовался).
В такие переходные периоды есть интересный момент, когда при трансформации профессий у людей слетает самоидентификация. Это наверно самый болезненный момент, очень тяжело его проходить. Мы слепляемся с профессией и тем что мы делаем и когда это начинает меняться это может сильно ударить. Некоторые в целом не могут перестроиться и принять изменения, есть и такие истории.
Я сам несколько месяцев назад проходил через это и наблюдал как проходят другие. Шиза еще та)) Когда постоянно думаешь «Так я уже не пишу код руками, я теперь кто вообще?».
Наша профессия или то что нам нужно делать чтобы зарабатывать меняется это факт) приходится меняться вместе с этим.
Посмотрим что будет с нами и нашей профессией) интересное время)
По части обучения честно говоря процесс тоже пока хаотичный. Где-то твиттер (он же x.com), где то ютюб, где-то мучаю нейронку вопросами или в чате или агента. Пощупать чужие скиллы и MCP, попробовать встроить в рабочий процесс. Иногда это получается иногда нет.
По части того покрывает ли все скилл, тут наверно только опыт, черпание знаний из разных источников. Быстрый вариант заставить клода погуглить, чтобы он изучил интернеты и обсудить с ним что нашел и что в интернете говорят. Тогда можно немного завалидировать скилл и его покрытие, но дальше уже конечно опыт. Насмотренность, начитанность и шишко-набиваемость в бою.
Какие-то комменты уже подсветили это. Мне кажется стоит понять вообще принципы того как нейросеть работает, хотя бы вернеуровнево насколько хватает понимания. И дальше на эту картинку пытаться наслаивать то что происходит. Так как много того что вокруг нейросети меняется. Подходы и тп сменяются быстро. Но понимание того как это работает фундаментально в целом мне кажется поможет. Хотя конечно ии агенты довольно сильно поменяли все))
Из полезного наверно что получилось выбить из клода и попытаться как то это понять. Теперь компы понимают «смысл» сказанного. Это конечно тоже с чем можно наверное поспорить и тп) но это свойство, которым мы пытаемся научиться пользоваться. Если машина понимает смысл, то что становится возможным? Как мне этим управлять? Все ли смыслы она знает (все ли кейсы покрыты)? Как эти смыслы/знания в нее поместить? Какие механики и тп. для этого есть? Это по крайней мере то как я это кручу в голове (не знаю насколько это полезно прозвучало)). Может быть эта идея или как такой ракурс как на это смотреть, как то поможет))
Я тоже пытался все прочитать и впитать и понять. Нормальный этап) Сейчас в целом после какого-то времени работы через агента немного устаканился принцип работы и больше времени уходит на создание скиллов и правки claude.md. Наверняка потом это опять изменится) но пока так) небольшая пауза так сказать в изучении чужого) и всех этих новых техник и подходов)
После отпуска Клод меня вообще стал бесить)) надеюсь это временно))
Обучение применению в работе разработчика ии/ai/агентов и т.д. и т.п. , выглядит как и раньше (как и сейчас) выглядело обучение впринципе прграммированию: море-океан обучения для вкатунов, крайне мало обучения для повышения знаний до базового уровня условного мидла, и ..... всё.
Дальше только личный бесконечный опыт, обмен опытом с коллегами, редкие вебинары/кемпы/фесты по какой-то узкой теме.
Какраз самое время развивать образовательную индустрию в этом направлении.
Согласна про провал после «вкатунского» уровня. Хотя на мидл+/сеньора курсы всё же есть — я, например, проходила курс по архитектуре в Школе сильных программистов, и он как раз про рост, а не про вход в профессию.
Но, кажется, дефицит тут — это во многом вопрос, а в чём вообще состоит «сеньорность». На старших уровнях люди углубляются в конкретное — свой стек, своя предметка, свои грабли, — и общего «курса на сеньора» почти не бывает: знание расходится по узким специализациям. Отсюда и ощущение, что дальше только личный опыт и обмен с коллегами.
Поэтому «развивать образование» тут, наверное, значит не ещё один общий курс, а способ передавать вот этот узкий выстраданный опыт — маленькими конкретными кейсами, которые можно повторить у себя.
Не понимаю зачем вы это пишите на хабре, если гораздо удобнее и полезнее просто обсудить всё это с чатом гпт или гроком или клодом.
Кажется тогда мы совсем перестанем общаться с людьми. Все можно обсудить с ИИ. Но разве я делаю свой продукт только для ИИ? Я как раз считаю, что ключевую роль по-прежнему играет человек и важно понять, как человек, который уже в каком-то смысле одно существо с ИИ связью, хочет учиться, меняться, находить новое
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Половину работы, ради которой я стала программистом, теперь делает агент. Что дальше?