>Нужно проверять сам код, понимать как он работает, и где потенциально может упасть
Если вы на бумаге распишете, что именно вы в этот момент делаете, вдруг окажется, что это вполне себе формализуемая работа и никакой магии в этом нет. Это раз. Два - то, что модели сейчас находят хренову тучу проблем в людском коде говорит о том, что человеки слишком хорошо о себе думают.
>Но мне часто приходилось работать на проектах без аналитика
Более того, аналитик - это вообще выдуманная должность чисто на нашем пространстве. На западе такой роли нет.
Вот именно аналитик сейчас совершенно спокойно может "написать" код. А тот разработчик, который дальше литкода мыслить не умеет, аналитика не заменит сходу.
Вообще думаю в будущем не будет ни чистых программистов, ни выделенных аналитиков. Будут билд инженеры.
Ещё раз - мой поинт в том, что бывает иначе. Когда сама компания ведёт разработку продукта хотя бы в виде работающего прямо в компании продукта/PMа/CTO/кого угодно. Часто есть ещё локальный штат. И команда (команды) аутстафферов. И всё это на ТМ, ГОДАМИ. Называть всё это неопытным заказчиком, обработанным маркетологами - ну такое себе. Это бизнес модель, отдельная от фикса.
В моём пузыре большинство заказчиков ТМ, так как целенаправленно их выбираем, вдоволь походив по граблям с фиксом. И как правило фикс требуют именно малоопытные заказчики. Те, кто уже годами разрабатывает, прекрасно знает, что жизнь продукта не заканчивается деплоем первой версии на сервер и именно после релиза и начинаются пляски. Поэтому ТМщики берут себе по сути на аутстафф как часть своей команды и владеют своим софтом.
Фиксед прайс - не единственная модель разработки софта. Многие опытные заказчики вполне осознанно выбирают ТМ, так как понимают, что им нужен результат, а не абстрактная цифра с гарантированными тёрками.
Заметьте, слова хоронить в моём посыле нету. Есть про усталость. По графику акций SaaS компаний восторга по их перспективам не прослеживается, и оно понятно, когда половину SaaSов себе на коленке стало возможным собрать за адекватное время.
Все уже друг от друга устали. И от расходов и от "качества" и от суровой реальности, где куча граблей и проблем, которые вдруг чудесным образом не исчезают с новым поделием. Поэтому SaaS и прочие силвер буллеты взлетали, теперь падают, ибо не буллеты по факту. Скоро и от агентов устанут, так как тоже не буллет.
>Выбор идёт между усталостью на согласованиях и переделками после запуска
Нет такого выбора. Это лишь перекладываение ответственности за принятие решений на заказчика до того, как работа будет начата. Больше ничего. Заказчику реально это не надо, так как он редко сам ещё понимает, что хочет. Всем надо поиграться с каким-то прототипом и осознать, как лучше делать и делать ли после прототипа что либо вообще. Это естественный жизненный цикл нормальной разработки (при условиях, что разрабатывается новая для заказчика тема и есть возможность дорабатывать потом, либо всё выкинуть).
И да, это всё полностью противоречит следующему вопросу заказчика, а сколько это всё будет стоить, при полном нежелании включать голову в продумывание требований. И решений этому не особо, кроме как оценивание и выполнение мелких этапов, где все осознанно идут на риск. Одни не знают, что получат, другие не знают - попали ли в оценку. Либо полный ТМ где риск берёт на себя заказчик и опытные заказчики вполне осознанно на это идут.
По моим ощущением бывает совсем тугодумом, причём без видимых причин. Эксалирует там, где не надо и не эскалирует там, где надо. Модель то умная, не вопрос, но определённые особенности поведения есть.
Как бы это сказать. Субъективно "не видел задачу в целом" и поэтому "чинил" проблемы местечково, не оглядываясь на последствия сверху. Да, это не то, что вообще ожидаемо требовать от ЛЛМки, но просто вот такое дело, что Астра с таким уровнем "мышления" уже справляется. Фейбл тоже, но у него свои тараканы.
Опять же, субъективно. Такие вещи замерять вообще непонятно как. Собирать разломанный сложный стенд и давать его "чинить" всем подряд?
Задачи детские, извините. Проблемы с дешёвыми моделями начинаются на уровнях интеграций ежа с ужом, когда в контексте надо держать и "понимать" не только проект и соответствующие API, но и логику процесса и прочее.
Вот буквально свежий кейс - 3 дня с горем пополам двигал проект дешёвым Spark 1.3 , т.к. опуса и астру выжег ещё в начале недели. Спарк неплохой кстати, вот такие мелкие задачки как в статье на раз делает. А вот с задачей покрупнее убил полтора дня, собрать целостно не мог систему. Уже готов был расчехлять IDE и лезть смотреть, что же там всё таки происходит =) Но вот с утра свежий лимит Астры подъехал и она за час перестроила всё это рукоблудство Спарка и сходу проект взлетел. И нет, сам бы я всё это недели делал, реально нетривиально там.
Не помню уже, когда открывал эту IDE. Стало неинтересно уже совершенно, когда результат получаешь какой запросил. Примерно так же, как код совершенно не интересен продукту, которыми мы по сути и стали.
>Нужно проверять сам код, понимать как он работает, и где потенциально может упасть
Если вы на бумаге распишете, что именно вы в этот момент делаете, вдруг окажется, что это вполне себе формализуемая работа и никакой магии в этом нет. Это раз. Два - то, что модели сейчас находят хренову тучу проблем в людском коде говорит о том, что человеки слишком хорошо о себе думают.
>Но мне часто приходилось работать на проектах без аналитика
Более того, аналитик - это вообще выдуманная должность чисто на нашем пространстве. На западе такой роли нет.
Вот именно аналитик сейчас совершенно спокойно может "написать" код. А тот разработчик, который дальше литкода мыслить не умеет, аналитика не заменит сходу.
Вообще думаю в будущем не будет ни чистых программистов, ни выделенных аналитиков. Будут билд инженеры.
Валидация результата - это не валидация кода.
ладно, проехали. С вашей колокольни пейзажи краше.
Поручите непосильную задачу клодексу, он всё настроит.
ну это как бы больше, чем просто виртуалка. сильно больше
Ещё раз - мой поинт в том, что бывает иначе. Когда сама компания ведёт разработку продукта хотя бы в виде работающего прямо в компании продукта/PMа/CTO/кого угодно. Часто есть ещё локальный штат. И команда (команды) аутстафферов. И всё это на ТМ, ГОДАМИ. Называть всё это неопытным заказчиком, обработанным маркетологами - ну такое себе. Это бизнес модель, отдельная от фикса.
В моём пузыре большинство заказчиков ТМ, так как целенаправленно их выбираем, вдоволь походив по граблям с фиксом. И как правило фикс требуют именно малоопытные заказчики. Те, кто уже годами разрабатывает, прекрасно знает, что жизнь продукта не заканчивается деплоем первой версии на сервер и именно после релиза и начинаются пляски. Поэтому ТМщики берут себе по сути на аутстафф как часть своей команды и владеют своим софтом.
Фиксед прайс - не единственная модель разработки софта. Многие опытные заказчики вполне осознанно выбирают ТМ, так как понимают, что им нужен результат, а не абстрактная цифра с гарантированными тёрками.
Заметьте, слова хоронить в моём посыле нету. Есть про усталость. По графику акций SaaS компаний восторга по их перспективам не прослеживается, и оно понятно, когда половину SaaSов себе на коленке стало возможным собрать за адекватное время.
Все уже друг от друга устали. И от расходов и от "качества" и от суровой реальности, где куча граблей и проблем, которые вдруг чудесным образом не исчезают с новым поделием. Поэтому SaaS и прочие силвер буллеты взлетали, теперь падают, ибо не буллеты по факту. Скоро и от агентов устанут, так как тоже не буллет.
>Выбор идёт между усталостью на согласованиях и переделками после запуска
Нет такого выбора. Это лишь перекладываение ответственности за принятие решений на заказчика до того, как работа будет начата. Больше ничего. Заказчику реально это не надо, так как он редко сам ещё понимает, что хочет. Всем надо поиграться с каким-то прототипом и осознать, как лучше делать и делать ли после прототипа что либо вообще. Это естественный жизненный цикл нормальной разработки (при условиях, что разрабатывается новая для заказчика тема и есть возможность дорабатывать потом, либо всё выкинуть).
И да, это всё полностью противоречит следующему вопросу заказчика, а сколько это всё будет стоить, при полном нежелании включать голову в продумывание требований. И решений этому не особо, кроме как оценивание и выполнение мелких этапов, где все осознанно идут на риск. Одни не знают, что получат, другие не знают - попали ли в оценку. Либо полный ТМ где риск берёт на себя заказчик и опытные заказчики вполне осознанно на это идут.
Надо очень усердно принать ... пока работает ЛЛМ, что бы всего лишь на пару десятков процентов ускориться. Достаточно открыть вторую сессию.
что сегодня the best, завтра bull shit, а название не сменишь
По моим ощущением бывает совсем тугодумом, причём без видимых причин. Эксалирует там, где не надо и не эскалирует там, где надо. Модель то умная, не вопрос, но определённые особенности поведения есть.
Как бы это сказать. Субъективно "не видел задачу в целом" и поэтому "чинил" проблемы местечково, не оглядываясь на последствия сверху. Да, это не то, что вообще ожидаемо требовать от ЛЛМки, но просто вот такое дело, что Астра с таким уровнем "мышления" уже справляется. Фейбл тоже, но у него свои тараканы.
Опять же, субъективно. Такие вещи замерять вообще непонятно как. Собирать разломанный сложный стенд и давать его "чинить" всем подряд?
Задачи детские, извините. Проблемы с дешёвыми моделями начинаются на уровнях интеграций ежа с ужом, когда в контексте надо держать и "понимать" не только проект и соответствующие API, но и логику процесса и прочее.
Вот буквально свежий кейс - 3 дня с горем пополам двигал проект дешёвым Spark 1.3 , т.к. опуса и астру выжег ещё в начале недели. Спарк неплохой кстати, вот такие мелкие задачки как в статье на раз делает. А вот с задачей покрупнее убил полтора дня, собрать целостно не мог систему. Уже готов был расчехлять IDE и лезть смотреть, что же там всё таки происходит =) Но вот с утра свежий лимит Астры подъехал и она за час перестроила всё это рукоблудство Спарка и сходу проект взлетел. И нет, сам бы я всё это недели делал, реально нетривиально там.
Пол года для моделей - вечность. Поколение уже сменилось.
Поновей модели не судьба потестить?
как-то мирились с тупейшими багами от человеков, так и с ИИшными смиримся и научимся с этим работать. В принципе подходы ровно те же.
Не помню уже, когда открывал эту IDE. Стало неинтересно уже совершенно, когда результат получаешь какой запросил. Примерно так же, как код совершенно не интересен продукту, которыми мы по сути и стали.