Forwarded from Этихлид
Claude 4, обзор
Прошло несколько дней работы с Claude 4, так что можно сказать пару слов.
Если вкратце, то для меня теперь выбор моделей для разработки выглядит так:
Sonnet 4
● если нужно подёргать много тулов (полазить по проекту, вызвать MCP, просто задачи вида "запускай тесты и фикси багидо посинения, пока всё не исправишь")
● задачи, для которых отсутствует заранее подготовленный контекст или его просто лень собирать :)
● небольшие повседневные задачи, где не нужно много думать
● веб-разработка
Gemini 2.5 Pro
● все задачи, где нужен длинный контекст
● иии... почти все остальные задачи
o3
● случаи, когда нужен чистый ризонинг
Переход с других моделей на Claude 4
● с Sonnet 3.7 - однозначно переходить:
* изменения в коде стали точнее
* лучше следует инструкциям и держит контекст
* менее упорот - иногда всё-таки делает то, что не просят, но намного реже
* новый cutoff - конец января 2025
● с Gemini 2.5 Pro - как минимум, стоит попробовать на своих задачах:
* лучше использует тулы
* структурнее подходит к решению задач
По поводу Opus 4: хорошо кушает токены и, как следствие, деньги (у меня $1/мин уходило в нескольких тестах).
Если у вас есть Claude Max, где не нужно платить за токены, то Opus можно использовать для сложных задач вместо Sonnet 4, а также в сценариях, когда нужно что-то долго делать с активным использованием тулов в процессе.
Далее в основном буду говорить про Sonnet.
Бенчмарки
Если приглядеться к числам на "хардовых" бенчмарках, то выглядит так себе - от мажорного релиза ожидалось большего.
По многим из них новый Sonnet несильно отличается от прошлого 3.7, а местами даже хуже.
Но на паре результаты всё-таки неплохие:
● MultiChallenge - стабильность работы в многоходовых диалогах с людьми
● Recall on Codebase Questions - метрика от Cursor, про которую ничего, кроме названия, неизвестно - будем считать, что это "доля правильных ответов на вопросы по кодовой базе при её исследовании в режиме агента"
И это подводит нас к следующему пункту:
В чём же хорош Claude 4?
Anthropic в анонсе много говорили именно про использование новых моделей в агентских сценариях и их интеграции в соответствующий инструментарий (например, в Claude Code & Claude Desktop).
И да, это у них вполне получилось - модели действительно очень хорошо работают с разными тулами и тащат длинные задачи (Opus у самих Anthropic работал до 7 часов, а на Reddit был результат в 40+ минут от пользователя).
За счёт этого они в реальной работе оказываются лучше, чем можно было бы предположить, смотря лишь на "хардовые" бенчмарки.
Потенциал Claude 4 не раскрыть в окружении, где нет тулов - у неё просто не так много других способностей, по которым бы её не обходили модели конкурентов.
Особенности
● охотнее сама строит планы для задач и потом их придерживается
● чаще делает какие-то временные скрипты для тестирования, проверки своих гипотез и т.п. Если нет нужного инструмента - сделай его :)
Иногда она их удаляет по завершению задачи, но чаще оставляет в проекте, приходится вычищать.
Anthropic даже в своём Claude 4 prompt engineering best practices добавили секцию о том, как такое поведение ограничить
● помните, что модель стала делать меньше делать то, что не просят?
Так вот, можно наоборот попросить уйти в отрыв:
Проблемы
● доступность API - это уже стало особенностью Anthropic, что в моменты пиковой нагрузки отваливаются запросы, инференс тормозит и вообще работать невозможно
● всё ещё может ходить кругами при решении проблем, хоть и реже - почему-то именно линейка Sonnet этим выделяется
● смайлики проникли и в Sonnet - ощущение иногда, что с ChatGPT 4o общаешься :)
Заключение
Противоречивый релиз, конечно, вышел.
Anthropic явно сфокусировались на определенных нишах - агентские системы и кодинг, - уйдя от построения моделей общего назначения (возможно, в силу ограниченности ресурсов на фоне конкурентов).
Посмотрим, к чему это их приведёт в перспективе, ну а пока что для Sonnet 4 у меня явно найдётся работа :)
#ai #model #review
Прошло несколько дней работы с Claude 4, так что можно сказать пару слов.
Если вкратце, то для меня теперь выбор моделей для разработки выглядит так:
Sonnet 4
● если нужно подёргать много тулов (полазить по проекту, вызвать MCP, просто задачи вида "запускай тесты и фикси баги
● задачи, для которых отсутствует заранее подготовленный контекст или его просто лень собирать :)
● небольшие повседневные задачи, где не нужно много думать
● веб-разработка
Gemini 2.5 Pro
● все задачи, где нужен длинный контекст
● иии... почти все остальные задачи
o3
● случаи, когда нужен чистый ризонинг
Переход с других моделей на Claude 4
● с Sonnet 3.7 - однозначно переходить:
* изменения в коде стали точнее
* лучше следует инструкциям и держит контекст
* менее упорот - иногда всё-таки делает то, что не просят, но намного реже
* новый cutoff - конец января 2025
● с Gemini 2.5 Pro - как минимум, стоит попробовать на своих задачах:
* лучше использует тулы
* структурнее подходит к решению задач
По поводу Opus 4: хорошо кушает токены и, как следствие, деньги (у меня $1/мин уходило в нескольких тестах).
Если у вас есть Claude Max, где не нужно платить за токены, то Opus можно использовать для сложных задач вместо Sonnet 4, а также в сценариях, когда нужно что-то долго делать с активным использованием тулов в процессе.
Далее в основном буду говорить про Sonnet.
Бенчмарки
Если приглядеться к числам на "хардовых" бенчмарках, то выглядит так себе - от мажорного релиза ожидалось большего.
По многим из них новый Sonnet несильно отличается от прошлого 3.7, а местами даже хуже.
Но на паре результаты всё-таки неплохие:
● MultiChallenge - стабильность работы в многоходовых диалогах с людьми
● Recall on Codebase Questions - метрика от Cursor, про которую ничего, кроме названия, неизвестно - будем считать, что это "доля правильных ответов на вопросы по кодовой базе при её исследовании в режиме агента"
И это подводит нас к следующему пункту:
В чём же хорош Claude 4?
Anthropic в анонсе много говорили именно про использование новых моделей в агентских сценариях и их интеграции в соответствующий инструментарий (например, в Claude Code & Claude Desktop).
И да, это у них вполне получилось - модели действительно очень хорошо работают с разными тулами и тащат длинные задачи (Opus у самих Anthropic работал до 7 часов, а на Reddit был результат в 40+ минут от пользователя).
За счёт этого они в реальной работе оказываются лучше, чем можно было бы предположить, смотря лишь на "хардовые" бенчмарки.
Потенциал Claude 4 не раскрыть в окружении, где нет тулов - у неё просто не так много других способностей, по которым бы её не обходили модели конкурентов.
Особенности
● охотнее сама строит планы для задач и потом их придерживается
● чаще делает какие-то временные скрипты для тестирования, проверки своих гипотез и т.п. Если нет нужного инструмента - сделай его :)
Иногда она их удаляет по завершению задачи, но чаще оставляет в проекте, приходится вычищать.
Anthropic даже в своём Claude 4 prompt engineering best practices добавили секцию о том, как такое поведение ограничить
● помните, что модель стала делать меньше делать то, что не просят?
Так вот, можно наоборот попросить уйти в отрыв:
Don't hold back. Give it your all.
- это из того же гайда по промптингу Claude 4 :)Проблемы
● доступность API - это уже стало особенностью Anthropic, что в моменты пиковой нагрузки отваливаются запросы, инференс тормозит и вообще работать невозможно
● всё ещё может ходить кругами при решении проблем, хоть и реже - почему-то именно линейка Sonnet этим выделяется
● смайлики проникли и в Sonnet - ощущение иногда, что с ChatGPT 4o общаешься :)
Заключение
Противоречивый релиз, конечно, вышел.
Anthropic явно сфокусировались на определенных нишах - агентские системы и кодинг, - уйдя от построения моделей общего назначения (возможно, в силу ограниченности ресурсов на фоне конкурентов).
Посмотрим, к чему это их приведёт в перспективе, ну а пока что для Sonnet 4 у меня явно найдётся работа :)
#ai #model #review
👍14❤1
Началась конференция
AI Engineer World's Fair 2025 - обещают кучу интересного про AI в разработке. Спикеры из Microsoft, OpenAI, Neo4j и еще из кучи топ компаний.
Онлайн трансляция тут: https://youtu.be/z4zXicOAF28
AI Engineer World's Fair 2025 - обещают кучу интересного про AI в разработке. Спикеры из Microsoft, OpenAI, Neo4j и еще из кучи топ компаний.
Онлайн трансляция тут: https://youtu.be/z4zXicOAF28
YouTube
AI Engineer World's Fair 2025 - Day 1 Keynotes & MCP track ft. Anthropic MCP team
full schedule here: https://ai.engineer/schedule
thanks @yashgargk for timestamps:
0:00:00 - start
0:15:15 - Welcome to AI Engineer - Laurie Voss (LlamaIndex)
0:22:17 - Designing AI-Intensive Applications - Shawn Wang (Latent Space)
0:35:46 - Spark to …
thanks @yashgargk for timestamps:
0:00:00 - start
0:15:15 - Welcome to AI Engineer - Laurie Voss (LlamaIndex)
0:22:17 - Designing AI-Intensive Applications - Shawn Wang (Latent Space)
0:35:46 - Spark to …
👍7
Forwarded from The AI Architect | AI Coding
Тёмная сторона вайб-кодинга
Эта история не имеет ничего общего с реальностью. Весь рассказ является плодом воображения автора.
Сегодня хочу рассказать про один серьёзный случай.
Есть у нас один хороший клиент Джон, который заказывал у нас уже несколько проектов. И вот, он попросил помощи в очередном своём проекте. Надо уточнить, что с появлением AI, Джон стал активным пользователем этого всего и очень сильно пытается создавать продукты самостоятельно, хотя, в программировании он не разбирается совсем. Рефат уже как то рассказывал про то, как Джон создавал mvp из палок и продавал это клиентам. Так вот, насколько я знаю по легенде, у Джона был свой проект, но он был недостаточно хорош, и Джону захотелось переписать его с нуля, изменив даже бренд.
Я получил доступ к репозиторию на Github и Google Doc с названием "PRD" с целью изучения этого и оценки насколько сложно будет передать этот проект нам на доработку.
Далее, я расскажу про свои впечатления от знакомства с этим репозиторием.
За 3 недели он успел настрогать 465 коммитов в репу, 35к loc Typescript, но большинство коммитов состояли из "Deployed your application" или из двух изменений в tailwindcss в одном файле❤️
Вот список инструментов, которые пробовал Джон, судя по репозиторию: Replit, Claude Code, Google Jules, Semgrep (какой-то AI AppSec Engineer)
Судя по истории коммитов, Джон делал скриншоты экрана (они сохранились в истории) и описывал где что не так прямо в окно чата. Причём, я думаю, что описывал он эти задачи именно голосом😎
Джон красавчик, в своем возрасте (он довольно взрослый мужчина) он сумел разобраться в новомодных приблудах.
Но есть несколько но:
🔺 репозиторий представляет из себя монорепу с мешаниной файлов. Хорошо хоть разграничил client от server. Правда, в папке server скинуты в одну кучу сразу все файлы (на бэкенде express.js), а на фронте файлы разложены по папочкам components, hooks, lib и т. д. — видно, что гайдлайны nextjs повлияли
🔺 есть закоммиченный .env с кредами от облачной модной БД neon.tech. Закоммитил Replit
🔺 есть закоммиченный файлик с интересным названием private.key. Его закоммитил Replit
🔺 есть license key от одного пропиетарного софта, который захардкожен прямо на стороне клиента. Закоммитил Claude Code.
🔺 в этом коде его логин и пароль от ERP (хоть и тестовый контур, но всё же) встречается 12 раз в 12 разных файлах. Я проверил, эти креды закоммитил Claude Code
Вишенка на торте — репозиторий публично открыт🤯 😦
Вторая — сфера работы Джона, отнюдь не инфоцыганство, а серьёзная сфера, по регулирующим законам которой, могут произойти серьёзные последствия, если сикреты из этого репозитория утекут не в те руки.
Vibe coding in a nutshell💪
Мы уже сообщили Джону, что он допустил ошибку. Он закрыл репозиторий и сбросил опубликованные креды.
Какие выводы можно сделать из этого случая?
Даже если вы офигенный эксперт в своей доменной зоне и AI даёт вам буст, то всему есть предел, об этом стоит помнить и понимать свои границы.
Из-за огромного хайпа в мире, AI может причинить большие убытки. Пожалуйста, доверьте работу с кодом профессионалам. Особенно, если в вашей сфере есть злые регуляторы. Да, мы тоже будем использовать AI coding tools, но мы понимаем как должен выглядеть результат.
Ну и монетка в копилку новомодных coding agents. Как бы создатели не старались, но пользователь всё ещё может выстрелить себе в ногу, даже в две:
- агенты почему-то не проверяют коммиты на наличие кредов в них
- агенты не проверяют, что репозиторий публично открыт и в нём находятся сикреты
Эта история не имеет ничего общего с реальностью. Весь рассказ является плодом воображения автора.
Сегодня хочу рассказать про один серьёзный случай.
Есть у нас один хороший клиент Джон, который заказывал у нас уже несколько проектов. И вот, он попросил помощи в очередном своём проекте. Надо уточнить, что с появлением AI, Джон стал активным пользователем этого всего и очень сильно пытается создавать продукты самостоятельно, хотя, в программировании он не разбирается совсем. Рефат уже как то рассказывал про то, как Джон создавал mvp из палок и продавал это клиентам. Так вот, насколько я знаю по легенде, у Джона был свой проект, но он был недостаточно хорош, и Джону захотелось переписать его с нуля, изменив даже бренд.
Я получил доступ к репозиторию на Github и Google Doc с названием "PRD" с целью изучения этого и оценки насколько сложно будет передать этот проект нам на доработку.
Далее, я расскажу про свои впечатления от знакомства с этим репозиторием.
За 3 недели он успел настрогать 465 коммитов в репу, 35к loc Typescript, но большинство коммитов состояли из "Deployed your application" или из двух изменений в tailwindcss в одном файле
Вот список инструментов, которые пробовал Джон, судя по репозиторию: Replit, Claude Code, Google Jules, Semgrep (какой-то AI AppSec Engineer)
Судя по истории коммитов, Джон делал скриншоты экрана (они сохранились в истории) и описывал где что не так прямо в окно чата. Причём, я думаю, что описывал он эти задачи именно голосом
Джон красавчик, в своем возрасте (он довольно взрослый мужчина) он сумел разобраться в новомодных приблудах.
Но есть несколько но:
🔺 репозиторий представляет из себя монорепу с мешаниной файлов. Хорошо хоть разграничил client от server. Правда, в папке server скинуты в одну кучу сразу все файлы (на бэкенде express.js), а на фронте файлы разложены по папочкам components, hooks, lib и т. д. — видно, что гайдлайны nextjs повлияли
🔺 есть закоммиченный .env с кредами от облачной модной БД neon.tech. Закоммитил Replit
🔺 есть закоммиченный файлик с интересным названием private.key. Его закоммитил Replit
🔺 есть license key от одного пропиетарного софта, который захардкожен прямо на стороне клиента. Закоммитил Claude Code.
🔺 в этом коде его логин и пароль от ERP (хоть и тестовый контур, но всё же) встречается 12 раз в 12 разных файлах. Я проверил, эти креды закоммитил Claude Code
Вишенка на торте — репозиторий публично открыт
Вторая — сфера работы Джона, отнюдь не инфоцыганство, а серьёзная сфера, по регулирующим законам которой, могут произойти серьёзные последствия, если сикреты из этого репозитория утекут не в те руки.
Vibe coding in a nutshell
Мы уже сообщили Джону, что он допустил ошибку. Он закрыл репозиторий и сбросил опубликованные креды.
Какие выводы можно сделать из этого случая?
Даже если вы офигенный эксперт в своей доменной зоне и AI даёт вам буст, то всему есть предел, об этом стоит помнить и понимать свои границы.
Из-за огромного хайпа в мире, AI может причинить большие убытки. Пожалуйста, доверьте работу с кодом профессионалам. Особенно, если в вашей сфере есть злые регуляторы. Да, мы тоже будем использовать AI coding tools, но мы понимаем как должен выглядеть результат.
Ну и монетка в копилку новомодных coding agents. Как бы создатели не старались, но пользователь всё ещё может выстрелить себе в ногу, даже в две:
- агенты почему-то не проверяют коммиты на наличие кредов в них
- агенты не проверяют, что репозиторий публично открыт и в нём находятся сикреты
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🔥4❤1😁1
The AI Architect | AI Coding
Тёмная сторона вайб-кодинга Эта история не имеет ничего общего с реальностью. Весь рассказ является плодом воображения автора. Сегодня хочу рассказать про один серьёзный случай. Есть у нас один хороший клиент Джон, который заказывал у нас уже несколько…
Весьма показательная история. Справедливости ради только отмечу, что для совсем не инженеров, которые очень хотят быстрый MVP, все-таки больше подходят такие решения, как lovable.dev и bolt.new - во всяком случае, они хоть как-то пытаются проблемы c секьюрити решать.
Ну, и, конечно, всегда стоит помнить о возможности хотя бы взять часовую консультацию у эксперта-разработчика на том же getmentor.dev (некоммерческий проект) - всяко дешевле выйдет, чем потенциальные потери от утечки ваших ключей.
Ну, и, конечно, всегда стоит помнить о возможности хотя бы взять часовую консультацию у эксперта-разработчика на том же getmentor.dev (некоммерческий проект) - всяко дешевле выйдет, чем потенциальные потери от утечки ваших ключей.
Lovable Documentation
Security - Lovable Documentation
Security features in Lovable
👍5
Бесплатный Lovable: Самое время нагенерить MVP по своим идеям
В эти выходные (до воскресенья 23:59 CET) Lovable.dev дает неограниченный бесплатный доступ к своему сервису - это значит, что каждый может накодить PoC/MVP своих идей без ограничений на кол-во запросов. Убедитесь только, что вы выбрали OpenAI/Anthropic или Gemini в выпадающем списке (подозреваю, что лучше всего результаты будут у Anthropic и Gemini).
А делается это все в рамках батла AI Showndown. Следим за результатами)
Делитесь, кстати, ссылками на свои поделки и своим мнением о Lovable в комментариях.
В эти выходные (до воскресенья 23:59 CET) Lovable.dev дает неограниченный бесплатный доступ к своему сервису - это значит, что каждый может накодить PoC/MVP своих идей без ограничений на кол-во запросов. Убедитесь только, что вы выбрали OpenAI/Anthropic или Gemini в выпадающем списке (подозреваю, что лучше всего результаты будут у Anthropic и Gemini).
А делается это все в рамках батла AI Showndown. Следим за результатами)
Делитесь, кстати, ссылками на свои поделки и своим мнением о Lovable в комментариях.
❤9🔥6🤔1
2025-06-24_22-48-49.png
341.1 KB
Может ли AI находить сложные ошибки в коде целых проектов?
У меня в канале много дотнетчиков (спасибо Жене @epeshkblog, Саше @dotnetmore, Кириллу @csharp_gepard и Леше @itbeard) и многие из вас наверняка помнят популярный вопрос с собеседований про GetHashCode) Следующий кейс как об этом.
Есть расхожее заблуждение о том, что LLM все еще слишком глупы для того, чтобы находить ошибки в коде проектов. Особенно когда речь идет о больших и сложных кодовых базах.
В действительности же нейросети развиваются каждый день, и чтобы GenAI тулинг смог находить даже сложные ошибки в коде, в сущности, необходимы всего 2 составляющие:
1. Мощная LLM с возможностью размышлений (reasoning, thinking). Например, наши внутренние бенчмарки показывают, что самыми внимательными к багам являются модели Gemini 2.5 Pro и OpenAI o3.
2. Релевантный контекст. Важно находить золотую середину между избыточным контекстом и недостаточным контекстом. В случае если в LLM поступает лишний контекст, она просто с большей вероятностью в нем запутается и качество ревью упадет драматически. С другой стороны, если контекста недостаточно, то нейросеть просто не сможет "понять" как то или иное изменение кода повлияет на проект в целом, упустив таким образом важные потенциальные проблемы. Простой пример - код, предназначенный для однопоточного выполнения, в многопоточной среде, как правило, будет выполняться с ошибками.
Например, мы CodeAlive предварительно индексируем кодовую базу, выстраивая граф вызовов, иерархию типов и другие связи - именно этот шаг помогает максимально эффективно работать с контекстом нашему AI Code Review.
Поделюсь таким кейсом:
Недавно мы заметили баг, из-за которого в системе дублировались артефакты
При этом, GetHashCode, на первый взгляд даже корректный, уже был реализован ранее (но я честно о нем даже и не вспомнил тогда ).
И тут и возникла та самая ситуация, когда даже разработчику непонятно, в чем дело (ведь мы же уже защитились!).
Почесав репу, я подумал, почему бы не попросить CodeAlive поискать корень проблемы:
Ответ прилагаю на скрине. Но он мне настолько понравился, что я продублировал его в текст. Здесь важно отменить, что весь контекст AI-агент собрал сам - все, что я дал ему на входе это вопрос выше.
Проблема действительно оказалась именно в некорректных св-вах в
Кстати, многие хотят попробовать CodeAlive сразу на больших проектах, без регистрации и смс, теперь это стало возможным. Мы проиндексировали опенсорс проекты (ASP.NET Core, Java Spring, laravel, GORM, VSCode, etc.) и теперь каждый может задать по ним свои вопросы: https://www.codealive.ai/#public-chats
У меня есть еще отдельный флоу для решения сложных coding проблем через LLM, если такое интересно, то ваши реакции - лучшая мотивация для нового поста) И поделитесь своими кейсами и флоу, в которых LLM-ки применяются на гране своих возможностей, мы можем собрать потом все в один пост.
У меня в канале много дотнетчиков (спасибо Жене @epeshkblog, Саше @dotnetmore, Кириллу @csharp_gepard и Леше @itbeard) и многие из вас наверняка помнят популярный вопрос с собеседований про GetHashCode) Следующий кейс как об этом.
Есть расхожее заблуждение о том, что LLM все еще слишком глупы для того, чтобы находить ошибки в коде проектов. Особенно когда речь идет о больших и сложных кодовых базах.
В действительности же нейросети развиваются каждый день, и чтобы GenAI тулинг смог находить даже сложные ошибки в коде, в сущности, необходимы всего 2 составляющие:
1. Мощная LLM с возможностью размышлений (reasoning, thinking). Например, наши внутренние бенчмарки показывают, что самыми внимательными к багам являются модели Gemini 2.5 Pro и OpenAI o3.
2. Релевантный контекст. Важно находить золотую середину между избыточным контекстом и недостаточным контекстом. В случае если в LLM поступает лишний контекст, она просто с большей вероятностью в нем запутается и качество ревью упадет драматически. С другой стороны, если контекста недостаточно, то нейросеть просто не сможет "понять" как то или иное изменение кода повлияет на проект в целом, упустив таким образом важные потенциальные проблемы. Простой пример - код, предназначенный для однопоточного выполнения, в многопоточной среде, как правило, будет выполняться с ошибками.
Например, мы CodeAlive предварительно индексируем кодовую базу, выстраивая граф вызовов, иерархию типов и другие связи - именно этот шаг помогает максимально эффективно работать с контекстом нашему AI Code Review.
Поделюсь таким кейсом:
Недавно мы заметили баг, из-за которого в системе дублировались артефакты
Identifier
артефакта - это композиция из fileName
, className
, funcName
). Но самое интересное то, что в коде мы уже обрабатывали дубликаты через HashSet и этой ошибки не должно было быть вовсе:HashSet<ArtifactAggregate> artifactsToSave = new();
void TryAddArtifact(ArtifactAggregate artifact)
{
if (artifactsToSave.Add(artifact) == false)
{
// log error
}
}
При этом, GetHashCode, на первый взгляд даже корректный, уже был реализован ранее (
И тут и возникла та самая ситуация, когда даже разработчику непонятно, в чем дело (ведь мы же уже защитились!).
Почесав репу, я подумал, почему бы не попросить CodeAlive поискать корень проблемы:
почему у нас дублируются Identifier артефактов в базе? мы же вроде защищены от этого в TryAddArtifact
Ответ прилагаю на скрине. Но он мне настолько понравился, что я продублировал его в текст. Здесь важно отменить, что весь контекст AI-агент собрал сам - все, что я дал ему на входе это вопрос выше.
Проблема действительно оказалась именно в некорректных св-вах в
Equals
и GetHashCode
.Кстати, многие хотят попробовать CodeAlive сразу на больших проектах, без регистрации и смс, теперь это стало возможным. Мы проиндексировали опенсорс проекты (ASP.NET Core, Java Spring, laravel, GORM, VSCode, etc.) и теперь каждый может задать по ним свои вопросы: https://www.codealive.ai/#public-chats
У меня есть еще отдельный флоу для решения сложных coding проблем через LLM, если такое интересно, то ваши реакции - лучшая мотивация для нового поста) И поделитесь своими кейсами и флоу, в которых LLM-ки применяются на гране своих возможностей, мы можем собрать потом все в один пост.
🔥34👍7👏5❤1💯1
🎙 Митап AI Driven Development в MOST IT Hub (Алматы)
Есть кто из Алматы?) Залетайте на митап
11 июля в 19:00 в MOST IT Hub опытные техлиды из Bereke Bank, QazCode и архитектор из CodeAlive поделятся своими рецептами использования AI-кодинг-агентов в решении реальных рабочих задач. Доклады будут актуальны не только для технических лидеров, но и для всех, кто интересуется AI-агентами.
🧠 В программе:
🔹 Иван Луценко, техлид из Bereke Bank, покажет, как он с помощью Claude сократил анализ крашей с нескольких часов до 15 минут и выстроил единый workflow для всех проектов.
🔹 Родион Мостовой, CEO и RAG-архитектор из CodeAlive, поделится своими находками в решении сложных задач с помощью LLM и расскажет, как его команда настраивала AI Code Review.
🔹 Но просто сгенерировать код недостаточно — AI-агентов нужно правильно интегрировать в команду. Павел Королев, техлид из QazCode, объяснит, как «обучить» искусственный интеллект особенностям вашего проекта и поддерживать его знания в актуальном состоянии.
📅 11 июля | 19:00
📍 MOST IT Hub - г. Алматы, ул. Ходжанова 2/2, БЦ Fortis, 3 этаж.
⏱ Длительность: 2,5 часа
📝 Регистрация по ссылке
⚠️ Количество мест ограничено
Есть кто из Алматы?) Залетайте на митап
11 июля в 19:00 в MOST IT Hub опытные техлиды из Bereke Bank, QazCode и архитектор из CodeAlive поделятся своими рецептами использования AI-кодинг-агентов в решении реальных рабочих задач. Доклады будут актуальны не только для технических лидеров, но и для всех, кто интересуется AI-агентами.
🧠 В программе:
🔹 Иван Луценко, техлид из Bereke Bank, покажет, как он с помощью Claude сократил анализ крашей с нескольких часов до 15 минут и выстроил единый workflow для всех проектов.
🔹 Родион Мостовой, CEO и RAG-архитектор из CodeAlive, поделится своими находками в решении сложных задач с помощью LLM и расскажет, как его команда настраивала AI Code Review.
🔹 Но просто сгенерировать код недостаточно — AI-агентов нужно правильно интегрировать в команду. Павел Королев, техлид из QazCode, объяснит, как «обучить» искусственный интеллект особенностям вашего проекта и поддерживать его знания в актуальном состоянии.
📝 Регистрация по ссылке
⚠️ Количество мест ограничено
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤1🔥1
GPT 4.5 лучше, чем Claude Opus 4, o3 Pro и Gemini 2.5 Pro?! И причем тут Mermaid?
GPT 4.5 от OpenAI - одна из наиболее странных и специфичных моделей. Она стоит в разы больше, чем GPT-4o/GPT 4.1/o4-mini, но на большинстве задач на программирование показывает сопоставимые или худшие результаты. Как только появилась эта модель, у меня в канале был пост о том, что GPT 4.5 гумманитарий, а не технарь, в котором она имитировала рассказы Пелевина.
Собственно, до сегодняшнего дня я использовал GPT 4.5 только для написания красивых текстов или переводов (и то я уже не уверен, что она здесь выигрывает у Sonnet 4).
Так вот, у нас в CodeAive чатик в своих ответах умеет генерировать Mermaid диаграммы любой сложности - и добиться около 100% корректности этих диаграмм было большим челленджем, по итогу которого мы реализовали целый пайплайн-фиксер, частью которого являются старые добрые проверки через регулярки (regular expressions).
Только проблема в том, что регулярками там надо проверять довольно много разных кейсов (36 тестов в сумме), поэтому паттерны там получились настолько сложные, что их легче просто протестить на разнообразных кейсах и забыть о них. Просто как пример:
В общем, есть один хак, про который подробнее я расскажу чуть позже, он позволяет моделям типа o3 быстрее генерировать сложный рабочий код через итеративное тестирование, но работает это пока только с Python. Я, конечно, воспользовался этим подходом и в итоге, у LLMки получился идеальный метод, который успешно проходил все тесты. Но настоящим челленджем по итогу оказалось корректно конвертировать этот метод обратно в C#. Ни одна сильная reasoning модель с этой задачей не справлялась и половина тестов просто не проходила. Какие модели я пробовал: o3, o3 Pro, o4-mini-hight, Claude 4 Opus Thinking, Grok 3 Thinking, Gemini 2.5 Pro (max thinking budget). Никакой итеративный подход, конечно, тоже не спасал (когда мы несем тексты ошибок обратно в чат и просим их исправить). Больше того, я даже нашел вот такой интересный список отличий регулярок в разных ЯП и скармливал LLMкам этот список (дистиллированный под Python vs C#) - результат тот же... полный фейл.
В общем, бросил я эту задачу, понадеявшись на грядущий Grok 4, а потом вдруг вспомнил, что у нас еще есть GPT 4.5 в арсенале. Ну и что бы вы думали? С одного простого промпта с первой же попытки GPT-4.5 нагенерила абсолютно корректный метод (Python - > C#), который успешно прошел все 36 тестов. Так что, sama (уверен, ты читаешь мой канал), не отключайте ее, пожалуйста)
Кейс, конечно, экзотический, но показательный - не сбрасывайте эту странную модельку со счетов.
А у вас были похожие кейсы, когда большинство сильных моделей не справлялись, а какая-то "маргинальная" справилась?
GPT 4.5 от OpenAI - одна из наиболее странных и специфичных моделей. Она стоит в разы больше, чем GPT-4o/GPT 4.1/o4-mini, но на большинстве задач на программирование показывает сопоставимые или худшие результаты. Как только появилась эта модель, у меня в канале был пост о том, что GPT 4.5 гумманитарий, а не технарь, в котором она имитировала рассказы Пелевина.
Собственно, до сегодняшнего дня я использовал GPT 4.5 только для написания красивых текстов или переводов (и то я уже не уверен, что она здесь выигрывает у Sonnet 4).
Так вот, у нас в CodeAive чатик в своих ответах умеет генерировать Mermaid диаграммы любой сложности - и добиться около 100% корректности этих диаграмм было большим челленджем, по итогу которого мы реализовали целый пайплайн-фиксер, частью которого являются старые добрые проверки через регулярки (regular expressions).
Только проблема в том, что регулярками там надо проверять довольно много разных кейсов (36 тестов в сумме), поэтому паттерны там получились настолько сложные, что их легче просто протестить на разнообразных кейсах и забыть о них. Просто как пример:
$@"(\b[a-zA-Z0-9_]+(?:<br\s*\/?>[a-zA-Z0-9_]+)*)\s*$begin:math:text$\\((.*?)$end:math:text$\)(?=\s*(?:@"(?:x--x)(?:\|.*?\|)?|$))"
В общем, есть один хак, про который подробнее я расскажу чуть позже, он позволяет моделям типа o3 быстрее генерировать сложный рабочий код через итеративное тестирование, но работает это пока только с Python. Я, конечно, воспользовался этим подходом и в итоге, у LLMки получился идеальный метод, который успешно проходил все тесты. Но настоящим челленджем по итогу оказалось корректно конвертировать этот метод обратно в C#. Ни одна сильная reasoning модель с этой задачей не справлялась и половина тестов просто не проходила. Какие модели я пробовал: o3, o3 Pro, o4-mini-hight, Claude 4 Opus Thinking, Grok 3 Thinking, Gemini 2.5 Pro (max thinking budget). Никакой итеративный подход, конечно, тоже не спасал (когда мы несем тексты ошибок обратно в чат и просим их исправить). Больше того, я даже нашел вот такой интересный список отличий регулярок в разных ЯП и скармливал LLMкам этот список (дистиллированный под Python vs C#) - результат тот же... полный фейл.
В общем, бросил я эту задачу, понадеявшись на грядущий Grok 4, а потом вдруг вспомнил, что у нас еще есть GPT 4.5 в арсенале. Ну и что бы вы думали? С одного простого промпта с первой же попытки GPT-4.5 нагенерила абсолютно корректный метод (Python - > C#), который успешно прошел все 36 тестов. Так что, sama (уверен, ты читаешь мой канал), не отключайте ее, пожалуйста)
Кейс, конечно, экзотический, но показательный - не сбрасывайте эту странную модельку со счетов.
А у вас были похожие кейсы, когда большинство сильных моделей не справлялись, а какая-то "маргинальная" справилась?
👍14🤔5❤1
Я стал редко постить что-то новое в свой канал, т. к. на него совершенно не остается времени из-за загрузки в CodeAlive - мы с мощной командой сделали инструмент, который позволяет разработчикам, аналитикам и тестировщикам быстрее разбираться в огромных кодовых базах, давая быстрые, точные и глубокие ответы на вопросы по коду всего проекта, а также умеет делать AI Code Review с учетом контекста проекта.
В общем, недавно я дал интервью Шахизе Менг из казахстанского издания er10, в котором много всего рассказал не только о пути нашего проекта, но и его технической составляющей. Если вам интересно как развивается KZ-EU AI DevTool стартап в 2025, то милости прошу. Немного позже я расскажу подробнее о том как у нас все работает. А сейчас, спасибо er10, и приятного чтива!
В общем, недавно я дал интервью Шахизе Менг из казахстанского издания er10, в котором много всего рассказал не только о пути нашего проекта, но и его технической составляющей. Если вам интересно как развивается KZ-EU AI DevTool стартап в 2025, то милости прошу. Немного позже я расскажу подробнее о том как у нас все работает. А сейчас, спасибо er10, и приятного чтива!
👍5🔥5❤1🤡1
Forwarded from er10.kz
Сэкономит 30% вашего бюджета: стартап CodeAlive упрощает работу с кодом
Может ли заядлый айтишник стать предпринимателем?
Опыт Родиона Мостового, фаундера стартапа CodeAlive, подтверждает, что да. В работе тимлидом он понял, что разработчики тратят много времени на то, чтобы разобраться в коде.
Со временем эта боль переросла в стартап CodeAlive, который превращает весь код и документацию компании в интерактивную базу знаний.
В эксклюзивном интервью для ER10 Media Родион Мостовой рассказал о взлетах, падениях и изнанке своего стартапа.
ER10.KZ | IT-медиа
Может ли заядлый айтишник стать предпринимателем?
Опыт Родиона Мостового, фаундера стартапа CodeAlive, подтверждает, что да. В работе тимлидом он понял, что разработчики тратят много времени на то, чтобы разобраться в коде.
Со временем эта боль переросла в стартап CodeAlive, который превращает весь код и документацию компании в интерактивную базу знаний.
В эксклюзивном интервью для ER10 Media Родион Мостовой рассказал о взлетах, падениях и изнанке своего стартапа.
ER10.KZ | IT-медиа
👍11🔥5❤1
Заставляем Claude Code думать на максимуме
Готовлю доклад про Context Engineering и раскапываю на досуге разных кодовых агентов - в т. ч. Claude Code.
Существует ряд сложных задач, над которыми LLM сначала надо хорошенько "подумать" прежде, чем кодить решение (а точнее, сжечь reasoning токены) - так вот, Claude Sonnet 4 и Claude Opus 4/4.1 тоже этим навыком владеют. И многие знают, что заставить СС подумать можно просто добавив в постановку задачи текст "think deep". Но немногие знают, что на самом деле у клода таких думающих режимов несколько, а именно:
Справа от названия режимаобъем мыслетоплева thinking budget tokens для LLM.
И теперь самое интересное - список ключевых слов, активирующих каждый из режимов (да, они прям захардкожены):
В общем, достаточно запомнить
Кстати, вот еще лайфхак как новый Codex на базе GPT-5 перевести в максимально "думающий" режим:
—
А что еще вам было бы интересно про подкапотную составляющую кодовых агентов? (в т. ч. Claude Code). Есть идея добавить в наш CodeAlive режим сравнения кишочков кодовых агентов, чтобы по вопросу пользователя показывать как та или иная фича или флоу работает в разных кодагентах (например, "как работает применение патча к файлам?") - интересно ли было бы такое?
Готовлю доклад про Context Engineering и раскапываю на досуге разных кодовых агентов - в т. ч. Claude Code.
Существует ряд сложных задач, над которыми LLM сначала надо хорошенько "подумать" прежде, чем кодить решение (а точнее, сжечь reasoning токены) - так вот, Claude Sonnet 4 и Claude Opus 4/4.1 тоже этим навыком владеют. И многие знают, что заставить СС подумать можно просто добавив в постановку задачи текст "think deep". Но немногие знают, что на самом деле у клода таких думающих режимов несколько, а именно:
HIGHEST: 31999,
MIDDLE: 10000,
BASIC: 4000
Справа от названия режима
И теперь самое интересное - список ключевых слов, активирующих каждый из режимов (да, они прям захардкожены):
HIGHEST: [{
pattern: "think harder",
}, {
pattern: "think intensely",
}, {
pattern: "think longer",
}, {
pattern: "think really hard",
}, {
pattern: "think super hard",
}, {
pattern: "think very hard",
}, {
pattern: "ultrathink",
}],
MIDDLE: [{
pattern: "think about it",
}, {
pattern: "think a lot",
}, {
pattern: "think deeply",
}, {
pattern: "think hard",
}, {
pattern: "think more",
}, {
pattern: "megathink",
}],
BASIC: [{
pattern: "think",
}]
В общем, достаточно запомнить
ultrathink
и будем вам "самый умный режим". Осторожно, возможно непредвиденное обжорство токенами.Кстати, вот еще лайфхак как новый Codex на базе GPT-5 перевести в максимально "думающий" режим:
codex --config model_reasoning_effort="high"
.—
А что еще вам было бы интересно про подкапотную составляющую кодовых агентов? (в т. ч. Claude Code). Есть идея добавить в наш CodeAlive режим сравнения кишочков кодовых агентов, чтобы по вопросу пользователя показывать как та или иная фича или флоу работает в разных кодагентах (например, "как работает применение патча к файлам?") - интересно ли было бы такое?
👍21🔥7❤2
AI-Driven Development. Родион Мостовой
Заставляем Claude Code думать на максимуме Готовлю доклад про Context Engineering и раскапываю на досуге разных кодовых агентов - в т. ч. Claude Code. Существует ряд сложных задач, над которыми LLM сначала надо хорошенько "подумать" прежде, чем кодить решение…
Claude Code vs Codex vs Codex CLI vs Aider
В последнее время я активно использую Claude Code, Aider, Gemini CLI, Codex и Codex CLI. И если с первым для большинства все понятно - CC сейчас стал эдаким индустриальным стандартом для AI-кодинга, который плавно заменяет Cursor, то кейсы для остальных тулов уже не так очевидны. Поэтому поделюсь своим форкфлоу:
Aider
aider (на базе Gemini 2.5 Pro) я люблю использовать в случаях когда четко знаю какие именно файлы нужны для решения задачи - тогда я просто загоняю их в контекст эйдера и точно знаю, что LLMка будет учитывать контекст всех этих файлов (другие кодагенты часто грешат частичным считыванием файлов). Ну и еще один кейс с эйдер - это применение плана изменений из CodeAlive - aider очень хорошо умеет применять патчи к указанным файлам по указанному плану изменений.
Codex CLI
Похоже, что как кодовый агент Codex CLI до сих пор довольно сырой (во всяком случае уступает Claude Code), зато поскольку он теперь работает на базе GPT-5, есть смысл применять его точечно в самых сложных местах: например, когда нужно пофиксить какой-то лютый баг, который Claude Sonnet/Opus даже в режиме ultrathink не осиливают. Ну или для реализации какого-нибудь запутанного алгоритма с кучей corner cases.
Пример из практики: у нас в CodeAlive возникла простенькая задачка по улучшению UX - когда пользователь при добавлении репозитория в систему вставляет ссылку на него, автоматически вытаскивать имя репозитория прямо из вставленной ссылки и подставлять его в поле Name (чтобы поберечь пальцы пользователей от лишних действий). Скажите ведь, что задача на 30 сек? Так вот, мы в CodeAlive для фронта используем Nuxt и, вероятно, по этой причине ни Claude Code, ни Gemini CLI, ни Junie не смогла осилить эту, на первый взгляд, совсем элементарную задачу (в реальности я хз почему, т. к. сам совсем не фронтэндщик, но это и неважно в данном случае). Больше того, даже Claude Opus 4.1 в режиме ultrathink так и не смогла найти причину бага и исправить его, выжрав при этом аж 10$!
В итоге, странную проблему смог пофиксить только Codex CLI в режиме high reasoning effort:
Теперь вы знаете что делать если CC и остальные агенты встали в ступор. Кстати, хорошая новость в том, что с недавних пор Codex CLI работает и по подписке ChatGPT Plus, а не только через API ключ.
Codex (web)
Что касается Codex, который облачный в веб интерфейсе, то я теперь использую его для решения каких-то сложных проблем в тех случаях, когда даже непонятно где вообще искать - например, поиск возможной причины OOM. Плюс Кодекса в вебе в том, что он умеет генерировать до 4-х вариантов (траекторий) решения и далее позволяет выбрать наиболее адекватное.
CodeAlive
CodeAlive я использую для кейсов когда необходимо быстро разобраться как что-то работает в кодовой базе на 50к и более строк кода или когда нужно что-то красиво визуализировать (мы очень много работали, чтобы диаграммы всегда были корректными). CodeAlive отдает точный и глубокий ответ на вопрос за несколько секунд, в отличие от кодагентов, которые по несколько минут могут собирать контекст даже на простые вопросы.
А в каких задачах вы используете что-то кроме Claude Code?
В последнее время я активно использую Claude Code, Aider, Gemini CLI, Codex и Codex CLI. И если с первым для большинства все понятно - CC сейчас стал эдаким индустриальным стандартом для AI-кодинга, который плавно заменяет Cursor, то кейсы для остальных тулов уже не так очевидны. Поэтому поделюсь своим форкфлоу:
Aider
aider (на базе Gemini 2.5 Pro) я люблю использовать в случаях когда четко знаю какие именно файлы нужны для решения задачи - тогда я просто загоняю их в контекст эйдера и точно знаю, что LLMка будет учитывать контекст всех этих файлов (другие кодагенты часто грешат частичным считыванием файлов). Ну и еще один кейс с эйдер - это применение плана изменений из CodeAlive - aider очень хорошо умеет применять патчи к указанным файлам по указанному плану изменений.
Codex CLI
Похоже, что как кодовый агент Codex CLI до сих пор довольно сырой (во всяком случае уступает Claude Code), зато поскольку он теперь работает на базе GPT-5, есть смысл применять его точечно в самых сложных местах: например, когда нужно пофиксить какой-то лютый баг, который Claude Sonnet/Opus даже в режиме ultrathink не осиливают. Ну или для реализации какого-нибудь запутанного алгоритма с кучей corner cases.
Пример из практики: у нас в CodeAlive возникла простенькая задачка по улучшению UX - когда пользователь при добавлении репозитория в систему вставляет ссылку на него, автоматически вытаскивать имя репозитория прямо из вставленной ссылки и подставлять его в поле Name (чтобы поберечь пальцы пользователей от лишних действий). Скажите ведь, что задача на 30 сек? Так вот, мы в CodeAlive для фронта используем Nuxt и, вероятно, по этой причине ни Claude Code, ни Gemini CLI, ни Junie не смогла осилить эту, на первый взгляд, совсем элементарную задачу (
В итоге, странную проблему смог пофиксить только Codex CLI в режиме high reasoning effort:
codex --config model_reasoning_effort="high"
. Промпт был простой:`Name` auto-fill logic is not working - it's extremely complicated problem, since even a Senior dev couldn't solve it. So, think hard to find the root cause and fix it. You can even come up with an alternative approach.
Теперь вы знаете что делать если CC и остальные агенты встали в ступор. Кстати, хорошая новость в том, что с недавних пор Codex CLI работает и по подписке ChatGPT Plus, а не только через API ключ.
Codex (web)
Что касается Codex, который облачный в веб интерфейсе, то я теперь использую его для решения каких-то сложных проблем в тех случаях, когда даже непонятно где вообще искать - например, поиск возможной причины OOM. Плюс Кодекса в вебе в том, что он умеет генерировать до 4-х вариантов (траекторий) решения и далее позволяет выбрать наиболее адекватное.
CodeAlive
CodeAlive я использую для кейсов когда необходимо быстро разобраться как что-то работает в кодовой базе на 50к и более строк кода или когда нужно что-то красиво визуализировать (мы очень много работали, чтобы диаграммы всегда были корректными). CodeAlive отдает точный и глубокий ответ на вопрос за несколько секунд, в отличие от кодагентов, которые по несколько минут могут собирать контекст даже на простые вопросы.
А в каких задачах вы используете что-то кроме Claude Code?
👍18🔥7💩1
Аудит кодовой базы на ошибки и уязвимости через LLM
Те, кто внимательно следит за моим каналом знают, что у нас в CodeAlive уже давно есть фича Code Review через AI, который учитывает контекст проекта, а не только смотрит diff. Дело в том, что этот AI-ревьюер встраивается в пайплайн разработки, и проверяет тот код, который разработчики отправляют в PR/MR. Это работает отлично, но мы все чаще получаем запрос от наших пользователей на то, чтобы CodeAlive сделал для них ревью (фактически аудит) всей кодовой базы целиком. И мы сейчас работаем именно над этой фичей. Так что если для вас актуальна задача проверки всего кода вашего пет или даже рабочего проекта - напишите мне и мы бесплатно проведем такой аудит, а с вас фидбек по результатам :)
И если среди нас есть специалисты, которые профессионально занимались аудитом кодовых баз - тоже напишите мне, нам было бы интересно с вами пообщаться.
Те, кто внимательно следит за моим каналом знают, что у нас в CodeAlive уже давно есть фича Code Review через AI, который учитывает контекст проекта, а не только смотрит diff. Дело в том, что этот AI-ревьюер встраивается в пайплайн разработки, и проверяет тот код, который разработчики отправляют в PR/MR. Это работает отлично, но мы все чаще получаем запрос от наших пользователей на то, чтобы CodeAlive сделал для них ревью (фактически аудит) всей кодовой базы целиком. И мы сейчас работаем именно над этой фичей. Так что если для вас актуальна задача проверки всего кода вашего пет или даже рабочего проекта - напишите мне и мы бесплатно проведем такой аудит, а с вас фидбек по результатам :)
И если среди нас есть специалисты, которые профессионально занимались аудитом кодовых баз - тоже напишите мне, нам было бы интересно с вами пообщаться.
🔥16👍3❤2💩1
Онлайн митап: AI Coding Talk в этот четверг
Приходите в четверг на онлайн встречу, на которой мы с AI-buddies из соседних каналов про AI-кодинг будем обсуждать то, как сегодня выглядит эффективная AI-driven разработка. Ребята, как и я, глубоко погружены в тему AI-assisted разработки, а кто-то даже свои тулы для этого делает. Я поделюсь своим текущим воркфлоу, а также расскажу про наш опыт Context Engineering в CodeAlive.
Вместе со мной участвуют следующие достопочтенные граждане:
- "The AI Architect | AI Coding", Тимур Хахалев
- AI и грабли, Николай Шейко
- Константин Доронин
- Глеб про AI, Глеб Кудрявцев
Начнём в четверг, 28 августа, в 16:30 по МСК, 18:30 по Алматы и в 15:30 CEST.
🗓 Ссылка на календарь
Ставьте напоминашку и делитесь с друзьями.
Приходите в четверг на онлайн встречу, на которой мы с AI-buddies из соседних каналов про AI-кодинг будем обсуждать то, как сегодня выглядит эффективная AI-driven разработка. Ребята, как и я, глубоко погружены в тему AI-assisted разработки, а кто-то даже свои тулы для этого делает. Я поделюсь своим текущим воркфлоу, а также расскажу про наш опыт Context Engineering в CodeAlive.
Вместе со мной участвуют следующие достопочтенные граждане:
- "The AI Architect | AI Coding", Тимур Хахалев
- AI и грабли, Николай Шейко
- Константин Доронин
- Глеб про AI, Глеб Кудрявцев
Начнём в четверг, 28 августа, в 16:30 по МСК, 18:30 по Алматы и в 15:30 CEST.
🗓 Ссылка на календарь
Ставьте напоминашку и делитесь с друзьями.
👍11🔥5❤3💩2
AI-Driven Development. Родион Мостовой
Онлайн митап: AI Coding Talk в этот четверг Приходите в четверг на онлайн встречу, на которой мы с AI-buddies из соседних каналов про AI-кодинг будем обсуждать то, как сегодня выглядит эффективная AI-driven разработка. Ребята, как и я, глубоко погружены в…
Напоминаю, наш скромный митапчик уже через 9 минут.
Добавляться через бота https://t.iss.one/group_sub_check_bot?start=68b04c36e5b9f465c329b7e6
По-умолчанию ютуб, но потом еще выложим на другие платформы.
Добавляться через бота https://t.iss.one/group_sub_check_bot?start=68b04c36e5b9f465c329b7e6
По-умолчанию ютуб, но потом еще выложим на другие платформы.
Telegram
group_sub_check
Нужны подписчики в телеграме? -> telepromo.org
🔥7