Forwarded from Книжный куб (Alexander Polomodov)
AI для разработки - базовый навык для 2024 - Владислава Куклева - Agile Days 2024 (Рубрика #AI)
Интересный доклад Владислава Куклева, CEO агенства Agentcy, про AI тулинг. Понятно по названию его компании, что финальным аккордом является история про мультиагнетные системы, но до это Владислаав успевает пробежаться по вопросам
- Архитектуры языковых моделей (рассказ про LLM на уровне сложности для обывателей)
- Проблемы LLM (галлюцинации и угадывание), но OpenAI дотюнила модели обучая на размеченных диалогах с пользователем + появился промпт инжиниринг, про который рассказывает автор. Правда, он не упоминает, что по новейшим исследованиям промты для LLM сами LLM пишут лучше, чем люди:)
- Создание при помощи LLMs дизайна, слайдов, диаграмм (mermaid.js)
- Помощники для написания кода: GitHub Copilot, Cursor, Phind
- Цепочки запросов и AI-агенты - как это устроено и почему сейчас это очень перспективное направление
- Мультиагентские системы и как отдельные агенты могут объединятся в команду - подробнее в whitepaper "ChatDev: Communicative Agents for Software Development"
#AI #ML #Software #Processes #Management
Интересный доклад Владислава Куклева, CEO агенства Agentcy, про AI тулинг. Понятно по названию его компании, что финальным аккордом является история про мультиагнетные системы, но до это Владислаав успевает пробежаться по вопросам
- Архитектуры языковых моделей (рассказ про LLM на уровне сложности для обывателей)
- Проблемы LLM (галлюцинации и угадывание), но OpenAI дотюнила модели обучая на размеченных диалогах с пользователем + появился промпт инжиниринг, про который рассказывает автор. Правда, он не упоминает, что по новейшим исследованиям промты для LLM сами LLM пишут лучше, чем люди:)
- Создание при помощи LLMs дизайна, слайдов, диаграмм (mermaid.js)
- Помощники для написания кода: GitHub Copilot, Cursor, Phind
- Цепочки запросов и AI-агенты - как это устроено и почему сейчас это очень перспективное направление
- Мультиагентские системы и как отдельные агенты могут объединятся в команду - подробнее в whitepaper "ChatDev: Communicative Agents for Software Development"
#AI #ML #Software #Processes #Management
YouTube
AI для разработки — базовый навык для 2024. Доклад Владислава Куклева
«С начала 2023 года я использую ChatGPT для разработки продуктов. За это время я набрал коллекцию промтов и инструментов, которые ускоряют каждый этап разработки. На этом докладе я поделюсь своими наработками, которые каждый сможет вынести и начать применять…
👍3
Forwarded from Grisha Skobelev
Сделал анонс в телеграмм, твиттере и линкедин, буду благодарен тебе если поделишься анонсом с коллегами и друзьями в своих соц сетях.
Telegram
{ между скобок } анонсы 📣
28 июля 12:00 по мск “Learning Domain-Driven Design Часть I. Cтратегическое проектирование / Геннадий Круглов”
Встретимся обсудить первую часть книги Learning Domain-Driven Design от Влада Хононова. Рассмотрим ключевые аспекты анализа бизнес-стратегий и…
Встретимся обсудить первую часть книги Learning Domain-Driven Design от Влада Хононова. Рассмотрим ключевые аспекты анализа бизнес-стратегий и…
❤2
Заметки на полях. Прочитал тут оригинал "MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS" Dr. Winston W. Rovce. E WESCON, August 1970, page 8-9. Institute of Electrical and Electronics Et)gineers,,
.328 Inc. Originally published by TRW.
Поводом стал очередной холивар в сообществе одном из крупнейших сообществ айтишников РФ про "ажайл-версус-вадапад". Собственно это одна из основополагающих статей про "программную инженерию". Первое ,что бросилось в глаза - количество ссылок на источники представлений о прекрасном. Их ровно 0. Т.е. товарищ описывает "ВАДАПАД" не ссылаясь вообще ни на что. Типа "Ну вот всё сложное софтовое создаётся так. Я сказал". Хотя надо заметить, что прослеживается отсылка на Гуда, Маккола "System's Engeneering". Она же "Системотехника" (перевод под редакцией Тарасенко, Перегудова).
И дальше товарищ начинает рассуждение о том, что неплохо бы (ОБОЖАЖМОЙ) проверять, что именно на каждом "ЭТАЖЕ". Более того, он утверждает, что единственное место, где производится тестирование - это самый конец разработки, перед вводом в эксплуатацию. Опять же, исходя из того, что он обсуждает свой собственно придуманный концепт.
А весь смысл статьи в том, что "Давайте проверять, что то, что мы делаем в софте - оно хорошее, и достаточно зрелое".
Т.е. он сразу говорит, что работать без обратных связей и проверки качества постановки задачи - дело гиблое.
Но камон! Кто сказал, что так вообще кто-то когда-то делал в сложных системах? Перед тем, как что-то сделать сложное всегда проходила куча экспертиз. Плюс в 1970-м году вообще машинное время - это ппц дорогой ресурс, там одна ЭВМ - это холодильник.
В общем у меня такое ощущение, что мы до сих пор говоря про "ВАДАПАД ПРОТИВ АЖАЙЛА" обсуждаем фантазию деда 50-ти летней давности, про которую он сам сказал, что: - "Нинада так делать".
Жесть)
.328 Inc. Originally published by TRW.
Поводом стал очередной холивар в сообществе одном из крупнейших сообществ айтишников РФ про "ажайл-версус-вадапад". Собственно это одна из основополагающих статей про "программную инженерию". Первое ,что бросилось в глаза - количество ссылок на источники представлений о прекрасном. Их ровно 0. Т.е. товарищ описывает "ВАДАПАД" не ссылаясь вообще ни на что. Типа "Ну вот всё сложное софтовое создаётся так. Я сказал". Хотя надо заметить, что прослеживается отсылка на Гуда, Маккола "System's Engeneering". Она же "Системотехника" (перевод под редакцией Тарасенко, Перегудова).
И дальше товарищ начинает рассуждение о том, что неплохо бы (ОБОЖАЖМОЙ) проверять, что именно на каждом "ЭТАЖЕ". Более того, он утверждает, что единственное место, где производится тестирование - это самый конец разработки, перед вводом в эксплуатацию. Опять же, исходя из того, что он обсуждает свой собственно придуманный концепт.
А весь смысл статьи в том, что "Давайте проверять, что то, что мы делаем в софте - оно хорошее, и достаточно зрелое".
Т.е. он сразу говорит, что работать без обратных связей и проверки качества постановки задачи - дело гиблое.
Но камон! Кто сказал, что так вообще кто-то когда-то делал в сложных системах? Перед тем, как что-то сделать сложное всегда проходила куча экспертиз. Плюс в 1970-м году вообще машинное время - это ппц дорогой ресурс, там одна ЭВМ - это холодильник.
В общем у меня такое ощущение, что мы до сих пор говоря про "ВАДАПАД ПРОТИВ АЖАЙЛА" обсуждаем фантазию деда 50-ти летней давности, про которую он сам сказал, что: - "Нинада так делать".
Жесть)
👍1
Вот годный вброс на тему, кто такой системный аналитик, и чем он занимается. Весьма хорошая отправная точка, чтобы посмотреть, и ответить на вопрос:
- А зачем Системный Аналитик нужен в проекте именно нам?
- А зачем Системный Аналитик нужен в проекте именно нам?
Telegram
Денис Бесков, Systems.Education in Comments 4 Денис Бесков
спросил пока у ясеня, в целом почти так:
Конечно, вот перечень задач для каждой из подролей системного аналитика:
а) Инженер по требованиям:
1. Сбор и документирование требований пользователей и стейкхолдеров.
2. Анализ и проверка требований на полноту…
Конечно, вот перечень задач для каждой из подролей системного аналитика:
а) Инженер по требованиям:
1. Сбор и документирование требований пользователей и стейкхолдеров.
2. Анализ и проверка требований на полноту…
👎3👍1
Заметка на полях. Статья подъехала. Ребята нашли достаточно сильное статистическое подтверждение тому, что неоднородность вселенной и наблюдаемое расширение - следствие гравитационного взаимодействия и не требует введения "тёмной энергии". И вообще, расширение вселенной может быть иллюзией наблюдателя) В самой статье они заявили достаточно громко, что требуется некоторый пересмотр стандартной Фридмановской модели. Так что, покупаем попкорн и ждём шуток про физиков в тёмной комнате, которой нет.
Для меня примечателен оказался и метод исследования в т.ч. Обрабатывались исходные данные Байесовскими статистическими методами. Генеративная АИшечка в таких вопросах, кстати, должна давать достаточно серьёзные преимущества в построении предсказаний на моделях с достаточно большим количеством весов. Если кто-то думает в эту сторону (обработка данных наблюдений всякими корелляционными методами и построение предсказаний LLMами) попрошу ещё прокомментировать это предположение. Что там есть перспективного нынче.
Для меня примечателен оказался и метод исследования в т.ч. Обрабатывались исходные данные Байесовскими статистическими методами. Генеративная АИшечка в таких вопросах, кстати, должна давать достаточно серьёзные преимущества в построении предсказаний на моделях с достаточно большим количеством весов. Если кто-то думает в эту сторону (обработка данных наблюдений всякими корелляционными методами и построение предсказаний LLMами) попрошу ещё прокомментировать это предположение. Что там есть перспективного нынче.
Заметки на полях, как фиксация некоторых размышлений на тему.
В профильных чатах разработчиков всяких ИТшненьких систем пронеслись несколько мыслей, которые стоит для себя зафиксировать:
1. Современная разработка скорее строится на народных приметах вида: "Скрам-мастер без татух - к беде"
2. В итоговом ИТ-продукте будут реализованы только те качества, за каждый из которых есть выгодополучатель.
Если ещё плюсом немного подытожить наблюдения, то можно построить типовую модель качества ИТ-системы примерно так:
- Функциональное качество (а-ля UX)
- Инфраструктурная доступность сервиса
- Стоимость вывода в пром.применение "следующей версии"
Что интересно, есть ещё один значимый, но конфликтогенный параметр - это Стоимость подержки (оно же управление инцидентами, исправление ошибок эксплуатации и т.п.). Конфликтогенный он потому, что за разработку и поддержку отвечают разные организационные единицы, чаще всего, и разработанный исходный код передаётся "как есть" тем, кто его будет дальше эксплуатировать, и "забор" проходит по приёмке "отелом девопсов".
Это хорошо кореллирует с ситуацией ещё и тем, что мы в целом чаще конформны к сложившейся среде. т.е. толерантны к негативным событиям, если они происходят в сложившемся окружении. В ИТ-шечке это можно выразить следующим образом:
- Если пользователь начал пользоваться продуктом, то он гарантированно будет ждать следующей версии, не смотря на все проблемы, которые ему это будет нести с большей вероятностью, чем искать новое решение.
Т.е. если пользователей продукта в моменте достаточно для его поддержания, то качество продукта - ПРИЕМЛЕМО. И для владельца актива по производству продукта важно защитить основных поставщиков качества. А в нашем случае это: Кодописатели, админы инфраструктуры, менеджеры с палками, которые штрафуют ФОТ.
Лично меня эта картинка подвигает на то, чтобы снижать порог толерантности, выражающийся в безусловном принятии как допустимого, и последующем бездействии к тому, что меня не устраивает в используемых мною продуктах.
В профильных чатах разработчиков всяких ИТшненьких систем пронеслись несколько мыслей, которые стоит для себя зафиксировать:
1. Современная разработка скорее строится на народных приметах вида: "Скрам-мастер без татух - к беде"
2. В итоговом ИТ-продукте будут реализованы только те качества, за каждый из которых есть выгодополучатель.
Если ещё плюсом немного подытожить наблюдения, то можно построить типовую модель качества ИТ-системы примерно так:
- Функциональное качество (а-ля UX)
- Инфраструктурная доступность сервиса
- Стоимость вывода в пром.применение "следующей версии"
Что интересно, есть ещё один значимый, но конфликтогенный параметр - это Стоимость подержки (оно же управление инцидентами, исправление ошибок эксплуатации и т.п.). Конфликтогенный он потому, что за разработку и поддержку отвечают разные организационные единицы, чаще всего, и разработанный исходный код передаётся "как есть" тем, кто его будет дальше эксплуатировать, и "забор" проходит по приёмке "отелом девопсов".
Это хорошо кореллирует с ситуацией ещё и тем, что мы в целом чаще конформны к сложившейся среде. т.е. толерантны к негативным событиям, если они происходят в сложившемся окружении. В ИТ-шечке это можно выразить следующим образом:
- Если пользователь начал пользоваться продуктом, то он гарантированно будет ждать следующей версии, не смотря на все проблемы, которые ему это будет нести с большей вероятностью, чем искать новое решение.
Т.е. если пользователей продукта в моменте достаточно для его поддержания, то качество продукта - ПРИЕМЛЕМО. И для владельца актива по производству продукта важно защитить основных поставщиков качества. А в нашем случае это: Кодописатели, админы инфраструктуры, менеджеры с палками, которые штрафуют ФОТ.
Лично меня эта картинка подвигает на то, чтобы снижать порог толерантности, выражающийся в безусловном принятии как допустимого, и последующем бездействии к тому, что меня не устраивает в используемых мною продуктах.
👍2
Заметки на полях. Про промпты. Кажется, в ближайшее время с нейросетями будет успешно работать тот кто сможет:
1. Концептуализировать процессы, и их алгоритмы
2. Концептуализировать предметную область
3. Ставить корректно задачи
Т.е. генеративные нейросетки не отменят компетентности. Они упростят распознавание лексики. Если с нейросеткой будет работать некомпетентный специалист, его результат ИИ не особо улучшит.
С другой стороны, очевидно, что будет запрос на такие нейросетки, которые смогут учить их пользователя пользоваться нейросетками =)
Отсюда для себя сделаю вывод чему стоит учиться:
1. Разрабатывать целостные, непротиворечивые описания мира
2. Описывать процессы (алгоритмизация)
3. Соблюдать контекст ведения рассуждения
4. Формулировать цели,
5 Декомпозировать цели на задачи
1. Концептуализировать процессы, и их алгоритмы
2. Концептуализировать предметную область
3. Ставить корректно задачи
Т.е. генеративные нейросетки не отменят компетентности. Они упростят распознавание лексики. Если с нейросеткой будет работать некомпетентный специалист, его результат ИИ не особо улучшит.
С другой стороны, очевидно, что будет запрос на такие нейросетки, которые смогут учить их пользователя пользоваться нейросетками =)
Отсюда для себя сделаю вывод чему стоит учиться:
1. Разрабатывать целостные, непротиворечивые описания мира
2. Описывать процессы (алгоритмизация)
3. Соблюдать контекст ведения рассуждения
4. Формулировать цели,
5 Декомпозировать цели на задачи
🔥3💯2
Заметки на инженерных полях. Был в 2023-м году на конференции "Стачка" и делал там доклад про то, какие инструменты есть и должны быть у архитектора. С тех пор значительно продвинулся в понимании этого вопроса, и на основании недавно прочитанного для себя заметочка:
Самый важный инструмент в работе архитектора, как и любого организатора коммуникаций - реалистичное представление о том, как увидеть фактическую обратную связь на принятые архитектурные решения. Ключевые вопросы, которые заметил (этакий чеклист для себя, как инструмент работы архитектора):
- Как распознать, что архитектурное решение отражает проблему, как субъективное восприятие заинтересованной стороной некоторого объективно существующего противоречия между желаемым и действительным/прогнозируемым действительным?
- Как распознать, что решение - оно вообще принято в работу и корректно понято?
- Как распознать, что решение правильно разработано?
- Как распознать, что решение правильно оценено на реализуемость?
- Как распознать, что реализация решения идёт по плану?
- Как распознать, что есть отклонения?
- Как распознать, что решение выполнено в достаточной мере, чтобы устранить исходную проблему, стимул для принятия решения?
- Как распознать, что реализованное решение действительно устранило исходную проблему/стимул?
- Как спланировать действия в будущем, на возникающие аналогичные проблемы/стимулы?
Самый важный инструмент в работе архитектора, как и любого организатора коммуникаций - реалистичное представление о том, как увидеть фактическую обратную связь на принятые архитектурные решения. Ключевые вопросы, которые заметил (этакий чеклист для себя, как инструмент работы архитектора):
- Как распознать, что архитектурное решение отражает проблему, как субъективное восприятие заинтересованной стороной некоторого объективно существующего противоречия между желаемым и действительным/прогнозируемым действительным?
- Как распознать, что решение - оно вообще принято в работу и корректно понято?
- Как распознать, что решение правильно разработано?
- Как распознать, что решение правильно оценено на реализуемость?
- Как распознать, что реализация решения идёт по плану?
- Как распознать, что есть отклонения?
- Как распознать, что решение выполнено в достаточной мере, чтобы устранить исходную проблему, стимул для принятия решения?
- Как распознать, что реализованное решение действительно устранило исходную проблему/стимул?
- Как спланировать действия в будущем, на возникающие аналогичные проблемы/стимулы?
👍1
Заметки на полях. Сегодня имел беседу про то, что такое управление конфигурацией. Как всегда. Две поляны между собой перекидываются какахами, кто более прав, а кто Лев...
1. Управление конфигурацией продукта (мутная тема достаточно, и крутится вокруг маркетинговых понятий в основном. Что-то типа "фича", "сторя","бизнес-ценность"... В русском понятийном пространстве это вообще заклинания, так-то).
2. Управление конфигурацией системы. А это про тяжёлые методологические абстракции высокого уровня вложенности.
Вы уже догадались, кто и чем может управлять? Правильно! Кто что в руках держит, тот и управляет. Если программист щупает код - то для него вся эта история про "бизнес-ценность" - это про подписанный акт приёмки. Точка. Если акт подписали, морду не разбили, руки не отрубили - бизнес ценность есть! Доказывать, что то, что я делаю сейчас соответствует ожиданиям "бизнеса"? Так код напишу, он сам себя и докажет! Это ж математика! Если работает и акт подписан - значит всё ок, ничего никому доказывать не надо! (Л - Логика ушла поспать на определении транзитивности отношений. Это второй курс. Дискретная математика. Разделы логика предикатов. Если что.)
А на уровне "Продуктовых аналитиков" есть что угодно, затем трактуемое как угодно. Зачем формализовывать потребности? Достаточно же написать "должна быть безопасная фича". И "квалифицированная, мотивированная команда экспертов".... У нас же все кто в ИТ высококвалифицированные, мотивированные команды профессионалов, да?)
В итоге имеем "аналитиков", которые сидят за плечами у "программистов" и говорят:
- А тут кароч кнопку такую, филолетовенькую, нарисуй, Василич просил, у него жена будет на показе, а она в таких туфлях ходить любит.
И когда Василич после показа софта с кнопкой подписывает акт, а потом спрашивает: - Куда бабки дели, ироды!? - то зовут сначала аналитика, который зовёт программиста, который говорит: - Василич, ну чо ты начинаешь, акт же подписали! И вроде все довольны, но что-то говной воняет...
Поэтому пока впечатление такое:
Искусственный интеллект не сможет победить естественный. То, что не существует, не сможет победить то, что стремится исчезнуть)
#идейное #управление_конфигурацией
1. Управление конфигурацией продукта (мутная тема достаточно, и крутится вокруг маркетинговых понятий в основном. Что-то типа "фича", "сторя","бизнес-ценность"... В русском понятийном пространстве это вообще заклинания, так-то).
2. Управление конфигурацией системы. А это про тяжёлые методологические абстракции высокого уровня вложенности.
Вы уже догадались, кто и чем может управлять? Правильно! Кто что в руках держит, тот и управляет. Если программист щупает код - то для него вся эта история про "бизнес-ценность" - это про подписанный акт приёмки. Точка. Если акт подписали, морду не разбили, руки не отрубили - бизнес ценность есть! Доказывать, что то, что я делаю сейчас соответствует ожиданиям "бизнеса"? Так код напишу, он сам себя и докажет! Это ж математика! Если работает и акт подписан - значит всё ок, ничего никому доказывать не надо! (Л - Логика ушла поспать на определении транзитивности отношений. Это второй курс. Дискретная математика. Разделы логика предикатов. Если что.)
А на уровне "Продуктовых аналитиков" есть что угодно, затем трактуемое как угодно. Зачем формализовывать потребности? Достаточно же написать "должна быть безопасная фича". И "квалифицированная, мотивированная команда экспертов".... У нас же все кто в ИТ высококвалифицированные, мотивированные команды профессионалов, да?)
В итоге имеем "аналитиков", которые сидят за плечами у "программистов" и говорят:
- А тут кароч кнопку такую, филолетовенькую, нарисуй, Василич просил, у него жена будет на показе, а она в таких туфлях ходить любит.
И когда Василич после показа софта с кнопкой подписывает акт, а потом спрашивает: - Куда бабки дели, ироды!? - то зовут сначала аналитика, который зовёт программиста, который говорит: - Василич, ну чо ты начинаешь, акт же подписали! И вроде все довольны, но что-то говной воняет...
Поэтому пока впечатление такое:
Искусственный интеллект не сможет победить естественный. То, что не существует, не сможет победить то, что стремится исчезнуть)
#идейное #управление_конфигурацией
😁1