Кажется, айтишники — ВСЕ. График вакансий в IT достиг исторического минимума и продолжает падать

вот поэтому технарей в вузах и учат, что первое дело в проектах (у вас в проектиках) - это грамотное ТЗ. И если заказчик не может его разработать - его разрабатывает исполнитель за норм оплату. Всё, что выходит за рамки утверждённого ТЗ и что там держал в уме заказчик - это его личные проблемы.

Вот вам ответ от нейросети (DeepSeek):

Объективно, текущие LLM (как ChatGPT, GPT-4, Gemini и аналоги) **не могут полностью заменить даже джуниор-разработчика**, но они становятся мощным инструментом в их руках. Вот ключевые аргументы:

### Что LLM умеют делать:
1. **Генерировать шаблонный код** по описанию задачи (например, написать функцию сортировки, API-эндпоинт, парсить данные).
2. **Находить ошибки** в коде, объяснять их и предлагать исправления.
3. **Документировать код**, предлагать названия переменных/функций, улучшать читаемость.
4. **Обучать** — объяснять концепции, технологии, синтаксис (как интерактивный учебник).
5. **Автоматизировать рутину** (написание тестов, рефакторинг, генерацию конфигов).

---

### Почему LLM не заменят разработчиков:
1. **Отсутствие глубокого понимания контекста**
LLM не способны анализировать бизнес-требования, учитывать нюансы проекта (например, баланс между скоростью и масштабируемостью) или принимать архитектурные решения.

2. **Критическое мышление и креативность**
Задачи вроде проектирования системы, оптимизации алгоритмов под уникальные условия или решение неочевидных багов требуют человеческого опыта и интуиции.

3. **Работа с неопределенностью**
LLM плохо справляются с задачами, где нет четкого ТЗ, или требуется уточнение у заказчика. Джуниоры учатся задавать правильные вопросы — модели это недоступно.

4. **Ответственность и безопасность**
LLM могут генерировать код с уязвимостями (например, SQL-инъекциями) или некорректной логикой. Проверка, тестирование и финальное решение всегда лежат на человеке.

5. **Коммуникация и командная работа**
Разработка — это не только код, но и обсуждение задач, презентация решений, менторство. LLM не заменят человеческое взаимодействие.

---

### Роль LLM для джуниоров:
- **Ускорение обучения**: быстро получить примеры кода, объяснение концепций, ответы на вопросы "как сделать X на языке Y".
- **Снижение порога входа**: меньше времени тратится на рутину (написание бойлерплейта, поиск синтаксических ошибок).
- **Повышение продуктивности**: фокус на сложных задачах, а не на повторяющихся операциях.

---

### Итог:
LLM — это **инструмент**, а не замена разработчика. Они помогают джуниорам быстрее расти и работать эффективнее, но не могут заменить человеческие навыки: анализ, принятие решений, творчество и коммуникацию. В будущем, вероятно, часть рутинных задач будет автоматизирована, но разработчики перейдут к более сложным и творческим аспектам профессии.

Учат-то учат, да не всех. У нас было: программисты - ПОВТ, своя кафедра, Разработчики РЭА - отдельная специальность на кафедре Радиосистем, мы, радиотехники - отдельная специальность на той же кафедре, и учебные курсы по специальностям у нас не пересекались вообще никак. И таким образом все программистские премудрости (алгоритмы, алгоритмизация, архитектура ПО, разработка проектов, документация и прочее-прочее) прошли мимо нас, радиотехников, абсолютно стороной (ну, разве что, семестр паскаля на первом курсе да семестр или два микрокотроллеров на ассеблере).
Так что - занимаюсь, учусь, книжки умные читаю чтоб не говнокод говнокодить, чтоб через полгода открыв свои же исходники, не подумать - "бля, что ж за мудила это сваял?!"

ТЗ - совершенно согласен. Грамотно и правильно составленное ТЗ - это считай половина проекта готово.

В том конкретном случае ТЗ у меня выглядело так.

Вот такое вот ТЗ - и какой тут ИИ?

Это сообщение отредактировал aalm - 8.05.2025 - 19:46

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

Техническое задание на разработку замены внешнего модуля сбора и обработки данных
1. Общие сведения
1.1. Назначение
Разработать аналог внешнего модуля (приблуды), который:

