Короткая заметка: ещё весной я проводил курс по применению ИИ для системных аналитиков. Ну и до этого в нескольких вариантах: курсы, лекции, мастер-классы.
Но уже летом я начал думать, как его менять. И, в общем, многое, что я там рассказывал, не особо уже актуально.
Раньше в курсах ведь что рассказывали: вот есть такие модели, вот так нужно составлять промпты, такие вот формулировки использовать... Но сейчас это всё уже ушло в прошлое. Если модель вас не понимает — возьмите нормальную топовую модель, перестаньте есть кактус. Не нужно уже растолковывать модели каждый шаг и расписывать роли. Всё это ушло в системные инструкции, rules.md и скиллы. И занимаются этим специальные люди — ну, впрочем, те, кто до этого экспериментировал с промптами. Хитрые промпты были нужны, когда модель вообще не понимала, чего от неё хотят. Сейчас такого у верхних моделей уже почти не встречается.
Сейчас горячие темы — управление контекстом, харнесс, гардрейлы, цепочки вызовов и проверок. Как кормить LLM контекстом и какие промежуточные артефакты она должна генерировать, чтобы и самой не запутаться, и человек мог быстро проверить, вот основные вопросы. Но ответов на них пока нет, потому что мы — сюрприз! — не до конца понимаем, что именно и как делает системный аналитик. В чем его основаная польза? Как проверить качество его работы? Где граница деятельности? Кто умеет на это отвечать, тот сможет построить ИИ-пайплайн, включающий задачи аналитика. Ну или будет пользоваться готовыми spec-kit или OpenSpec.
Вот только эти SDD-инструменты пришли с запада, а там, как мы знаем, организация разработки несколько отличается, и аналитиков уже давно нет. Ну и как работать с требованиями они, значит, тоже уже забыли. Программистам это всё тоже не нужно и не интересно, они приниципиально не понимают: "На первый взгляд может показаться, что эти требования и сценарии слишком очевидны. Но, во-первых, очевидные вещи тоже нужно где-то зафиксировать. Во-вторых, OpenSpec сгенерировал их самостоятельно — видимо, они ему всё-таки нужны." (это цитата из рандомной статьи программиста про SDD с Хабра). Требования, наверное, зачем-то нужны, ну пусть будут. Разработчика интересует, как всегда, другое — чтобы тесты были, чтобы стиль кода соблюдался, чтобы миграции нормально сформировались и применились.
В этом есть очевидный (нам с вами) риск: всё сделано, как положено с точки зрения программиста, но в результате получилась какая-то фигня. Потому что требования толком никто не проверял и не анализировал.
Дальше возникает интересный вопрос: нужно ли нам всё ещё сохранять две отдельные роли аналитика и разработчика (которые обе проверяют работу ИИ, но проверяют в ней разное), или у нас возникнут новые фулл-стеки, как броненосцы в сказке Киплинга — разработчики научатся видеть смысл в требованиях, а аналитики начнут понимать нюансы разработки? Или всех их просто сметет, и все эти вопросы через пару итераций погрузятся так глубоко, что только узкие специалисты будут знать, как так внутри устроены спеки/код/релизные пайплайны, как сейчас мало кто задумывается об устройстве конвейера и ветвлений в процессоре?
История разделения труда дает нам двоякие примеры: с одной стороны, углубление разделения труда, с другой — наоборот, поглощение чисто навыковых профессий. Когда-то ретушер, линотипист и чертежник были отдельными профессиями, но цифра их съела. И все просто чертежники стали чертежниками-конструкторами. Кем станут аналитики, вот вопрос.
Но уже летом я начал думать, как его менять. И, в общем, многое, что я там рассказывал, не особо уже актуально.
Раньше в курсах ведь что рассказывали: вот есть такие модели, вот так нужно составлять промпты, такие вот формулировки использовать... Но сейчас это всё уже ушло в прошлое. Если модель вас не понимает — возьмите нормальную топовую модель, перестаньте есть кактус. Не нужно уже растолковывать модели каждый шаг и расписывать роли. Всё это ушло в системные инструкции, rules.md и скиллы. И занимаются этим специальные люди — ну, впрочем, те, кто до этого экспериментировал с промптами. Хитрые промпты были нужны, когда модель вообще не понимала, чего от неё хотят. Сейчас такого у верхних моделей уже почти не встречается.
Сейчас горячие темы — управление контекстом, харнесс, гардрейлы, цепочки вызовов и проверок. Как кормить LLM контекстом и какие промежуточные артефакты она должна генерировать, чтобы и самой не запутаться, и человек мог быстро проверить, вот основные вопросы. Но ответов на них пока нет, потому что мы — сюрприз! — не до конца понимаем, что именно и как делает системный аналитик. В чем его основаная польза? Как проверить качество его работы? Где граница деятельности? Кто умеет на это отвечать, тот сможет построить ИИ-пайплайн, включающий задачи аналитика. Ну или будет пользоваться готовыми spec-kit или OpenSpec.
Вот только эти SDD-инструменты пришли с запада, а там, как мы знаем, организация разработки несколько отличается, и аналитиков уже давно нет. Ну и как работать с требованиями они, значит, тоже уже забыли. Программистам это всё тоже не нужно и не интересно, они приниципиально не понимают: "На первый взгляд может показаться, что эти требования и сценарии слишком очевидны. Но, во-первых, очевидные вещи тоже нужно где-то зафиксировать. Во-вторых, OpenSpec сгенерировал их самостоятельно — видимо, они ему всё-таки нужны." (это цитата из рандомной статьи программиста про SDD с Хабра). Требования, наверное, зачем-то нужны, ну пусть будут. Разработчика интересует, как всегда, другое — чтобы тесты были, чтобы стиль кода соблюдался, чтобы миграции нормально сформировались и применились.
В этом есть очевидный (нам с вами) риск: всё сделано, как положено с точки зрения программиста, но в результате получилась какая-то фигня. Потому что требования толком никто не проверял и не анализировал.
Дальше возникает интересный вопрос: нужно ли нам всё ещё сохранять две отдельные роли аналитика и разработчика (которые обе проверяют работу ИИ, но проверяют в ней разное), или у нас возникнут новые фулл-стеки, как броненосцы в сказке Киплинга — разработчики научатся видеть смысл в требованиях, а аналитики начнут понимать нюансы разработки? Или всех их просто сметет, и все эти вопросы через пару итераций погрузятся так глубоко, что только узкие специалисты будут знать, как так внутри устроены спеки/код/релизные пайплайны, как сейчас мало кто задумывается об устройстве конвейера и ветвлений в процессоре?
История разделения труда дает нам двоякие примеры: с одной стороны, углубление разделения труда, с другой — наоборот, поглощение чисто навыковых профессий. Когда-то ретушер, линотипист и чертежник были отдельными профессиями, но цифра их съела. И все просто чертежники стали чертежниками-конструкторами. Кем станут аналитики, вот вопрос.