Comments 9
«Подключить Firebase SDK для управления push-уведомлениями» — с перечнём кейсов, когда нужны пуши.
Для команды это выглядело как идеальный кандидат для того, чтобы сделать с нейросетями: функционал не ключевой, риски низкие, есть официальная SDK с понятным API.
пишу на swift. Во многих сторонних библиотеках (в том числе firebase) обязательно есть какие-нибудь приколы с инициализацией, которые ИИ не учитывает. У вас в Node.js по-другому?
В размышлениях, кому всё-таки помогают "нейронки", а для кого они вредны, попытался представить себе аналогичную или максимальною похожую "человеческую" роль в коллективе. Сразу вспомнился один коллега (подчинённый), разработчик в годах (60+). Огромный опыт за плечами, участие в куче проектов, много языков, перфоленты-перфокарты и т. д. Но - огромная самоуверенность в своих решениях, иногда откровенно поверхностных (а местами - просто "костыльных"), небрежность, невнимание к мелочам. Когда он обучал совсем молодых коллег - всегда возникал внутренний вопрос: та заразительная энергия, с которой он доносит до них не совсем (или совсем не) достоверную информацию - это вред или благо?Смогут ли они её осознать правильно, не имея опыта за плечами, не пойдёт ли она во вред? В общем, так и родилась аналогия, что современный ИИ - это эдакий мега-"дед", учиться у которого, не имея опыта, довольно авантюрная затея. Если же подойти критически - он отличный напарник, собеседник и вообще - неиссякаемый кладезь мудрости.
Статья очень актуальна, сам пришел примерно к такой модели работы. Особенно с последними моделями уже практически не приходится задумываться о качестве кода, самое главное - правильно донести до нейросетки что тебе нужно.
Вместо написания кода теперь написание промптов)
Попробую дать свою обратную связь.
Сегодня этот слой работы — написание кода — схлопывается до 5-10%.
Тут у меня два момента. Первый, это о каком коде идет речь? Если это написание какого-то специфического алгоритма. Для которого важны каждый шаг реализации - это далеко не тоже самое как, например, скомпоновать какую-нибудь интерактивную формочку.
И второй момент, по своему опыту могу сказать, что львиная доля времени как раз и уходила на то, что бы быть Тони Старком, а вовсе не Джарвисом.
Вот эти вот:
... на борьбу с синтаксисом, написание бойлерплейта и ручную реализацию стандартных паттернов
Занимают львиную долю только на определенном уровне развития. Пока ты не достаточно хорошо знаешь синтаксись, недостаточно хорошо понимаешь паттерны. А бойлерплейт просто по определению вещь из разряда копировать-вставить.
Вы говорите вот такую штуку:
Нейросети отлично справляются с реализацией, освобождая нас для высокоуровневого «Как?»: проектирования архитектуры и выстраивания связей.
И далее сразу же идет:
Теперь наша работа — это не укладка кирпичей, а создание чертежей.
А разве "проектирования архитектуры и выстраивания связей." - это не создание чертежей?
А вот это прям даже как то поразило:
Мы увидели, как неверный подход к постановке задачи и отсутствие подготовительного этапа бизнес-анализа чуть не привели нас к созданию бесполезного продукта, а смена парадигмы позволила решить задачу за пару часов.
Дело в том, что еще с середины 70х писали хорошие книги ровно вот про это. В конце 90х при формализации юниверсального языка моделирования все это было наглядно структурировано в выразительную систему. И вот в конце 2025 года мы читаем: "Мы увидели, как неверный подход к постановке задачи и отсутствие..."
У меня просто слов нет. Таким образом ваше введение больше обескураживает, чем подготавливает к получению ценной информации.
ИИ здесь не помощник, потому что если бы мы спросили его "как сделать админку", он бы просто сделал админку, не задавая вопросов "а зачем?".
На самом деле, ИИ везде может быть помощником. Просто нужно понимать о какой работе идет речь. Если разделить разработку ПО на анализ-проектирование-кодирование-тестирование-деплой то на каждом этапе будут свои типы задач. Например, нет никакого смысла спрашивать "как сделать админку?", если до этого не задать вопрос: "что я должен сделать?". Этот вопрос вы так же можете задавать ИИ. Собственно выше вы к этому и пришли. Правда я не понял, использовали вы ИИ или нет. Видимо нет, раз пишете, что ИИ не помощник.
К этому моменту у нас появился достаточно детализированный «скелет» архитектуры, который уже можно было превратить в формальную спецификацию для генерации кода.
Из того, что представлено в статье не очень понятно о каком скелете архитектуры идет речь. Архитектура - это про ясные представления/срезы вашего приложения, которые выразительно показывают все строительные блоки и отношения между ними. Ну, например, если это про то как приложение выглядит на диске, то про файлы, папки, семантику папок и названий. У вас же просто перечисление каких-то конкретных реализаций и технологий никакого намека на архитектуру из статьи получить не удалось.
И только теперь, когда у нас есть выверенное ТЗ...
Либо у вас с глоссарием проблемы, либо со смыслом. ТЗ - это первичный документ проекта. А на данном этапе у вас уже есть спецификация, т.е. вторичный документ, который описывает конкретные характеристики приложения.
В таком режиме ИИ выступает как идеальный Junior+/Middle, который пишет код строго по гайдлайнам, не отвлекаясь на самодеятельность.
Гайдлайны - это наборы ориентиров для получения единого стиля, политики. Это не ТЗ или спецификация, поэтому никакие строгие гайдлайны не исключают самодеятельность. Они только влияют на ее форму. Скорее всего опять вопрос к выбранному вами глоссарию.
Это позволяет держать контроль над кодовой базой и избегать "спагетти-кода", который так любят генерировать нейросети, если их не ограничивать.
Вот как раз, что бы этого не произошло и нужно придерживаться спецификации и архитектуры.
Это не "волшебная таблетка", которая позволит уволить всех программистов, а инструмент, который кратно усиливает сильного инженера. Но если у вас нет архитектурного мышления, нейросети лишь помогут вам быстрее создать неработающего монстра.
Тут вы поднимаете другой вопрос. А можно ли продать неработающего монстра, но дешевого? И как мы можем видеть на примере огромного количества некачественного ПО на рынке ответ: "Да можем". Вы, судя по всему, в этом не заинтересованы. Но с другой стороны, а не изменится ли это в будущем, когда конкуренты начнут использовав ИИ делать все быстрее, дешевле и возможности маневрировать будет еще меньше чем сейчас? То, что там 30-40% будет не работать? Ну так и что. Вон, была такая игра как Киберпанк за много много миллионов зеленых рублей. Так там на выходе не работало до 30% всех навыков прокачки. И это далеко не единичный случай супердорогово ПО очень и очень низкого качества.
Системный анализ. Умение извлекать из бизнес-заказчика требования и переводить абстрактные боли в конкретные технические сценарии. Если вы сами не понимаете цели, ИИ додумает за вас, и скорее всего – неверно, если вы не предоставите достаточно контекста.
Тут сразу возникает вопрос, а выделенного аналитика у вас нет? Или это дорого?
Вы должны знать паттерны, лучшие практики и антипаттерны. Если вы не знаете, что такое микросервисы или идемпотентность, вы не сможете попросить ИИ реализовать их в коде так, как вам требуется.
Поэтому первым делом и нужно поработать с ИИ, что бы выяснить, что нужно делать. А уже потом просить это реализовать. Паттерны, микросервисы и идемпотентность ИИ сможет расжевать так же как и все остальное. Тут вопрос в другом, позволит ли бизнес разработчику тратить время на вот эту самую "насмотренность". Потому именно в процессе работы разработчик ее и получает. Но вот если бизнес ставит в рамки, когда на это нет времени, то и насмотренности взяться будет не откуда. Зато появятся условия для появления той самой магии.
Теперь вы читаете кода и спецификаций в 10 раз больше, чем пишете. Навык быстро сканировать глазами сгенерированный код и документацию и находить в них логические дыры (а не пропущенные запятые) становится критическим.
Во первых, так было всегда. Уже давным давно при ревью никто не ищет запятые. Во вторых, вот это вот "становится критическим" по сути сводит на нет плюсы от использования ИИ. Потому что, если человек должен через себя пропускать все детали и брать за них ответственность, то это ровно то чем занимался разработчик и без всяукого ИИ. Откуда тогда возьмется 3-10 краное ускорение то? Если разработчик все так же отвечает за каждую строчку кода?
В эпоху LLM ваша ценность как программиста не в том, насколько быстро вы пишете код, а в том, насколько точно вы понимаете, какой код вообще нужно написать.
Тут хочется спросить, а вы точно в курсе, что данное положение на рынке было последние 40 лет? Когда требовали "быстро писать код" как раз и понимали "быстро написать код, который нужно написать"
Разработчик превращается из "писателя" в "режиссера", который определяет замысел, разбивает его на сцены и контролирует каждый дубль. А код? Код — это просто расходный материал.
Это просто белый пушной зверёк какой-то. Честно, слов нет.
Код пишет нейросеть. Что остается разработчику?