#AI

Прикольный мини-тренажер по промптингу. Поиграйтесь сами, отправьте друзьям. Особенно тем, которые не могут начать.

https://prompttrainer.replit.app/

Тут можно накидать фидбека автору: https://xn--r1a.website/Gpt_budni/13

#архитектура

Сижу, готовлюсь к занятию завтра, никого не трогаю, и тут мне присылают ЭТО. Открыл на 5 минут, залип на пару часов.

Это как Tower Defense, только нужно строить архитектуру из брокеров, хранилищ, балансеров, гейтвеев и фаерволов, чтобы не умереть под растущим трафиком и заработать кучу золота.

Можно запускать в браузере, можно поставить локально: https://github.com/pshenok/server-survival

Легальный способ прокрастинации в рабочее время под видом обучения и тестирования новой архитектуры. Пишите, какой у вас рекорд.

Кстати, про обучение. Так уж совпало, что все паттерны и технологии из игры мы разбираем на курсе интеграция и архитектура систем, начинаем завтра, до осени повторов не планирую.

Если кто-то страдает из-за недоступности swagger editor в РФ, то держите замену: https://forge.etsi.org/swagger/editor/

Тут трехдневная конфа про ИИ-разработку от стратоплана стартовала, пока интересно

https://entropy-x-stratoplan.com

Товарищи продакты, смотрите, что тинек выкатил. Оно бесплатное, правда с экзаменом:

https://education.tbank.ru/experience-in-it/ml-product/

#вайбкодинг

Чет подумал, что между аналитиком-проектировщиком и разработчиком лежит пропасть в плане фидбека от реальности.

Разраб каждый день что-то собирает, тестит, запускает. Результат, который можно пощупать руками, виден постоянно. Каждый день ощущаешь какой-то акт творения, который подкидывает простого дофамина. Ну как простого.

Аналист днями-неделями-месяцами пытается понять, что тут нахрен происходит, как со всеми договориться, и как бы все это собрать, чтобы оно работало. Результат — спеки и таски, которые однажды (возможно) кто-то запилит и выкатит. Акт творения почувствовать сложнее, нередко приходится добывать дофаминку из социальных поглаживаний. А я ж социопат

Интересно, каким было бы распределение по уровню счастья и депрессий?

Но вайбкодинг меняет игру.

Как разраба меня подбешивает, что работа превращается в постоянное ожидание кода от агента, которое сменяется нудным ревью и отладкой его креативов. Нереально сфокусироваться и войти в поток, удовольствие от работы минимальное.

Как аналист я счастлив: проектирую всякие штуки, могу пощупать и оценить результат без команды и всех этих кожаных. Ожидание и ревью — лишь небольшие издержки.

А чему ты радуешься на работе, юзернейм?

#манагерское

Выводы, которые большинство сделает из поста:

— Вот видите, никому не нужна ваша чистая архитектура, профессиональный инженер говорит!

— Мы же говорили, во всех проблемах, включая разработку, виноват тупой бизнес!

Зато в комментах вспомнят: “Главная проблема музыки в России — это лично ты”.

Ваш проект умрёт не из-за разработки

Я всю профессиональную жизнь связан с разработкой. Видел много нормально запроганных, но мёртвых проектов, в которых создатель просрал продуктовую работу. Видел много успешно работающих проектов, где разработка была полным дерьмом даже без юниттестов — но создатель делал продуктовую работу на отлично, и проект, пусть и со страдающими программистами, но ехал вперёд.

И ни разу я не видел проекта, который не запустился из-за медленной разработки.

Конечно, в долине смерти много бизнесов, где код говно, а программисты нарушают обещания. Но причина их смерти — не в программистах, а всё в той же просранной продуктовой работе: нулевой product-market-fit, несходящаяся экономика, неумение нанимать людей и тестировать гипотезы. Плохой код — скорее следствие общих проблем, а не причина.

Когда пойдёте на следующий курс по вайб-кодингу, чтобы заменить своих программистов, вспомните пожалуйста меня — ваш проект умрёт не из-за программистов, не из-за бухгалтеров и не из-за поставщиков воды в офис. Он умрёт из-за вас.

#оффтоп

Похоже перплексити всерьез решил потягаться с гуглом. А что создал ты, юзернейм?

Это не кризис, это пиздец (с)

Кажется, SE были первой независимой школой по сисанализу. Когда делали NextWay, регулярно оглядывались на них. Для меня это одни из немногих фанатиков, кто исповедует no bullshit policy, а не рубит бабло на хайпе. И кроме нас с SE полностью живые программы сейчас никто не ведет, на сколько знаю.

Держитесь, ждем с новыми проектами.

#интеграция #конференции

Завтра на ИнфоСтарте буду вещать аналитикам 1С про системный подход к интеграции.
Если будете там завтра, приходите заходите на чай знакомиться, если есть друзья из 1С — киньте им ссылку.

Немного впечатлений с ИнфоСтарта

Если не обращать внимание, что код местами написан на русском, то особых отличий от “нашей” итшечки незаметно.

Роль аналиста 1С как будто моложе обычных сисаналистов, поэтому слышал много разговор про зоны ответственности, на сколько аналитик должен погружаться в харды, как работать с интеграцией и т.п. Примерно как 5-7 лет назад на AD, но по-другому.

Отдельно запомнился доклад Романа Данилова про сисдизайн для аналитика, к которому он приложил кучу полезных ссылок — перешлите знакомым джунам и вкатунам.

И особо ламповые пати спикеров. Хочу тперь сделать пару стримов, чтобы лучше познакомиться с этим миром.

