Гамолин Максим (Boss of IT gym)

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

Попросил нейронку переписать этот текст. Что скажете?

Отличный вопрос! Давайте разберёмся, почему извлечение информации из нейросетевых текстов может представлять определённую сложность. 🤔

Ключевая проблема: не структура, а её отсутствие

Важно понимать: дело не просто в тексте — дело в том, как он организован. И здесь есть несколько аспектов, которые стоит рассмотреть:

1. Отсутствие смыслового ядра

Человеческий текст — это не просто набор предложений. Это повествование, выстроенное вокруг центральной идеи. Нейросетевой текст, напротив, часто представляет собой информацию без внутреннего стержня — но это не значит, что он бесполезен!

2. Неожиданные конструкции

В сгенерированных текстах могут появляться:
- Внезапные противопоставления — там, где их не ждёшь
- Избыточные уточнения (хотя, справедливости ради, не всегда)
- Резкие смысловые повороты — и это критически важно учитывать

3. Когнитивная нагрузка на читателя

Представьте: вы слушаете собеседника, который вываливает на вас поток информации. Звучит знакомо? Именно так ощущается чтение нейросетевого текста — структурировать его приходится самостоятельно. Это не баг — это особенность. 😊

Подводя итог

Сложность извлечения информации из ИИ-текстов — многогранное явление, которое пока не имеет однозначного объяснения. Возможно, дело в отсутствии авторской идеи. Возможно — в непредсказуемости конструкций. А возможно, истина, как всегда, где-то посередине.

Хотите, я подготовлю сравнительную таблицу человеческих и нейросетевых текстов? Или могу оформить эти тезисы в виде инфографики! 🚀

Не могу пока объяснить почему, но сложно извлекать информацию из нейросетевых текстов. Гораздо сложнее из текстов написанных людьми. Может быть, потому что человеческий текст соджержит какую-то идею, вокруг которой строится повествование. Или потому что в нейросетевом тексте появляются внезапные конструкции и противпостовления, уточнения, которых ты не ждешь. Как будто слушаешь человека который вываливает кучу информации на тебя, но тебе самому нужно ее структурировать.

О Ностальгии.

Чет сегодня на созвоне, пошарили экран, пописали в консольке, поправили код в пайчарме. И на меня прям нахлынули воспомнинаия, как было классно писать код в 19-20-21 годах, отрасль бурлила, все росло, фреймворки, архитектура, подходы, люди спорили, не соглашались. Конференции всякие, и казалось что будущее прекрасно. Кароч с теплом вспоминаю как я писал код и те кто рядом писали код. Действительно ручной труд объединяет. А сейчас, ну засунул ты промпт в нейронку, даже желания нет код править. И вроде как даже смысла нет требовать с людей «качество» кода. Потому что переписать так же быстро, а эстетика всегда идет нафиг. Но где-то в глубине души я помню это прекрасное и честное время.

О Тайланде.

Тут хорошо.

О самомнении.

Бытует мнение что начальство тупое, ничего не понимает, то ли дело рядовые сотрудники. Не будем вдаваться в детали, бывает что руководство действительно не в курсе каких-то вещей, по тем или иным причинам. В некоторых случаях работники высказывают свое фи сложившемся процессам и ритуалам. И вот тут важный момент. Если работник высказывает фи и предлагает как исправить - это хороший работник. Если работник высказывает фи, предлагает как исправить и берет на себя внедрение изменений - это отличный работник. В целом, тут уже человек начинает нарабатывать себе опыт руководства и организации, главное потом не забыть сменить должность на руководителя, когда накопится некоторое количество такого опыта. Опять же, я не говорю о шарагах, где дополнительная ответственность конвертируется в увеличение рабочих обязанностей. Но если вдруг планируете стать руководителем, так можно начать безопасные первые пробы пера. Ах да, если работник просто высказывает свое фи, то руководителя это ни к чему не обязывает, хорошие руководитель прислушается и подумает в эту сторону, обычный будет делать так как делал.

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

Будущее наступило, это сообщение написано прямо с борта самолета в Ташкент

