Обновить
2

Пользователь

0,1
Рейтинг
Отправить сообщение

Вот я тоже в недоумении, нам всё рассказывают про какой-то чудо ИИ, а показывают вместо него убогого инвалида типа чатгпт.

Я не вижу проблемы с недетерминированностью кода. Проект будет иметь два слоя: слой промптов (тз) и слой кода. Код будет генерировать одна модель, тест вторая, агент будет проверять и если сработало, то переносить код в репозиторий, если нет, то просить детализировать тз.

Если тз правильно структурировать и хранить, то оно заменит код. Но правильно писать тз для сложных систем смогут только те же самые инженеры, что и сегодня, потому что там надо удерживать в голове всё тот же проект.

Если бы вы работали много с Индусами, то не боялись бы так сильно за эту часть. Индусы требуют детальных инструкций, не имеют обратной связи и не дают детерминированный код, но с ними давно научились работать некоторые.

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

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

Они не понимают, что у них нет шансов справиться без инженеров, потому что чтобы объяснить ИИ что он должен сделать надо это понимать самому. Любой человек, который может удержать в голове сложную систему и есть инженер, прослойка между бизнесом и системой. У руководителей этого навыка нет, у них другие таланты.

Спасибо, зашёл написать этот же коммент.

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

Нет, в Германии 45% это чистый НДФЛ, остальные сборы сверху идут. Но 45% это с суммы свыше 277к евро в год, а у сборов страховых потолок гораздо ниже. По итогу до 50% все налоги примерно, если считать что работодатель сверх ФОТ отчисляет.

Нет, не входят, кроме 30% НДФЛ там ещё медстраховки и прочие отчисления.

А это не так начисляется. По закону там 1000 + 30%.

Это НДФЛ 1000 - 13%.

Откуда это 100/0.7? Всё правильно у него посчитано 100*0.3.

В Германии в любом случае выше.

Эффективность - понятие относительное, а не абсолютное. По отношению ко времени, затрачиваемому на учёбу, сова довольно эффективна: за 25 часов тапания совы я научился большему, чем моя жена за 300 часов интеграционных курсов и 100 часов домашки там же.

Но это до уровня С1 и как там будет на В1 я понятия ещё не имею.

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

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

Скрам имеет одну неразрешимую проблему: итеративность искуственна. Тоесть она не привязана к реальности проекта или продукта.

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

Худший совет, что я слышал в своей жизни.

Работали в ИТ команде в общей сложности 16 лет и только последние 3 года, когда появились подряд два токсичных персонажа, в команде начался разлад, приведший к развалу.

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

Только как внешнее зло она может помочь сплотиться на ранних этапах, и то если не слишком долго.

Одно из топовых требований к микросервису - чтобы 1 команда могла переписать его целиком за 1 спринт. Так что да, write-only.

Компании, для которых актуальны приведённые вами преимущества, составляют очень узкую прослойку ИТ рынка. Я в таких не работал, например, а только слышал и читал о них.

Я работал там, где 9 из 10 гипотез подтверждаются, а продакт должен просто бэклог приоритезировать правильно.

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

Да, внутри каждого микросервиса накосячить сложнее, но на уровне всего продукта сложность никуда не денется.

Присоединюсь к вашему комментарию, как к первому разумному, до которого я, долистал.

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

Фундаментальная и неразрешимая проблема скрама, в том что реальная разработка не итеративна. На этом фоне описанные вами % не так уж и важны.

Это не вопрос подхода, это вопрос терминологии.

Исторически в самоорганизованной команде появляется её лидер, который не только пишет код, но и что-то организует и коммуницирует, его называли тимлидом раньше. Сейчас кого только так не называют, в том числе и линейных менеджеров.

Информация

В рейтинге
3 763-й
Зарегистрирован
Активность

Специализация

Специалист
От 1 000 000 ₽
SQL
.NET
Microsoft SQL