Comments 26
Одна из гипотез в том, что станут востребованы "кастомные" приложения. Одна команда\бизнес - несколько приложений созданных специально под потребности команды\бизнеса.
В этом варианте количество занятых в индустрии может вырасти.
Ну оно и сейчас достаточно распространено, по крайней мере для крупных компаний.
Еще пять лет назад работал в компании, с персоналом в 15 тыс. человек, где были десятки приложений на андройд для внутреннего пользования: для взаимодействия с отделами, для специальных расчетов и подборов сырья и материала из доступного пула от снабжения, даже приложение-голосовалка для выбора даты своего отпуска. Чем не "кастомные" приложения?
У любой даже средней компании есть как минимум кастомный сайт, не говоря про зоопарк внутренних систем и интеграций) Да и тренда на обобщение и универсальность не видно, как бы различные платформы это не продвигали.
Так что мне кажется, что больше возможностей (меньше time-to-market) - больше продуктов и решений для большего числа заказчиков
Ха, ха, ха - кодеры сеньеры выгляните в окошко и позырте на компютерных художников сидящих на обочин улиц с вытянутыми руками за милостиней ! Вас это конечно не ждет, вы будете дирижировать ИИ в больших консерваториях изредко озаряя их гениальными идеями !
Дело в том, что основное рабочее время художник рисует. А программист (по крайней мере синьор) не программирует (как можно было бы подумать), а общается с людьми чтобы понять что же именно надо программировать.
Вот в том то и дело, что сениоры код пишут мало, их можно пока не менять. А вот мидлов можно будет заменять, в помощь сеньору останутся джуны - подкручивать промты.
До сениоров тоже добируться, когда будут более совершенные системы с глубоким анализом кода и требований.
Такой стиль - это от недоразвитости ИТ-индустрии. В машиностроении такого нет. Там все делается по проекту. Проектная документация ПОЛНОСТЬЮ определяет, каким необходимо изготовить изделие. Нынешний стиль работы сеньора - это как каменщик-шабашник, который обсуждает с частником, как надо выложить дом.
В ИТ я даже техническое задание на "изделие" нечасто вижу.
Как только в ИТ придет (а я надеюсь на это) методика, когда программную систему реализуют полностью по проектной документации, ТОЧНО по проекту, что сеньоры, что рядовые "каменщики" будут не "общаться с людьми" а работать.
Индустрии важнее сделать быстрее, чем, качественнее.И это осознанное решение (в большинстве случаев :) )
Например, когда делают софт для стимуляторов сердца - то делают по техзаданию и проектной документации. Но занимает это годы
А жилые многоэтажки? У девелоперов прям огромное желание делать качественно?
Или у девелоперов желание точно делать сметы, прогнозировать стоимость и сроки?
100500 раз поднималась эта аналогия. А каждый раз ответ: у заказчика жилой многоэтажки нет желания каждый день менять форму парадных, количество комнат на этаже и грузоподъёмность лифтов. А у заказчиков ПО - есть, и это из них не вытравить, они подсели на регулярные обновления.
Многоэтажки ремонтируются, реновируются, перестраиваются. Придомовая территория благоустраивается. Водопровод, электрооборудование, тепло - меняется, модернизируется. И все это делается по проекту, с составлением смет, сроков, стоимостей. Считаются деньги. Согласовываются и выделяются деньги (ну и воруются, бгг). И только в ИТ, я повторяю, с планированием и экономикой бардак фееричный.
Не нравится пример со строительством - берите судостроение. Военно-морской флот. Строются по проекту. Модернизируется и перевооружается флот по проекту. Соответственно, техническое задание, проект, сметы, стоимость, сроки.
Учитесь, айтишники.
А причём тут айтишники? Это заказчики не готовы ждать 5 лет, когда будет готов проект, чтобы после этого запустить новый проект по модернизации.
Обычно как? Вы сделайте хотя бы одну кнопку, да так, чтобы побыстрее (подешевле) а мы потом посмотрим, куда это всё дальше двигать. А там уже пофиг, что завтра захотят вторую кнопку, которая идёт вообще вразрез с логикой первой кнопки. Но переделывать нормально никто не позволит (денег нет), вы как-нибудь выкручивайтесь на скотче и синей изоленте.
По аналогии со строительством, это как если бы после постройки 3 этажей туда пустили жильцов (а что? готовы же этажи, пусть деньги приносят), а потом оказалось что в уже построенном крыле 1-го этажа надо снести комнаты и расположить супермаркет, потому что покупателей на квартиры не нашлось, а арендатор на магазин есть. И всё это без прекращения стройки верхних этажей.
Странная аналогия.
Кто составляет проект? Заказчик на коленке? Не думаю. Скорее всего проект оформляют умные люди.
Сеньоры в программировании, это как раз эти люди. А собрать по проекту/набить код в ide, сможет уже простой трудяга/Джун/нейронка.
Ну и опять таки, требования разные. В ИТ чаще требуется гибкость системы, возможность изменять и модифицировать некоторые параметры быстро и часто.
Чем вам поможет проект 10 этажного здания, если на этапе строительства 5го этажа, скажут, что нужно 20 этажей?
Скорее всего ответом на такое станет - нет технической возможности.
И это оправдано для строительства, но не для ИТ, где такой ответ будет означать провал проекта.
ТО есть, для строительства нормально, когда на середине строительства заказчик вместо пятиэтажки вдруг решил, что ему надо небоскреб (за те-же деньги, бгг) - то окружающие только пальцем у виска покрутят.
А в ИТ если заказчик просил простенький сайт-визитку и вы наполовину уже сделали, а потом заказчик вдруг потребовал соцсеть на десять миллионов пользователей - то вы с готовностью беретесь доделывать, потому что ответ "нет технической возможности" будет означать провал проекта?
Есть исследования от Британской Society of Authors, согласно которым без работы осталось только 26% иллюстраторов, но при этом вырос спрос на фрилансеров в области дизайна (всякие логотипы, дизайн упаковок итд). Так что не останутся компьютерные художники на обочине. Там более, когда уже сейчас любой человек может невооружённым взглядом в большинстве случаев определить, что изображение сгенерировано и это вызывает раздражение
Поиграются с ИИ какое -то время, потом поймут что без человека соответствующей квалификации это все не работает. К тому же ИИ не накажешь за ошибки, дыры в безопасности и т д и т п. Получишь кучу кода и кто все это будет контролировать? Людей потребуется больше и квалификации выше. Веб -это только вершина айсберга. А под водой огромные и сложные области программирования намного больше чем WEB и ресурсов на это тоже требуется много и высококвалифицированных. ИИ туда не прикрутишь из-за специфики и опять же необходимости контроля со стороны квалифицированного программиста.
Автор немного наврал с датой в начале. В конце 2022 года был доступен gpt 3.0 уже
Пишу только самостоятельно, нейронки использую часто только для пояснения не понятных нюансов или иногда вместо даташита, на простые вопросы они знают ответ а если что-то сложнее надо то можно сам даташит им закинуть, но это не дает никакой гарантии что он справится, а нейронный автокомплит часто вставляет не то что надо и это только раздражает, это что касается embedded, здесь у меня опыта не много а если юзайть нейропомощников то я ничего не научусь.
Лично я, вообще отказался от copilot, потому что он больше мешает, чем помогает. Он совершенно не понимает контекста и такое ощущение, что просто берёт код из чужих репозиториев, вообще никак его не меняя... Включаю его только для документации, переводов и прочей рутинной мишуры.
GPT чат использую с функционалом проектов. Прошу в основном либо найти баги (он это делает нормально, если настроить проект), сгенерировать боллерплейты, шаблоны, заготовки и т.д. Чаще всего он генерирует рабочий код, но требующий доработки. Так же, прошу его генерировать, не больше одного класса/модуля/компонента. Чем меньше код, тем лучше он его пишет. Прошу GPT не переписывать код при каждой правке, а описать кратко только варианты изменения. Так быстрее и понятнее. Под каждую задачу делаю новый чат в проекте. С таким подходом вполне удаётся быть более эффективным, при этом не теряя навык и не делегируя всё нейронке.
Далеко не всегда нейронка генерит, то что нужно. Более-того, она обожает уходить в цикл. Например, у вас ошибка в программе. GPT посоветует, допустим, откатить версию, какого-нибудь модуля. Ошибка не пропала? Обновите модуль обратно. Ещё есть ошибка? Удалите модуль и поставьте обратно. Ошибка сохранилась? Попробуйте эту версию модуля (ссылка на несуществующую страницу). И так по кругу, хотя ошибка оказывается вообще в другом месте и по другой причине, а модуль не причём.
Никто не отменял необходимость думать и тестить всё самому. Почти всегда пробежаться дебагером или посмотреть логи, поможет быстрее решить проблему, чем мучить GPT.
Имхо, но GPT, как тот самый мифический идеальный джун. Идеально знает теорию, но плохо кодит и решает проблемы.
Автор правильно говорит, все это нагнетается СЕО компаний чтобы еще больше привлечь денег. Помню тут уже чемоданы на Марс собирали несколько лет назад, в очереди за билетами стояли. Теперь вот программистов хоронят. А караван все идёт и идёт.
А вот, скажите пожалуйста господа, был ли у кого опыт, дать задание нейро-помощнику на программу (функцию) для отрисовки чертежа к. л. детали для некой конструкции? Ну хотя бы контур, что бы его потом лазером вырезать.
Уже 2 года не пишу код, хотя по сравнению с gpt4 я справлялся заметно лучше, но количество перевешивало качество - ИИ уже тогда справлялся заметно быстрее. Начиная с O1 языковые модели стали писать код лучше большинства программистов, и за пару запросов стало можно исправить уже не один файл, а сразу несколько. Причем в единицу времени ИИ стал выдавать не только больше кода по количеству, но улучшать его качество быстрее чем это может делать человек. С выходом grok3 и Claude Sonnet 3.7 ИИ шагнул еще дальше и значительно.
Большинство людей и компаний пока не понимают как реализовывать потенциал нейросетей на максимум, в частности такие платформы как Cursor используют, скажем, меньше 10% его потенциала (личное оценочное мнение исходя из профессионального опыта). Но те немногие кто уже сегодня использует его на полную катушку получают "нечестное" преимущество в конкурентной борьбе. Еще на стадии выхода о1 я столкнулся с тем что моя попытка прочитать и понять все правки кода который делает ИИ замедляют прогресс в разы, а отказ от попыток вставить свои 5 копеек безусловно приводит к снижению тренированности мозга и параличу при отключении от ИИ.
Но независимо от того что человек выбирает - снижать скорость разработки и продолжать держать руку на пульсе, или не сдерживать взрывной рост объема кода неизбежно накапливая технический долг и растущий разрыв между компетенциями оператора ИИ и требуемыми для решений возникающих кризисов, люди программисты уже проиграли в конкурентной борьбе с ИИ.
Отказ от ИИ в надежде что это тонизирует мозг так же нелеп, как желание отказаться от тракторов в пользу мотыги для здоровья позвоночника и борьбы с ожирением, или отказ от электричества для нормализации циркадных ритмов и решения других проблем, что многие обсуждают на полном серьезе и некоторые даже реализуют на практике.
Отказ от ИИ в надежде что это тонизирует мозг так же нелеп, как желание отказаться от тракторов в пользу мотыги для здоровья позвоночника
Фигня а не сравнение. Тогда уже не трактор а обработка полей с помощью бомб. Потому что сейчас даже после самых лучших моделей надо переписывать код, тратя время на проверку.
неизбежно накапливая технический долг
Вот вот, кому надо на от*бись, те уже давно всякими нокодами обходились
Мой CEO видит это точно так же: Компания — это "soft factory", где скорость — главная метрика, качество определяется как "разумная достаточность" (выполнение заявленной функции, не более), а ИИ — обязательный инструмент для достижения этой скорости и выживания в конкурентной борьбе.
Главное — создать и выполнить заявленную функцию в срок.
В его картине мира люди (разработчики) — это заменяемый ресурс. Их ценность измеряется скоростью выполнения плана. Они — "производственные единицы" на "soft factory", средство для достижения главной цели (выполнения функции в срок).
Почему я перестал использовать редакторы кода на основе ИИ