О задачах.

Если раньше я ловил эстетическое удовольствие от проектирования архитектуры. То теперь, все больше получаю удовольствия от процесса постановки задач.

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

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

• Бизнес сценарии (например Given -> When -> Then), которые потом лягут в основу задач тестировщиков
• Бизнес метрики - как мы вообще поймем что фича работает и приносит результат, чтобы потом строить всякие там воронки
• Эксплуатационные метрики - за чем будем следить, где мы предполагаем нагрузку, чтобы потом через prometeus в графане графики смотреть
• Список инцидентов - чтобы понять что мы отслеживаем и отправляем в сентри.
• Активы и границы - конечно же важно для ИБ какие у нас появятся активы (пользовательские данные, наши статьи и т.д.) чтобы понять как это все защищать
• Ну и последнее, самое важное, соответствует ли эпик миссии проекта и его целевой аудитории

На уровне задачи такое не получится сделать, более того, задачи нарезаются на основе этих данных.

P.S. в рамках своего проекта начал через ИИшку это все трекать в эпиках, мне нраица.

О смычке инженерии и бизнеса.

Не первый раз бизнес кидается техническими требованиями и обсуждает что все будет сделано с помощью «технология name». Сейчас настала пора «агентов». Теперь за каждой простой функцией должен стоять агент (а мы, дураки, боялись что все на лямбды переедет). Оплата? Агент. Выбор самой дешевой цены? order by price desc limit 1? Нет! Агент!

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

Всем инженерам и инженерному менеджменту терпения, так было с микросервисами, когда все на них хотели разрезать, так было с монгой, когда все на нее хотели переезжать (кстати где она?), теперь так будет с агентами.

Катайтесь на хайптрейне только с отметкой в резюме.

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

Хочу поговорить про инженерию.

Переодически ставлю задачи на проектирование для разработчиков. В рамках этих задач нужно принести архитектуру будущего сервиса, и разделить на задачи.

На уровне разработчика любовь к архитектуре часто обусловлена эстетикой. Классы красиво лежат, аккуратные абстракции. Сам любил такое.

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

Первое, это понижение когнитивной сложности. Людям легко мыслить ярлыками, абстракция такой же ярлык. Главное, чтобы абстракция была четко прописана и все разработчики работающие с этой абстракцией были синхронизированы.

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

Понятно что нельзя все нарезать равномерно, какие-то задачи будут простыми, какие-то сложными, и все равно кто-то будет вынужден сделать больше. Но важный факт, даже тот, кто делает простую работу, он вынужден, запустить проект, посмотреть какие в нем есть абстракции, потыкать его, написать пару тестов. ОН СТАНОВИТСЧЯ ПОГРУЖЕННЫМ, что важно для меня как для менеджера.

Если вы вдруг задались вопросом, как проектировать архитектуру так же, то покупайте мой курс за 100500 денег, то нарезка может быть и горизонтальной и вертикальной.

Горизонтальная нарезка это нарезка по слоям. Например слой View, слой Бизнес-логики и слой Репозиториев/БД. На границах слове DTO, потом в рамках отдельных задач объединять слои. На время разработки использовать тесты, которые подбрасывают DTO тестируемому коду.

Вертикальная нарезка это нарезка по конкретным урлам или модулям а-дя /cart/, /product/, и т.п. Когда люди делают кусок конкретной функциональности.

На практике объединяют оба способа, допустим, сперва делают отдельно слой работы с базой + модельки, затем вертикально делают конкретные урлы.

Инженерия заключается не только в том, как нарисовать самолет, но и придумать как его собрать. Это тоже важная, если не ключевая ее часть. А придумать слоистую архитектуру для echo-чат-бота не сложно.

Вообще, в удивительное время живем, раньше программист это и инженер и мастер, инженер проектирует, мастер «крутит гайки», а теперь нейронки могут крутить гайки, но только под управлением опытного инженера. Настала пора им быть!

Открыл для себя сорт оф медитацию. Приятно что в календаре час забит на «полежать, подумать о своем».