Прошёл ещё один сезон Podlodka PHP Crew.
Из яркого — два финальных доклада про AI (которые я помогал готовить как член ПК и был ведущим на этих сессиях).
Доклад Петра Мязина начинает с вводной о том, что есть некоторые уровни внедрения AI в SDLC. Кажется сообществу пора давно дать классификацию. Я чуть расширил его модель, и мне кажется для сообщества она может быть примерно такой.
Уровни внедрения AI в дев-инструменты:
1. Вне процесса
LLM-чаты, живущие отдельно от IDE и CI. Нет связи с кодом, репозиториями и трекером задач.
2. Точечный ассистент / inline-AI
Автокомплит, explain/fix, генерация мелких фрагментов кода и тестов.
Встроенный чат, читающий отдельные файлы.
3. IDE-агенты (task-level)
Агент понимает задачу («обнови X», «сделай миграцию») и сам вызывает операции IDE.
Разработчик остаётся в цикле: ревьюит, откатывает, правит.
4. Background / remote-агенты
Агенты работают в фоне или удалённо: массовые правки в монорепе, линтинг, миграции, документация, анализ логов.
Есть интеграция с CI/CD и трекером: агент сам поднимает PR, пишет отчёты и инициирует диалог.
5. Сквозные SDLC-агенты
Мультиагентная система, покрывающая весь цикл: от user story до релиза и мониторинга.
Человек задаёт цели, агенты координируются сами.
————
По этой классификации компания Петра уже на уровне 4 с элементами 5. Примечательно, что около 60% задач у них запускаются через background-агентов.
Ключевые нюансы этого пути:
— Не все задачи агенты могут качественно реализовать на background агентах.
— Требуется более мелкое дробление задач.
— Потолок у background AI-агента ниже, чем
у локального (3 стадия).
— Аналитики устают отвечать на уточняющие вопросы агентов.
— Ревью разработчиков остаётся обязательным.
— Экономика сходится: укладывается в лимиты подписки 200$.
— Всё построено на codex-стеке, у которого есть свои UX-ограничения.
7 сезон PHP Crew обещают выложить уже на следующей неделе и можно будет взять по этой ссылке https://podlodka.io/crew-records.
Из яркого — два финальных доклада про AI (которые я помогал готовить как член ПК и был ведущим на этих сессиях).
Доклад Петра Мязина начинает с вводной о том, что есть некоторые уровни внедрения AI в SDLC. Кажется сообществу пора давно дать классификацию. Я чуть расширил его модель, и мне кажется для сообщества она может быть примерно такой.
Уровни внедрения AI в дев-инструменты:
1. Вне процесса
LLM-чаты, живущие отдельно от IDE и CI. Нет связи с кодом, репозиториями и трекером задач.
2. Точечный ассистент / inline-AI
Автокомплит, explain/fix, генерация мелких фрагментов кода и тестов.
Встроенный чат, читающий отдельные файлы.
3. IDE-агенты (task-level)
Агент понимает задачу («обнови X», «сделай миграцию») и сам вызывает операции IDE.
Разработчик остаётся в цикле: ревьюит, откатывает, правит.
4. Background / remote-агенты
Агенты работают в фоне или удалённо: массовые правки в монорепе, линтинг, миграции, документация, анализ логов.
Есть интеграция с CI/CD и трекером: агент сам поднимает PR, пишет отчёты и инициирует диалог.
5. Сквозные SDLC-агенты
Мультиагентная система, покрывающая весь цикл: от user story до релиза и мониторинга.
Человек задаёт цели, агенты координируются сами.
————
По этой классификации компания Петра уже на уровне 4 с элементами 5. Примечательно, что около 60% задач у них запускаются через background-агентов.
Ключевые нюансы этого пути:
— Не все задачи агенты могут качественно реализовать на background агентах.
— Требуется более мелкое дробление задач.
— Потолок у background AI-агента ниже, чем
у локального (3 стадия).
— Аналитики устают отвечать на уточняющие вопросы агентов.
— Ревью разработчиков остаётся обязательным.
— Экономика сходится: укладывается в лимиты подписки 200$.
— Всё построено на codex-стеке, у которого есть свои UX-ограничения.
7 сезон PHP Crew обещают выложить уже на следующей неделе и можно будет взять по этой ссылке https://podlodka.io/crew-records.
🔥6👍3
Второй доклад от Павла Бучнева сосредотачивается на 3 уровне: как разработчику грамотно заниматься контекст инжинирингом — на мой взгляд одним из самых главных современных скилов современного разработчика, аналитика, qa, еtc.
Иллюстрации в докладе потрясающие, взял небольшое количество для примера).
Павел на своем опыте разработал свой личный фреймворк успешной AI разработки, сфокусированном на управлении контекстом. По факту можно считать его подход разновидностью CDD (Context Driven Development).
Подход основан основана на:
- Целом ряде best bractis,
- Написанным им open source CTX библиотеке,
- Ручном ювелирном управлении контекстом (даже Claude Code в его парадигме хуже т.к. добавляет много своего контекста)
- Feature Request в строгом и детализированном формате
- Продуманных гайдлайнах в базовом контексте
- Из непривычного - очень много Feature Request и контекста он задает голосом, на его личном опыте это работает гораздо быстрее и в большем потоке чем описывать руками. Исходник прогоняет через chatGPT превращая его в FR.
UPD: кстати это видео выложили в открытый доступ.
Иллюстрации в докладе потрясающие, взял небольшое количество для примера).
Павел на своем опыте разработал свой личный фреймворк успешной AI разработки, сфокусированном на управлении контекстом. По факту можно считать его подход разновидностью CDD (Context Driven Development).
Подход основан основана на:
- Целом ряде best bractis,
- Написанным им open source CTX библиотеке,
- Ручном ювелирном управлении контекстом (даже Claude Code в его парадигме хуже т.к. добавляет много своего контекста)
- Feature Request в строгом и детализированном формате
- Продуманных гайдлайнах в базовом контексте
- Из непривычного - очень много Feature Request и контекста он задает голосом, на его личном опыте это работает гораздо быстрее и в большем потоке чем описывать руками. Исходник прогоняет через chatGPT превращая его в FR.
UPD: кстати это видео выложили в открытый доступ.
🔥7👍3❤1
Исследование. Взяли 46 команд которые использовали AI в разработке и сопоставили их с аналогичными 46 командами не использующими AI.
Самая важная мысль: разрыв в производительности этих команд увеличивается со временем.
Уже сейчас х4.
Если гипотетически предположить что тенденция сохранится через несколько лет разрыв будет лишь кратно (второй слайд).
"Богатые становятся богаче". Те кто раньше внедрил AI могут наращивать преимущество, в то время как отстающие будут все больше отставать.
Самая важная мысль: разрыв в производительности этих команд увеличивается со временем.
Уже сейчас х4.
Если гипотетически предположить что тенденция сохранится через несколько лет разрыв будет лишь кратно (второй слайд).
"Богатые становятся богаче". Те кто раньше внедрил AI могут наращивать преимущество, в то время как отстающие будут все больше отставать.
👍5🔥2
Forwarded from AI for Devs
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
🔥 Prompt Caching: токены LLM в 10 раз дешевле — но за счёт чего?
Подготовили перевод просто пушечной статьи про кэширование промтов. Внутри много теоретической базы изложенной простыми словами, с классными примерами и наглядными анимациями(без математики тоже не обошлось 🫠) .
Вот как сам автор описал свою статью и мы с ним полностью согласны:
📚 Читайте и комментируйте на Хабр.
@ai_for_devs
Подготовили перевод просто пушечной статьи про кэширование промтов. Внутри много теоретической базы изложенной простыми словами, с классными примерами и наглядными анимациями
Вот как сам автор описал свою статью и мы с ним полностью согласны:
Не удовлетворившись ответами в документации вендоров ПО для разработчиков, которые хорошо объясняют, как пользоваться кэшированием промптов, но аккуратно обходят вопрос о том, что именно кэшируется, я решил копнуть глубже.
Я нырнул в кроличью нору устройства LLM, пока не понял, какие именно данные провайдеры кэшируют, для чего они используются и как это делает всё быстрее и дешевле для всех.
К концу этой статьи вы:
– глубже поймёте, как работают LLM
– сформируете новую интуицию о том, почему LLM устроены именно так
– разберётесь, какие именно нули и единицы кэшируются и как это снижает стоимость ваших запросов к LLM
📚 Читайте и комментируйте на Хабр.
@ai_for_devs
👍3🔥3❤1
Forwarded from Книжный куб (Alexander Polomodov)
From Vibe Coding To Vibe Engineering (Рубрика #AI)
Посмотрел юморное выступление Kitze (Кристияна Ристовски), состоявшееся в конце 2025 года на саммите AI Engineer. Спикер - заметный в сообществе фронтенд-разработчик и предприниматель, что известен своим саркастичным подходом к современной веб-разработке, которую он критикует излишнюю сложность инструментов (Webpack, конфигурации) и пропагандирует подход "Just Ship It". В этом докладе Kitze утверждает, что "vibe coding" веселый способ создания пет-проектов, но для реальной работы нужно превратить это в "vibe engineering. Если говорить про тезисы, то вот они
1️⃣ Спираль смерти (The Doom Loop)
Проблема с vibe coding в том, что как только вы начинаете вручную править код, написанный ИИ, вы ломаете «вайб». Вы тратите время на чтение чужого (машинного) кода, пытаетесь его понять, вносите правку, а потом при следующей генерации ИИ может затереть ваши изменения или перестать понимать контекст. Решение от Kitze в том, что если ИИ написал баг, не чините его руками. Заставьте ИИ починить его. Это требует дисциплины, но это единственный способ сохранить скорость. Вы должны стать менеджером, который не делает работу за стажера, а заставляет стажера переделать задачу правильно.
2️⃣ Контекст - это всё
Обычный vibe doding ломается на больших проектах, потому что ИИ «забывает» или не знает структуру всего проекта. А "vibe engineering" - это уже построение инфраструктуры вокруг LLM, которая автоматически скармливает модели весь актуальный контекст проекта (структуру файлов, типы, документацию) перед каждым запросом. Kitze показывает, что вместо написания кода он теперь пишет скрипты и промпты, которые собирают контекст для ИИ. Это и есть новая инженерия.
3️⃣ От синтаксиса к семантике
Разработчик перестает быть "писателем кода" и становится "архитектором намерений". Ваша задача - четко описать что должно произойти, а как это будет написано (на React, Vue или чистом JS) - становится вторичным.
Интересно, что автор предлагает эволюцию названия и подходов:
- "Vibe coding": "Я попросил Claude сделать змейку, и оно работает. Прикольно". Это хаотичный процесс, случайный результат.
- "Vibe engineering: "Я построил конвейер, где ИИ имеет доступ ко всей моей базе кода, знает мои линтеры и тесты, и я могу надежно генерировать сложные фичи, управляя процессом через промпты и тесты". Это уже похоже на инженерию
Kitze аргументирует, что мы должны перейти от стадии "игры" с ИИ к стадии профессионального встраивания ИИ в инженерные процессы.
Если подумать о том, а как предложенные изменения влияют на индустрию, то получим следующее
- Vibe coding опасен для новичков. Если ты не можешь верифицировать результат (не понимаешь архитектуру), ты создашь монстра. Новички теперь должны учиться не синтаксису
- Опытный инженер - становится супер-продуктивен. Если он знает что хочет получить, то с помощью vibe engineering может заменить целую команду из 3-5 человек. Kitze приводит пример, как он переписал огромные куски Sizzy за дни, а не месяцы (sizzy - это браузер для разработчиков и qa-инженеров)
- DevEx меняется - раньше мы оптимизировали подсветку синтаксиса и автодополнение. Теперь DX - это то, насколько легко ваш проект "читается" нейросетью. Если ваш код непонятен для LLM, вы проиграли.
Ну и однострочные выводы из доклада звучат так
- Не пишите код, управляйте им. Лучший код - тот, который вы не писали руками.
- Инвестируйте в контекст. Научитесь создавать инструменты, которые позволяют ИИ "видеть" ваш проект целиком.
- Сопротивляйтесь желанию "быстро поправить руками". Это ловушка, которая возвращает вас в старую парадигму и замедляет в долгосрочной перспективе.
- Код становится эфемерным. Мы привыкли беречь код. В эпоху vibe engineering код можно легко удалить и сгенерировать заново, если он перестал соответствовать требованиям. Ценность - в описании задачи, а не в файле с кодом.
#Engineering #AI #Software #ML #DevEx #Productivity #IDE
Посмотрел юморное выступление Kitze (Кристияна Ристовски), состоявшееся в конце 2025 года на саммите AI Engineer. Спикер - заметный в сообществе фронтенд-разработчик и предприниматель, что известен своим саркастичным подходом к современной веб-разработке, которую он критикует излишнюю сложность инструментов (Webpack, конфигурации) и пропагандирует подход "Just Ship It". В этом докладе Kitze утверждает, что "vibe coding" веселый способ создания пет-проектов, но для реальной работы нужно превратить это в "vibe engineering. Если говорить про тезисы, то вот они
1️⃣ Спираль смерти (The Doom Loop)
Проблема с vibe coding в том, что как только вы начинаете вручную править код, написанный ИИ, вы ломаете «вайб». Вы тратите время на чтение чужого (машинного) кода, пытаетесь его понять, вносите правку, а потом при следующей генерации ИИ может затереть ваши изменения или перестать понимать контекст. Решение от Kitze в том, что если ИИ написал баг, не чините его руками. Заставьте ИИ починить его. Это требует дисциплины, но это единственный способ сохранить скорость. Вы должны стать менеджером, который не делает работу за стажера, а заставляет стажера переделать задачу правильно.
2️⃣ Контекст - это всё
Обычный vibe doding ломается на больших проектах, потому что ИИ «забывает» или не знает структуру всего проекта. А "vibe engineering" - это уже построение инфраструктуры вокруг LLM, которая автоматически скармливает модели весь актуальный контекст проекта (структуру файлов, типы, документацию) перед каждым запросом. Kitze показывает, что вместо написания кода он теперь пишет скрипты и промпты, которые собирают контекст для ИИ. Это и есть новая инженерия.
3️⃣ От синтаксиса к семантике
Разработчик перестает быть "писателем кода" и становится "архитектором намерений". Ваша задача - четко описать что должно произойти, а как это будет написано (на React, Vue или чистом JS) - становится вторичным.
Интересно, что автор предлагает эволюцию названия и подходов:
- "Vibe coding": "Я попросил Claude сделать змейку, и оно работает. Прикольно". Это хаотичный процесс, случайный результат.
- "Vibe engineering: "Я построил конвейер, где ИИ имеет доступ ко всей моей базе кода, знает мои линтеры и тесты, и я могу надежно генерировать сложные фичи, управляя процессом через промпты и тесты". Это уже похоже на инженерию
Kitze аргументирует, что мы должны перейти от стадии "игры" с ИИ к стадии профессионального встраивания ИИ в инженерные процессы.
Если подумать о том, а как предложенные изменения влияют на индустрию, то получим следующее
- Vibe coding опасен для новичков. Если ты не можешь верифицировать результат (не понимаешь архитектуру), ты создашь монстра. Новички теперь должны учиться не синтаксису
for loop, а системному дизайну и проверке качества.- Опытный инженер - становится супер-продуктивен. Если он знает что хочет получить, то с помощью vibe engineering может заменить целую команду из 3-5 человек. Kitze приводит пример, как он переписал огромные куски Sizzy за дни, а не месяцы (sizzy - это браузер для разработчиков и qa-инженеров)
- DevEx меняется - раньше мы оптимизировали подсветку синтаксиса и автодополнение. Теперь DX - это то, насколько легко ваш проект "читается" нейросетью. Если ваш код непонятен для LLM, вы проиграли.
Ну и однострочные выводы из доклада звучат так
- Не пишите код, управляйте им. Лучший код - тот, который вы не писали руками.
- Инвестируйте в контекст. Научитесь создавать инструменты, которые позволяют ИИ "видеть" ваш проект целиком.
- Сопротивляйтесь желанию "быстро поправить руками". Это ловушка, которая возвращает вас в старую парадигму и замедляет в долгосрочной перспективе.
- Код становится эфемерным. Мы привыкли беречь код. В эпоху vibe engineering код можно легко удалить и сгенерировать заново, если он перестал соответствовать требованиям. Ценность - в описании задачи, а не в файле с кодом.
#Engineering #AI #Software #ML #DevEx #Productivity #IDE
YouTube
From Vibe Coding To Vibe Engineering – Kitze, Sizzy
Web development has always moved in cycles of hype, from frameworks to tooling. With the rise of large language models, we're entering a new era of "vibe coding," where developers shape software through collaboration with Al rather than syntax. This talk…
👍7❤1
Вот только ты подумал что JetBrains наконец то выпустили BYOK, слили junie в ai, и Claudе начнет отставать, и тут на тебе - Claude Code получил нативную поддержку LSP - это замашка на один из основных "доводов против claude code" - не было хорошего понимания кода по сравнению с IDE и даже редакторами вроде cursor. Борьба за лучший инструмент в enterprise сегменте в разгаре.
BYOK JetBrains кстати хорошо ладит с litellm proxy и свежей GLM-4.7 – по бенчмаркам чуть ли не opus. Выглядит потенциально неплохо, проверяем.
Пока закрытость и кастомный api anthropic имхо наоборот бьют скорее ей в минус, т.к. в enterprise борьба за ИБ зачастую актуальнее.
И работает это ровно до тех пор пока к claude моделям в действительности (а не в бенчмарках) достоточно плотно не подберутся китайцы.
BYOK JetBrains кстати хорошо ладит с litellm proxy и свежей GLM-4.7 – по бенчмаркам чуть ли не opus. Выглядит потенциально неплохо, проверяем.
Пока закрытость и кастомный api anthropic имхо наоборот бьют скорее ей в минус, т.к. в enterprise борьба за ИБ зачастую актуальнее.
И работает это ровно до тех пор пока к claude моделям в действительности (а не в бенчмарках) достоточно плотно не подберутся китайцы.
The JetBrains Blog
Bring Your Own Key (BYOK) Is Now Live in JetBrains IDEs | The JetBrains AI Blog
Bring Your Own Key (BYOK) is now available in the AI chat inside JetBrains IDEs as well as for AI agents, including JetBrains’ Junie and Claude Agent. Whether you’re looking to use cutting-edge fronti
👍6
Ваша работа — выпускать код, который доказанно работает https://habr.com/p/980006/
Habr
Ваша работа — выпускать код, который доказанно работает
Во всех обсуждениях ценности ИИ-помощников в разработке ПО мне встречается одна печальная история: разработчик-джун, вооружившийся каким-нибудь LLM-инструментом, создаёт для своих коллег или...
💯6❤1🔥1
Кстати пропустил новость что TypeScript вышел на 1-е место среди языков на github.
TypeScript cтал самым используемым языком на платформе.
Я в отпуске перебрал несколько сотен новых open source проектов (развлечение у меня такое), большая часть из них была на node/ts.
Команды всё чаще предпочитают строго типизированный код при использовании ИИ: развитая типизация TypeScript делает автосгенерированный AI-код более надежным.
TypeScript cтал самым используемым языком на платформе.
Я в отпуске перебрал несколько сотен новых open source проектов (развлечение у меня такое), большая часть из них была на node/ts.
Команды всё чаще предпочитают строго типизированный код при использовании ИИ: развитая типизация TypeScript делает автосгенерированный AI-код более надежным.
Хабр
TypeScript стал самым популярным языком на GitHub, впервые обогнав Python и JavaScript
GitHub представил ежегодный отчёт Octoverse 2025, и впервые за всю историю рейтинг возглавил TypeScript. Ещё недавно язык воспринимался как надстройка над JavaScript, но теперь он стал новым...
👍6🤔1