#конференции

Про интеграцию в дикой природе

Сам рассказывал про базовый алгоритм работы с интеграцией на крупных задачах:

0) Выявляем требования и собираем процесс в BPMN, EPC, CJM, Use Case или в любом другом удобном формате

1) Маппим его на существующие роли и системы с помощью контекстной диаграммы, на которой показываем отношения использования (взаимодействия). Уже здесь можем увидеть, что не хватает каких-то систем и функций

2) Показываем потоки данных на Data Flow Diagram. Здесь проверяем, везде ли есть нужные данные, кто мастер-система, что с актуальностью и частотой использования данных

3) Разворачиваем каждую стрелочку контекстной диаграммы в сценарий взаимодействия с помощью диаграммы последовательности. Проверяем, все ли методы есть для реализации сценариев, чего не хватает

4) Проектируем / дорабатываем API на основе п.3, прописываем структуру методов. Проверяем полноту по CRUDL+Search+Archive+Clone

5) Делаем трассировку: каждое взаимодействие из п.1 должно быть покрыто сценариями из п.3, объекты из п.2 должны появиться на уровне п.4. Если что-то где-то возникает из воздуха, то ищем, где мы продолбались

Выбор паттернов, специфику технологий и НФТ не рассматривали, ибо не впихнуть.

Перешлите знакомым, если будет полезно.

P.S. А еще постарайтесь не забыть по дороге, что вы аналитик.

#конференции #интеграция

Вас не заменит AI, вас заменят процессы

Есть такой опенсоурс продукт для аналитиков AI IDE BAS — плагин для VS Code, в котором можно разрабатывать требования, делать техдизайн, генерить спеки.

Ребята молодцы, круто что у нас занимаются такими проектами, но я так и не понял, зачем генерить классические артефакты и передавать их разрабам, если я могу вооружиться курсором/кодексом/коворком и сразу получить код на их основе. Нужны ли код-агентам артефакты в том же виде, что и мясным разрабам? Вряд ли, намного эффективнее выглядит связка SDD + TDD.

По слухам из бигтехов, аналитики пытаются оптимизировать работу с помощью AI, чтобы было все так же, только быстрее, выше, сильнее. Реальные изменения пойдут, когда начнется переосмысление самого процесса поставки. Вот тогда из него начнут выпадать лишние шаги и роли. Точнее трансформироваться.

Пока народ вокруг пытается только ускориться с помощью иишечки, можете не беспокоиться. Следите за процессами. Ну или меняйте(сь) сами.

#AI #манагерское

Пока я философствовал, Александр Поломодов выпустил две статьи на эту тему:

От классического PDLC к AI-native разработке — как AI меняет процессы разработки

От AI-native разработки к AI-native организации (с примерами из опыта бигтехов) — как перестраивать организации вокруг AI-процессов

С иишечкой все будет бешено ускоряться, поэтому для выживания будут критичны изменения:

• процесс поставки должен стать короче, количество ролей уменьшиться

• структура управления будет более плоской, соотношение инженер-менеджер вырастет

Понятно, что это прогнозы, но выглядит логично и правдоподобно.

#вайбкодинг

Как-то сел пилить относительно сложный проект в n8n и решил сделать это с гпт. В чатике спроектировали архитектуру, базу, нарезали логику на флоу. Получилось красивенько.

Увидел, что в нейтоне есть свой AI-агент. Тупенький, но неплохо делает каркас воркфлоу и дает инструкцию, что где нужно настроить. Потому что обучен на тоннах роднных доков и шаблонов.

Сначала ак и шел, но вспомнил: workflow в n8n — это обычный json с нодами, настройками и кодом внутри. А что это значит? Правильно, копируем сгенеренный драфт с инструкциям из нейтона в гпт, и просим перегенерить правильно. Ошибки так же отлаживаем. Получается нудно, но значительно быстрее.

Но нашлись люди, которые сделали открытый плагин и скилл под VS Code / Cursor.

Можно прямо в курсоре собрать флоу, посмотреть, отдебажить и задеплоить в свой нейтон. Еще говорят, что умеет работать с гитом и просто решать конфликты, но тут я точно не верю.

Лютая дичь. Пошел тестить.

https://github.com/Etiennelescot/n8n-as-code

#оффтоп

Читаю новости законотворчества и понимаю, что точно никакой AI нас не заменит.

Этим ребятам доверяю, постараюсь дойти. Обещают авторский взгляд на сисдизайн.

#оффтоп

Сегодня день бэкапа, завтра день смеха.
Совпадение?

Spec Driven Development

В комментах просили ссылок, накидаю сюда.
После того, как появился вайбкодинг, энтузиасты обнаружили, что просто промпт “сделай хорошо” для сложных задач не работает. А если после первой версии попросить модельку что-то доработать или поправить, то она начинает ломать старый код.

Так родилась идея, что на вход нужно давать более конкретные описания, а после контролировать действия агента. В итоге пришли к флоу:

Описываем хотелки —> Проектируем —> Декомпозируем —> Реализуем

Что-то знакомое? Почти как с людьми, только с агентами. Назвали подход Spec Driven Development.
Пока это лишь общая концепция, а не что-то конкретное. Нет единой терминологии, общих правил, принятых практик.

Наиболее популярные инструменты:
• SpecKit — от гитхаба
• Kiro — от амазона
• OpenSpec — опенсорс

Это далеко не все, вот подборка относительно известных инструментов, плюс многие пилят свои фреймворки.

Про реализацию SDD в SpecKit: часть 1, часть 2.

#вайбкодинг