BlaNote | Дзен

Векторное мышление: как задавать направление вместо формулировок

Мы привыкли считать, что мышление - это работа со словами. Чётко сформулировал - получил результат. Ошибся в формулировке - получил неправильный ответ. Работа с большими языковыми моделями (LLM) показывает, что это представление неполное. Куда важнее не что именно ты сказал, а в каком направлении ты указал. Этот способ мышления всё чаще называют векторным. Векторное мышление - это подход, при котором: смысл представляется не как текст или формула, а как точка или направление в многомерном пространстве признаков...

2 недели назад

Написание логики без if/else на примере Java.

if и else уходят в закат Иногда на уме возникают какие-то безумные идеи - как писать логику без операций ветвления? Да, такая тема существует - ниже я объясню зачем, как это работает, какие техники используют, и в каких случаях это реально даёт пользу, а где - это просто красивая теория, которая на практике вредна. Зачем вообще избавляться от if/else. Коротко: Когда мотив имеет смысл 1. Слишком много if/else или switch - код трудно читать и невозможно расширять без правок. 2. Появляется состояние, зависящее от типа/статуса/режима, и каждый новый тип добавляет новые ветки...

1 месяц назад

«анти-vibe-coding» Мне тут ChatGPT сказал, что я, оказывается, занимаюсь «анти-vibe-coding'ом». Методология SDD (Spec-Driven Development) - это не формальный стандарт вроде Scrum или TDD, а современный подход к разработке, который делает спецификацию центральным элементом всего процесса. По сути, это «анти-vibe-coding» подход: - Сначала - чётко формулируем, что и зачем мы делаем. - Потом - реализуем ровно то, что описано. - И проверяем, что результат соответствует спецификации. Суть SDD (Spec-Driven Development) можно описать формулой: | Спецификация - План - Реализация - Проверка соответствия В отличие от классического "code-driven" подхода, где код рождает документацию постфактум, здесь всё наоборот: - Спецификация задаёт направление. - Реализация служит доказательством. - Документация - не побочный продукт, а фундамент. Основные принципы. Specification First - любая фича начинается с текстовой (или формальной) спецификации - описания цели, сценариев, ограничений, допущений. Traceability - каждый кусок кода должен иметь соответствующую запись в спецификации. Это обеспечивает прозрачность и контроль изменений. Predictable Outcomes - мы формулируем, что считаем успешным результатом заранее. Код проверяется не просто на корректность, а на соответствие ожидаемому поведению. Iterative Refinement - спецификация не статична - её можно уточнять по мере исследования, но изменения должны быть осознанными и фиксироваться. Human-AI Co-development (новая черта) - в эпоху Copilot/ChatGPT спецификация становится интерфейсом не только между людьми, но и между человеком и ИИ-ассистентом: она описывает намерения, чтобы ИИ мог правильно генерировать код.

3 месяца назад

Как ИИ воспринимает форматированный документ?

В статье на Habr я рассказывал про форматированные документы - правила, рассуждал о возможности их применения как инструкции, спецификации и шаринг между команды в разработки программного приложения. Есть интересный пример и его разбор который не вошел в статью. В модуле нашего приложения `create` есть форматированный документ, который является описанием обработки ошибок: CREATE_ERROR_HANDLING.md # TRIGGER: ERROR_HANDLING_CREATE ## Контекст В модуле `create` реализована специализированная обработка ошибок для валидации создания постов...

3 месяца назад

VibeCode. Как не назови все равно полетит Plain Text vs XML or Markdown: на чём писать промпты для ИИ-кодера? Структура — это новый язык общения с ИИ. Особенно когда дело касается кода. Есть миф: чтобы попросить ИИ написать код, достаточно набросать запрос в чат «как есть». Plain text, без правил. Сработает? Иногда. Будет эффективно? Редко. Почему ИИ «понимает» структурированный промпт (с тегами, отступами, чёткими блоками) лучше, чем простой текст? Читать далее habr.com/...794/

3 месяца назад