Что я действительно вижу - расширение области автоматизации.
Есть куча второстепенных задач, автоматизировать которые традиционным способом нецелесообразно - ROI равно бесконечности.
А вот с помощью вайбкодинга иногда уже становится целесообразно. Или думают что целесообразно - так как надо считать расходы на весь жизненный цикл, а не только на первичную разработку.
Я стараюсь не читать до обеда советских газет и отзывов в интернете. Там все жалуются на всех, и если этому верить, то можно окончательно утратить веру в человечество.
Если опираться на информацию от лично знакомых мне людей, то все совсем неплохо. Понятно что там совсем небольшая выборка, но хоть что то.
Подскажите про Figma Make - он даёт на выходе обычный проект Figma Design, с которым можно работать далее штатным образом? Или там какие-то свои проекты?
Если свои, то перенос результатов из Figma Make в Figma Design не пытались сделать?
Есть понятный и очевидный тезис, с которым никто не спорит: Хороший код - хорошо, плохой код - плохо. Те кто пишут плохой код - редиски (неважно кожаные они или кремниевые). Менеджеры которые выпускают плохой код в прод - редиски.
Это ок - за всё хорошее и против всего плохого.
А вот дальше часто происходит нечто странное. Говорят "ИИ пишет плохой код". А что имеют в виду?
Первый вариант - "Существует код, который одновременно написан ИИ и плох". Ну существует, и что? Существует код, который написан человеком и плох.
Второй вариант - "Весь код, написанный ИИ, плох". Это очевидное вранье.
Третий вариант - "Доля плохого кода, написанного ИИ (относительно общего объема кода написанного ИИ) выше, чем доля плохого кода написанного людьми (относительно общего объема кода написанного людьми)". Этот вопрос требует исследования, я убедительных доказательств не видел. Сравнения в основном выполняются по публичным репозиториям, а самый шлак обычно в корпоративном секторе и недоступен для сравнения.
То есть мы (не персонально вы или я, а программистское сообщество в целом) не факт что имеем моральное право стоять в белом пальто и говорить "ИИ пишет плохой код". Может быть пальто не такое и белое?
А меня признаться удивляют люди, которые говорят что ИИ пишет "плохой", "некачественный" или "небезопасный" код. А на чем, простите, этот самый ИИ обучался?
ИИ - это зеркало, в котором отражается современный уровень ИТ. ИИ пишет код на уровне медианного разработчика.
Есть много разработчиков, которые пишут хуже чем ИИ. Разнообразного говнокода я в жизни повидал (а на старте карьеры признаться и написал) более чем достаточно, и его авторы - люди. И этот говнокод - в проде.
Не думаю что в других странах бизнес настолько доверяет облачным провайдерам, что готов передавать туда критичные данные. Безопасники везде плюс-минус одинаковые, данные должны обрабатываться внутри контролируемого периметра.
То есть GPU всё равно закупать, а это сейчас очень дорого.
Да, интересные мысли. Но меня здесь больше волнуют не джуны, а в целом организация разработки ПО.
Вот есть то что называется "промышленной разработкой": команда из большого количества разных специалистов - бизнес-аналитик, дизайнер, системный аналитик, архитектор, разработчик, тестировщик, девопс, техпис (и еще каждой твари по паре) делают большой проект. Они реализуют задачи, передавая их друг другу (по принципу конвейера). SDLC и так далее.
И тут появляется ИИ. Как он повлияет на конвейер? Как изменится набор ролей? Как изменится соотношение количества специалистов разных ролей? Как изменятся передаваемые между ними артефакты?
По этой теме я пока ничего концептуального не видел:
Часть статей про то, что "конвейер" вообще не нужен, и всё это может делать один человек (т.н. "инженер полного цикла"). Наверно может, но далеко не во всех случаях.
Вторая часть статей - про то, как изменится работа разработчика, безотносительно к другим специалистам. Будто бы разработчик работает в вакууме. Тот же Spec driven development обычно описан так, что всё это делает один специалист. В реальных больших проектах это скорее всего не так.
Вот и интересно - есть ли практика внедрения ИИ в командную разработку на всех этапах процесса разработки? Не просто "оставляем процесс как есть, а каждый специалист использует ИИ для своих задач", а "перестраиваем процесс с целью максимально эффективного использования ИИ".
Информационные системы, уже подключенные к ЕСИА в соответствии с положениями Регламента версии 2.42 и ниже, могут продолжать применение действующих технических решений до 31 декабря 2026 года. При наступлении указанной даты все участники информационного взаимодействия обязаны применять техническое решение по реализации протокола OpenID Connect при взаимодействии с ЕСИА (создано в соответствии с техническим заданием, согласованным Минцифры России), а также прошедшее процедуру оценки влияния на выполнение предъявленных к СКЗИ требований.
Я правда думаю что срок перенесут, почти никто не готов будет.
За последние пару лет там всё сильно усложнилось, просто так не подключиться.
Во-первых, СКЗИ "КриптоПро CSP" нужен не абы какой, а в исполнении КС3. По требованиям формуляра там должен быть аппаратный модуль доверенной загрузки и замкнутая программная среда. Достаточно легко это настроить на Астре, на других ОС есть нюансы.
Во-вторых, для взаимодействия с ЕСИА нужно использовать либо одно из типовых решений (их по сути два и оба специфические), либо пройти процедуру оценки влияния среды функционирования на СКЗИ. Это полгода и 3-5 миллионов рублей.
Персоны - это простой, дешевый и быстрый метод, который приносит некоторую ограниченную пользу. Полноценные исследования (в том числе описанные в разделе "Что делать?") приводят к более качественному результату, но дольше и дороже.
Здесь не должно быть противопоставления, это методы из разных весовых категорий. В зависимости от ситуации на проекте можно использовать и тот, и другой.
Исследования лучше чем выдуманные из головы персоны, персоны лучше чем ничего.
Запрос №1 очень опасный. Если нет индекса по полю created_at, то будет sequence scan, что на большой таблице создаст нагрузку на систему. ORDER BY на больших таблицах надо с осторожностью использовать.
Что я действительно вижу - расширение области автоматизации.
Есть куча второстепенных задач, автоматизировать которые традиционным способом нецелесообразно - ROI равно бесконечности.
А вот с помощью вайбкодинга иногда уже становится целесообразно. Или думают что целесообразно - так как надо считать расходы на весь жизненный цикл, а не только на первичную разработку.
В общем ниша какая то есть.
Очень похоже на github speckit
Я стараюсь не читать до обеда советских газет и отзывов в интернете. Там все жалуются на всех, и если этому верить, то можно окончательно утратить веру в человечество.
Если опираться на информацию от лично знакомых мне людей, то все совсем неплохо. Понятно что там совсем небольшая выборка, но хоть что то.
Мда, как то вам не везло с работодателями.
Адекватные работодатели существуют, и их немало.
В любых вопросах, которые могут стать причиной судебного разбирательства - бумага лишней не бывает :)
В моих мечтах живет проект Figma Design, который можно править и руками, и с помощью ИИ. И чтобы ИИ корректно использовал дизайн-систему и компоненты.
Но видимо это пока мечта.
Спасибо, интересно.
Подскажите про Figma Make - он даёт на выходе обычный проект Figma Design, с которым можно работать далее штатным образом? Или там какие-то свои проекты?
Если свои, то перенос результатов из Figma Make в Figma Design не пытались сделать?
Есть понятный и очевидный тезис, с которым никто не спорит: Хороший код - хорошо, плохой код - плохо. Те кто пишут плохой код - редиски (неважно кожаные они или кремниевые). Менеджеры которые выпускают плохой код в прод - редиски.
Это ок - за всё хорошее и против всего плохого.
А вот дальше часто происходит нечто странное. Говорят "ИИ пишет плохой код". А что имеют в виду?
Первый вариант - "Существует код, который одновременно написан ИИ и плох". Ну существует, и что? Существует код, который написан человеком и плох.
Второй вариант - "Весь код, написанный ИИ, плох". Это очевидное вранье.
Третий вариант - "Доля плохого кода, написанного ИИ (относительно общего объема кода написанного ИИ) выше, чем доля плохого кода написанного людьми (относительно общего объема кода написанного людьми)".
Этот вопрос требует исследования, я убедительных доказательств не видел. Сравнения в основном выполняются по публичным репозиториям, а самый шлак обычно в корпоративном секторе и недоступен для сравнения.
То есть мы (не персонально вы или я, а программистское сообщество в целом) не факт что имеем моральное право стоять в белом пальто и говорить "ИИ пишет плохой код". Может быть пальто не такое и белое?
А меня признаться удивляют люди, которые говорят что ИИ пишет "плохой", "некачественный" или "небезопасный" код. А на чем, простите, этот самый ИИ обучался?
ИИ - это зеркало, в котором отражается современный уровень ИТ. ИИ пишет код на уровне медианного разработчика.
Есть много разработчиков, которые пишут хуже чем ИИ. Разнообразного говнокода я в жизни повидал (а на старте карьеры признаться и написал) более чем достаточно, и его авторы - люди. И этот говнокод - в проде.
А почему только для СНГ?
Не думаю что в других странах бизнес настолько доверяет облачным провайдерам, что готов передавать туда критичные данные. Безопасники везде плюс-минус одинаковые, данные должны обрабатываться внутри контролируемого периметра.
То есть GPU всё равно закупать, а это сейчас очень дорого.
Бизнес от среднего и выше крайне скептически относится к решениям в облаке и хочет всё on premise.
Большой вопрос сколько будет это стоить включая железо для развертывания LLM.
Аналог в математике - умножение на 1 :)
Или прибавление нуля
Да, интересные мысли. Но меня здесь больше волнуют не джуны, а в целом организация разработки ПО.
Вот есть то что называется "промышленной разработкой": команда из большого количества разных специалистов - бизнес-аналитик, дизайнер, системный аналитик, архитектор, разработчик, тестировщик, девопс, техпис (и еще каждой твари по паре) делают большой проект.
Они реализуют задачи, передавая их друг другу (по принципу конвейера). SDLC и так далее.
И тут появляется ИИ.
Как он повлияет на конвейер? Как изменится набор ролей? Как изменится соотношение количества специалистов разных ролей? Как изменятся передаваемые между ними артефакты?
По этой теме я пока ничего концептуального не видел:
Часть статей про то, что "конвейер" вообще не нужен, и всё это может делать один человек (т.н. "инженер полного цикла"). Наверно может, но далеко не во всех случаях.
Вторая часть статей - про то, как изменится работа разработчика, безотносительно к другим специалистам. Будто бы разработчик работает в вакууме. Тот же Spec driven development обычно описан так, что всё это делает один специалист. В реальных больших проектах это скорее всего не так.
Вот и интересно - есть ли практика внедрения ИИ в командную разработку на всех этапах процесса разработки? Не просто "оставляем процесс как есть, а каждый специалист использует ИИ для своих задач", а "перестраиваем процесс с целью максимально эффективного использования ИИ".
Вам не кажется, что "погонщик LLM" при таком подходе перестает быть разработчиком, а становится системным аналитиком (и немного архитектором)?
И к спецификациям надо применять подходы и наработки именно из сферы системного анализа?
Вносите вы смущение в умы :(
Есть же классификация у Вигерса, все ее плюс-минус знают. А у вас очень похожая схема, но в деталях отличается.
Даже интересно стало что имели в виду авторы вопроса
Регламент ЕСИА, пункт 10.1:
Я правда думаю что срок перенесут, почти никто не готов будет.
За последние пару лет там всё сильно усложнилось, просто так не подключиться.
Во-первых, СКЗИ "КриптоПро CSP" нужен не абы какой, а в исполнении КС3. По требованиям формуляра там должен быть аппаратный модуль доверенной загрузки и замкнутая программная среда. Достаточно легко это настроить на Астре, на других ОС есть нюансы.
Во-вторых, для взаимодействия с ЕСИА нужно использовать либо одно из типовых решений (их по сути два и оба специфические), либо пройти процедуру оценки влияния среды функционирования на СКЗИ. Это полгода и 3-5 миллионов рублей.
Персоны - это простой, дешевый и быстрый метод, который приносит некоторую ограниченную пользу. Полноценные исследования (в том числе описанные в разделе "Что делать?") приводят к более качественному результату, но дольше и дороже.
Здесь не должно быть противопоставления, это методы из разных весовых категорий. В зависимости от ситуации на проекте можно использовать и тот, и другой.
Исследования лучше чем выдуманные из головы персоны, персоны лучше чем ничего.
Запрос №1 очень опасный. Если нет индекса по полю created_at, то будет sequence scan, что на большой таблице создаст нагрузку на систему. ORDER BY на больших таблицах надо с осторожностью использовать.