Большие модели не могут быть фармерами кода! Удивительное открытие Принстона: GPT-4 имеет 0 шансов на успех в решении проблем программирования на GitHub
инструменты программирования ИИ, такие как ChatGPT, угрожают, и Stack Overflow снова увольняет! Тем не менее, Принстон и Чикаго обнаружили, что GPT-4 имеет 0% разрешения реальных проблем GitHub.
Stack Overflow, уже созданный ChatGPT!
Из-за того, что программисты стекались в ChatGPT и Github Copilot, Stack Overflow сегодня пришлось объявить об увольнении более 100 сотрудников, что составляет почти 1/3 от числа сотрудников.
Итак, инструменты программирования ИИ, такие как ChatGPT, действительно подорвут всю индустрию?
Но недавнее исследование, проведенное Принстонским и Чикагским университетами, показало, что LLM не так легко сделать, как фермера кода.
Адрес доклада:
Перед лицом 2294 реальных проблем GitHub проходимость GPT-4 по решению случайных задач GitHub оказалась равна 0%!
Даже самая лучшая модель, Claude 2, решает только 1,96% из них.
Могут ли программисты потерять работу из-за ChatGPT? Ответ – абсолютно нет на данный момент.
Приспосабливайся или погибни
Как любимый сайт каждого разработчика в мире, Stack Overflow и раньше преуспевал, начав в прошлом году бум найма, удвоив штат компании до 540 человек.
Однако все изменилось с тех пор, как OpenAI выпустила ChatGPT в ноябре прошлого года.
Помощь, предоставляемая чат-ботами с искусственным интеллектом, более конкретна, чем сообщение на форуме 5-летней давности. С помощью LLM разработчики могут мгновенно исправлять точный код, предложения по оптимизации и описание того, что делает каждая строка кода.
Хотя LLM не дает 100% надежных ответов, уникальная возможность немедленной проверки кода, просто протестировав его в интегрированной среде разработки IDE, делает написание кода идеальным вариантом использования ChatGPT.
В результате трафик Stack Overflow значительно сократился, а инструменты программирования ИИ, такие как ChatGPT и Github Copilot на базе GPT-4, стали новыми местами для фермеров кода.
Сегодня генеральный директор Прашант Чандрасекар объявил, что Stack Overflow уволила более ста сотрудников, или 28% своей рабочей силы.
Генеральный директор объясняет увольнения тем, что Stack Overflow пытается выйти на путь прибыльности под макроэкономическим давлением и продолжает внедрять продуктовые инновации.
** Пересечь реку и снести мост? **
Самая большая ирония влияния ChatGPT на Stack Overflow заключается в том, что сила большой языковой модели в значительной степени исходит от скрейпинговых сайтов, таких как Stack Overflow.
Что произойдет, если большие языковые модели опустошат эти данные, ничего не вернув, и если все источники данных будут вытеснены из бизнеса?
Сейчас у многих технологических компаний уже нависла проблема: чем меньше программистов, тем меньше будет и искусственных данных.
Как обучать новые модели ИИ без актуальных данных?
Хотите использовать наши данные? Возьми деньги**
Stack Overflow, конечно же, не может сидеть на месте, он выбрал два пути для спасения -
Один из них заключается в разработке собственного инструмента программирования ИИ, OverflowAI, а другой — в поиске партнерских отношений напрямую с технологическими компаниями, такими как OpenAI, которые используют данные Stack Overflow для создания моделей ИИ.
OpenAI разрабатывает элементы управления веб-краулером для ChatGPT, чтобы данные с таких сайтов, как Stack Overflow, не могли быть просканированы.
Генеральный директор сказал, что Stack Overflow занял свою позицию: тот, кто хочет использовать наши данные для обучения LLM, платит.
Руководители считают, что такие сайты, как Stack Overflow, имеют решающее значение для разработки больших языковых моделей, и для того, чтобы продвинуться вперед, им необходимо обучаться новым знаниям.
Прашант Чандрасекар, генеральный директор Stack Overflow
LLM хочет получить код фермера, пока рано
Итак, могут ли большие языковые модели действительно использовать фермеров кода?
Команды из Принстона и Чикаго обнаружили, что это не так просто!
В последней статье исследователи предлагают новый фреймворк, SWE-bench, для оценки способности больших моделей решать 2294 реальных задач на GitHub.
Было обнаружено, что ведущие крупные модели, такие как GPT-4 и Claude 2, имеют менее 5% способности решать реальные задачи.
Если быть более точным, GPT-4 может решать случайные задачи GitHub с проходным баллом 0%, в то время как лучшая модель, Claude 2, может решить только 1,96% из них.
Более того, при использовании BM-25 для получения соответствующих файлов кода для каждой проблемы, только 23% патчей, написанных Claude 2, были действительными (готовыми к репозиторию), и только ~1% действительно решали проблему.
Кроме того, производительность разных моделей при решении задач с 12 популярными библиотеками Python также различается.
Модель GPT-4 достигла такого результата, что действительно удивительно, ведь многие уже давно расценивают ее как «оружие программирования».
Но чтобы ясно увидеть реальную силу ИИ, не стоит зацикливаться и волноваться.
Некоторые пользователи сети заявили, что это лучший ответ на вопрос «являются ли фермеры кода безработными из-за программирования».
В конце концов, кто-то сделал реальный набор данных для модели кода, и Hum был просто интервью с LLM leetcode. Мы все знаем, что это неправильная мера для инженеров-людей. Менее 4% звучит правильно, так как большие модели все еще далеки от полной автономности.
Так действительно ли это относится к результатам SWE-bench по оценке возможностей больших моделей?
SWE-bench: Предназначен для кодирования моделей
В этом исследовании авторы обнаружили, что многие современные критерии для измерения способности к кодированию больших моделей стали насыщенными и не могут измерить истинную силу больших моделей.
Например, в Human задача вызова слишком проста, и LLM нужно всего несколько строк кода, чтобы решить отдельную задачу.
Однако программная инженерия на самом деле не так проста.
Исправление ошибки может потребовать просмотра огромной библиотеки ресурсов, понимания взаимосвязей между функциями в разных файлах или поиска небольшой ошибки в сложном коде.
Вдохновленные этим, исследователи из Принстона и Чикаго представили SWE-bench.
SWE-bench получает экземпляры задач из реального репозитория Python, подключая проблемы GitHub и решения merge request для решения связанных тестов.
Как показано на рисунке, задача модели, обычно отчета об ошибке или запроса функции, заключается в устранении проблемы, зафиксированной в репозитории GitHub.
Каждая задача требует создания патча и описания изменений, которые должны быть применены к существующей кодовой базе.
Затем используйте тестовый фреймворк репозитория SWE-bench для оценки измененной кодовой базы.
Чтобы найти качественные примеры масштабных задач, исследователи прошли три этапа скрининга:
**Этап 1: Выбор склада и поиск данных. **
Запросы на вытягивание (PR) были впервые собраны из 12 популярных репозиториев Python с открытым исходным кодом на GitHub, создав в общей сложности около 90 000 запросов на вытягивание.
Исследователи сосредоточились на популярных репозиториях, потому что они, как правило, лучше поддерживаются, имеют четкие рекомендации для участников и имеют лучшее покрытие тестами. Каждый PR имеет связанную кодовую базу, т. е. состояние репозитория до слияния PR.
**Этап 2: Фильтрация на основе атрибутов. **
Задача кандидата создается путем выбора объединенного PR, который соответствует следующим критериям: (1) решает проблему GitHub; (2) Изменен тестовый файл репозитория, который указывает на то, что пользователь, скорее всего, внес свой вклад в тесты, чтобы проверить, решена ли проблема.
**Этап 3: Фильтрация на основе выполнения. **
Для каждой задачи-кандидата применяется тестовое содержимое PR, а также соответствующие результаты теста до и после другого содержимого PR.
Исследователь отфильтровывает экземпляры заданий, в которых нет хотя бы одного теста, и статус этих тестов меняется с «не пройден» (далее — «не пройден тест»). Кроме того, отфильтровываются экземпляры, вызывающие ошибки установки или эксплуатации.
На этих этапах отбора исходные 90 000 запросов на вытягивание распределяются по 2 294 экземплярам задач, которые составляют стенд SWE.
Окончательная классификация этих экземпляров задач в разных репозиториях показана на рисунке 3 ниже, где таблица является основной характеристикой экземпляров задач SWE-bench.
Исследователи подчеркивают, что эти кодовые базы большие, содержащие тысячи файлов, и что эталонные запросы на вытягивание часто изменяют несколько файлов одновременно.
SWE-bench имеет ряд преимуществ по сравнению с существующими бенчмарками LM-программирования.
К ним относятся реальные настройки с предоставленными пользователями проблемами и решениями, разнообразные входные данные с уникальными вопросами кода из 12 репозиториев, надежная платформа оценки на основе выполнения и возможность постоянно обновлять тесты производительности новыми экземплярами с минимальным вмешательством человека.
Задача LLM: редактировать кодовую базу, решать задачи
Исследователь предоставит большой модели текстовое описание проблемы, а также полную кодовую базу.
Задача большой модели — отредактировать кодовую базу для решения проблемы.
На практике исследователи представляют изменения в виде файлов исправлений, которые указывают, какие строки в кодовой базе следует изменить для решения проблемы.
Как оценить, является ли решение, предложенное LLM, хорошим или нет?
Исследователи используют патчи Unix, применяют сгенерированные патчи к кодовой базе, а затем выполняют модульные и системные тесты, связанные с экземплярами задач.
Если патч применен успешно и все эти тесты пройдены, схема, рекомендованная LLM, может считаться успешно решенной проблемой.
Метрика базового уровня, которая представляет собой процент разрешенных экземпляров задач.
Построение уникального датасета для SWE-bench
Традиционные тесты NLP обычно включают в себя только короткие последовательности ввода и вывода и учитывают некоторые «искусственные» задачи, созданные специально для бенчмарков.
В отличие от этого, чтобы построить SWE-стенд, исследователи внедрили уникальные свойства в набор данных.
Например, используются реальные задачи программной инженерии.
Поскольку каждый экземпляр задачи в SWE-bench содержит большую и сложную кодовую базу и описание связанной с ней проблемы, решение SWE-bench требует сложных навыков и знаний опытных инженеров-программистов, которые часто не оцениваются в традиционных тестах генерации кода.
Более того, процесс сбора может быть легко применен к любому репозиторию Python на GitHub практически без вмешательства человека.
В результате исследователи могут расширить стенд SWE, предоставив новые экземпляры задач, и оценить языковую модель для задач, созданных после даты обучения, гарантируя, что обучающий корпус не содержит решения.
Кроме того, исследователи гарантируют различные длинные входные данные в бенчмарке, робастную оценку, кросс-контекстное редактирование кода, широкий спектр решений и т. д.
Тонкая настройка SWE-Llama
Далее пришло время оценить эффективность открытых и проприетарных моделей в фреймворке SWE-bench.
Тем не менее, исследователи обнаружили, что готовые модели тонкой настройки CodeLlama не могут следовать подробным инструкциям для создания общебиблиотечных правок кода, часто выводя ответы заполнителей или нерелевантный код.
Чтобы оценить возможности этих моделей, исследователи выполнили контролируемую тонкую настройку (SFT) на модели CodeLlama-Python с 7 миллиардами параметров и моделью CodeLlama-Python с 13 миллиардами параметров.
Результирующая модель представляет собой специализированный редактор репозитория, который работает на оборудовании потребительского класса и решает проблемы GitHub.
### Большие модели терпят неудачу
Затем исследователи оценили GPT-3.5, GPT-4, Cluade 2 и тонко настроенные модели.
Оказалось, что все модели потерпели неудачу – ни одна из них не решала всех, кроме простейших проблем.
Например, Claude 2 и GPT-4 могут решить только 4,8% и 1,7% задач соответственно.
После использования ретривера BM25 производительность Claude 2 снизилась до 1,96%.
**Разные библиотеки имеют разный уровень сложности. **
Если разбить производительность по репозиториям, то можно увидеть, что все модели демонстрируют схожие тенденции в библиотеках.
Тем не менее, проблемы, решаемые каждой моделью, не обязательно полностью пересекаются. Например, в конфигурации оракула Claude 2 и SWE-Llama 13b работают сопоставимо, решая 110 и 91 экземпляр на модель соответственно.
**Сложность зависит от длины контекста. **
Модели могут быть предварительно обучены на длинных последовательностях кода, но, как правило, требуют создания одной функции за раз и предоставляют платформу с ограниченным контекстом для определения проблемы.
Как видно на рисунке, производительность Claude 2 значительно снижается по мере увеличения общей длины контекста, что можно наблюдать и в других моделях.
Даже если увеличение максимального размера контекста BM25 улучшит полноту памяти по сравнению с файлами Oracle, производительность все равно снизится, потому что модель просто не сможет найти проблемный код в обширном тезаурусе.
**Сложность не зависит от даты решения проблемы. **
В таблице 7 показаны результаты моделирования по датам для PR, созданных до или после 2023 года в настройках поиска "oracle".
Для большинства моделей, за исключением GPT-4, есть небольшая разница в производительности до или после этой даты.
Кроме того, исследование показало, что тонкая настройка модели чувствительна к изменениям в распределении контекста, и легче сгенерировать патч, чем сгенерировать весь файл. А большие модели, как правило, дают более короткие и простые правки.
LLM не заменяет программистов, но может ускорить рабочие процессы
Некоторые пользователи сети возлагают надежды и надежды на будущее «универсальной модели».
Правильно, это то, о чем я говорю. Универсальная модель недостаточно хороша, чтобы иметь достаточно широкую длину контекста для самостоятельного кодирования, за исключением относительно коротких фрагментов кода.
Но я думаю, что это только вопрос времени. Я предвижу, что в ближайшем будущем магистр права широкого профиля со специальной подготовкой станет очень профессиональной моделью.
Несмотря на то, что большие модели не могут заменить программистов, они могут ускорить их рабочие процессы. То, что раньше занимало команду из 10 человек, теперь может понадобиться только 4 человека. Это высвобождает ресурсы для других целей, подготовленных компанией.
Вместо того, чтобы увольнять сотрудников, чтобы сэкономить деньги, позвольте разработчикам делать великие вещи с головокружительной скоростью!
Ресурсы:
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Большие модели не могут быть фармерами кода! Удивительное открытие Принстона: GPT-4 имеет 0 шансов на успех в решении проблем программирования на GitHub
Источник статьи: Синь Цзи Юань
Stack Overflow, уже созданный ChatGPT!
Из-за того, что программисты стекались в ChatGPT и Github Copilot, Stack Overflow сегодня пришлось объявить об увольнении более 100 сотрудников, что составляет почти 1/3 от числа сотрудников.
Но недавнее исследование, проведенное Принстонским и Чикагским университетами, показало, что LLM не так легко сделать, как фермера кода.
Перед лицом 2294 реальных проблем GitHub проходимость GPT-4 по решению случайных задач GitHub оказалась равна 0%!
Даже самая лучшая модель, Claude 2, решает только 1,96% из них.
Приспосабливайся или погибни
Как любимый сайт каждого разработчика в мире, Stack Overflow и раньше преуспевал, начав в прошлом году бум найма, удвоив штат компании до 540 человек.
Однако все изменилось с тех пор, как OpenAI выпустила ChatGPT в ноябре прошлого года.
Хотя LLM не дает 100% надежных ответов, уникальная возможность немедленной проверки кода, просто протестировав его в интегрированной среде разработки IDE, делает написание кода идеальным вариантом использования ChatGPT.
В результате трафик Stack Overflow значительно сократился, а инструменты программирования ИИ, такие как ChatGPT и Github Copilot на базе GPT-4, стали новыми местами для фермеров кода.
Сегодня генеральный директор Прашант Чандрасекар объявил, что Stack Overflow уволила более ста сотрудников, или 28% своей рабочей силы.
** Пересечь реку и снести мост? **
Самая большая ирония влияния ChatGPT на Stack Overflow заключается в том, что сила большой языковой модели в значительной степени исходит от скрейпинговых сайтов, таких как Stack Overflow.
Что произойдет, если большие языковые модели опустошат эти данные, ничего не вернув, и если все источники данных будут вытеснены из бизнеса?
Сейчас у многих технологических компаний уже нависла проблема: чем меньше программистов, тем меньше будет и искусственных данных.
Как обучать новые модели ИИ без актуальных данных?
Хотите использовать наши данные? Возьми деньги**
Stack Overflow, конечно же, не может сидеть на месте, он выбрал два пути для спасения -
Один из них заключается в разработке собственного инструмента программирования ИИ, OverflowAI, а другой — в поиске партнерских отношений напрямую с технологическими компаниями, такими как OpenAI, которые используют данные Stack Overflow для создания моделей ИИ.
Генеральный директор сказал, что Stack Overflow занял свою позицию: тот, кто хочет использовать наши данные для обучения LLM, платит.
Руководители считают, что такие сайты, как Stack Overflow, имеют решающее значение для разработки больших языковых моделей, и для того, чтобы продвинуться вперед, им необходимо обучаться новым знаниям.
LLM хочет получить код фермера, пока рано
Итак, могут ли большие языковые модели действительно использовать фермеров кода?
Команды из Принстона и Чикаго обнаружили, что это не так просто!
Было обнаружено, что ведущие крупные модели, такие как GPT-4 и Claude 2, имеют менее 5% способности решать реальные задачи.
Если быть более точным, GPT-4 может решать случайные задачи GitHub с проходным баллом 0%, в то время как лучшая модель, Claude 2, может решить только 1,96% из них.
Кроме того, производительность разных моделей при решении задач с 12 популярными библиотеками Python также различается.
Но чтобы ясно увидеть реальную силу ИИ, не стоит зацикливаться и волноваться.
SWE-bench: Предназначен для кодирования моделей
В этом исследовании авторы обнаружили, что многие современные критерии для измерения способности к кодированию больших моделей стали насыщенными и не могут измерить истинную силу больших моделей.
Например, в Human задача вызова слишком проста, и LLM нужно всего несколько строк кода, чтобы решить отдельную задачу.
Однако программная инженерия на самом деле не так проста.
Вдохновленные этим, исследователи из Принстона и Чикаго представили SWE-bench.
SWE-bench получает экземпляры задач из реального репозитория Python, подключая проблемы GitHub и решения merge request для решения связанных тестов.
Как показано на рисунке, задача модели, обычно отчета об ошибке или запроса функции, заключается в устранении проблемы, зафиксированной в репозитории GitHub.
Каждая задача требует создания патча и описания изменений, которые должны быть применены к существующей кодовой базе.
Затем используйте тестовый фреймворк репозитория SWE-bench для оценки измененной кодовой базы.
Запросы на вытягивание (PR) были впервые собраны из 12 популярных репозиториев Python с открытым исходным кодом на GitHub, создав в общей сложности около 90 000 запросов на вытягивание.
Исследователи сосредоточились на популярных репозиториях, потому что они, как правило, лучше поддерживаются, имеют четкие рекомендации для участников и имеют лучшее покрытие тестами. Каждый PR имеет связанную кодовую базу, т. е. состояние репозитория до слияния PR.
**Этап 2: Фильтрация на основе атрибутов. **
Задача кандидата создается путем выбора объединенного PR, который соответствует следующим критериям: (1) решает проблему GitHub; (2) Изменен тестовый файл репозитория, который указывает на то, что пользователь, скорее всего, внес свой вклад в тесты, чтобы проверить, решена ли проблема.
**Этап 3: Фильтрация на основе выполнения. **
Для каждой задачи-кандидата применяется тестовое содержимое PR, а также соответствующие результаты теста до и после другого содержимого PR.
Исследователь отфильтровывает экземпляры заданий, в которых нет хотя бы одного теста, и статус этих тестов меняется с «не пройден» (далее — «не пройден тест»). Кроме того, отфильтровываются экземпляры, вызывающие ошибки установки или эксплуатации.
На этих этапах отбора исходные 90 000 запросов на вытягивание распределяются по 2 294 экземплярам задач, которые составляют стенд SWE.
Окончательная классификация этих экземпляров задач в разных репозиториях показана на рисунке 3 ниже, где таблица является основной характеристикой экземпляров задач SWE-bench.
Исследователи подчеркивают, что эти кодовые базы большие, содержащие тысячи файлов, и что эталонные запросы на вытягивание часто изменяют несколько файлов одновременно.
SWE-bench имеет ряд преимуществ по сравнению с существующими бенчмарками LM-программирования.
К ним относятся реальные настройки с предоставленными пользователями проблемами и решениями, разнообразные входные данные с уникальными вопросами кода из 12 репозиториев, надежная платформа оценки на основе выполнения и возможность постоянно обновлять тесты производительности новыми экземплярами с минимальным вмешательством человека.
Задача LLM: редактировать кодовую базу, решать задачи
Исследователь предоставит большой модели текстовое описание проблемы, а также полную кодовую базу.
Задача большой модели — отредактировать кодовую базу для решения проблемы.
На практике исследователи представляют изменения в виде файлов исправлений, которые указывают, какие строки в кодовой базе следует изменить для решения проблемы.
Исследователи используют патчи Unix, применяют сгенерированные патчи к кодовой базе, а затем выполняют модульные и системные тесты, связанные с экземплярами задач.
Метрика базового уровня, которая представляет собой процент разрешенных экземпляров задач.
Построение уникального датасета для SWE-bench
Традиционные тесты NLP обычно включают в себя только короткие последовательности ввода и вывода и учитывают некоторые «искусственные» задачи, созданные специально для бенчмарков.
В отличие от этого, чтобы построить SWE-стенд, исследователи внедрили уникальные свойства в набор данных.
Например, используются реальные задачи программной инженерии.
Более того, процесс сбора может быть легко применен к любому репозиторию Python на GitHub практически без вмешательства человека.
В результате исследователи могут расширить стенд SWE, предоставив новые экземпляры задач, и оценить языковую модель для задач, созданных после даты обучения, гарантируя, что обучающий корпус не содержит решения.
Кроме того, исследователи гарантируют различные длинные входные данные в бенчмарке, робастную оценку, кросс-контекстное редактирование кода, широкий спектр решений и т. д.
Тонкая настройка SWE-Llama
Далее пришло время оценить эффективность открытых и проприетарных моделей в фреймворке SWE-bench.
Тем не менее, исследователи обнаружили, что готовые модели тонкой настройки CodeLlama не могут следовать подробным инструкциям для создания общебиблиотечных правок кода, часто выводя ответы заполнителей или нерелевантный код.
Чтобы оценить возможности этих моделей, исследователи выполнили контролируемую тонкую настройку (SFT) на модели CodeLlama-Python с 7 миллиардами параметров и моделью CodeLlama-Python с 13 миллиардами параметров.
Результирующая модель представляет собой специализированный редактор репозитория, который работает на оборудовании потребительского класса и решает проблемы GitHub.
Затем исследователи оценили GPT-3.5, GPT-4, Cluade 2 и тонко настроенные модели.
Оказалось, что все модели потерпели неудачу – ни одна из них не решала всех, кроме простейших проблем.
Например, Claude 2 и GPT-4 могут решить только 4,8% и 1,7% задач соответственно.
После использования ретривера BM25 производительность Claude 2 снизилась до 1,96%.
**Разные библиотеки имеют разный уровень сложности. **
Если разбить производительность по репозиториям, то можно увидеть, что все модели демонстрируют схожие тенденции в библиотеках.
Тем не менее, проблемы, решаемые каждой моделью, не обязательно полностью пересекаются. Например, в конфигурации оракула Claude 2 и SWE-Llama 13b работают сопоставимо, решая 110 и 91 экземпляр на модель соответственно.
**Сложность зависит от длины контекста. **
Модели могут быть предварительно обучены на длинных последовательностях кода, но, как правило, требуют создания одной функции за раз и предоставляют платформу с ограниченным контекстом для определения проблемы.
Как видно на рисунке, производительность Claude 2 значительно снижается по мере увеличения общей длины контекста, что можно наблюдать и в других моделях.
Даже если увеличение максимального размера контекста BM25 улучшит полноту памяти по сравнению с файлами Oracle, производительность все равно снизится, потому что модель просто не сможет найти проблемный код в обширном тезаурусе.
В таблице 7 показаны результаты моделирования по датам для PR, созданных до или после 2023 года в настройках поиска "oracle".
Для большинства моделей, за исключением GPT-4, есть небольшая разница в производительности до или после этой даты.
LLM не заменяет программистов, но может ускорить рабочие процессы
Некоторые пользователи сети возлагают надежды и надежды на будущее «универсальной модели».
Правильно, это то, о чем я говорю. Универсальная модель недостаточно хороша, чтобы иметь достаточно широкую длину контекста для самостоятельного кодирования, за исключением относительно коротких фрагментов кода.
Но я думаю, что это только вопрос времени. Я предвижу, что в ближайшем будущем магистр права широкого профиля со специальной подготовкой станет очень профессиональной моделью.
Вместо того, чтобы увольнять сотрудников, чтобы сэкономить деньги, позвольте разработчикам делать великие вещи с головокружительной скоростью!