Собирает данные с внешних датчиков/источников.

Обрабатывает их в заданном формате.

Передает обработанные данные на основной прибор по Wi-Fi или Ethernet.

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

2. Требования к системе
2.1. Аппаратные требования

Совместимость с основным прибором (ARM-процессор, Linux).

Поддержка интерфейсов:

Wi-Fi (стандарт IEEE 802.11 a/b/g/n/ac).

Ethernet (100/1000 Мбит/с).

Возможность подключения к внешним датчикам (интерфейсы: UART, SPI, I2C, ADC и др. — уточнить по остаточным данным).

Достаточная вычислительная мощность для обработки данных в реальном времени.

2.2. Программные требования

ОС: Linux (версия и дистрибутив — уточнить).

Протокол передачи данных: TCP/IP (или специфический протокол, если известен).

Формат данных на выходе: бинарный/JSON/XML (уточнить по анализу работы прибора).

Поддержка автоматического переподключения при обрыве связи.

2.3. Функциональные требования

Сбор данных с внешних источников (аналогично оригинальному модулю).

Предварительная обработка данных (фильтрация, агрегация, преобразование форматов).

Надежная передача данных на основной прибор.

Логирование ошибок и статуса работы.

3. Ограничения и допущения
Отсутствие документации → требуется реверс-инжиниринг или анализ работы прибора.

Невозможность тестирования с оригинальным модулем → необходимо эмулировать его поведение.

Совместимость с существующей инфраструктурой → нельзя менять формат данных на стороне основного прибора.

4. Этапы разработки
Анализ

Изучение работы основного прибора (логирование входящего трафика).

Определение формата данных и протокола обмена.

Выяснение требований к внешним датчикам.

Проектирование

Выбор аппаратной платформы (Raspberry Pi, Orange Pi, кастомное решение).

Разработка схемы обмена данными.

Проектирование ПО (язык: C/Python/Go).

Реализация

Написание драйверов для работы с датчиками.

Реализация обработки и передачи данных.

Тестирование в эмулируемой среде.

Интеграция и тестирование

Проверка совместимости с основным прибором.

Настройка стабильного соединения.

Испытания в реальных условиях.

5. Критерии приемки
Модуль стабильно передает данные в требуемом формате.

Обеспечивается совместимость с существующей системой.

Реализована обработка ошибок и восстановление связи.

6. Дополнительные требования
Возможность удаленного обновления ПО.

Минимизация задержек при передаче данных.

Энергоэффективность (если модуль автономный).

Итог:
Необходимо разработать аппаратно-программный модуль, заменяющий оригинальную "приблуду", с сохранением всех функций и совместимостью с основным прибором.

Сроки и бюджет — обсудим после уточнения деталей. 🚀

Ну это же всё совершенно очевидные вещи, надерганные ключевые фразы из написанного мной и совершенно безбожно, по современному, по хипстерски
разбавленные водой пустословия. Обсуждение с заказчиком - всё, что он мог мне сказать, я написал.
Хотя спору нет, есть от этой портянки один плюс - бюджет мероприятия с таким докУментом можно смело поднимать на порядок минимум

Это сообщение отредактировал aalm - 8.05.2025 - 21:01

Ну так это тоже важно, мне например он здорово помогает в таких моментах, когда из словоблудия заказчика нужно как раз составить "красивый" структурированный документ, естественно подправив его, и да это тоже помогает поднять "бюджет" мероприятия красиво преподнеся его заказчику как обоснование затрат.
ИИ это умеет, если нужно налить воды и раздуть ТЗ он очень неплохо это делает.

Jeners

И всё бы хорошо, но у 90% ""пользователей" ИИ" голова выключается сразу после отправки запроса. "Контролировать" и "уточнять"??! -
И это НЕ про математику или программирование! Сейчас чатГПТ используют даже абсолютные гуманитарии!!!

Лично я столкнулся с тем, что ИИ упорно пытался отстоять своё неправильное решение!

Это сообщение отредактировал murla - 9.05.2025 - 00:05

Да.
Только нужно постоянно контролировать!
Вдумчиво!!! (если результат важен)

Давно заметил резкий спад разговоров про IT на ТВ.

Гугл уже создает часть кода с помощью ИИ.

Это сообщение отредактировал Plutarch - 9.05.2025 - 04:05