Короче, закрываю тему инди-хакерства.
Во-первых, за все годы что я к этому призываю, так ни один из ребят и не сделал хотя бы бесплатный работающий сервис, который можно было бы заценить. Хотя сейчас для этого идеальное время, но окно возможностей быстро закрывается, и программистов будет требоваться в сотни раз меньше, и в 35 тебя уже считают совсем старым для айтишки. Ну ок.
Во-вторых,
"Если вы занимаетесь бизнесом в России — вы сумасшедший и это не обсуждается." (с)
Вот по мотивам вчерашних событий мнение уважаемых людей.
Нологи на ип могут повысить до 25+%, отменят патенты, и ещё много чего.
Если у вас ИП, рекомендую закрыть пока не поздно.
У меня например впервые вообще за всё время, в октябре дополнительно списалось 19 тыс. руб. совершенно непонятно за что. Я не владею никакой частной собственностью - ни квартиры, ни машины, ни дачи, ни земли, ни миллионов на вкладах... В качестве движимого имущества только кот и несколько велосипедов.
Улучшений тут уже не жду совсем, никогда, на моей жизни точно.
поколение й
Во-первых, за все годы что я к этому призываю, так ни один из ребят и не сделал хотя бы бесплатный работающий сервис, который можно было бы заценить. Хотя сейчас для этого идеальное время, но окно возможностей быстро закрывается, и программистов будет требоваться в сотни раз меньше, и в 35 тебя уже считают совсем старым для айтишки. Ну ок.
Во-вторых,
"Если вы занимаетесь бизнесом в России — вы сумасшедший и это не обсуждается." (с)
Вот по мотивам вчерашних событий мнение уважаемых людей.
Нологи на ип могут повысить до 25+%, отменят патенты, и ещё много чего.
Если у вас ИП, рекомендую закрыть пока не поздно.
У меня например впервые вообще за всё время, в октябре дополнительно списалось 19 тыс. руб. совершенно непонятно за что. Я не владею никакой частной собственностью - ни квартиры, ни машины, ни дачи, ни земли, ни миллионов на вкладах... В качестве движимого имущества только кот и несколько велосипедов.
Улучшений тут уже не жду совсем, никогда, на моей жизни точно.
поколение й
1🤔31✍5💯5😁3🤯2
В эпоху AI весь DevOps уходит в пространства огромных размерностей. Когда у вас сотни окружений, метрик, версий, согласований и конфигов, в которых разбирается только нейронка, любые решения "под ключ" теряют смысл. AI-проекты будут более чем полностью состоять из собственного харнеса и кучи ямлов и интеграций. При этом любая "похожесть" сервисов исчезает: любые две точки в таком пространстве будут отличаться по слишком многим осям.
Тут на помощь как раз приходит HoTT (как минимум, как концептуальная база рассуждений об): все эти окружения, сервисы и конфиги описываем как типы, а их "похожесть" -- это пути (эквивалентности). Тогда мы вполне можем свернуть лишние оси (например, дифы в YAML и версиях), если они не меняют поведение.
можно ли срочно поднять prod в другом регионе?
dev/stage/prod достаточно похожи, чтобы баг не вылез только в проде?
инфра уехала от IaC -- кто виноват?? :)
быстро понимаем, что замена компонента не сломает контракт...
можно ли слить окружения, выкинуть дубли, переиспользовать артефакт?
compliance, policy, security, вот это всё...
Решение принимаем по унивалентности (формально допустимой эквивалентности поведений и контрактов). Как наиболее корректно деплоить и откатывать, сливать и переносить, допускать и фиксить...
Тут на помощь как раз приходит HoTT (как минимум, как концептуальная база рассуждений об): все эти окружения, сервисы и конфиги описываем как типы, а их "похожесть" -- это пути (эквивалентности). Тогда мы вполне можем свернуть лишние оси (например, дифы в YAML и версиях), если они не меняют поведение.
можно ли срочно поднять prod в другом регионе?
dev/stage/prod достаточно похожи, чтобы баг не вылез только в проде?
инфра уехала от IaC -- кто виноват?? :)
быстро понимаем, что замена компонента не сломает контракт...
можно ли слить окружения, выкинуть дубли, переиспользовать артефакт?
compliance, policy, security, вот это всё...
Решение принимаем по унивалентности (формально допустимой эквивалентности поведений и контрактов). Как наиболее корректно деплоить и откатывать, сливать и переносить, допускать и фиксить...
❤31🤯10
Продолжаю работу с ментатами 🤓
...Вот, кстати, еще на неделе прилетел отказ от [...] со следующей сноской:
"Сейчас ребята приняли решение рассматривать кандидатов с бОльшим опытом сбора требований и общения с бизнесом напрямую"
...А ленивых и алчных не очень-то и жалко. Друзья из СПО, кстати, фиксируют кратный отток абитуры из айти в квалифицированные рабочие специальности. Видно по заполняемости залов на днях открытых дверей...
Очень хорошо, просто прекрасно. Уже совсем скоро даже крепкие мидлы будут цениться на вес золота, ведь квалифицированной смены им из-за вайб-кодинга и "джуны никому не нужны" уже никогда не будет, и никак эту ситуацию теперь не исправить в принципе.
...Буду чаще обращать на это внимание, всему виной спешка и плохое отношение к проектированию. Сделай побыстрее лишь бы работало, но сейчас есть время для рефакторинга и улучшения логики работы кода, правда это отнимет больше времени чем бы я сразу писал чистый и хороший код.
...Разбирался с тем, как наблюдать за AI в проде и считать его расход.
Первая же находка — ошибка модели у меня исчезает без следа. Если вызов падает, трек просто помечается «не найден», а перенос завершается как обычно. Неверный ключ — и все спорные треки тихо становятся ненайденными. То самое «всё равно 200 OK». Тесты не ловят: на тестовых 50 треках до модели не доходит ни один.
Я проверил себя по чек-листу из того же поста, и полностью прошёл только один пункт из четырёх: модели не нужны чувствительные данные. По остальным — пробелы.
...В проекте игры, которую делаю с использованием Codex, сделал команду анализа цикломатической сложности кода. Нашел класс-"свалку" с 34 методами с цикломатической сложностью некоторых методов в 39. И WMC (Weighted Methods per Class) 328. Которая считается как сумма цикломатической сложности всех методов.
При проектировании предложил объект с 9 методами и один вспомогательный иммутабельный класс. После переписывания WMC = 116, максимальная цикломатическая сложность метода = 10, методов считая приватные = 29. Код при этом стал человекочитаемым. И даже возможен ручной рефакторинг.
...Плюс попробовал новый харнесс нашего агента на opencode (модели open ai) и мультиагентов (роли ведущего, разработчика, архитектора...). В итоге расход токенов улетел в небеса, а скорость реализации была ниже чем написал бы сам (наверное) =)
...Кажется к экономии токенов еще предстоит привыкнуть, так как в первую неделю неоптимальным промтом сжег 5000 долларов.
Бюджет был посчитан, но показалось странным, что он был достаточно небольшим, в результате в тз прислали такое количество ограничений и правил для модели, что только его отправка этого тз с кэшированием и батч обработками съело порядка 4 тысяч долларов за неделю.
...Начал весь свой код писать агентом при помощи [...] и теперь другого способа работы с AI просто не представляю, так как удобно и эффективно.
За вчерашний день (даже за 1 час) агент написал весь бэкенд для проекта, а на следующей неделе остается добавить фронтенд (да работаю как фулстек), а потом протестировать.
Теперь мы из обычных программистов превратились в составителей спек и операторов агентов, но возможно это не так и плохо.
...А на основе этих принципов можно (точнее, хочется) постепенно прийти к формальным спецификациям и "правилам игры". И здесь мне видится некоторое окно возможностей, в том смысле, что пока очень мало кто (по моему субъективному опыту) точно знает, как делать правильно. То есть, это область с [пока] низкой теоретизированностью, что потенциально дает человеку, который понимает, что делает, и готов тратить часы своего времени на синтез новых знаний, сильное конкурентное преимущество. И даже если брать не настоящий синтез новых знаний, а, так сказать, пребывание во фронтире уже имеющихся, все равно преимущество сильное. Спасибо.
...Нам собирались дать (и уже дали) в компании протестировать Клода, но его практически сразу забанили). Прям неудачно совпало
...Написание множества автоматизаций (с помощью AI) для получения активности разработчиков в репозиториях и т.п.
**Результат:**
Два разработчика оказались под угрозой увольнения.
...Вот, кстати, еще на неделе прилетел отказ от [...] со следующей сноской:
"Сейчас ребята приняли решение рассматривать кандидатов с бОльшим опытом сбора требований и общения с бизнесом напрямую"
...А ленивых и алчных не очень-то и жалко. Друзья из СПО, кстати, фиксируют кратный отток абитуры из айти в квалифицированные рабочие специальности. Видно по заполняемости залов на днях открытых дверей...
Очень хорошо, просто прекрасно. Уже совсем скоро даже крепкие мидлы будут цениться на вес золота, ведь квалифицированной смены им из-за вайб-кодинга и "джуны никому не нужны" уже никогда не будет, и никак эту ситуацию теперь не исправить в принципе.
...Буду чаще обращать на это внимание, всему виной спешка и плохое отношение к проектированию. Сделай побыстрее лишь бы работало, но сейчас есть время для рефакторинга и улучшения логики работы кода, правда это отнимет больше времени чем бы я сразу писал чистый и хороший код.
...Разбирался с тем, как наблюдать за AI в проде и считать его расход.
Первая же находка — ошибка модели у меня исчезает без следа. Если вызов падает, трек просто помечается «не найден», а перенос завершается как обычно. Неверный ключ — и все спорные треки тихо становятся ненайденными. То самое «всё равно 200 OK». Тесты не ловят: на тестовых 50 треках до модели не доходит ни один.
Я проверил себя по чек-листу из того же поста, и полностью прошёл только один пункт из четырёх: модели не нужны чувствительные данные. По остальным — пробелы.
...В проекте игры, которую делаю с использованием Codex, сделал команду анализа цикломатической сложности кода. Нашел класс-"свалку" с 34 методами с цикломатической сложностью некоторых методов в 39. И WMC (Weighted Methods per Class) 328. Которая считается как сумма цикломатической сложности всех методов.
При проектировании предложил объект с 9 методами и один вспомогательный иммутабельный класс. После переписывания WMC = 116, максимальная цикломатическая сложность метода = 10, методов считая приватные = 29. Код при этом стал человекочитаемым. И даже возможен ручной рефакторинг.
...Плюс попробовал новый харнесс нашего агента на opencode (модели open ai) и мультиагентов (роли ведущего, разработчика, архитектора...). В итоге расход токенов улетел в небеса, а скорость реализации была ниже чем написал бы сам (наверное) =)
...Кажется к экономии токенов еще предстоит привыкнуть, так как в первую неделю неоптимальным промтом сжег 5000 долларов.
Бюджет был посчитан, но показалось странным, что он был достаточно небольшим, в результате в тз прислали такое количество ограничений и правил для модели, что только его отправка этого тз с кэшированием и батч обработками съело порядка 4 тысяч долларов за неделю.
...Начал весь свой код писать агентом при помощи [...] и теперь другого способа работы с AI просто не представляю, так как удобно и эффективно.
За вчерашний день (даже за 1 час) агент написал весь бэкенд для проекта, а на следующей неделе остается добавить фронтенд (да работаю как фулстек), а потом протестировать.
Теперь мы из обычных программистов превратились в составителей спек и операторов агентов, но возможно это не так и плохо.
...А на основе этих принципов можно (точнее, хочется) постепенно прийти к формальным спецификациям и "правилам игры". И здесь мне видится некоторое окно возможностей, в том смысле, что пока очень мало кто (по моему субъективному опыту) точно знает, как делать правильно. То есть, это область с [пока] низкой теоретизированностью, что потенциально дает человеку, который понимает, что делает, и готов тратить часы своего времени на синтез новых знаний, сильное конкурентное преимущество. И даже если брать не настоящий синтез новых знаний, а, так сказать, пребывание во фронтире уже имеющихся, все равно преимущество сильное. Спасибо.
...Нам собирались дать (и уже дали) в компании протестировать Клода, но его практически сразу забанили). Прям неудачно совпало
...Написание множества автоматизаций (с помощью AI) для получения активности разработчиков в репозиториях и т.п.
**Результат:**
Два разработчика оказались под угрозой увольнения.
❤22✍10👍2
Вы думаете, что формальные методы решат проблему агентной/AI-инженерии раз и навсегда? Это полная чушь!
Сейчас эта темка разгоняется в сети по двум причинам:
- (само)пиар AI-корпораций (типа как фейки с решением сотен математических задачек, где на самом деле и конь не валялся);
- чтобы курсы продавать.
Меня, давнего сторонника ФМ, крайне беспокоит эта новая эйфория.
В сентябре Борис Чорный (отец Claude Code) заявил: TLA+ отлично справляется с проектированием сложных параллельных систем и следит за тем, чтобы в них не было ошибок =>
"Я использовал Opus 5.5 для формальной проверки Claude Agent SDK с использованием Lean. Пара коротких подсказок = 16 сообщений об исправлении различных ошибок и условий гонки. Видео прилагается. TLA+ также работает хорошо. Иногда я объединяю Lean и TLA+, чтобы выявить проблемы, связанные с потоками данных, параллелизмом и state mgmt."
Ну, вот база: даже самый правильный software design и идеальный system design не приводят автоматически/через нейронки, к правильному коду.
Это собственно доказывается математически (Гёдель и Co).
Чтобы проверить некоторое свойство/характеристику системы (или сгенерировать код на основе этого свойства), нам нужно для начала иметь само это свойство для его проверки. А попробуйте-ка вытащить минимально удовлетворительное множество таких свойств из тупых башечек заказчиков :)
(на Функциональных архитектурах модуль "Мета-спеки" про это)
Если вы не понимаете, как представить некоторое свойство системы в некотором логическом формате, то никакой формальный метод не поможет. Если вы не можете формализовать представление человечка о том, а что именно этому человечку нужно, вы не сможете доказать, что ваша система делает именно это.
Сделать красиво, как у конкурентов но лучше, система должна работать быстро, должна выдерживать любые нагрузки, интеграция со всеми системами, полная безопасность, простой и интуитивный интерфейс, должна автоматически всё делать, должна работать на любом устройстве/браузере, в posix и windows 95, чтобы всё по ГОСТам...
А на просьбу пояснить, на любое уточнение отвечают: ну тыж программист, тыж профессионал.
Кроме того, ФМ (как минимум, языки формальных спек) подразумевают инварианты и свойства поведения, но они принципиально не работают например на протяжении нескольких шагов. Нету таких формальных подходов, когда мы хотим определить свойство на протяжении "delete, а потом undo к исходному состоянию". Огромные проблемы с реальным временем, и даже с вычислениями с плавающей точкой...
По большому счёту, мы не можем даже утверждать, что "существует поведение, при котором P истинно" (доказательство, что в игре можно выиграть). Мы попадаем в многомерные гиперпространства, которые могут быть нишевыми; мы даже не можем формально определять свойства в категориях (пространствах состояний), что существует только один путь из состояния X в состояние Z... И таких "мета-свойств", на которых нейронки ломаются, очень много.
(имею в виду, если вы пишете спецификацию, и эта спецификация напрямую соответствует системе, которую вы хотите создать, то ФМ не смогут полноценно выразить её как набор свойств вашей системы; хотя всяческие хаки, моки и приляпки возможны).
В использовании ФМ для генерации и проверки вайб-кода есть безусловно большой потенциал (и множество подводных камней). Но есть также куда много вещей, которые они не способны даже выразить, не говоря уже о формальной проверке.
Подробно разберём с ментатами в СильныхИдеях, что из этого следует, и как тут правильно поступать и рассуждать. А для не-ментатов, так и быть, будет особый приятный бонус.
Ежа
Сейчас эта темка разгоняется в сети по двум причинам:
- (само)пиар AI-корпораций (типа как фейки с решением сотен математических задачек, где на самом деле и конь не валялся);
- чтобы курсы продавать.
Меня, давнего сторонника ФМ, крайне беспокоит эта новая эйфория.
В сентябре Борис Чорный (отец Claude Code) заявил: TLA+ отлично справляется с проектированием сложных параллельных систем и следит за тем, чтобы в них не было ошибок =>
"Я использовал Opus 5.5 для формальной проверки Claude Agent SDK с использованием Lean. Пара коротких подсказок = 16 сообщений об исправлении различных ошибок и условий гонки. Видео прилагается. TLA+ также работает хорошо. Иногда я объединяю Lean и TLA+, чтобы выявить проблемы, связанные с потоками данных, параллелизмом и state mgmt."
Ну, вот база: даже самый правильный software design и идеальный system design не приводят автоматически/через нейронки, к правильному коду.
Это собственно доказывается математически (Гёдель и Co).
Чтобы проверить некоторое свойство/характеристику системы (или сгенерировать код на основе этого свойства), нам нужно для начала иметь само это свойство для его проверки. А попробуйте-ка вытащить минимально удовлетворительное множество таких свойств из тупых башечек заказчиков :)
(на Функциональных архитектурах модуль "Мета-спеки" про это)
Если вы не понимаете, как представить некоторое свойство системы в некотором логическом формате, то никакой формальный метод не поможет. Если вы не можете формализовать представление человечка о том, а что именно этому человечку нужно, вы не сможете доказать, что ваша система делает именно это.
Сделать красиво, как у конкурентов но лучше, система должна работать быстро, должна выдерживать любые нагрузки, интеграция со всеми системами, полная безопасность, простой и интуитивный интерфейс, должна автоматически всё делать, должна работать на любом устройстве/браузере, в posix и windows 95, чтобы всё по ГОСТам...
А на просьбу пояснить, на любое уточнение отвечают: ну тыж программист, тыж профессионал.
Кроме того, ФМ (как минимум, языки формальных спек) подразумевают инварианты и свойства поведения, но они принципиально не работают например на протяжении нескольких шагов. Нету таких формальных подходов, когда мы хотим определить свойство на протяжении "delete, а потом undo к исходному состоянию". Огромные проблемы с реальным временем, и даже с вычислениями с плавающей точкой...
По большому счёту, мы не можем даже утверждать, что "существует поведение, при котором P истинно" (доказательство, что в игре можно выиграть). Мы попадаем в многомерные гиперпространства, которые могут быть нишевыми; мы даже не можем формально определять свойства в категориях (пространствах состояний), что существует только один путь из состояния X в состояние Z... И таких "мета-свойств", на которых нейронки ломаются, очень много.
(имею в виду, если вы пишете спецификацию, и эта спецификация напрямую соответствует системе, которую вы хотите создать, то ФМ не смогут полноценно выразить её как набор свойств вашей системы; хотя всяческие хаки, моки и приляпки возможны).
В использовании ФМ для генерации и проверки вайб-кода есть безусловно большой потенциал (и множество подводных камней). Но есть также куда много вещей, которые они не способны даже выразить, не говоря уже о формальной проверке.
Подробно разберём с ментатами в СильныхИдеях, что из этого следует, и как тут правильно поступать и рассуждать. А для не-ментатов, так и быть, будет особый приятный бонус.
Ежа
❤23🤔15⚡2👍1
Скорость вывода твоего саас-а на рынок даже в нишу, где есть норм спрос, ещё ничего не значит, если архитектура потенциально не выдержит реального масштаба.
Типичная статистика по американским SaaS инди-хакеров: продажи на $10k/мес, но уходят в минус уже на $2k/мес.
Типичные траблы:
Повторная отправка всего документа в промпт вместо кэша и точечных чанков сжирает океан токенов.
AI нахерачила новые подключения к базе на каждый серверный запрос вместо пулинга, и при 50+ пользователях база падает :) А со временем отсутствие индексов приводит к полной остановке сервера.
Отсутствие транзакций и блокировок (юзер дважды кликает "Вывести", и вайб-код списывает деньги дважды, так как баланс читается параллельно).
Когда что-то ломается, вайб-кодер просит AI "починить ошибку", но нейронка не видит всей системы и лепит приляпку, которая ломает авторизацию или валидацию.
И через 3-4 месяца код превращается в неуправляемую кашу нейродерьма, которую проще выбросить и переписать заново белковыми (но уже за 5 миллионов рублей).
Чек-лист (санитарные правила безопасности для вайб-кода) как тут надо правильно, дам ментатам в Функциональных архитектурах.
По-взрослому, конечно лучше заплатить опытному архитектору например 50-100 тыс. руб. за пару часов проверки схемы базы, API и вебхуков перед запуском. Но ведь CEO/CTO скорее удавятся, лишь бы не платить за консалт. Проще забросить в жпт и жить в самоуспокоенности (оч короткое время:).
Я внешним консалтингом не занимаюсь, только ментатам помогаю, но жалко иногда правильных пацанов, у которых проблемы с ит-бизнесом -- исключительно проблемы с их эго.
Типичная статистика по американским SaaS инди-хакеров: продажи на $10k/мес, но уходят в минус уже на $2k/мес.
Типичные траблы:
Повторная отправка всего документа в промпт вместо кэша и точечных чанков сжирает океан токенов.
AI нахерачила новые подключения к базе на каждый серверный запрос вместо пулинга, и при 50+ пользователях база падает :) А со временем отсутствие индексов приводит к полной остановке сервера.
Отсутствие транзакций и блокировок (юзер дважды кликает "Вывести", и вайб-код списывает деньги дважды, так как баланс читается параллельно).
Когда что-то ломается, вайб-кодер просит AI "починить ошибку", но нейронка не видит всей системы и лепит приляпку, которая ломает авторизацию или валидацию.
И через 3-4 месяца код превращается в неуправляемую кашу нейродерьма, которую проще выбросить и переписать заново белковыми (но уже за 5 миллионов рублей).
Чек-лист (санитарные правила безопасности для вайб-кода) как тут надо правильно, дам ментатам в Функциональных архитектурах.
По-взрослому, конечно лучше заплатить опытному архитектору например 50-100 тыс. руб. за пару часов проверки схемы базы, API и вебхуков перед запуском. Но ведь CEO/CTO скорее удавятся, лишь бы не платить за консалт. Проще забросить в жпт и жить в самоуспокоенности (оч короткое время:).
Я внешним консалтингом не занимаюсь, только ментатам помогаю, но жалко иногда правильных пацанов, у которых проблемы с ит-бизнесом -- исключительно проблемы с их эго.
2✍40❤🔥2
.
Облако драгоценностей за неделю.
За 3-й квартал посетители российских компьютерных клубов выросли на 5-7%, и тренд уже долго сохраняется. Люди жаждут живого коопа, дота база :)
Приватный клуб.
null
Для донов-начинающих:
Вы не глупы, вы просто применяете неэффективные стратегии обучения. А если вы вообще не применяете какую-либо стратегию обучения осознанно, это и значит, что она у вас есть, но просто крайне неэффективна.
Учиться — это скилл.
Точно так же, как нужна практика, чтобы научиться лучше ездить на велосипеде, водить машину или успешно играть в доту или контру, вам нужна практика, и чтобы учиться чему-то новому. И точно так же, как есть хорошие и плохие способы научиться играть в игры (например, в шахматы), то же и для обучения чему-либо.
Важно прежде всего то, как ...
В 2026-м году умение писать код на Java или Python, да и веб-фреймворки — это уже далеко не то, за что вам будут платить. Искусственный интеллект уже может это делать, причём на уровне миддла фактически.
Так, например, раньше вы могли получать деньги за написание 100 строк кода, инспекцию кода, настройка и запуск скриптов... Но теперь вы можете просто попросить AI сделать это за вас.
Однако хорошая новость заключается в том, что ...
Продолжение: с учетом сказанного, вот пять скиллов, на которых вам желательно сосредоточиться прямо сейчас...
Для донов-неначинающих:
Вы же выиграли третий квартал 2026-го года?
И я не имею в виду: "Ты был занят?"
Я имею в виду: действительно ли тот результат, который вы хотели, ощутимо к вам приблизился?
Возможно, ответ "да". Возможно, "нет". А скорее всего, вы никогда и не выбирали достаточно чёткий результат, чтобы к нему стремиться.
Каким бы ни был ответ, дело не в том, чтобы корить себя, а вот в чём...
Продолжаю набор на занятия для неначинающих (миддлы сеньоры), 2 места закончились за 1:33 минуты...
До достижения чего-то значимого в 2026-м году остаётся один квартал. Я не хочу, чтобы вы дожили до декабря, зная, что упорно трудились, но без толку, потому что так и не ...
"Пока вы не сделаете бессознательное сознательным, оно будет управлять вашей жизнью, и вы будете называть это судьбой."
— Карл Юнг
(все старые материалы для донов быстро сгорают)
=
Новые материалы для ментатов Лаборатории.
В СильныеИдеи добавлен материал "162) Почему покрытие кода тестами -- зло".
Сейчас конец 2026-го года, а я-то думал, что это общеизвестный факт, что покрытие кода тестами в качестве метрики качества кода в лучшем случае бесполезно.
Вот база: никогда не ставьте цели по покрытию кода тестами. Вообще неважно, какой целевой показатель вы установите: 100% покрытие кода, 90%, 30% или какое-либо другое число...
=
"Функциональные архитектуры" 181(+2) топиков.
Карпатый про AI DSL, промпт для нечётких ситуаций
LPF закончен, куда и как дальше => ???(Meta)Principles Framework (сделано 0% :)
=
"ЛаМПовое":
Команда как НИИ
Мета-Антропик: in May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day.
=
Лаборатория идёт со скоростью самых лучших ментатов 💪🏻
(продолжаю бесконечное ужесточение правил занятий :)
=
Истинным навыком ментата был присущий только им способ ментального конструирования, которое называется "великим синтезом". Этот синтез требовал такого терпения, на которое был способен только ментат. Обычный человек не мог даже мечтать о таком терпении.
"Капитул Дюны"
Облако драгоценностей за неделю.
За 3-й квартал посетители российских компьютерных клубов выросли на 5-7%, и тренд уже долго сохраняется. Люди жаждут живого коопа, дота база :)
Приватный клуб.
null
Для донов-начинающих:
Вы не глупы, вы просто применяете неэффективные стратегии обучения. А если вы вообще не применяете какую-либо стратегию обучения осознанно, это и значит, что она у вас есть, но просто крайне неэффективна.
Учиться — это скилл.
Точно так же, как нужна практика, чтобы научиться лучше ездить на велосипеде, водить машину или успешно играть в доту или контру, вам нужна практика, и чтобы учиться чему-то новому. И точно так же, как есть хорошие и плохие способы научиться играть в игры (например, в шахматы), то же и для обучения чему-либо.
Важно прежде всего то, как ...
В 2026-м году умение писать код на Java или Python, да и веб-фреймворки — это уже далеко не то, за что вам будут платить. Искусственный интеллект уже может это делать, причём на уровне миддла фактически.
Так, например, раньше вы могли получать деньги за написание 100 строк кода, инспекцию кода, настройка и запуск скриптов... Но теперь вы можете просто попросить AI сделать это за вас.
Однако хорошая новость заключается в том, что ...
Продолжение: с учетом сказанного, вот пять скиллов, на которых вам желательно сосредоточиться прямо сейчас...
Для донов-неначинающих:
Вы же выиграли третий квартал 2026-го года?
И я не имею в виду: "Ты был занят?"
Я имею в виду: действительно ли тот результат, который вы хотели, ощутимо к вам приблизился?
Возможно, ответ "да". Возможно, "нет". А скорее всего, вы никогда и не выбирали достаточно чёткий результат, чтобы к нему стремиться.
Каким бы ни был ответ, дело не в том, чтобы корить себя, а вот в чём...
Продолжаю набор на занятия для неначинающих (миддлы сеньоры), 2 места закончились за 1:33 минуты...
До достижения чего-то значимого в 2026-м году остаётся один квартал. Я не хочу, чтобы вы дожили до декабря, зная, что упорно трудились, но без толку, потому что так и не ...
"Пока вы не сделаете бессознательное сознательным, оно будет управлять вашей жизнью, и вы будете называть это судьбой."
— Карл Юнг
(все старые материалы для донов быстро сгорают)
=
Новые материалы для ментатов Лаборатории.
В СильныеИдеи добавлен материал "162) Почему покрытие кода тестами -- зло".
Сейчас конец 2026-го года, а я-то думал, что это общеизвестный факт, что покрытие кода тестами в качестве метрики качества кода в лучшем случае бесполезно.
Вот база: никогда не ставьте цели по покрытию кода тестами. Вообще неважно, какой целевой показатель вы установите: 100% покрытие кода, 90%, 30% или какое-либо другое число...
=
"Функциональные архитектуры" 181(+2) топиков.
Карпатый про AI DSL, промпт для нечётких ситуаций
LPF закончен, куда и как дальше => ???
=
"ЛаМПовое":
Команда как НИИ
Мета-Антропик: in May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day.
=
Лаборатория идёт со скоростью самых лучших ментатов 💪🏻
(продолжаю бесконечное ужесточение правил занятий :)
=
Истинным навыком ментата был присущий только им способ ментального конструирования, которое называется "великим синтезом". Этот синтез требовал такого терпения, на которое был способен только ментат. Обычный человек не мог даже мечтать о таком терпении.
"Капитул Дюны"
❤30✍6
.
Ну, с Днём Репетитора!!1
Сейчас прекрасная пора для EdTech, а благодаря искусственному идиоту, будет ещё прекраснее. Например, только на геткурсе онлайн-школы за первое полугодие 26-го заработали почти 70 миллиардов рублей.
А весь русский рынок онлайн-образования с 22-го дико летит вверх, почти в два раза: с 95 до 170 миллиардов в 2025-м. И это при том, что многих инфоцыганов с дикими оборотами пересажали :) В результате, волшебных таблеток почти не стало, а качество мощно выросло, обучение реально повзрослело, и спрос становится тоже обдуманным и адекватным.
Бред, когда заявляют, что AI уничтожает онлайн-обучение. Так-то "в интернете есть всё и бесплатно" уже 30 лет, проблема не в доступности знаний, проблема всегда была, есть и будет в мотивации к обучению, в способности заниматься самостоятельно и полноценно, которая уже почти полностью исчезла ("только кнут" :). А AI как раз уничтожает именно эту способность. Например, боссы пресловутых школ обучения английскому отмечают, что массовость AI на спрос на их занятия вообще никак не повлияла, никакого снижения нету.
Скажу кстати страшное, но продвижение в мягких нишах (психология, обучение, здоровье, отношения...) сейчас лучше всего работает в максе, извините, но это факт.
Соответственно, индивидуальное репетиторство/менторство шикарно цветёт. Школьники тупеют уже за считанные месяцы: ранее требовались хотя бы минимальные социальные скиллы, чтобы "дали списать домашку", а сейчас просто кнопку нажать. Но экзамены-то сдавать надо :)
Вузовское обучение айтишным темам быстро обесценивается: к реальной работе и так-то особо не готовили, а теперь ещё везде нужны хорошие скиллы, как работать с AI - с сильными западными моделями и всяческими опенсорсными харнесами, чему официально учить у нас никогда не будут просто по факту. Поэтому, в частности, сменить работу сегодня разработчику без карьерного консультанта практически нереально, если он не качал нетворк. Но попробуй-ка ещё найди такого хорошего консультанта.
Главный же минус, что работа с ментором, особенно на индивидуалке, становится привилегией богатых людей, тех у кого есть деньги, потому что цены на занятия ощутимо растут. А остальным остаются мутные нейрослоповые галлюцинации от дешёвых моделек.
Выход, очевидно, только в интенсивном росте, работе над собой. Бежать вперёд сегодня надо изо всех сил. Ну и побольше думать.
В конце концов, во всём, что делают люди, есть структура; и если вы сможете выявить эту структуру, то сможете понять, и как её изменить. Особенно с учётом контекстов, в которых было бы замечательно иметь подходящую структуру.
Ну, с Днём Репетитора!!1
Сейчас прекрасная пора для EdTech, а благодаря искусственному идиоту, будет ещё прекраснее. Например, только на геткурсе онлайн-школы за первое полугодие 26-го заработали почти 70 миллиардов рублей.
А весь русский рынок онлайн-образования с 22-го дико летит вверх, почти в два раза: с 95 до 170 миллиардов в 2025-м. И это при том, что многих инфоцыганов с дикими оборотами пересажали :) В результате, волшебных таблеток почти не стало, а качество мощно выросло, обучение реально повзрослело, и спрос становится тоже обдуманным и адекватным.
Бред, когда заявляют, что AI уничтожает онлайн-обучение. Так-то "в интернете есть всё и бесплатно" уже 30 лет, проблема не в доступности знаний, проблема всегда была, есть и будет в мотивации к обучению, в способности заниматься самостоятельно и полноценно, которая уже почти полностью исчезла ("только кнут" :). А AI как раз уничтожает именно эту способность. Например, боссы пресловутых школ обучения английскому отмечают, что массовость AI на спрос на их занятия вообще никак не повлияла, никакого снижения нету.
Скажу кстати страшное, но продвижение в мягких нишах (психология, обучение, здоровье, отношения...) сейчас лучше всего работает в максе, извините, но это факт.
Соответственно, индивидуальное репетиторство/менторство шикарно цветёт. Школьники тупеют уже за считанные месяцы: ранее требовались хотя бы минимальные социальные скиллы, чтобы "дали списать домашку", а сейчас просто кнопку нажать. Но экзамены-то сдавать надо :)
Вузовское обучение айтишным темам быстро обесценивается: к реальной работе и так-то особо не готовили, а теперь ещё везде нужны хорошие скиллы, как работать с AI - с сильными западными моделями и всяческими опенсорсными харнесами, чему официально учить у нас никогда не будут просто по факту. Поэтому, в частности, сменить работу сегодня разработчику без карьерного консультанта практически нереально, если он не качал нетворк. Но попробуй-ка ещё найди такого хорошего консультанта.
Главный же минус, что работа с ментором, особенно на индивидуалке, становится привилегией богатых людей, тех у кого есть деньги, потому что цены на занятия ощутимо растут. А остальным остаются мутные нейрослоповые галлюцинации от дешёвых моделек.
Выход, очевидно, только в интенсивном росте, работе над собой. Бежать вперёд сегодня надо изо всех сил. Ну и побольше думать.
В конце концов, во всём, что делают люди, есть структура; и если вы сможете выявить эту структуру, то сможете понять, и как её изменить. Особенно с учётом контекстов, в которых было бы замечательно иметь подходящую структуру.
1❤38✍5👍4
Авторитеты поясняют за будущее айтишки с AI.
Роберт Мартин: агенты могут писать код лучше/быстрее людей, если жёстко ограничить их спецификациями, метриками и автотестами. Но человек всегда должен оставаться за штурвалом.
Джордж Хотц (легендарный хакер geohot): крупные компании из-за медленной обратной связи утонут в AI-слопе, а малые команды и одиночки наоборот получат преимущество.
Джон Кармак: использование AI неизбежно, но ценность остаётся в реальном решении проблем. Что будет в геймдеве, пока непонятно: либо меньше разработчиков в целом, либо больше маленьких команд.
Андерс Хейлсберг (наш любимый автор Delphi, C# и TS): AI -- незаменимый инструмент продуктивности разработки, но не замена белковым. Но джунов будет сильно меньше, а требования к мидлам растут сильно быстрее. Общее количество рабочих мест в ИТ сократится, но и рост силы AI замедляется по асимптоте.
DHH (папа RoR): ручной код экономически невыгоден, английский - лучший язык программирования, худший программист с AI в 1000 раз лучше лучшего программиста без AI. Но приведёт это к вымыванию профессиональных навыков и исчезновению рабочих мест.
Бьярн Страуструп: AI-код пока не готов для safety-/performance-critical систем. Мелкие изменения в промпте вызывают каскадные правки. "Английский - лучший язык программирования" называет идиотским высказыванием. Возможно, на перспективу безопаснее карьера в "низкоуровневых" языках (сишечка база, ага; ассемблер?), то есть в высоконагрузочных и встраиваемых системах, робототехнике.
Кент Бек: "Просто правильно сформулируйте спецификацию, и всё остальное приложится" — боже мой, я слышу эту чушь уже 50 лет."
Роберт Мартин: агенты могут писать код лучше/быстрее людей, если жёстко ограничить их спецификациями, метриками и автотестами. Но человек всегда должен оставаться за штурвалом.
Джордж Хотц (легендарный хакер geohot): крупные компании из-за медленной обратной связи утонут в AI-слопе, а малые команды и одиночки наоборот получат преимущество.
Джон Кармак: использование AI неизбежно, но ценность остаётся в реальном решении проблем. Что будет в геймдеве, пока непонятно: либо меньше разработчиков в целом, либо больше маленьких команд.
Андерс Хейлсберг (наш любимый автор Delphi, C# и TS): AI -- незаменимый инструмент продуктивности разработки, но не замена белковым. Но джунов будет сильно меньше, а требования к мидлам растут сильно быстрее. Общее количество рабочих мест в ИТ сократится, но и рост силы AI замедляется по асимптоте.
DHH (папа RoR): ручной код экономически невыгоден, английский - лучший язык программирования, худший программист с AI в 1000 раз лучше лучшего программиста без AI. Но приведёт это к вымыванию профессиональных навыков и исчезновению рабочих мест.
Бьярн Страуструп: AI-код пока не готов для safety-/performance-critical систем. Мелкие изменения в промпте вызывают каскадные правки. "Английский - лучший язык программирования" называет идиотским высказыванием. Возможно, на перспективу безопаснее карьера в "низкоуровневых" языках (сишечка база, ага; ассемблер?), то есть в высоконагрузочных и встраиваемых системах, робототехнике.
Кент Бек: "Просто правильно сформулируйте спецификацию, и всё остальное приложится" — боже мой, я слышу эту чушь уже 50 лет."
1❤46👍6
Кто в массе потеряет работу из-за AI скорее: программисты или менеджеры? Ну очевидно же.
Open Executive provides a single coherent executive voice backed by nine specialist AI agents:
Chief Strategy Officer — competitive analysis, M&A, market positioning, OKRs
Chief Financial Officer — financial modeling, fundraising, unit economics, cash flow
Chief HR/People Officer — hiring, compensation, performance, culture
General Counsel — contracts, IP, employment law basics, compliance
Chief Operating Officer — process design, vendor management, operational scaling
Chief Marketing Officer — GTM strategy, brand, communications, PR
Chief Product Officer — roadmap, prioritization, product strategy
Head of Sales — pipeline and qualification, founder-led sales, pricing conversations, proposals, forecasting
Board Communications Director — board decks, investor relations, governance
↑↑↑ с вещами на выход :)
Open Executive provides a single coherent executive voice backed by nine specialist AI agents:
Chief Strategy Officer — competitive analysis, M&A, market positioning, OKRs
Chief Financial Officer — financial modeling, fundraising, unit economics, cash flow
Chief HR/People Officer — hiring, compensation, performance, culture
General Counsel — contracts, IP, employment law basics, compliance
Chief Operating Officer — process design, vendor management, operational scaling
Chief Marketing Officer — GTM strategy, brand, communications, PR
Chief Product Officer — roadmap, prioritization, product strategy
Head of Sales — pipeline and qualification, founder-led sales, pricing conversations, proposals, forecasting
Board Communications Director — board decks, investor relations, governance
↑↑↑ с вещами на выход :)
😁34👍8❤5
Горячие топ-темки в айтишке: системный аналитик и 1C. В октябре уже наверное с десяток разных каналов написали про вкат в это. Менторство-шменторство с нуля за месяц на 300k/s, классика.
Про 1C ничего не могу сказать, помню ещё смешные случаи на их первых презентациях на ИТ-конференциях в 90-е ("а не застрелят за баги в бухгалтерии?" без шуток), ну разве что кроме очевидных вещей, что это не универсальный фреймворк разработки, а система автоматизации деятельности предприятий, и как минимум надо уверенно разбираться в соответствующих доменах (бухгалтерия финансы склад производство логистика, mrp/erp...). Ну а безусловные (и большие) плюсы, что это в России абсолютно стабильная темка + будете хорошо разбираться в соответствующих бизнес-процессах + в силу некоторой эээ неидеальности платформы 1C огромное поле для инди-хакерства.
Системный Аналитик (СисА) - это примитивно говоря "сеньор + архитектор + техлид + тимлид + продакт + dba + devops + бизнес-аналитик" в одном флаконе за символическую для работодателя цену, с единственным исключением: можно не уметь программировать.
Если это ещё 2-3 года назад была отдельная профессия, на которую сбрасывали постановку задач (на входе тупой заказчик который сам не знает что хочет, а на выходе ТЗ и спецификации, которые ленивый мидл может кое-как понять и что-то такое зарелизить), то сегодня спрос совершенно реально вырос ровно по той очевидной причине, что от СисА как раз не требуется умение программировать. Тогда это было скорее минусом и ограничивающим фактором, но сегодня из-за искусственного кодера стало большим плюсом и реально востребовано. Я собственно про это уже давно пишу, что вот поэтому сегодня и надо срочно расти в техдира; ну ок, или в системного аналитика.
Далее раскрою тему СисА более подробно (хорошие новости реально) => ...
Про 1C ничего не могу сказать, помню ещё смешные случаи на их первых презентациях на ИТ-конференциях в 90-е ("а не застрелят за баги в бухгалтерии?" без шуток), ну разве что кроме очевидных вещей, что это не универсальный фреймворк разработки, а система автоматизации деятельности предприятий, и как минимум надо уверенно разбираться в соответствующих доменах (бухгалтерия финансы склад производство логистика, mrp/erp...). Ну а безусловные (и большие) плюсы, что это в России абсолютно стабильная темка + будете хорошо разбираться в соответствующих бизнес-процессах + в силу некоторой эээ неидеальности платформы 1C огромное поле для инди-хакерства.
Системный Аналитик (СисА) - это примитивно говоря "сеньор + архитектор + техлид + тимлид + продакт + dba + devops + бизнес-аналитик" в одном флаконе за символическую для работодателя цену, с единственным исключением: можно не уметь программировать.
Если это ещё 2-3 года назад была отдельная профессия, на которую сбрасывали постановку задач (на входе тупой заказчик который сам не знает что хочет, а на выходе ТЗ и спецификации, которые ленивый мидл может кое-как понять и что-то такое зарелизить), то сегодня спрос совершенно реально вырос ровно по той очевидной причине, что от СисА как раз не требуется умение программировать. Тогда это было скорее минусом и ограничивающим фактором, но сегодня из-за искусственного кодера стало большим плюсом и реально востребовано. Я собственно про это уже давно пишу, что вот поэтому сегодня и надо срочно расти в техдира; ну ок, или в системного аналитика.
Далее раскрою тему СисА более подробно (хорошие новости реально) => ...
❤44✍3👍1
...Многие конторы просекли, что сегодня можно вполне обходиться без кодеров, которые раньше и стоили дорого, и трудно найти было,
а ведь автоматизировать хочется много чего,
но поговнокодив нейронками свои проэкты, быстро убедились что фиг прокатит без условного системного аналитика (умного посредника между заказчиком и исполнителем, хорошо владеющего онтологией ИТ).
Вот ещё до массового распространения нейронок хороший разбор на хабре, кто такой СисА: первое второе
Что хочут, знания и скиллы =>
Цикл разработки
Требования
Интеграции. REST. Очереди.
Базы данных. Связи. NoSQL.
SQL
Архитектура. Монолит-микросервисы.
Безопасность. Аутентификация, авторизация.
=
И: С какими интеграциями вы сталкивались?
К: Много работала с REST и интеграцией через очереди.
И: Давайте поговорим про REST. Расскажите про выбор методов, заголовки, тело запроса.
К: … (рассказываю)
И: Как реализовать асинхронное взаимодействие через http?
К: Вебхуки, более древний способ — long/short polling.
И: Расскажите про вебхуки? Какое отличие long от short polling? В чём минус polling?
К: …(рассказываю)
И: Хорошо, какие ещё инструменты для асинхронного взаимодействия знаете?
К: Веб-сокеты, очереди сообщений.
=
Стандартный набор задач:
Написание SQL-запроса.
Проектирование БД.
Проектирование API.
Проектирование системы (несколько микросервисов).
Описание процесса с помощью sequence-диаграммы.
=
Уметь выявлять требования с помощью разных техник
Описывать пользовательские и функциональные требования
Владеть моделированием процессов и данных
Понимать, как устроены приложения
Разбираться в процессе программирования
Ориентироваться в коде
Вчера например на нн с ходу нашёл свежую вакансию (удалёнка) на 200-250k =>
Умение выстраивать взаимодействие и совместную работу с заказчиками, командой, экспертами и другими участниками процесса создания, развития и сопровождения проектов;
Уметь принимать участие в проработке архитектурных решений;
Уметь планировать процесс разработки фичи, декомпозировать сложные процессы и задачи, ставить задачи другим участникам;
Навыки моделирования системы и умение описывать их с помощью разных нотаций и разных способов;
Опыт работы по описыванию бизнес-процессов, поведения пользователей и отклика системы, системных функций;
Уметь:
Проектировать модель данных БД;
Проектировать интеграционные взаимодействия;
Проектировать и описывать интеграции REST API, Ореп API, Kafka;
Проводить анализ данных, находить инсайты, аномалии. Формировать дашборды, визуализировать данные;
Принимать участие в написании тест-кейсов и тестировании (приемке разработки).
Как раньше под сисадмином-аникейщиком понимали мастера на все руки, да и от кодеров требовали настроить принтер ("тыжпрограммист"), так сегодня просто поднялись по абстракциям.
(Постепенно так и придём к теории типов, теоркату и математике)
Да, и вот что следует полезное прозаическое для нас с вами => ...
а ведь автоматизировать хочется много чего,
но поговнокодив нейронками свои проэкты, быстро убедились что фиг прокатит без условного системного аналитика (умного посредника между заказчиком и исполнителем, хорошо владеющего онтологией ИТ).
Вот ещё до массового распространения нейронок хороший разбор на хабре, кто такой СисА: первое второе
Что хочут, знания и скиллы =>
Цикл разработки
Требования
Интеграции. REST. Очереди.
Базы данных. Связи. NoSQL.
SQL
Архитектура. Монолит-микросервисы.
Безопасность. Аутентификация, авторизация.
=
И: С какими интеграциями вы сталкивались?
К: Много работала с REST и интеграцией через очереди.
И: Давайте поговорим про REST. Расскажите про выбор методов, заголовки, тело запроса.
К: … (рассказываю)
И: Как реализовать асинхронное взаимодействие через http?
К: Вебхуки, более древний способ — long/short polling.
И: Расскажите про вебхуки? Какое отличие long от short polling? В чём минус polling?
К: …(рассказываю)
И: Хорошо, какие ещё инструменты для асинхронного взаимодействия знаете?
К: Веб-сокеты, очереди сообщений.
=
Стандартный набор задач:
Написание SQL-запроса.
Проектирование БД.
Проектирование API.
Проектирование системы (несколько микросервисов).
Описание процесса с помощью sequence-диаграммы.
=
Уметь выявлять требования с помощью разных техник
Описывать пользовательские и функциональные требования
Владеть моделированием процессов и данных
Понимать, как устроены приложения
Разбираться в процессе программирования
Ориентироваться в коде
Вчера например на нн с ходу нашёл свежую вакансию (удалёнка) на 200-250k =>
Умение выстраивать взаимодействие и совместную работу с заказчиками, командой, экспертами и другими участниками процесса создания, развития и сопровождения проектов;
Уметь принимать участие в проработке архитектурных решений;
Уметь планировать процесс разработки фичи, декомпозировать сложные процессы и задачи, ставить задачи другим участникам;
Навыки моделирования системы и умение описывать их с помощью разных нотаций и разных способов;
Опыт работы по описыванию бизнес-процессов, поведения пользователей и отклика системы, системных функций;
Уметь:
Проектировать модель данных БД;
Проектировать интеграционные взаимодействия;
Проектировать и описывать интеграции REST API, Ореп API, Kafka;
Проводить анализ данных, находить инсайты, аномалии. Формировать дашборды, визуализировать данные;
Принимать участие в написании тест-кейсов и тестировании (приемке разработки).
Как раньше под сисадмином-аникейщиком понимали мастера на все руки, да и от кодеров требовали настроить принтер ("тыжпрограммист"), так сегодня просто поднялись по абстракциям.
(Постепенно так и придём к теории типов, теоркату и математике)
Да, и вот что следует полезное прозаическое для нас с вами => ...
❤34✍9👍2
Несмотря на кучу архитектурных тем, в системной аналитике практически полностью выпал скилл программирования, причём практически официально. А так-то он был реально самый тяжёлый и самый долгий для изучения в ИТ, и который давался далеко не всем на профессиональном уровне.
А вот то что сейчас требуется (ну или совсем скоро будет) массово, буквально в десятки раз больше, чем раньше обычные программисты, как манагеры распробуют вайбкодинг -- это пресловутый системный аналитик. Фактически системный аналитик - это чел на которого можно за копейки полностью спихнуть создание продукта, которым раньше занимался коллектив из десятков разработчиков :)
И что классно, что совершенно реально СисА сегодня может стать едва ли не каждый сообразительный, это по сути чистая инженерия, даже думать особо не надо. Ну может с десяток доменных терминологий/DSL изучить - буквально по статьям на хабре/вики, и сотню классических архитектурных паттернов, которые давно известны и хорошо разобраны, и надо просто уметь грамотно их комбинировать, причём вполне достаточно логики первого порядка.
Я кстати именно эти моменты по сути и разбираю на Last Principles Framework, только формально - через теорию категорий; постепенно и все онлайн-школы к ней придут (а я тем временем уйду ещё дальше :).
Сеньорам и техлидам выросшим из сеньоров, вообще можно не париться, ну разве что поактивнее качать AI-инженерию, дабы загонять в неё под автономию как можно больше рабочих процессов (ментатам тут помогаю по мере возможности), и главное конечно, профессиональная работа со спецификациями, буквально "думать спеками" (готовлю тут особую фишку).
А тем, кто реально планировал/планирует, ну или просто ещё искренне хочет "войти войти", порекомендую всё же это не бросать. Но если вы на данный момент изучаете программирование, вот его пока лучше отложить (хотя конечно минимальный скилл "написать/понять скрипт на питоне/пыхе/баше" всё равно будет востребован, но второстепенно), а взяться за system design, devops, и, очень важно, изучить базы данных и особенно SQL, потому что реляционная модель это база моделирования данных. Без её знания никаких нормальных спецификаций не получится.
Что как изучать в целом в каком порядке? Вбейте в поиске
"системный аналитик" курсы
походите по рекламным ссылкам, скачайте силлабусы, забросьте в бесплатный дипсик и попросите "начни со мной заниматься по этой схеме по шагам".
Вот например
4 месяца обучения
Нагрузка ~10 часов в неделю
5 проектов
2 промежуточных тестирования
Большая итоговая работа
9 воркшопов
Программная архитектура системы, стили архитектуры, микросервисная архитектура, системная интеграция, проектирование REST API, проектирование RPC, Query‑Based, Async APIs
Стоит 120-150 тысяч рублей :)
[чёта я ооооочень сильно недооцениваю свои курсы и проекты для ментатов, хм...]
Короче, резюме, что системный аналитик - это резко взлетевшая с явлением AI профессия, которая по сути станет новой массовой базой в ИТ, а спрос на неё превысит прежний спрос на программистов в сотни раз!!1 А по доступности она станет наоборот в сотни раз доступнее.
Но только "в сотни раз доступнее" в том смысле, что, да, потенциально её сможет освоить вообще любой человек, закончивший условный технический вуз, а не то что раньше жёстким фильтром были например алгоритмы и структуры данных-кодинг, над которыми приходилось реально сильно ломать голову, и давалось далеко не каждому.
Но при этом сам порог входа ощутимо вырастает, так как изучать всё же надо реально дофига. 4x4x10 = за 160 часов? Ну хз, вряд ли, хотя базу условного аналитика-джуна можно получить, да.
Зато СисА можно реально хорошо вытаскивать чисто на зубрёшке и софтах. А я в этом традиционно помогу.
А вот то что сейчас требуется (ну или совсем скоро будет) массово, буквально в десятки раз больше, чем раньше обычные программисты, как манагеры распробуют вайбкодинг -- это пресловутый системный аналитик. Фактически системный аналитик - это чел на которого можно за копейки полностью спихнуть создание продукта, которым раньше занимался коллектив из десятков разработчиков :)
И что классно, что совершенно реально СисА сегодня может стать едва ли не каждый сообразительный, это по сути чистая инженерия, даже думать особо не надо. Ну может с десяток доменных терминологий/DSL изучить - буквально по статьям на хабре/вики, и сотню классических архитектурных паттернов, которые давно известны и хорошо разобраны, и надо просто уметь грамотно их комбинировать, причём вполне достаточно логики первого порядка.
Я кстати именно эти моменты по сути и разбираю на Last Principles Framework, только формально - через теорию категорий; постепенно и все онлайн-школы к ней придут (а я тем временем уйду ещё дальше :).
Сеньорам и техлидам выросшим из сеньоров, вообще можно не париться, ну разве что поактивнее качать AI-инженерию, дабы загонять в неё под автономию как можно больше рабочих процессов (ментатам тут помогаю по мере возможности), и главное конечно, профессиональная работа со спецификациями, буквально "думать спеками" (готовлю тут особую фишку).
А тем, кто реально планировал/планирует, ну или просто ещё искренне хочет "войти войти", порекомендую всё же это не бросать. Но если вы на данный момент изучаете программирование, вот его пока лучше отложить (хотя конечно минимальный скилл "написать/понять скрипт на питоне/пыхе/баше" всё равно будет востребован, но второстепенно), а взяться за system design, devops, и, очень важно, изучить базы данных и особенно SQL, потому что реляционная модель это база моделирования данных. Без её знания никаких нормальных спецификаций не получится.
Что как изучать в целом в каком порядке? Вбейте в поиске
"системный аналитик" курсы
походите по рекламным ссылкам, скачайте силлабусы, забросьте в бесплатный дипсик и попросите "начни со мной заниматься по этой схеме по шагам".
Вот например
4 месяца обучения
Нагрузка ~10 часов в неделю
5 проектов
2 промежуточных тестирования
Большая итоговая работа
9 воркшопов
Программная архитектура системы, стили архитектуры, микросервисная архитектура, системная интеграция, проектирование REST API, проектирование RPC, Query‑Based, Async APIs
Стоит 120-150 тысяч рублей :)
[чёта я ооооочень сильно недооцениваю свои курсы и проекты для ментатов, хм...]
Короче, резюме, что системный аналитик - это резко взлетевшая с явлением AI профессия, которая по сути станет новой массовой базой в ИТ, а спрос на неё превысит прежний спрос на программистов в сотни раз!!1 А по доступности она станет наоборот в сотни раз доступнее.
Но только "в сотни раз доступнее" в том смысле, что, да, потенциально её сможет освоить вообще любой человек, закончивший условный технический вуз, а не то что раньше жёстким фильтром были например алгоритмы и структуры данных-кодинг, над которыми приходилось реально сильно ломать голову, и давалось далеко не каждому.
Но при этом сам порог входа ощутимо вырастает, так как изучать всё же надо реально дофига. 4x4x10 = за 160 часов? Ну хз, вряд ли, хотя базу условного аналитика-джуна можно получить, да.
Зато СисА можно реально хорошо вытаскивать чисто на зубрёшке и софтах. А я в этом традиционно помогу.
❤38✍6👍2
Крайне доволен эпик багом в PHP. Ну а с какого фига скачиваешь бесплатно мощную платформу разработки, за качество которой никто никакой ответственности не несёт по определению потому что халява и опенсорс, и доверяешь ей критически важные для твоего бизнеса проекты? Ты дурак?
Вообще, тренд на обесценивание инструментов и платформ разработки, начавшийся лет 20 назад, вот сегодня и приносит закономерные результаты. Когда-то ведь за IDE и компилятор на одно рабочее место приходилось платить 500-1000 долларов, я сам бегал покупал в МГУ лицензии Borland C++ в коробке. Крайне поучительный урок для айтишки, из которого никаких выводов сделано не будет, и это тоже хорошо.
Потому что, говорю уже не один год, как не выкручивайся, в конечном итоге всё сведётся к формально верифицированному стеку, от железа и ОС до компиляторов и IDE, а постепенно полноценная верификация будет требоваться вообще от любого продукта. Но темка эта ещё долго будет сильно дорогостоящей. Представьте если бы 60 миллиардов направить не на разрушение Рунета, а на верификацию российских продуктов? Вот это действительно была бы взрослая кибер-защита национальных ИТ-интересов.
Что же касается самого бага, всё что я прочитал даже в уважаемых пабликах, ну просто какой-то примитивный уровень истеричных белок и ноль критического мышления, "70% сайтов работает на пыхапы" и прочий бред. По дефолту
Ну и в целом, количество 0day с явлением AI никак особо не увеличилось, никаких эпических мировых сбоев не будет, потому что над серьёзными проектами работают профессиональные безопасники; а если пользуетесь халявным опенсорсом, так это чисто ваши проблемы. На какое-то время возможно критических багов будет чуть побольше, потому что просто теперь можно забросить большой проект в нейронку и она его почистит, но никаких "всё пропало" точно не будет.
А вот мелких багов станет в сотни раз больше из-за вайб-кодинга, поэтому кибербез однозначно будет расти.
Вообще, тренд на обесценивание инструментов и платформ разработки, начавшийся лет 20 назад, вот сегодня и приносит закономерные результаты. Когда-то ведь за IDE и компилятор на одно рабочее место приходилось платить 500-1000 долларов, я сам бегал покупал в МГУ лицензии Borland C++ в коробке. Крайне поучительный урок для айтишки, из которого никаких выводов сделано не будет, и это тоже хорошо.
Потому что, говорю уже не один год, как не выкручивайся, в конечном итоге всё сведётся к формально верифицированному стеку, от железа и ОС до компиляторов и IDE, а постепенно полноценная верификация будет требоваться вообще от любого продукта. Но темка эта ещё долго будет сильно дорогостоящей. Представьте если бы 60 миллиардов направить не на разрушение Рунета, а на верификацию российских продуктов? Вот это действительно была бы взрослая кибер-защита национальных ИТ-интересов.
Что же касается самого бага, всё что я прочитал даже в уважаемых пабликах, ну просто какой-то примитивный уровень истеричных белок и ноль критического мышления, "70% сайтов работает на пыхапы" и прочий бред. По дефолту
session.upload_progress.cleanup включён например и это уже норм, и в целом требуется с десяток предварительных нестандартных условий (обход ASLR, утечка памяти, нестрогий режим сессий) плюс весьма сложная цепочка эксплойта. Многие десятки популярных сайтов были просканированы, и ни на одном этот баг не сработал. Ну а если тебя взломали, значит просто твой вебмастер лох (а скорее всего вайб-кодер), гони его нафиг.Ну и в целом, количество 0day с явлением AI никак особо не увеличилось, никаких эпических мировых сбоев не будет, потому что над серьёзными проектами работают профессиональные безопасники; а если пользуетесь халявным опенсорсом, так это чисто ваши проблемы. На какое-то время возможно критических багов будет чуть побольше, потому что просто теперь можно забросить большой проект в нейронку и она его почистит, но никаких "всё пропало" точно не будет.
А вот мелких багов станет в сотни раз больше из-за вайб-кодинга, поэтому кибербез однозначно будет расти.
1👍28✍10❤5
Мой подход к кибербезу кстати стратегический, а не эти ваши SOC GRC DFIR/TH/MA ... Нормально делай - нормально будет ) Качественное проектирование, формальные методы, по определению снижают количество багов, особенно критических - и соответственно общее время разработки - во многие разы.
Вначале необходимость продумывания архитектуры вас замедляет. Но по мере того, как ваш проект растёт, вас начинает замедлять отсутствие продуманной архитектуры.
Создайте Big Ball of Mud, и агенты с радостью продолжат копаться в говнокоде.
Создайте структурированную систему с разделением задач и чёткими контрактами (типами) между модулями, и агенты будут продуктивно следовать такому шаблону.
Если AI продолжает и продолжает ошибаться в коде, прекратите давать ему больше и больше инструкций, что нужно сделать. Давайте ему наоборот больше информации о том, что должно оставаться неизменным, а что вообще нельзя/не надо делать.
Думайте инвариантами и safe-паттернами на формальных языках, которые нейронке сложно сломать ("Функциональные архитектуры" в помощь).
Вначале необходимость продумывания архитектуры вас замедляет. Но по мере того, как ваш проект растёт, вас начинает замедлять отсутствие продуманной архитектуры.
Создайте Big Ball of Mud, и агенты с радостью продолжат копаться в говнокоде.
Создайте структурированную систему с разделением задач и чёткими контрактами (типами) между модулями, и агенты будут продуктивно следовать такому шаблону.
Если AI продолжает и продолжает ошибаться в коде, прекратите давать ему больше и больше инструкций, что нужно сделать. Давайте ему наоборот больше информации о том, что должно оставаться неизменным, а что вообще нельзя/не надо делать.
Думайте инвариантами и safe-паттернами на формальных языках, которые нейронке сложно сломать ("Функциональные архитектуры" в помощь).
5✍33❤13
Действительно, нейронка сейчас вполне может создать проект среднего размера на сотни тысяч строк кода просто по словесному описанию. Причём и архитектуру продумает неплохо, и сопровождать и развивать в принципе тоже сможет без излишних затрат. Хотя в целом конечно и платить за это хорошим моделям придётся прилично, суммарно - от одного доллара на каждые 100 строк добавленного/модифицированного кода.
Засада в том, что проект состоит из сотен/тысяч мелких решений: как работают экранные формы, что делать при той или иной ошибке, как вести себя в "редких" случаях (коих всегда воз и маленькая тележка), что важнее - скорость или надёжность. Если их не указать явно, нейронка примет такие решения сама, и далеко не всегда так, как вы представляли себе, т.к. читать мысли пока не умеет.
Кроме того любой проект - это всегда множество внутренних компромиссов, например между откликом и надёжностью; теоремы CAP, FLP (Fischer–Lynch–Paterson), что разбирал на Функциональных архитектурах, доказаны математически. Заложишься на "поскорее сделать", и проект через месяц заткнётся на 50 юзерах или будет лагать по 10 секунд. Ну или бот РКН штрафанёт на миллиончик за утечку персданных :)
=
Ведь по сути полное и точное описание продукта и есть программирование :) только на условно естественном языке. Карпатый недаром недавно рекомендовал упрощённые технические языки вроде ASD-STE100; я за более формальные подходы, потому что порог входа с ними выше, но зато и эффект куда мощнее.
Самые впечатляющие случаи, где AI сам написал огромный проект, как правило, делались на качественной спецификации и больших наборах тестов. Например, когда переписывали компиляторы, там уже был и стандарт и тысячи готовых проверок. А без спек и тестов уже 100 тысяч строк кода нейронка вдолгую совсем не потянет, проект быстро развалится.
Короче, роль чела сильно смещается к продвинутому системному аналитику: тестировщику с качественным фидбеком + продакту + архитектору. Собственно, заказчик всегда "словами описывал" желаемый продукт команде разработчиков, и работало это только при постоянном общении, бесконечных уточнениях и формальной приёмке. С AI всё это и остаётся, только быстрее (и дешевле?).
В любом случае, всегда требуйте в таких процессах от AI задавать уточняющие вопросы "до понимания на 90%", и писать хотя бы регрессионные тесты. Жертвовать ими можно, только если не планируете развивать проект вдолгую.
Засада в том, что проект состоит из сотен/тысяч мелких решений: как работают экранные формы, что делать при той или иной ошибке, как вести себя в "редких" случаях (коих всегда воз и маленькая тележка), что важнее - скорость или надёжность. Если их не указать явно, нейронка примет такие решения сама, и далеко не всегда так, как вы представляли себе, т.к. читать мысли пока не умеет.
Кроме того любой проект - это всегда множество внутренних компромиссов, например между откликом и надёжностью; теоремы CAP, FLP (Fischer–Lynch–Paterson), что разбирал на Функциональных архитектурах, доказаны математически. Заложишься на "поскорее сделать", и проект через месяц заткнётся на 50 юзерах или будет лагать по 10 секунд. Ну или бот РКН штрафанёт на миллиончик за утечку персданных :)
=
Ведь по сути полное и точное описание продукта и есть программирование :) только на условно естественном языке. Карпатый недаром недавно рекомендовал упрощённые технические языки вроде ASD-STE100; я за более формальные подходы, потому что порог входа с ними выше, но зато и эффект куда мощнее.
Самые впечатляющие случаи, где AI сам написал огромный проект, как правило, делались на качественной спецификации и больших наборах тестов. Например, когда переписывали компиляторы, там уже был и стандарт и тысячи готовых проверок. А без спек и тестов уже 100 тысяч строк кода нейронка вдолгую совсем не потянет, проект быстро развалится.
Короче, роль чела сильно смещается к продвинутому системному аналитику: тестировщику с качественным фидбеком + продакту + архитектору. Собственно, заказчик всегда "словами описывал" желаемый продукт команде разработчиков, и работало это только при постоянном общении, бесконечных уточнениях и формальной приёмке. С AI всё это и остаётся, только быстрее (и дешевле?).
В любом случае, всегда требуйте в таких процессах от AI задавать уточняющие вопросы "до понимания на 90%", и писать хотя бы регрессионные тесты. Жертвовать ими можно, только если не планируете развивать проект вдолгую.
👍22❤16✍7
...Но есть маааленький нюанс: на длинной дистанции проект, созданный AI, ломается более чем полностью. Без проектной дисциплины он деградирует на порядки быстрее обычного.
Нейронка ничего не помнит, каждая сессия начинается почти с нуля и каждый раз сжирает океан токенов. AI не знает, почему минуту назад сделала фичу именно так.
Без тестов любая правка может незаметно сломать что-то в логике в другом месте (особенно это страшно в асинхронщине; помните "Незримые механизмы логики"?). На проекте в сотни тысяч строк никто не заметит этого вообще, да и кому замечать-то?
Код вообще никто не понимает, и если условный системный аналитик не держит в голове/в спеках общую картину, рано или поздно появятся баги/логические тупики, которые не сможет исправить ни он, ни самая топовая нейронка.
Архитектура постепенно расползается: AI хорошо дописывает новое, но слабо переделывает старое, потому что нету никакого понимания. В итоге код стремительно раздувается и запутывается, и технический долг растёт на порядки быстрее, чем в проектах, которые пишут люди.
Абсолютная база: тесты. Это и память проекта, и спецификации в некотором смысле, и защита от регрессий. На длинной дистанции без них вообще никак, сколь бы дорого они не обходились.
Документация: ТЗ, спецификации, описание архитектуры, записи, почему приняты те или иные ключевые решения.
Модульность: мелкие независимые части с понятными границами, чтобы AI мог работать с куском кода, не видя всё целиком (DDD в помощь).
СисА :) Тот, кто отвечает за архитектуру, и имеет целостное её понимание.
=
Короче, запустить весьма приличный проэкт просто "словами в микрофон" реально уже сейчас (если есть баблишко, сотня килорублей на токены :). Даже 100 тысяч строк кстати это очень приличный размер, для сравнения, типовая мобильная игра - это 5, максимум 10 тысяч строк ручного кода. Правда, и AI код раздувает очень сильно, в разы точно, а в сравнении с функциональщиной, так и на порядки.
Так вот, чтобы многими месяцами/годами развивать любой серьёзный проект, нужна полноценная инженерная культура. Нейронка будут постепенно лучше справляться с памятью и контекстом, но необходимость держать продукт и кодовую базу в порядке с помощью человека никуда не денется.
Нейронка ничего не помнит, каждая сессия начинается почти с нуля и каждый раз сжирает океан токенов. AI не знает, почему минуту назад сделала фичу именно так.
Без тестов любая правка может незаметно сломать что-то в логике в другом месте (особенно это страшно в асинхронщине; помните "Незримые механизмы логики"?). На проекте в сотни тысяч строк никто не заметит этого вообще, да и кому замечать-то?
Код вообще никто не понимает, и если условный системный аналитик не держит в голове/в спеках общую картину, рано или поздно появятся баги/логические тупики, которые не сможет исправить ни он, ни самая топовая нейронка.
Архитектура постепенно расползается: AI хорошо дописывает новое, но слабо переделывает старое, потому что нету никакого понимания. В итоге код стремительно раздувается и запутывается, и технический долг растёт на порядки быстрее, чем в проектах, которые пишут люди.
Абсолютная база: тесты. Это и память проекта, и спецификации в некотором смысле, и защита от регрессий. На длинной дистанции без них вообще никак, сколь бы дорого они не обходились.
Документация: ТЗ, спецификации, описание архитектуры, записи, почему приняты те или иные ключевые решения.
Модульность: мелкие независимые части с понятными границами, чтобы AI мог работать с куском кода, не видя всё целиком (DDD в помощь).
СисА :) Тот, кто отвечает за архитектуру, и имеет целостное её понимание.
=
Короче, запустить весьма приличный проэкт просто "словами в микрофон" реально уже сейчас (если есть баблишко, сотня килорублей на токены :). Даже 100 тысяч строк кстати это очень приличный размер, для сравнения, типовая мобильная игра - это 5, максимум 10 тысяч строк ручного кода. Правда, и AI код раздувает очень сильно, в разы точно, а в сравнении с функциональщиной, так и на порядки.
Так вот, чтобы многими месяцами/годами развивать любой серьёзный проект, нужна полноценная инженерная культура. Нейронка будут постепенно лучше справляться с памятью и контекстом, но необходимость держать продукт и кодовую базу в порядке с помощью человека никуда не денется.
❤27✍12🔥2
И вот база айтишки с аишкой на годы вперёд: одним из главных навыков, а скорее всего, и самым главным, станет мышление спецификациями. Спеки теперь -- это основной рабочий инструмент архитектора (разработчика в целом), которым раньше был код как главный артефакт, а документация обычно отставала. Но теперь код можно перегенерировать заново, и (вероятно) точное описание того, а что вообще нужно, остаётся единственным источником истины в проекте.
AI делает то, что вы описали, а не то, что вы подразумевали и имели в виду. Даже небольшая неточность в спецификации сразу превращается в неправильный код, причём в больших объёмах; цена нечёткого мышления сильно растёт (а откуда чёткое мышление взять-то? :).
Спецификация и есть тест! Чётко заданные контракты (в идеале, системой типов), инварианты и граничные случаи легко превратить в тесты, ведь без них нечем оценить, правильно ли нейронка всё сделала.
Спеки -- память проекта. Как говорил выше, на длинной дистанции спецификации и записи о ключевых архитектурных решениях единственные дают AI контекст, без которого он просто ничего не сможет сделать.
База =>
Думать контрактами: что модуль принимает, что гарантирует, что запрещено. Это собственно тип модуля, только в математическом смысле, о чём подробно пояснял Роберт Харпер, формализовавший языки ML и подготовивший кучу курсов для Карнеги-Меллона, в книге "Модули важнее всего" (в СИ делал выжимку из неё; на бусти скоро будет гайд).
Явно задавать инварианты и граничные случаи, то есть то, что "очевидно" человеку, но не сетке.
Уметь проводить границы (На "Функциональных архитектурах" у меня есть большой модуль "Математика DDD"): делить систему на части, каждую из которых можно описать и проверять отдельно.
Записывать, почему принято то или иное решение, а не только что решили.
Видеть, что не описано: уметь находить дыры и неоднозначности в требованиях.
Теория категорий очень в помощь для тотальной композиционности всего и на всех уровнях.
=
И, да, если системный аналитик - самозванец после онлайн-курсов, который не понимает, как подобные системы работают на деле, то он выдумает красивую, но нереализуемую или тормозную спецификацию; то есть инженерная экспертиза хотя бы на уровне крепкого мидла обязательна.
Короче, ценность разработчика-27 быстро смещается от умения написать код к умению точно сформулировать спецификации и умению грамотно проверить результаты. Кто умеет ясно и чётко думать спеками и формализовать требования, только и останется в айтишке!
=
...Это всё был прогрев на мой новый курс "Стань системным аналитиком с нуля на зп 512k за 4 недели всего за 128 тысяч рублей можно в кредит"!!1
Шутка.
Ментатам по этим темкам будет бесплатно доступен тренажёр спецификаций, уже скоро. Нет, не навайбкоженная фигня. Делаю в основном вручную, качественный контент/задачи без глубокого понимания формальных логик на уровне PhD тут фиг сделаешь :) Понятно, что вайб-клоны появятся быстро, но мне не жалко, чем больше будут учиться формально рассуждать, тем только лучше.
AI делает то, что вы описали, а не то, что вы подразумевали и имели в виду. Даже небольшая неточность в спецификации сразу превращается в неправильный код, причём в больших объёмах; цена нечёткого мышления сильно растёт (а откуда чёткое мышление взять-то? :).
Спецификация и есть тест! Чётко заданные контракты (в идеале, системой типов), инварианты и граничные случаи легко превратить в тесты, ведь без них нечем оценить, правильно ли нейронка всё сделала.
Спеки -- память проекта. Как говорил выше, на длинной дистанции спецификации и записи о ключевых архитектурных решениях единственные дают AI контекст, без которого он просто ничего не сможет сделать.
База =>
Думать контрактами: что модуль принимает, что гарантирует, что запрещено. Это собственно тип модуля, только в математическом смысле, о чём подробно пояснял Роберт Харпер, формализовавший языки ML и подготовивший кучу курсов для Карнеги-Меллона, в книге "Модули важнее всего" (в СИ делал выжимку из неё; на бусти скоро будет гайд).
Явно задавать инварианты и граничные случаи, то есть то, что "очевидно" человеку, но не сетке.
Уметь проводить границы (На "Функциональных архитектурах" у меня есть большой модуль "Математика DDD"): делить систему на части, каждую из которых можно описать и проверять отдельно.
Записывать, почему принято то или иное решение, а не только что решили.
Видеть, что не описано: уметь находить дыры и неоднозначности в требованиях.
Теория категорий очень в помощь для тотальной композиционности всего и на всех уровнях.
=
И, да, если системный аналитик - самозванец после онлайн-курсов, который не понимает, как подобные системы работают на деле, то он выдумает красивую, но нереализуемую или тормозную спецификацию; то есть инженерная экспертиза хотя бы на уровне крепкого мидла обязательна.
Короче, ценность разработчика-27 быстро смещается от умения написать код к умению точно сформулировать спецификации и умению грамотно проверить результаты. Кто умеет ясно и чётко думать спеками и формализовать требования, только и останется в айтишке!
=
...Это всё был прогрев на мой новый курс "Стань системным аналитиком с нуля на зп 512k за 4 недели всего за 128 тысяч рублей можно в кредит"!!1
Шутка.
Ментатам по этим темкам будет бесплатно доступен тренажёр спецификаций, уже скоро. Нет, не навайбкоженная фигня. Делаю в основном вручную, качественный контент/задачи без глубокого понимания формальных логик на уровне PhD тут фиг сделаешь :) Понятно, что вайб-клоны появятся быстро, но мне не жалко, чем больше будут учиться формально рассуждать, тем только лучше.
✍35❤14🥰3
Продолжаю работу с ментатами 🤓
Вообще, как некоторое резюме задания - очень частый соблазн поставить проверку "а вдруг сюда откуда-нибудь дойдут неконсистентные значения параметров". Это очень частая мысль и на самом деле я раньше думал, что это хорошая мысль - значит я хороший программист, раз вижу потенциальную опасность и ставлю защиту :) А оказалось, что это признак плохого дизайна системы...
Раньше я считал «хорошим кодом» максимально точные типы и длинные говорящие имена. Но именно точность множества и порождает мономорфизм: чем конкретнее тип, тем больше сущностей и реализаций ему соответствует, и тем больше мест, где можно ошибиться...
Я приступал к курсу с мыслями:
- у меня с именами переменных всё ок, я же стараюсь давать понятные имена :)
- стиль кодирования влияет только на косметические изменения, а не на суть кода.
Как же я ошибался)
выяснилось, что около 40% сессий пользователей покрываются двумя сценариями, а остальные 60 еще несколькими тысячами...
Оказалось, что OpenSpec даёт такую схему работы, к которой я так или иначе стремился раньше. Думаю, что это результат чтения ваших блогов. В моей голове крутилась мысль, что с ИИ надо работать через спецификации: задаём ему крутую спеку, а код пускай лежит на агенте, главное чётко описать требования...
(и заодно хочу поблагодарить за сайд-квест с ИИ-разработкой, спасибо, было очень полезно, сам бы долго еще полз к этим темам)
В целом концепция логичная и понятная, стараюсь аналогично делать в повседневной практике.
Регулярно сталкиваюсь с прямо противоположными ситуациями от коллег :)
Есть большое множество способов избавиться от if и их можно долго изучать, но всё равно оказываться в ситуации, когда тебе не понятно, а как убрать условие в каком-то конкретном случае. Хорошо, что все эти способы сводятся к паре мета-правил из которых и вытекают многочисленные советы. Тут поймал себя на мысли, что большая часть материалов Лаборатории сводится к таким сильным правилам и идеям, которые лежат в основе множества разнообразных подходов.
Нам достаточно понять эти правила и научиться их применять.
Так приятно, когда ребята уже сами замечают твои мета-схемы )
ФА ещё для меня была крайне интересна потому, что я сразу начал её прикладное применение. Уже и разобрался с value objects, почему они независимы от api моделей, как и почему не делать двойных одинаковых валидаций и т.д. Та мозаика, которую я сам нащупывал (я писал о предыдущем проекте в [...]), теперь после ФА сложилась в цельную непротиворечивую систему.
Я в неё реально погрузился с головой просто забыв обо всём остальном.
Кстати, хорошо что ФА закрыто для начинающих, мне кажется не познав болей на реальном проекте, невозможно по достоинству оценить саму ФА...
- Стараюсь решать задачки в строгой последовательности "декомпозиция - спецификация - дизайн - код" - тоже есть успехи, отчасти благодаря openspec. Но в первую очередь благодаря вам :)
Первое впечатления от курса по теории категорий великолепное. Понимаю что треком «как понять в программировании все» вы мне заложили свинцовый фундамент. Помою тогда я еще плохо умел учиться и просто материалы из подготовительных постов в ВК конспектировал в тетрадку.
Интересная кстати связка с треком по вычислительным моделям, я и сам не замечал.
Честно сказать, мало что могу добавить, кроме повторяющихся слов про проверке типизатором вместо компилятора.
Но наверное это и неплохо - оформилась мысль, что каждый проект на питоне требует (требует!) таких проверок,
потому что надеяться на разум или даже !сверх!разум, как показывает старкрафт, опрометчиво.
Я ровно с этой проблемой столкнулся на проекте [...], где мы пилили агентов (по СИ "156) First principle для внедрения AI в проект").
Так там ещё они постоянно пытались свои недоделанные приляпки заставлять использовать, вместо того же OpenTelemetry, но хотя бы да, двигались в правильную сторону.
Действительно, для недетерминированной системы старые методики наблюдаемости неприменимы.
Да более того, один из агентов как раз по метрикам был в полном порядке, но по факту нёс околесицу и дальше одного инструмента не уходил (а должен был минимум 3 использовать из 5).
Но тогда я чётко для себя понял что без тотального контроля что куда и почему разбирать поведение системы на проде, да и на тестовых контурах, невозможно.
Ещё заметил, что бизнес часто пытается внедрить GenAI туда, где бизнесово детерминированное поведение, которое можно однозначно посчитать, но вот требует потом точно такого же детерминированного поведения от недетерминированной системы.
Это кстати экзистенциальная проблема. когда менеджеры продолжают относиться к нейронкам как к обычным инструментам (библиотеки фреймворки), и пытаются их тупо "внедрять", но это ведь совсем другое, это куда ближе к иррациональным человечкам...
Вообще за последнее время столько новой информации, что "голова" пухнет =)
Вроде только начал разбираться с SDD, а уже вижу spdd, openprose и что лучше пока не понятно.
Хочется попробовать всё, но время ограничено и не успеть (несмотря на то, что использование агентов пока позволило автоматизировать часть ручного труда и успеваю в рабочий день изучать новое) =)
С одной стороны - появилось забытое чувство радости от изучения нового, когда только начинал путь в айти.
С другой стороны - понимание, что каждая новая версия будет обесценивать часть проделанной работы за счёт того, что станет умнее. Но кажется здесь и нужно находить и сосредоточиваться как раз на том, что не зависит от модели (в частности о чём пишется в ФА).
Вообщем здесь ещё работать и работать, но хотя бы появилось некоторое начальное понимание...
Да, и теоркат в помощь) Нейронки формальные описания хорошо воспринимают, а когда везде присутствует композиционность, система хорошо декомпозируется, и сломать что-то довольно сложно.
Вообще, как некоторое резюме задания - очень частый соблазн поставить проверку "а вдруг сюда откуда-нибудь дойдут неконсистентные значения параметров". Это очень частая мысль и на самом деле я раньше думал, что это хорошая мысль - значит я хороший программист, раз вижу потенциальную опасность и ставлю защиту :) А оказалось, что это признак плохого дизайна системы...
Раньше я считал «хорошим кодом» максимально точные типы и длинные говорящие имена. Но именно точность множества и порождает мономорфизм: чем конкретнее тип, тем больше сущностей и реализаций ему соответствует, и тем больше мест, где можно ошибиться...
Я приступал к курсу с мыслями:
- у меня с именами переменных всё ок, я же стараюсь давать понятные имена :)
- стиль кодирования влияет только на косметические изменения, а не на суть кода.
Как же я ошибался)
выяснилось, что около 40% сессий пользователей покрываются двумя сценариями, а остальные 60 еще несколькими тысячами...
Оказалось, что OpenSpec даёт такую схему работы, к которой я так или иначе стремился раньше. Думаю, что это результат чтения ваших блогов. В моей голове крутилась мысль, что с ИИ надо работать через спецификации: задаём ему крутую спеку, а код пускай лежит на агенте, главное чётко описать требования...
(и заодно хочу поблагодарить за сайд-квест с ИИ-разработкой, спасибо, было очень полезно, сам бы долго еще полз к этим темам)
В целом концепция логичная и понятная, стараюсь аналогично делать в повседневной практике.
Регулярно сталкиваюсь с прямо противоположными ситуациями от коллег :)
Есть большое множество способов избавиться от if и их можно долго изучать, но всё равно оказываться в ситуации, когда тебе не понятно, а как убрать условие в каком-то конкретном случае. Хорошо, что все эти способы сводятся к паре мета-правил из которых и вытекают многочисленные советы. Тут поймал себя на мысли, что большая часть материалов Лаборатории сводится к таким сильным правилам и идеям, которые лежат в основе множества разнообразных подходов.
Нам достаточно понять эти правила и научиться их применять.
Так приятно, когда ребята уже сами замечают твои мета-схемы )
ФА ещё для меня была крайне интересна потому, что я сразу начал её прикладное применение. Уже и разобрался с value objects, почему они независимы от api моделей, как и почему не делать двойных одинаковых валидаций и т.д. Та мозаика, которую я сам нащупывал (я писал о предыдущем проекте в [...]), теперь после ФА сложилась в цельную непротиворечивую систему.
Я в неё реально погрузился с головой просто забыв обо всём остальном.
Кстати, хорошо что ФА закрыто для начинающих, мне кажется не познав болей на реальном проекте, невозможно по достоинству оценить саму ФА...
- Стараюсь решать задачки в строгой последовательности "декомпозиция - спецификация - дизайн - код" - тоже есть успехи, отчасти благодаря openspec. Но в первую очередь благодаря вам :)
Первое впечатления от курса по теории категорий великолепное. Понимаю что треком «как понять в программировании все» вы мне заложили свинцовый фундамент. Помою тогда я еще плохо умел учиться и просто материалы из подготовительных постов в ВК конспектировал в тетрадку.
Интересная кстати связка с треком по вычислительным моделям, я и сам не замечал.
Честно сказать, мало что могу добавить, кроме повторяющихся слов про проверке типизатором вместо компилятора.
Но наверное это и неплохо - оформилась мысль, что каждый проект на питоне требует (требует!) таких проверок,
потому что надеяться на разум или даже !сверх!разум, как показывает старкрафт, опрометчиво.
Я ровно с этой проблемой столкнулся на проекте [...], где мы пилили агентов (по СИ "156) First principle для внедрения AI в проект").
Так там ещё они постоянно пытались свои недоделанные приляпки заставлять использовать, вместо того же OpenTelemetry, но хотя бы да, двигались в правильную сторону.
Действительно, для недетерминированной системы старые методики наблюдаемости неприменимы.
Да более того, один из агентов как раз по метрикам был в полном порядке, но по факту нёс околесицу и дальше одного инструмента не уходил (а должен был минимум 3 использовать из 5).
Но тогда я чётко для себя понял что без тотального контроля что куда и почему разбирать поведение системы на проде, да и на тестовых контурах, невозможно.
Ещё заметил, что бизнес часто пытается внедрить GenAI туда, где бизнесово детерминированное поведение, которое можно однозначно посчитать, но вот требует потом точно такого же детерминированного поведения от недетерминированной системы.
Это кстати экзистенциальная проблема. когда менеджеры продолжают относиться к нейронкам как к обычным инструментам (библиотеки фреймворки), и пытаются их тупо "внедрять", но это ведь совсем другое, это куда ближе к иррациональным человечкам...
Вообще за последнее время столько новой информации, что "голова" пухнет =)
Вроде только начал разбираться с SDD, а уже вижу spdd, openprose и что лучше пока не понятно.
Хочется попробовать всё, но время ограничено и не успеть (несмотря на то, что использование агентов пока позволило автоматизировать часть ручного труда и успеваю в рабочий день изучать новое) =)
С одной стороны - появилось забытое чувство радости от изучения нового, когда только начинал путь в айти.
С другой стороны - понимание, что каждая новая версия будет обесценивать часть проделанной работы за счёт того, что станет умнее. Но кажется здесь и нужно находить и сосредоточиваться как раз на том, что не зависит от модели (в частности о чём пишется в ФА).
Вообщем здесь ещё работать и работать, но хотя бы появилось некоторое начальное понимание...
Да, и теоркат в помощь) Нейронки формальные описания хорошо воспринимают, а когда везде присутствует композиционность, система хорошо декомпозируется, и сломать что-то довольно сложно.
❤26✍8
Немного про тренажёр спецификаций: это такая интерактивная история, как девопс Олег устраивается на новую работу, и встречается с кучей проблемных спек и всяческими интригами. Каждая небольшая серия под некоторый вид формальной логики, по 3-5 задачек - от простой на 5-10 минут до посложнее на 20-30 минут. Цель: научиться правильно рассуждать спеками.
Код весь hand made 100% (windows), задачки готовлю по заветам Теренса Тао в процессе тесного чатинга с продвинутыми модельками. Наверное можно и навайбкодить, но всё равно придётся редактировать и перепроверять, в каких-то случаях только SAT-солвер поможет (например, семантика Крипке), а в более тяжёлых логиках нужны более мощные модел чекеры (например TLA+ для темпоральной логики), а то и пруф-ассистанты.
Кстати с удивлением выяснил, что и в Lean4 и в Coq/Rocq и в Isabelle/HOL нишево формализованы лишь базовые логики (пропозициональная, классическая предикатов...), а едва например появляется фикс-поинт, автоматика исчезает, и надо много думать ручками интерактивно. Поэтому особо тут фиг навайбкодишь если не PhD (ну ладно, если не мехмат:), и это радует. Возможно придётся пилить свой прувер )
Название не придумал пока, например хорошо SATisfactory :) но занято.
Мыслить спеками - теперь база, но главное конечно не знание формализмов, а логическая грамотность. Нейронки всё лучше пишут не только код, но и доказательства, пред- постусловия и инварианты в Lean/Dafny/Coq, однако узкое место -- правильная формулировка, что нужно формализовать, а это как раз навык человека будет ещё долго (естественный язык размыт, а логика нет). Тесты проверяют отдельные примеры, а формальная спецификация описывает свойства для всех случаев: при сотнях тысяч строк сгенерированного кода это сильный аргумент, согласитесь.
Да, 80% пользы вы получите за 20% усилий: строгая система типов, функциональная архитектура, контракты в коде, property-based тесты. И логиком становиться совсем не обязательно, но мыслить спеками -- в терминах инвариантов, кванторов, состояний, переходов, живучести и безопасности, станет ценным навыком, потому что именно на языках логики точнее всего можно поставить задачу сетке, и проверить результат.
Я дал ребятам первые задачки потестить =>
Во-первых, структурирование своих мыслей по поводу задачи - уже само по себе полезный и важный навык. Я об этом догадывался и раньше, прежде чем начинать делать задачу, сначала пытался всё подробно расписать на бумаге, что зачем и почему, что будет если А и что будет если Б, как и на что будет влиять. И ещё тогда заметил что когда сам себе составляешь такую спецификацию - код потом по ней пишется как по маслу (оно и не мудрено, всё ж уже загружено и прощупано в голове вдоль и поперёк). Очень выручало при реализации сложных задач.
Но тут надо поправку сделать, что я чем-то подобным как раз занимаюсь когда спеки пишу для агента.
Самое бесценное, а именно что из №... вообще не следует, что надо (агенту) бэкапы делать, мне пришло только вечером лежа в кровати :))
Спасибо огромное, 10 системных аналитиков из 10, мне прямо очень понравилось !!!
=
Из тренажёра:
Первую спецификацию Олегу выдали для разминки. Это был сервис заказов, который в компании все называли "тот, что падает по пятницам".
— А как же они договорились о спецификации?
— Никак. Каждый вписывал свои пункты ночью, пока другой спал. Поэтому там "ровно одним способом" и рядом "неверно, что одновременно обоими".
На вторую неделю Олега допустили к продовой корзине. В «ОблакоСофте» корзина была местной легендой: товары в ней иногда исчезали, а иногда появлялись чужие. Пользователи писали в поддержку: "Кто положил мне в корзину шесть пылесосов?"...
Ещё там был спор про релизы: blue-green или canary. Одна фраза говорила "canary только с Prometheus и алертами", другая — "если есть Prometheus и алерты, то canary".
— Это же одно и то же, — сказал Олег.
— Вот и наш прошлый стажёр так сказал, — ответил тимлид. — Подправил спеку. Мы потом месяц катили релизы через blue-green при полностью настроенном мониторинге. Без резервного окружения.
— И как?
— Пылесосы...
ex falso quodlibet
Код весь hand made 100% (windows), задачки готовлю по заветам Теренса Тао в процессе тесного чатинга с продвинутыми модельками. Наверное можно и навайбкодить, но всё равно придётся редактировать и перепроверять, в каких-то случаях только SAT-солвер поможет (например, семантика Крипке), а в более тяжёлых логиках нужны более мощные модел чекеры (например TLA+ для темпоральной логики), а то и пруф-ассистанты.
Кстати с удивлением выяснил, что и в Lean4 и в Coq/Rocq и в Isabelle/HOL нишево формализованы лишь базовые логики (пропозициональная, классическая предикатов...), а едва например появляется фикс-поинт, автоматика исчезает, и надо много думать ручками интерактивно. Поэтому особо тут фиг навайбкодишь если не PhD (ну ладно, если не мехмат:), и это радует. Возможно придётся пилить свой прувер )
Название не придумал пока, например хорошо SATisfactory :) но занято.
Мыслить спеками - теперь база, но главное конечно не знание формализмов, а логическая грамотность. Нейронки всё лучше пишут не только код, но и доказательства, пред- постусловия и инварианты в Lean/Dafny/Coq, однако узкое место -- правильная формулировка, что нужно формализовать, а это как раз навык человека будет ещё долго (естественный язык размыт, а логика нет). Тесты проверяют отдельные примеры, а формальная спецификация описывает свойства для всех случаев: при сотнях тысяч строк сгенерированного кода это сильный аргумент, согласитесь.
Да, 80% пользы вы получите за 20% усилий: строгая система типов, функциональная архитектура, контракты в коде, property-based тесты. И логиком становиться совсем не обязательно, но мыслить спеками -- в терминах инвариантов, кванторов, состояний, переходов, живучести и безопасности, станет ценным навыком, потому что именно на языках логики точнее всего можно поставить задачу сетке, и проверить результат.
Я дал ребятам первые задачки потестить =>
Во-первых, структурирование своих мыслей по поводу задачи - уже само по себе полезный и важный навык. Я об этом догадывался и раньше, прежде чем начинать делать задачу, сначала пытался всё подробно расписать на бумаге, что зачем и почему, что будет если А и что будет если Б, как и на что будет влиять. И ещё тогда заметил что когда сам себе составляешь такую спецификацию - код потом по ней пишется как по маслу (оно и не мудрено, всё ж уже загружено и прощупано в голове вдоль и поперёк). Очень выручало при реализации сложных задач.
Но тут надо поправку сделать, что я чем-то подобным как раз занимаюсь когда спеки пишу для агента.
Самое бесценное, а именно что из №... вообще не следует, что надо (агенту) бэкапы делать, мне пришло только вечером лежа в кровати :))
Спасибо огромное, 10 системных аналитиков из 10, мне прямо очень понравилось !!!
=
Из тренажёра:
Первую спецификацию Олегу выдали для разминки. Это был сервис заказов, который в компании все называли "тот, что падает по пятницам".
— А как же они договорились о спецификации?
— Никак. Каждый вписывал свои пункты ночью, пока другой спал. Поэтому там "ровно одним способом" и рядом "неверно, что одновременно обоими".
На вторую неделю Олега допустили к продовой корзине. В «ОблакоСофте» корзина была местной легендой: товары в ней иногда исчезали, а иногда появлялись чужие. Пользователи писали в поддержку: "Кто положил мне в корзину шесть пылесосов?"...
Ещё там был спор про релизы: blue-green или canary. Одна фраза говорила "canary только с Prometheus и алертами", другая — "если есть Prometheus и алерты, то canary".
— Это же одно и то же, — сказал Олег.
— Вот и наш прошлый стажёр так сказал, — ответил тимлид. — Подправил спеку. Мы потом месяц катили релизы через blue-green при полностью настроенном мониторинге. Без резервного окружения.
— И как?
— Пылесосы...
ex falso quodlibet
❤25👍12✍5