Таким образом, оно добавляло допущение только для одного типа наблюдений, и количество предсказаний с допущением уменьшалось. В конечном счёте модель эфира была отброшена не непосредственно наблюдениями, а специальной теорией относительности Эйнштейна, которая имела меньше допущений и большую предсказательную способность, чем конкурирующая модель. По критерию наблюдений специальная теория относительности получила более высокий ранг, чем модель эфира.
Однако, эфирная теория Лоренца в плане предсказаний эквивалентна СТО.
Как же он “пришёл”? Ну вот есть понятный вариант с яблоком. Индуктивных умозаключений пока не просматривается. Т.е. яблоко, пусть как как обобщённый символ озарения, пока не имеет альтернативы.🍎🤯
также наблюдая эллиптические орбиты небесных тел вокруг Солнца и Луны вокруг Земли,
Я полагаю, что “элиптические орбиты” это модель, а не наблюдения.
по индукции и вывели
Мне знакомы такие виды индукции - математическая индукция, неполная индукция, полная индукция. Все эти виды предполагают определённую формальную запись. Всё-таки, хотелось бы посмотреть на индуктивный вывод закона тяготения.
Пока для описания явлния есть только модель с яблоком, которое упало прямо на голову Ньютону, после чего он сразу понял суть гравитации. Ну т.е. что-то копилось, копилось в нейронных сетях молодого Исаака, и вот, бац - insight. Это понятно, но это не индукция.
Senior-инженеры успевают пройти путь от наброска на доске до рабочего прототипа еще до обеда. Но кто-то все равно должен ловить пробелы в безопасности, compliance-риски и архитектурные противоречия, спрятанные в годах неформального знания команды.
В моей команде одна инженер уровня L5 потратила почти три дня на то, чтобы остановить AI-сгенерированный сценарий аутентификации, который создал бы пробелы в журнале аудита в регулируемой системе.
Проектирование схемы аутентификации и её требований (включая требования к журналу аудита) — это senior-уровень ответственности. “Ловить” на этапе, когда ИИ уже сгенерировал сценарий/код, — это слишком поздняя точка контроля.
Тут похоже на то, что процесс деформировался – senior-ы, увлёкшись “от наброска до прототипа до обеда”, перестали как следует прорабатывать постановку и design review, и контроль качества переместился вниз, на middle, уже на этапе готового кода. И вот, middle-инженер де-факто выполняет senior-функцию, но без соответствующего признания.
Точнее было бы сказать: индустриальный консенсус не “против RAG”, а “против embedding-based retrieval как retrieval-механизма по умолчанию”. Большинство инструментов используют текстовый (grep/regex) retrieval вместо векторного, оставляя эмбеддинги для узкого класса семантических запросов. Grep – это тоже форма retrieval, так что RAG как класс тут никуда не исключается. Меняется лишь то, чем наполнено R.
Но выстраданное уточнение: DDD – это про бакенд. Именно там живёт то, ради чего DDD придуман: инварианты, транзакции, бизнес-правила, согласованность данных.
Однако, DDD придуман для другого. А именно – для синхронизации людей (domain experts <-> engineers, заказчик <-> исполнитель) вокруг одной модели предметной области, для управления сложностью решения задач из предметной области через построение декомпозированной модели, разделяемой бизнесом и разработчиками через общий язык – Ubiquitous Language.
И вот этот самый Ubiquitous Language – он вполне уместен для пояснения “фронтовикам”, что же нужно сделать. Собственно, ТЗ составляется с использованием понятийного аппарата из соответствующего bounded context. Далее по коду, который написан в соответствии со словарём, можно “грепать” или “триграмить” (как это делает Cursor для объёмных кодовых баз) или даже делать RAG.
Стратегическая часть DDD – описание домена, карта контекстов и Ubiquitous language – ключевая для понимания системы со стороны участников процесса. Да и для onboarding отличная штука. Именно UL и нужен, чтобы с “фронтовиком” общаться.
Возьмём тактическую часть DDD – допустим, Aggregate. Как паттерн моделирования (кластер сущностей + инварианты) он нужен везде, где есть сложная составная сущность, редактируемая как единое целое, включая фронт.
Соглашусь, что тот структурный шаблон, что Вы рассмотрели, на фронте действительно не приживается. Но bounded context и Ubiquitous Language относятся и к фронту, и к бэку одновременно: у обоих один и тот же язык и одни и те же понятия внутри контекста, просто бэкенд защищает инварианты, а фронт их использует (отображение, редактирование). Поэтому документы стратегического DDD (описание доменов, карта контекстов, словарь) остаются отличным источником для генерации фронтового кода – типов, форм, текстов ошибок.
Можно тут пояснить, вроде как $5 / $25? Потом, по подписке получаются гораздо более низкие “эквивалентные” цены…
С другой стороны, Deep Seek тоже демпингует: $3.48 $0.87 (75% off(3))
Ну и по ссылке, как достигнут мега-контекст. Иновационный метод таков: DeepSeek’s innovation was to make the model more selective about what it pays attention to. Instead of treating all earlier text as equally important, V4 compresses older information and focuses on the parts most likely to matter in the present moment, while still keeping nearby text in full so it does not miss important details.
сразу пойду заниматься гомосексуализмом, сатанизмом, квадроберством и донатить фашистам
Тут не совсем однородные члены предложения, КМК. Было бы интересно узнать, каково Ваше определение понятия “фашисты”. Потому что, например, “фашистский режим Бенито Муссолини в Италии придерживался враждебного отношения к гомосексуализму, основываясь на идеологии культа силы, мужества и традиционных семейных ценностей”.
Вы же, кстати, за мужество и традиционные семейные ценности?
В своё время я уже присматривался к OpenSpec, но остались несколько неясностей, из-за которых мы тогда не стали его внедрять. Хотелось бы поделиться наблюдениями.
В README.md /opsx:propose и /opsx:apply подаются как ключевые команды, однако в спеках их описания нет. Зато присутствуют specs/ai-tool-paths/spec.md и artifact-graph/spec.md, которые, на мой взгляд, относятся скорее к внутренним контрактам, чем к user-facing.
В целом, складывается впечатление, что у OpenSpec пока есть сложности с тем, чтобы отразить собственный functional design.
Что касается technical design - я не нашёл, где можно посмотреть текущую архитектуру: какие есть компоненты, кто кого вызывает, как устроены границы. README.md предлагает выполнить npm install -g @fission-ai/openspec@latest, но мотивация именно такого шага на этом этапе для меня не вполне очевидна.
В текущем виде, для задач моей области, этого, к сожалению, оказывается недостаточно.
С агентами вот такая штука, по моей практике (системный архитектор вот тут).
Составление спецификаций (ТЗ) занимает процентов 80% времени, и агент составить её самостоятельно не может, тут польза в “парном проектировании”. На этапе construction надо смотреть, что эти агенты делают, причём детально, иначе накапливается Comprehension Debt.
По моему опыту для прототипа или MVP все эти привлечения “команд агентов” хороши. Для продукта в активной эксплуатации использовании ИИ более напоминает использование экзоскелета, чем использование дополнительной команды агентов-инженеров.
GitHub Copilot ввёл свой стандарт Agent Skills, Anthropic, OpenAI и Google сошлись на похожем формате.
Можно подробнее про “GitHub Copilot ввёл свой стандарт”? Они разве не используют open standart?
И еще вопрос - непонятно, как SKILL передаётся при использовании: “Все четыре — через OpenRouter, одним API-ключом, одинаковый формат запросов, temperature=0. Ключевые обращения — по 20 повторов, остальные — по 5. Итого 480 запусков со скиллом”.
То, что хранится в .claude/commands/. В начале прошлого года уже можно было делать, вот tutorial весны 2025 года.
Второй пример. Вызов с оборудования определённых функций, получение данных, передача в калькулятор и пересчёт различных параметров с выдачей на гора результата. Например пересчёт из количества секторов в пуле массива в терабайты или тибибайты.
Можете пояснить, как эту задачу решает skill? MCP, вызов какого-то cli? Пока непонятно, в чём преимущество перед командами.
Однако, эфирная теория Лоренца в плане предсказаний эквивалентна СТО.
Разве это мешает ей быть моделью?
Как же он “пришёл”? Ну вот есть понятный вариант с яблоком. Индуктивных умозаключений пока не просматривается. Т.е. яблоко, пусть как как обобщённый символ озарения, пока не имеет альтернативы.🍎🤯
Я полагаю, что “элиптические орбиты” это модель, а не наблюдения.
Мне знакомы такие виды индукции - математическая индукция, неполная индукция, полная индукция. Все эти виды предполагают определённую формальную запись. Всё-таки, хотелось бы посмотреть на индуктивный вывод закона тяготения.
Пока для описания явлния есть только модель с яблоком, которое упало прямо на голову Ньютону, после чего он сразу понял суть гравитации. Ну т.е. что-то копилось, копилось в нейронных сетях молодого Исаака, и вот, бац - insight. Это понятно, но это не индукция.
Хотелось бы, конечно, посмотреть на вывод по индукции законов тяготения…
Тут интересно посмотреть на определение научной индукции, в котором утверждается эта самая “непогрешимость”…
Но, в целом, интересная подборка и обзор источников.
Да, не очень понятно применение из статьи. Мегаполисы освещать по ночам? Там небо, кстати, и так “убито”.
Проектирование схемы аутентификации и её требований (включая требования к журналу аудита) — это senior-уровень ответственности. “Ловить” на этапе, когда ИИ уже сгенерировал сценарий/код, — это слишком поздняя точка контроля.
Тут похоже на то, что процесс деформировался – senior-ы, увлёкшись “от наброска до прототипа до обеда”, перестали как следует прорабатывать постановку и design review, и контроль качества переместился вниз, на middle, уже на этапе готового кода. И вот, middle-инженер де-факто выполняет senior-функцию, но без соответствующего признания.
Точнее было бы сказать: индустриальный консенсус не “против RAG”, а “против embedding-based retrieval как retrieval-механизма по умолчанию”. Большинство инструментов используют текстовый (grep/regex) retrieval вместо векторного, оставляя эмбеддинги для узкого класса семантических запросов. Grep – это тоже форма retrieval, так что RAG как класс тут никуда не исключается. Меняется лишь то, чем наполнено
R.Замечательная статья, спасибо. 👍
Небольшая “реплика из зала”.
Однако, DDD придуман для другого. А именно – для синхронизации людей (domain experts <-> engineers, заказчик <-> исполнитель) вокруг одной модели предметной области, для управления сложностью решения задач из предметной области через построение декомпозированной модели, разделяемой бизнесом и разработчиками через общий язык – Ubiquitous Language.
И вот этот самый Ubiquitous Language – он вполне уместен для пояснения “фронтовикам”, что же нужно сделать. Собственно, ТЗ составляется с использованием понятийного аппарата из соответствующего bounded context. Далее по коду, который написан в соответствии со словарём, можно “грепать” или “триграмить” (как это делает Cursor для объёмных кодовых баз) или даже делать RAG.
Стратегическая часть DDD – описание домена, карта контекстов и Ubiquitous language – ключевая для понимания системы со стороны участников процесса. Да и для onboarding отличная штука. Именно UL и нужен, чтобы с “фронтовиком” общаться.
Возьмём тактическую часть DDD – допустим, Aggregate. Как паттерн моделирования (кластер сущностей + инварианты) он нужен везде, где есть сложная составная сущность, редактируемая как единое целое, включая фронт.
Соглашусь, что тот структурный шаблон, что Вы рассмотрели, на фронте действительно не приживается. Но bounded context и Ubiquitous Language относятся и к фронту, и к бэку одновременно: у обоих один и тот же язык и одни и те же понятия внутри контекста, просто бэкенд защищает инварианты, а фронт их использует (отображение, редактирование). Поэтому документы стратегического DDD (описание доменов, карта контекстов, словарь) остаются отличным источником для генерации фронтового кода – типов, форм, текстов ошибок.
Интересный кейс. Есть пара вопросов, если можно. Какой-то был PRD, с чего всё начиналось? Почему не openspec?
Интересно, т.е. даже со “средним во всём”, всё равно выходит, что “за несколько вечеров написал линтер, который без Spec-Kit писал бы пару месяцев”?
Можно тут пояснить, вроде как $5 / $25? Потом, по подписке получаются гораздо более низкие “эквивалентные” цены…
С другой стороны, Deep Seek тоже демпингует:
$3.48$0.87 (75% off(3))Ну и по ссылке, как достигнут мега-контекст. Иновационный метод таков: DeepSeek’s innovation was to make the model more selective about what it pays attention to. Instead of treating all earlier text as equally important, V4 compresses older information and focuses on the parts most likely to matter in the present moment, while still keeping nearby text in full so it does not miss important details.
Тут не совсем однородные члены предложения, КМК. Было бы интересно узнать, каково Ваше определение понятия “фашисты”. Потому что, например, “фашистский режим Бенито Муссолини в Италии придерживался враждебного отношения к гомосексуализму, основываясь на идеологии культа силы, мужества и традиционных семейных ценностей”.
Вы же, кстати, за мужество и традиционные семейные ценности?
Интересно. Можно поподробнее про понимание? Вот после agentic tool, чем тут хуже?
Судя по ap - правильно понимаю, что работа с AI идёт через браузер, а не через agentic tools типа claude code?
В своё время я уже присматривался к OpenSpec, но остались несколько неясностей, из-за которых мы тогда не стали его внедрять. Хотелось бы поделиться наблюдениями.
В README.md
/opsx:proposeи/opsx:applyподаются как ключевые команды, однако в спеках их описания нет. Зато присутствуют specs/ai-tool-paths/spec.md и artifact-graph/spec.md, которые, на мой взгляд, относятся скорее к внутренним контрактам, чем к user-facing.В целом, складывается впечатление, что у OpenSpec пока есть сложности с тем, чтобы отразить собственный functional design.
Что касается technical design - я не нашёл, где можно посмотреть текущую архитектуру: какие есть компоненты, кто кого вызывает, как устроены границы. README.md предлагает выполнить
npm install -g @fission-ai/openspec@latest, но мотивация именно такого шага на этом этапе для меня не вполне очевидна.В текущем виде, для задач моей области, этого, к сожалению, оказывается недостаточно.
Очень круто🔥 Если есть возможность, сделайте кнопку (или ещё как), как задонатить.
Касательно AI-Driven - как организована работа c AI? Какие-то инструменты, типа spec-driven framework, использовали?
С агентами вот такая штука, по моей практике (системный архитектор вот тут).
Составление спецификаций (ТЗ) занимает процентов 80% времени, и агент составить её самостоятельно не может, тут польза в “парном проектировании”. На этапе construction надо смотреть, что эти агенты делают, причём детально, иначе накапливается Comprehension Debt.
По моему опыту для прототипа или MVP все эти привлечения “команд агентов” хороши. Для продукта в активной эксплуатации использовании ИИ более напоминает использование экзоскелета, чем использование дополнительной команды агентов-инженеров.
Можно подробнее про “GitHub Copilot ввёл свой стандарт”? Они разве не используют open standart?
И еще вопрос - непонятно, как SKILL передаётся при использовании: “Все четыре — через OpenRouter, одним API-ключом, одинаковый формат запросов, temperature=0. Ключевые обращения — по 20 повторов, остальные — по 5. Итого 480 запусков со скиллом”.
Интересная статья, воспользуюсь, при случае.
Однако ж…:
Это не вайбокодинг, если смотреть на исходное определение:
Вот это настоящее искусство☝️. А то, что Вы описали - ну каждый ведь может. Кто способен глянуть diff и оценить “нормальность”.
Автор термина, кстати, сейчас предлагает использовать понятие agentic engineering.
То, что хранится в .claude/commands/. В начале прошлого года уже можно было делать, вот tutorial весны 2025 года.
Можете пояснить, как эту задачу решает skill? MCP, вызов какого-то cli? Пока непонятно, в чём преимущество перед командами.
Впрочем, прочитал внимательнее - в статье это отражено, чуть дальше.