Комментарии 4
Все это убеждает меня в том что я правильно выбрал путь - изучение бизнес и системного анализа, вместо разработки. Опыт разработки есть, но там я так же часто проектировал, на фрилансе, рисуя на бумаге для себя. А сейчас изучая область, становится понятно, насколько эффективнее все было бы имея я хорошо продуманную модель перед ее реализацией.
В закладки однозначно. И доставляет отдельно про сокращение книги, тоже к тому же выводу пришел, что читать и слушать все же лучше полностью, просто из-за того что нервная система не успевает переваривать сжатую информацию эффективно, и возникает явный дефицит контекста для закрепления.
Ожидаю появление новых языков для vibecoding в направлении DDD \ DSL. Полагаю, что это будет в развитие исполняемого BPMN, куда добавят модель данных / docflow. И конечно сам BPMN-AI будет куда более понятный и реально low-code \ no-code (сегодняшний исполняемый BPMN - все равно требует "много кода", хотя его почему-то называют low-code).
В целом вектор новых AI-языков программирования: Model-First, Предметно-ориентированное проектирование через DSL (специальные framework как для бизнес-домена, так и типовых интерфейсов), semantic layer (типовые онтологии предметной области + технологические онтологии интерфейсов), визуальное программирование (визуальные конструкции, визуализация логики \ алгоритмов), включая моделирование данных (в т.ч. noSQL), причем в связке workflow \ docflow. Что-то в эту сторону.
И все это "в одном флаконе": "программирование без программирования", точнее "спускаться" до кода java\js\c\etc будет можно, но (утрировано) как сейчас смотреть ассемблер. Может уже есть подобное?
Вот в какую ловушку я неоднократно попадал. В инженерных командах легко создаётся впечатление, как будто мы уже разобрались во всех деталях: мы же программисты‑эксперты, знаем наши паттерны и придерживаемся наилучших практик. Нам просто нужен кто‑то (заинтересованный представитель бизнеса или продукт‑менеджер), который нам скажет, что делать.
Проблема, наверное, заключается в том, что все стремятся получить какую-то одну модель предметной области. В то же время, никакой одной модели не может быть. Есть разные модели и эти модели различаются степенью детализации (менее подробная и более подробная), уровнем рассмотрения (физическая, логическая и концептуальная модели) и способом рассмотрения (статический способ и динамический способ). Причём, всё это надо учитывать в комплексе.
В свою очередь, суть системного анализа заключается в том, чтобы находить в различных предметных областях одни и те же составляющие, хотя бы даже и называемые различным образом. Идеальное программирование — это программирование этих самых составляющих. Языковые модели, в этом смысле, призваны декодировать каждую предметную область с последующей обратной кодировкой.
Программисты очень любят использовать свои любимые "паттерны", то есть — любят навязывать предметной области какие-то свои заранее выбранные "наилучшие практики".
Модели и агенты постоянно совершенствуются, но полностью доверять им нельзя. Они по‑прежнему допускают ошибки, и нужен человек, полностью отвечающий за проект. Как можно убедиться, что результат работы агента верен?
А у нас есть критерий верности решения каждой задачи? Мы всегда имеем дело со спорными ситуациями. Например, нельзя предложить структуру, которая была бы одновременно расширяемой (вроде связного списка), и допускала бы быстрый доступ (вроде простого массива). Всегда приходится выбирать и где-то проводить границу. Проверяемость — это всегда доказательство некоторой теоремы, но специалисты по математической логике давно нам доказали неразрешимость этой задачи. Но, даже, если мы хотим добиться хотя бы относительной проверяемости, то нам понадобятся аксиомы, исходные объекты и правила вывода. А это уже целые базы знаний! Ничего этого пока ещё нет. То есть — этим активно занимались в 80-тые и 90-тые годы прошлого века. Похоже, настало время вернуть в строй эти концепции. И это означает, что (почти по известному фильму)))) "агенты начнут видеть сны, у агентов появятся секреты" (с) [ почти, (с) ].
Основная мысль статьи посещала меня много раз в разное время, но она была слабо материализована в реальных проектах, попытки бывали

Парадигма DDD стала гораздо важнее, когда ИИ пишет код за вас