Поверхностно пересказываем что то вроде копенгагенской интерпретации и что про нее говорят на уровне первого семестра физики, выдаём это за свежий взгляд, стартап, устройства, клиника, профит. Я думал это время давно ушло.
Пока ничего принципиально не меняется. Раньше замысел нужно было описывать кодом, сейчас замысел и код надо описывать словами. Суть не меняется - нужно производить как можно быстрее работающий код, так чтобы не терять контроль и не утонуть в хаосе и неопределенности.
До тех пор, пока АИ недостаточно умён, чтобы взять на себя всестороннюю ответственность за развитие продукта, программист по сути занимается тем же самым что и раньше, пропуская через мозг понимание что как работает и куда это все идёт.
Что возможно станет приятнее, это укрупнение задач отдельного разработчика, когда целую фитчу или модуль пишет один человек. Раньше наниматели старались этого избежать, опасаясь рисков - медленно, риск прочесть если человек уволится. Теперь становится быстрее и с АИ намного легче оперировать чужим кодом.
И ещё - невероятно дешевые POC. Теперь вместо того чтобы просить коллегу рассмотреть возможность что то добавить в его модуль я могу добавить это сам с АИ за пол часа и прийти на митинг с готовым вариантом решения.
Исследователь может локально изменить параметры нуклеотидного метаболизма и мгновенно увидеть, как это повлияет на скорость репликации ДНК на другом конце клетки и сборку рибосом в центре цитоплазмы.
Но речь не идёт о том чтобы изменить генетический код и посмотреть что будет. Потому что в лоб невозможно смоделировать даже поведение молекул одного белка.
Создай десктопное приложение "Инженерный калькулятор" на Python с использованием библиотеки Tkinter.
Вот чего я не ожидал, так это увидеть Opus 4.6 на первом месте.
Блин, да сколько можно этих тетрисов. Такие тесты ровным счётом ничего не отражают. Попробуйте поработать с энтерпрайз приложением на миллион строк в разных задачах несколько месяцев. Все кого я знаю в таком опыте остановились пока на Sonet для быстрого решения и Opus для качественного. Эти модели дают самый стабильный результат.
Мне гораздо важнее знать, как она работает в плохих случаях и насколько легко это обнаружить, если я дам этой системе генерировать код вместо меня.
Имея опыт с моделью допольно легко предсказать где она сделает как ожидается, а где может накосячить. Но вообще, задачи которые делаются на C++ не сильно пока подходят под агентное программирование.
Я утверждал, что использую ее для создания почти 100% кода уже в любой задаче. И это так и есть. При этом мои задачи обычные для программиста - не простые не сложные. Вайбкодить в классическом смысле - просто в общих чертаъхх ставить задачи я не пробовал, не знаю насколько хорошо это рабтает. Я обычно описываю довольно детально как экономить ресурсы в местах где их имеет смысл экономить. Знаю, что мой коллега который вынесет мозг любому за малейшую неоптимальность в коде уже вайбкодит безудержно. А значит оно работает. Вы утверждали, что модель не понимает как оно работает внутри. Но как раз это абсолютно неверно. У моделей есть куча "психологических" проблем - она слишком верит сказанному, она предположит не переспрашивая, она упростит себе задачу без спроса если что-то не стыковалось и так далее. Но что несомненно - что у нее в нейронной сети есть те же самые абстрактные образы любой программистской концепции, что и у человека. Она знает о ranges в точности то же что и вы. Только тупит в других ситуациях.
Если в инпуте миллион элементов, он аллоцирует вектор на миллион элементов, хотя можно обойтись обычным поэлементным циклом с условием.
Если мы зачем-то вперли туда ranges, то модель верит что он нужен и пляшет от этого. Если бы вы давали эту задачу на собесе, метания бедного кандидата были бы примерно в том же духе.
Да, согласен, она затупила. И именно по той причине, что задача далека от задач с понятной целью. LLM просто не догнала что и зачем я делаю. В реальнй работе я даже не встречал такого поведения LLM - чтобы поменяла работу алгоритма при улучшении. При работе с агентом через несколько месяцев вырабатывается своебразное чувство локтя - что и как ему поручать. Своей постановкой задачи вы его немонго ломаете, поэтому я не справился. Продолжим тогда. Промпт: "Ты уверен что здесь все так просто и нет никагого подвоха? " Ответ: Нет, подвох тут есть. Моя правка была правильной только при одном важном предположении: фильтр можно применять к исходным данным, а не к результату run_paid_request ... и дальше когда я просил не менять поведение:
Как вам?
На сём предлагаю закончить дискуссию о волшебном умении ллм решить любую задачу.
А вы можете решить любую задчу? Каждый месяу LLM становятся лучше и поверьте, эти дискуссии в самом начале.
Ok, давайте развеем ваши сомнения. Первое - LLM создают для реальных задач а не разгадывания загадок. Ваш код сам по себе абсурден, потому что если вы фильтруете по результату, то вероятно вы еще не знаете как этот результат будет считаться и не можете избежать вызова тяжелой функции.LLM работает хорошо когда ясно понимает что и зачем вы делаете. Она не для собесов, а для работы.
Тем не менее, давайте попробуем. Я немного поменяю вашу задачу. Я создаю файл cpp:
#include <iostream>
#include <ranges>
#include <vector>
void process_data(std::ranges::forward_range auto &&input) {
static const auto run_paid_request = [](auto i) {
// here we are planing some heavy calculation
// ...
return i + 1;
};
auto output = input
| std::views::transform(run_paid_request)
| std::views::filter([](auto i) {
return i % 2 == 0; // here will be some complicated filter
});
for(auto o : output) {
std::cout << "result: " << o << std::endl;
}
}
int main() {
process_data(std::vector<int> {1, 2, 3, 4, 5});
return 0;
}
Промпт: Я начал создавать функцию для выполннеия задач обработки с фильтрацией.Исправь, если я где-то ошибся.
Ответ:
Код синтаксически корректен, но содержит логическую ошибку: transform (дорогая операция run_paid_request) выполняется до filter, а значит тяжёлые вычисления запускаются для всех элементов, включая те, которые потом отбрасываются фильтром.
Нужно поменять порядок — сначала фильтровать, потом обрабатывать:
Edited
f.cpp+2-2
Теперь filter идёт первым — фильтр отсеивает ненужные элементы, и только прошедшие попадают в transform (run_paid_request). Это избавляет от лишних дорогих вычислений.
С входом {1, 2, 3, 4, 5}:
filter (чётные) → {2, 4}
transform (+1) → {3, 5}
Вывод: result: 3, result: 5
И вот правки:
Не вникал как работают эти ranges. Все правильно? Похоже, что LLM знает как это работает?
Ну. Ok, LLM не сильно ускоряет принятие архитектурных решений. Иногда ускоряет, потому что можно себе позволить затупить и заставить агента слепить POC, чтобы понять что так будет плохо и переделать. Но если вы сильны в этом, то да, не ускорит.
Но продумывание архитектуры это совсем небольшой процент работы. Мы изучаем чужой код, пишем новый код в существующую архитектуру, пишем новый код используя принятые решения. Это 99 процентов работы. Раньше я воображал как все будет работать и садился кодить. Теперь я воображаю, потом машу волшебной палочкой, потом ревьюваю что получилось. Это вообще другой уровень.
Выше по тексту я описывал задачу. Где в ней бойлерплейт? Это нужно впереть в довольно сложный фреймворк не совсем близкую к нему концепцию. Разобрать как разработчик организовал все визиторы которые разбирают expression tree iqueryable, правильно их поменять, разобрать все нюансы и косяки самопального DSL. Даже учитывая что это мой код я бы просидел неделю, а опус сделал все с тестами за два часа. Мне остаётся только изучить и улучшить. Если то что получилось не понравится PM, мне понадобится ещё два часа чтобы переделать. Это чудо.
"Умеют единицы", это не отражает реальную ситуацию. Скорее 30% уже пробовали и сработались с этим новым виртуальным коллегой, а 70% или не пробовали, или не попытались сработаться и сразу его забраковали, или попытались но слишком рано и все еще не в курсе насколько он поумнел.
Вплоть до, казалось бы очевидных вещей вроде разделения на слои (view, view model и иже с ними), хреначит бизнеслогику прямо в UI контролы.
Х.з. В существующую архитектуру он вписывает все красиво. Раньше приходилось писать типа "посмотри как сделана фитча какая-то и делай аналогичную архитектуру.", теперь как будто сам догадывается. Логику может унести в неожиданное место, это да, ну так все равно каждую строчку ревьювать. Пишешь куда перенести логику и он переносит.
Проблема пока не в том что он может заменить программиста, проблема что он его может ускорить в разы, чем заменить всех коллег этого программиста.
Поверхностно пересказываем что то вроде копенгагенской интерпретации и что про нее говорят на уровне первого семестра физики, выдаём это за свежий взгляд, стартап, устройства,
клиника, профит. Я думал это время давно ушло.Пока ничего принципиально не меняется. Раньше замысел нужно было описывать кодом, сейчас замысел и код надо описывать словами. Суть не меняется - нужно производить как можно быстрее работающий код, так чтобы не терять контроль и не утонуть в хаосе и неопределенности.
До тех пор, пока АИ недостаточно умён, чтобы взять на себя всестороннюю ответственность за развитие продукта, программист по сути занимается тем же самым что и раньше, пропуская через мозг понимание что как работает и куда это все идёт.
Что возможно станет приятнее, это укрупнение задач отдельного разработчика, когда целую фитчу или модуль пишет один человек. Раньше наниматели старались этого избежать, опасаясь рисков - медленно, риск прочесть если человек уволится. Теперь становится быстрее и с АИ намного легче оперировать чужим кодом.
И ещё - невероятно дешевые POC. Теперь вместо того чтобы просить коллегу рассмотреть возможность что то добавить в его модуль я могу добавить это сам с АИ за пол часа и прийти на митинг с готовым вариантом решения.
Но речь не идёт о том чтобы изменить генетический код и посмотреть что будет. Потому что в лоб невозможно смоделировать даже поведение молекул одного белка.
Блин, да сколько можно этих тетрисов. Такие тесты ровным счётом ничего не отражают. Попробуйте поработать с энтерпрайз приложением на миллион строк в разных задачах несколько месяцев. Все кого я знаю в таком опыте остановились пока на Sonet для быстрого решения и Opus для качественного. Эти модели дают самый стабильный результат.
Поскольку сейчас практически любой агент создаёт субагентов, то формально это уже не совсем одноагентные системы.
Имея опыт с моделью допольно легко предсказать где она сделает как ожидается, а где может накосячить. Но вообще, задачи которые делаются на C++ не сильно пока подходят под агентное программирование.
Это нейронка. Точно как мозг человека она не может выполнить код в уме и давать детерминированный выход. Она дает только достаточно хороший выход.
Это анекдот про сибирских мужиков и японскую бензопилу. Вам предлагают инструмент который валит лес, а вы ищите лом которые ее сломает.
Я утверждал, что использую ее для создания почти 100% кода уже в любой задаче. И это так и есть. При этом мои задачи обычные для программиста - не простые не сложные. Вайбкодить в классическом смысле - просто в общих чертаъхх ставить задачи я не пробовал, не знаю насколько хорошо это рабтает. Я обычно описываю довольно детально как экономить ресурсы в местах где их имеет смысл экономить.
Знаю, что мой коллега который вынесет мозг любому за малейшую неоптимальность в коде уже вайбкодит безудержно. А значит оно работает.
Вы утверждали, что модель не понимает как оно работает внутри. Но как раз это абсолютно неверно. У моделей есть куча "психологических" проблем - она слишком верит сказанному, она предположит не переспрашивая, она упростит себе задачу без спроса если что-то не стыковалось и так далее.
Но что несомненно - что у нее в нейронной сети есть те же самые абстрактные образы любой программистской концепции, что и у человека.
Она знает о ranges в точности то же что и вы. Только тупит в других ситуациях.
Если мы зачем-то вперли туда ranges, то модель верит что он нужен и пляшет от этого. Если бы вы давали эту задачу на собесе, метания бедного кандидата были бы примерно в том же духе.
Да, согласен, она затупила. И именно по той причине, что задача далека от задач с понятной целью. LLM просто не догнала что и зачем я делаю. В реальнй работе я даже не встречал такого поведения LLM - чтобы поменяла работу алгоритма при улучшении. При работе с агентом через несколько месяцев вырабатывается своебразное чувство локтя - что и как ему поручать. Своей постановкой задачи вы его немонго ломаете, поэтому я не справился.
Продолжим тогда.
Промпт:
"Ты уверен что здесь все так просто и нет никагого подвоха? "
Ответ:
Нет, подвох тут есть. Моя правка была правильной только при одном важном предположении: фильтр можно применять к исходным данным, а не к результату run_paid_request
...
и дальше когда я просил не менять поведение:
Как вам?
А вы можете решить любую задчу?
Каждый месяу LLM становятся лучше и поверьте, эти дискуссии в самом начале.
Ok, давайте развеем ваши сомнения.
Первое - LLM создают для реальных задач а не разгадывания загадок. Ваш код сам по себе абсурден, потому что если вы фильтруете по результату, то вероятно вы еще не знаете как этот результат будет считаться и не можете избежать вызова тяжелой функции.LLM работает хорошо когда ясно понимает что и зачем вы делаете. Она не для собесов, а для работы.
Тем не менее, давайте попробуем. Я немного поменяю вашу задачу.
Я создаю файл cpp:
#include <iostream>#include <ranges>#include <vector>void process_data(std::ranges::forward_range auto &&input) {static const auto run_paid_request = [](auto i) {// here we are planing some heavy calculation// ...return i + 1;};auto output = input| std::views::transform(run_paid_request)| std::views::filter([](auto i) {return i % 2 == 0; // here will be some complicated filter});for(auto o : output) {std::cout << "result: " << o << std::endl;}}int main() {process_data(std::vector<int> {1, 2, 3, 4, 5});return 0;}Промпт:
Я начал создавать функцию для выполннеия задач обработки с фильтрацией.Исправь, если я где-то ошибся.
Ответ:
Код синтаксически корректен, но содержит логическую ошибку: transform (дорогая операция run_paid_request) выполняется до filter, а значит тяжёлые вычисления запускаются для всех элементов, включая те, которые потом отбрасываются фильтром.
Нужно поменять порядок — сначала фильтровать, потом обрабатывать:
Edited
f.cpp+2-2
Теперь filter идёт первым — фильтр отсеивает ненужные элементы, и только прошедшие попадают в transform (run_paid_request). Это избавляет от лишних дорогих вычислений.
С входом
{1, 2, 3, 4, 5}:filter (чётные) →
{2, 4}transform (+1) →
{3, 5}Вывод:
result: 3,result: 5И вот правки:
Не вникал как работают эти ranges.
Все правильно? Похоже, что LLM знает как это работает?
Ну. Ok, LLM не сильно ускоряет принятие архитектурных решений. Иногда ускоряет, потому что можно себе позволить затупить и заставить агента слепить POC, чтобы понять что так будет плохо и переделать. Но если вы сильны в этом, то да, не ускорит.
Но продумывание архитектуры это совсем небольшой процент работы. Мы изучаем чужой код, пишем новый код в существующую архитектуру, пишем новый код используя принятые решения. Это 99 процентов работы. Раньше я воображал как все будет работать и садился кодить. Теперь я воображаю, потом машу волшебной палочкой, потом ревьюваю что получилось. Это вообще другой уровень.
Ну так вы и вы можете назвать monkey job что угодно. Приведите пример не monkey job.
Скажем так, я сильно сомневаюсь что современные модели будут иметь какие то сложности с пониманием ranges.
Могу загрузить этот код для ревью и уверен что агент все починит. Пока времени нет.
Не ускорит, не снизит нагрузку на мой мозг и так далее. Таких задач все меньше.
Любая программа это конвертация одного в другое. Это был один из примеров. Какую задачу тогда по вашему не поможет сделать llm?
Выше по тексту я описывал задачу. Где в ней бойлерплейт? Это нужно впереть в довольно сложный фреймворк не совсем близкую к нему концепцию. Разобрать как разработчик организовал все визиторы которые разбирают expression tree iqueryable, правильно их поменять, разобрать все нюансы и косяки самопального DSL. Даже учитывая что это мой код я бы просидел неделю, а опус сделал все с тестами за два часа. Мне остаётся только изучить и улучшить. Если то что получилось не понравится PM, мне понадобится ещё два часа чтобы переделать. Это чудо.
"Умеют единицы", это не отражает реальную ситуацию. Скорее 30% уже пробовали и сработались с этим новым виртуальным коллегой, а 70% или не пробовали, или не попытались сработаться и сразу его забраковали, или попытались но слишком рано и все еще не в курсе насколько он поумнел.
Х.з. В существующую архитектуру он вписывает все красиво. Раньше приходилось писать типа "посмотри как сделана фитча какая-то и делай аналогичную архитектуру.", теперь как будто сам догадывается. Логику может унести в неожиданное место, это да, ну так все равно каждую строчку ревьювать. Пишешь куда перенести логику и он переносит.
Проблема пока не в том что он может заменить программиста, проблема что он его может ускорить в разы, чем заменить всех коллег этого программиста.
Потому что трудно обсуждать тему как сажать картошку, когда у тебя гребаная скатерть самобранка.