Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 83
Вот почему я больше не читаю код
Да, хреново когда не знал, да еще и забыл...
Сегодня ты не читаешь код, а завтра твоя программа, сгенерённая ИИ для постов картинок ИИ с описаниями от ИИ постит в Фейсбук детскую порнографию с прекрасным описанием, всё как ты и просил, и вдруг ты слышишь требовательный стук в дверь. Но не переживай, это же профиль твоей жены, тебе ничего не грозит.
Иногда читать может быть нужно, а иногда достаточно хорошо настроенного CI/CD, линтеров, тестов, чекеров безопасности и других инструментов. Чем больше автоматизации для проверки кода, тем меньше потребность его читать. А задачи от пользователей могут быть почти сразу быть направлены в разработку используя AI агентов.
да, линтер конечно спасет от cp. а тесты, штош их тоже АИ писал
Бывает код вида if (time == n) { db.dropAll() }
Я конечно утрирую, но когда llm создавала граничную ситуацию там, где её нет (и не покроешь тестами) - я видел своими глазами. Не будешь же функцию с одз в long реально гонять на всех long-aх в тестах.
Тесты как трусы: прикрывают, но не защищают.
Надо сделать невалидное состояние невозможным.
А можно пример, что там LLM накосячил?
А можно пример, что там LLM накосячил?
Доступа к коду этому у меня уже нет. Но упрощенно выглядело так - есть код, обрабатывающий диапазоны значений и функции для каждого из диапазонов. Условно от 1 до 10 использовать f1(x), от 11 до 20 использовать f2(x) и от 20 до 30 f3(x))
Надо было добавить пару диапазонов, LLM сделала из перекрывающимся в части диапазона (от 1 до 10 f1(x) и от 8 до 22 f2(x) ), но при этом внутрь функции f2 запихнула проверку if (x == 10 || x == 21) return;
Как итог - тесты проходили, на граничных значениях все хорошо, в центре диапазона всё хорошо, а взять значение немного у края - то сумма считается уже неправильно.
В жизни конечно код был чуть сложнее - отвечал за подсчет коммиссий. На ревью кстати было не так просто увидеть т.к. код ветвистый а изолированные функции выглядели просто и корректно. Ошибку заметили только благодаря тому, что условие проверки границ внутри функции вызывало подозрение.
Но не переживай, это же профиль твоей жены, тебе ничего не грозит.
Ахахахаха. Супер! :)
Один нюанс: все это работает, пока антропик и прочие демпигуют, работают в минус и прожигают шальное бабло инвесторов. На чужом горбу в рай. Впрочем, ничего нового.
Но есть и обратная сторона - триллион на AI уже сожжен (буквально, в гигаватт-часах), чипы распаяны, ДЦ уже построены, модели уже обучены.
5% нынешней окупаемости отрасли смогут покрыть только инференс, даже в случае банкроства и распродажи ДЦ с долговых аукционов.
Т.е. в каждый момент времени можно ожидать, что уже достигнугнутый моделями уровень ниже не упадет даже с наступлением полномасштабного кризиса отрасли (на таком масштабе пузыря он неизбежно совпадет с общим финансовым кризисом).
Следствие - те, кого модели могут оставить без работы уже сейчас, они оставят без работы и в случае кризиса ИИ отрасли. Банкроство ИИ стартапов не возродит профессию переводчика текстов, например.
Исторические аналогии - банкроство железных дорог, как стартапов 19 века, не остановило железнодорожное сообщение. Построенными дорогами все равно пользовались. За исключением совсем экстремальных случаев ЖД веток в никуда.
Речь про цену данного удовольствия. Все эти пророки "новой эры" любят повторять, что "как раньше уже не будет". Хорошо, не будет. Но вся бравада строится исключительно на том, что теперь всегда будет так, как сейчас. То есть антропик теперь во веки вечные будет толкать им свой товар по 100 баксов в месяц. А если по 1000 баксов? А по 5000? Уже за 1000 баксов болтовни будет на пару порядков меньше. Какой-то вселенский закон запрещает такой исход событий? Всегда на рынке будет такая же анархия и конкуренция как сейчас? Это тоже каким-то законом предопределено?
Смотрите хотя бы опыт Яндекс такси. Сначала тоже кипятком ссали от низких цен.
Мне кажется, вы привели Я.Т. как пример "не в ту сторону".
ЯТ замечательно заменил бомбил и тогда и сейчас. Вы вообще часто на дороге руку поднимаете? Да, сказочно дешевый период закончился, начался просто дешевый. Он по прежнему дешевый, дешевле, чем бомбила.
А еще, мне кажется, AI отлично офшорится. Никто не обязывает иметь ИИшный дата-центр через квартал - там все равно скорости медленные. Можно даже правдоподобно вообразить AI-датацентры за северным полярным кругом - там проще с охлаждением и проще ставить АЭС.
Ят монополист. Где вы видели чтобы в монополиях без контроля со стороны что-то было дешево?
тут не так давно был всплеск статей (вроде и на хабре тоже было что-то) о том, что ии-ускорители выходят из строя быстрее, чем успевают окупиться, так что ДЦ сами по себе могут быть не сильно ликвидным активом.
Это всё до появления нечётких или противоречивых требований, эдж кейсов и прочей грязи, после которой ваша сверкающая машинка быстро падает и делает громкий бум.
Только человек может выявить противоречия, сбалансировать решение, документировать для будущих изменений.
Приведенные в статье утилиты это редкое исключение когда можно делегировать LLM
Так просто уже существует опенсорс утилиты делающие то что нужно. Естественно их пересборка легко дается иИ
Совсем не обязательно, у меня AI агент на нечётки и противоречивых требованиях вопросы задаёт. Но конечно если человек сам разбирается со своими противоречиями и определяет какое соотношение между крайностями дихотомий для него допустимо, то разработка идёт на порядки эффективнее.
Я не волшебник, я только учусь, но такой подход не будет работать с чем то длиннее ТЗ в полстраницы. Ни с кремниевой нейронкой, ни с белковой. Я склонен считать, что ЛЛМки в целом уже достигли уровня человека в разработке, а вместе с этим начали воспроизводить все человеческие косяки.
Без внятного ТЗ результат ХЗ
Что вы Клод попросите реализовать, то он и реализует. Как попросите так и сделает. Из самых лучших побужденией. Откуда ей знать какой будет у вашего проекта трафик? Фрилансеру из Бангладеш хотя бы бюджет известен.
Теория разбитых окон в разработке
ЛЛМка честно пытается воспроизвести что-то похожее на то, что у вас было. При этом если было до этого 10-летнее легаси, то она по умолчанию его и выдаст. Если вы хотите, чтобы было написано иначе сформулируйте правила соответствующим образом.
Ваши договорённости с вашим джуном известны только вам и вашему джуну.
Новый джун, что нейросетевой, что мясной их знать не будет. Тем более новый джун с новым наставником. Просите его это корректно документировать и вносить в соответствующие правила. Контекст проекта не должен состоять из одного кода.
Приказ понял? Повтори как понял!
Просите нейронку объяснять как работает имеющийся код, проверяйте её объяснения, записывайте и импортируйте в AGENTS.md наиболее важные вещи. Проверяйте её объяснения, сверяйте её структуры и API.
Делегирование бывает разных уровней
Освоив работу с LLM-кой последовательно, начинайте делегировать задачи более высокоуровневым агентам. При этом вы сможете меньше проверять код из под LLM-ки, например код внутри методов (Да, бл..дь! Его всё ещё надо было поглядывать), и чуть больше успевать. Но придётся лучше формализовать уже порядок работы с нейро-джунами со стороны нейро-сениоров.
То что кто-то ошибается в 10% случае, когда вы ошибаетесь в 3%, не делает его хуже
В такой ситации значительно важнее, что его 10% и ваши 3% могут не пересекаться.
Скрытый текст
Есть универсальный алгоритм решения задач и проблем, любую задачу можно декомпозировать, это можно повторять рекурсивно, затем для каждой задачи можно написать её точное определение в виде тестов, когда для каждой микро задачи будет готово решение можно провести обратно - композицию. Даже сегодня любой ИИ агент запросто способен разбить любое ТЗ на задачи, причём так, чтобы максимизировать параллелизм в разработке, то есть планировать задачи таким образом, чтобы множество других агентов или людей могли работать над задачами параллельно, не пересекаясь по функционалу, что минимизирует конфликты.
Таким образом благодаря этому алгоритму можно добиться того, что любое ограничение контекста больше не является проблемой. А учитывая с какой скоростью ИИ агенты закрывают задачи, сколько бы потом не было багов - это можно компенсировать добавлением тестов после каждого бага, чтобы он никогда не повторялся и в итоге система будет стремиться к полному покрытию тестами и легко может разрабатываться используя в том числе исключительно AI агентов.
можно декомпозировать, можно повторять, можно написать, будет готово решение, агент способен, можно добиться, можно компенсировать, может разрабатываться.
вот бы прочитать статью о том, как все это декомпозировано, повторено, написано, решено, добыто, компенсировано и разработано?
Я это сделал при работе над своим agentic framework, решая тяжелую задачу в одиночку, которую пара команд не осилила за два последних года из-за плохой организации работы как раз вот в этой области: планирование, декомпозиция, гапсы и проч.
чтобы не быть голословным
Планирую за этот месяц закончить эту задачу. Без агента было бы непосильно, просто из-за количества времени на этап планирования, которое менджмент просто не одобрил бы. Но для того, чтобы его так использовать, я два месяца разрабатывал как раз фреймворк, просто plain usage какой угодно "дорогой" модели/агента это просто токены жечь.
Не уверен, что хочу писать об этом целую статью, поскольку проект фрейморка в стадии PoC, хочу убедиться, еще на паре "тяжелых" бизнес-задач, что это работает (мультиагентность и оркестрация в том числе), до промышленного внедрения еще полгода или больше. Просто поверьте, что подход разбития ТЗ на задачи агентом работает, хорошо грумит гапсы между легаси ТЗ и тем, что уже ушло дальше (бизнес-фичи поменяли codebase), хорошо раскладывает горизонтальные и вертикальные имплементации. Выявляет параллелизацию. Умеет оркестрировать.
Я не профи в использовании agentic swe, возможно, можно уйти и дальше. В чатиках пишут про бесконечные циклы решения задач от первого промпта/ТЗ до деплоя. Может, и врут, но заманчиво.
любую задачу можно декомпозировать, это можно повторять рекурсивно, затем для каждой задачи можно написать её точное определение в виде тестов
Один из ключевых тезисов теории систем и системного анализа говорит о том, что свойства системы не равны сумме свойств всех её частей.
Проводя декомпозицию задачи по уровням, вы теряете контекст применения, из-за чего, конечная подзадача, на глубине нескольких подуровней, может не отражать или отражать неверно/избыточно первоначальную часть задачи.
Проблемы которые будут:
Часто - избыточная алгоритмическая сложность (квадратичный/экспоненциальный алгоритм вместо линейного например)
Редко - избыточное переусложнение кода в результате расширения одз (нужна функция решающая частные случаи, при сегментации задачи остаётся подзадача решающая все случаи)
А если делать это с помощью llm - появляется ещё одна вероятность - придумывание контекста (когда режешь задачу на подзадачи и даёшь llm узкий сценарий, она будет реализовывать решение в контексте наиболее вероятного в выборке обучения, что может сильно не совпадать с реальностью)
Так что на бумаге звучит отлично, на практике имеет ограниченную применимость
Эмерджентность не доказана!
Пока что успехи моделирования говорят о том, что свойства систем полностью определяются свойствами ее составляющих.
Проблема только в мощности моделирующей машины. Т.е. в конечном счете в энергии.
Если нет математического доказательства, это не значит, что нет самой проблемы. Есть масса примеров от поведения молекул, до колоний насекомых.
Можно конечно упереться и сказать что мы недостаточно моделируем, но на примере простых задач - например знаменитой задачи трёх тел - можно заметить что далеко не всё мы можем смоделировать как минимум сейчас. Значит в практическом случае для нас все равно она есть.
В программах ситуация когда каждый блок в тестах ведёт себя корректно, а система в целом нет, не новость - когда речь про сложные асинхронные системы.
Каким образом, работа с агентами может улучшить написание следующего кода: у нас есть аудио с речью, речь как мы знаем можно разделить на форманты F0-F5 (для примера ограничимся F5)? Мы хотим написать функцию, которая сдвинет указанную форманты на некоторую частоту. Вот правильный код на основе praat, который ни одна LLM не смогла написать:
Скрытый текст
def change_formants_shifts(signal, sr, formant_shifts, formants=None):
"""
Изменяет частоты формант в аудиофайле на фиксированное значение для каждой форманты.
"""
if formants:
frequencies = formants["frequencies"]
times = formants["voiced_times"]
else:
frequencies, times, _, _ = formant_frequencies(signal, sr)
# Определение функции для получения новой частоты форманты
def get_new_formant_freq(original_freq, formant_num):
if original_freq <= 0:
return original_freq
return original_freq + formant_shifts[formant_num]
# Создание нового объекта звука для изменённого звука
modified_signal = np.copy(signal)
# Итерация по каждому временно́му шагу и изменение частот формант
for t_idx, t in enumerate(times):
for i in range(5): # Форманты F1 до F5
original_freq = frequencies[i][t_idx]
if original_freq > 0: # Убедиться, что частота форманты действительна
new_freq = get_new_formant_freq(original_freq, i)
# Расчёт коэффициента ресэмплинга
resample_ratio = new_freq / original_freq
# Регулировка значений звука вокруг частоты форманты
segment_start = max(0, int(t * sr) - int(sr / 50))
segment_end = min(len(signal), int(t * sr) + int(sr / 50))
segment = signal[segment_start:segment_end]
# Ресэмплинг сегмента для изменения частоты форманты
resampled_segment = resample(segment, int(len(segment) * resample_ratio))
# Регулировка длины для соответствия оригинальному сегменту
if len(resampled_segment) > (segment_end - segment_start):
resampled_segment = resampled_segment[:segment_end - segment_start]
elif len(resampled_segment) < (segment_end - segment_start):
pad_width = (segment_end - segment_start) - len(resampled_segment)
resampled_segment = np.pad(resampled_segment, (0, pad_width), mode='constant')
# Добавление ресэмплированного сегмента к изменённым значениям
modified_signal[segment_start:segment_end] = resampled_segment
modified_signal = np.clip(modified_signal, -1, 1)
return modified_signal, srВы хоть обложитесь сотней агентов, они не сделают.
Напишут они код? Да напишут.
Будет он делать то что нужно? Нет.
Могут в этом помочь отладчики или консоль или что-то еще? Нет.
Знают ли модели о проблемах, если начать разбирать их код? Конкретно о каждой проблеме они всегда что-то напишут.
Могут ли они сразу перечислить все возможно проблемы, чтобы учесть их? Нет.
То есть на выходе вы получите выполняющийся без ошибок код, который будет делать что угодно, только не то что нужно.
Данный пример с аудио, просто один из таких примеров. В реальной работе их множество, когда мы не можете простым выполнением кода, проверить правильный результат или нет. И как уже написал, даже если ваш агент будет заранее рассуждать о возможных проблемах, задачу это не решит и вероятней всего на выходе вы получите "фарш".
Вероятно с этим смогут справиться будущие модели, которые добавят на вход и на выход аудио модальность. Так или иначе для таких конкретных моментов можно использовать подход human in a loop, то есть настроить с машиной взаимодействие так, что единственное на что она будет отвлекать внимание человека, это на обратную связь по аудио файлам. С другой стороны в некоторых случаях, вероятно уже есть модели с аудио модальностью и можно это решить сочетая несколько нейросетей вместе, что само по себе тоже задача, которую вероятно AI агент мог бы решить, если бы у него возникли бы сложности подсказки от человека помогли бы.
Замените пример proxy3d на любую другую не стандартную (не обязательно даже узкоспецилизированную) задачу и получите тот же результат. Так и будем надеятся на абстрактные будущие модели каждый раз?
Даже я, как человек никогда не занимавшийся rocket science, за свою карьеру делал достаточно задач, которые нейронки не осилят (или умножат время разработки на x2 и более) просто потому что это задачи редко встречающияся за пределами определенных отраслей и в случаях, близким к 100%, эти задачи не имеют готовых не-коммерческих решений на которых можно было бы обучить LLM.
Я понимаю, что большая часть работы программистов в конторах среднего звена - это перекладывание json'ов и круды и вот с этим LLM уже научились более-менее прилично справляться (и то за бездумные коммиты LLM кода я бы бил бы по рукам разрабу на код ревью), но есть и другие задачи.
Простите, я из чистого любопытства, не обладая никаким знанием предметной области, и посредственным знанием (прикладным) Python, попытался что-то получить исходя из поставленной задачи "Мы хотим написать функцию, которая сдвинет указанную форманты на некоторую частоту".
Код совершенная чушь или как утверждает модель -- "другой подход"?
shift_formant_in_lpc
import numpy as np
def shift_formant_in_lpc(lpc_coeffs, sample_rate, formant_index, shift_hz):
"""
Сдвигает указанную форманту на заданное количество герц.
formant_index: 0 = F1, 1 = F2, и т.д.
shift_hz: на сколько сдвинуть (положительное — вверх, отрицательное — вниз)
Возвращает новые LPC-коэффициенты.
"""
# Находим корни полинома
roots = np.roots(lpc_coeffs)
# Переводим в полярные координаты (частота, magnitude)
angles = np.angle(roots)
magnitudes = np.abs(roots)
freqs = angles * sample_rate / (2 * np.pi)
# Находим пары сопряжённых корней с положительной частотой
# и сортируем по частоте, чтобы найти нужную форманту
positive_mask = freqs > 0
positive_indices = np.where(positive_mask)[0]
# Сортируем индексы по частоте
sorted_indices = positive_indices[np.argsort(freqs[positive_indices])]
# Фильтруем: оставляем только "настоящие" форманты (90-5000 Hz)
formant_indices = []
for idx in sorted_indices:
f = freqs[idx]
bw = -np.log(magnitudes[idx]) * sample_rate / np.pi
if 90 < f < 5000 and bw < 500:
formant_indices.append(idx)
# Проверяем, есть ли нужная форманта
if formant_index >= len(formant_indices):
# Форманта не найдена — возвращаем без изменений
return lpc_coeffs
# Индекс корня, который будем сдвигать
root_idx = formant_indices[formant_index]
# Текущая частота и новая частота
old_freq = freqs[root_idx]
new_freq = old_freq + shift_hz
# Ограничиваем разумным диапазоном
new_freq = np.clip(new_freq, 90, sample_rate / 2 - 100)
# Новый угол
new_angle = new_freq * 2 * np.pi / sample_rate
# Модифицируем корень (сохраняем magnitude, меняем угол)
roots[root_idx] = magnitudes[root_idx] * np.exp(1j * new_angle)
# Находим и модифицируем сопряжённый корень
# (он имеет ту же magnitude и противоположный угол)
conjugate_idx = np.where(
(np.abs(magnitudes - magnitudes[root_idx]) < 1e-10) &
(np.abs(angles + angles[root_idx]) < 1e-10)
)[0]
if len(conjugate_idx) > 0:
roots[conjugate_idx[0]] = magnitudes[root_idx] * np.exp(-1j * new_angle)
# Пересчитываем коэффициенты из корней
new_coeffs = np.real(np.poly(roots))
# Нормализуем (первый коэффициент должен быть 1)
new_coeffs = new_coeffs / new_coeffs[0]
return new_coeffs
def shift_formant_all_frames(lpc_coeffs_all, sample_rate, formant_index, shift_hz):
"""
Применяет сдвиг форманты ко всем фреймам.
"""
new_lpc = np.zeros_like(lpc_coeffs_all)
for i, lpc in enumerate(lpc_coeffs_all):
new_lpc[i] = shift_formant_in_lpc(lpc, sample_rate, formant_index, shift_hz)
return new_lpc
# Использование
audio, sr = load_audio("input.wav")
frames, hop = split_into_frames(audio, sr)
lpc_coeffs, gains = analyze_frames(frames, lpc_order=16)
# Сдвигаем F2 на +200 Hz
new_lpc_coeffs = shift_formant_all_frames(lpc_coeffs, sr, formant_index=1, shift_hz=200)
# Проверяем, что форманты изменились
old_formants, _ = extract_formants_from_frames(lpc_coeffs, sr)
new_formants, _ = extract_formants_from_frames(new_lpc_coeffs, sr)
print(f"F2 до: {np.nanmean(old_formants[:, 1]):.0f} Hz")
print(f"F2 после: {np.nanmean(new_formants[:, 1]):.0f} Hz")объяснение моделью разницы между сгенерированным кодом и вашей функцией
уже достаточно поздно, поэтому я просто отложил в сторону этап глубокого изучения предметки, чтобы что-то понимать, это буквально один проход за сеанс. Но если бы передо мной стояла такая задача, то я решал бы ее как раз через создание базы решения, в том числе грумил бы вопрос относительно валидации результатов, вроде создания синтетических тестов.
Отдельно хочу указать, что я не ставил себе задачу опровержения вашего комментария, просто любопытно, где же все таки границы решения задач: в подготовке самой модели или в наших собственных руках.
-- модель opus 4.5.
Что вам не нужно: имена переменных, форматирование, комментарии для людей или паттерны, придуманные только для того, чтобы пощадить ваш мозг.
Ну-ну. То есть, вы утверждаете, что ИИ не нужен читабельный код? Вы серьезно думаете, что если у вас код без комметариев, без нормальной архитектуры, с одной гигантской функцией main и переменными с именами a,b,c, без строгой типизации и с размазанной по всех кодовой базе логикой, то нейронка сможет так же легко читать и поддерживать этот код? Sweet summer child...
А ещё я бы не разделял код на "оптимизированный для LLM" и "оптимизированный для человека". LLM обучили работать с кодом так же, как это делает человек. Они так же юзают grep для навигации по кодовой базе, запускают тесты, линтер, читают логи, анализируют коды ошибок. Если кодовая база написана хорошо, есть тесты, правильное разбиение на модули, логирование, правильная обработка ошибок - то поддерживать это будет легко как человеку, так и нейронке. Если код изначально написан плохо - то плохо будет для обоих. Но только опытный разработчик может решить, что пора всё отрефакторить, переписать. Выкинуть старую архитектуру на определённом этапе и сделать хорошо. А нейронка будет вставлять костыли, фиксить одно, и в то же время ломая другое.
Для ИИ нужен так же как и для людей хороший CI/CD который гарантирует что код читается и нужного качества. И самое критичное скажем для Claude Code CLI агента, это то, что если CI/CD требует чтобы каждый файл с кодом или документацией будет меньше 1500 строк, то у Claude Code CLI будет намного больше шансов прочитать его целиком, а следовательно полностью осознанно сделать правки. Плюс такое ограничение вынуждает агента разделять код на файлы. В общем все те лучшие практики программирования которые накапливали люди за это время на текущий момент применимы так же, и иногда даже критичнее для AI чем для людей.
Качество кода - это несколько более широкое понятие, чем просто разбить код на небольшие читаемые куски. Это какая же CI/CD система способна например определить, что код нарушает принцип open/close, или что там захардкожено что-то что захардкожено быть не должно, или что библиотека даёт вызывающему возможность парой вызовов апи привести данные в неконсистентное состояние? Пусть этот код даже разбит на вылизанные куски и снабжён мильоном .md документов?
То есть, вы утверждаете, что ИИ не нужен читабельный код?
Да , так и есть.
Мне Claude легко и влет парсит и правит любые XML, JSON файлы (ну те что мне попадались), идеально разбирается в их структуре. Не требуя никаких подсказок.
Но да, иногда делает осечки.
Но это такая милая мелочь и одновременно спасительная.
Потому что не делай он их, нам бы всем уже пришел конец.
Ну, если вы работаете джейсоноукладчиком – тогда AI вполне может справиться со всеми вашими задачами.
Claude легко и влет парсит и правит любые XML, JSON файлы (ну те что мне попадались)
У вас сравнение сломанное. XML\JSON декларируют только структуру, но не логику. А анализ исполняемого кода это не только парсинг синтаксического дерева.
Вы серьезно думаете, что если у вас код без комметариев, без нормальной архитектуры, с одной гигантской функцией main и переменными с именами a,b,c, без строгой типизации и с размазанной по всех кодовой базе логикой, то нейронка сможет так же легко читать и поддерживать этот код?
На самом деле - читать вполне сможет, правда. Ради интереса скармливал исходники Java игр и приложений, восстановленные из class-файлов. То есть это как раз огромные функции, с кучей переменных aa, bb, cc, с проблемами типизации (в Java int a и double a - разные переменные и в выводе такого - дофига). Сходу человеком это не читается вообще никак.
И съев эту мешанину она радостно говорит - вот, функция aB() это обработка выстрела, а переменная bC хранит здоровье, а вот в c и d - хранятся координаты блоков уровня.
Можно даже в бесплатном DeepSeek попробовать, реально работает.
А я благодаря Claude Opus и Claude Sonnet больше не пишу код руками, не требуется его теперь и читать тоже, так как всегда можно задавать вопросы AI агенту. Уже более 6 месяцев я разрабатываю своего бота программиста используя Claude модели, и всё это время все свои 500+ репозиториев в open-source и в общественном достоянии поддерживаю используя этого самого бота-программиста, который мне Claude и помог написать. По сути для меня это означает первый реальный шаг к автоматизации автоматизации. Ну и конечно сам бот-программист тоже с открытым кодом и в общественном достоянии. Для меня это первое ПО, которое способно писать себя самостоятельно. Так что я очень доволен что появился ИИ и из программиста я больше трансформировался в тех-лида, который теперь принимает Pull Requests от ИИ и людей. А моя разработка фактически в одиночку помогла мне догнать и обогнать продукты крупных корпораций.
Если раньше я нанимал программистов, чтобы они помогали мне разрабатывать опенсорс проекты, то теперь такой мысли вообще не возникает. AI-агент, который интегрирован с GitHub фактически заменяет человека программиста в привычном мне flow - создать issue - сделать ревью Pull Request и смержить. Теперь я могу больше сфокусироваться на планировании и архитектуре, и поддерживать куда больше опенсорсных проектов фактически в одиночку. Поэтому с приходом ИИ ощущается что за $200 подписки Claude MAX я нанял себе целую команду разработки, которая готова работать по запросу 24/7. И разрабатывает код в десятки раз быстрее чем многие junior и middle программисты. Я может быть плохой senior программист, но за 25 лет программирования я не научился писать код вручную быстрее и точнее чем это делают AI агенты. Зато если их тех-лидить получается эффективнее на порядки.
Господи, избавь нас от лукавого!
больше не пишу код руками, не требуется его теперь и читать тоже
Но, думаю, Вы знаете язык программирования, на котором Claude пишет код, на довольно хорошем уровне, поэтому у Вас есть возможность ставить задачи максимально понятным языком и со всеми подробностями, необходимыми для решения задачи. Значит ли это, что программисты пока могут спать спокойно или в будущем всё-таки знание языка будет не нужно?
все свои 500+ репозиториев в open-source
Даже страшно представить что там.
Зачем представлять, если можно посмотреть, а потом написать действительно полезный комментарий?
Так ссылку на эти 500+ репозиториев ни в комментарии, ни в профиле автора нет. Покажет - почитаем)
В профиле есть, в разделе "Контактная информация".
P.S. Ниже даже кто-то пишет, что не смог найти ссылку на оригинал статьи, это печально.
Показываю:
Картинка похожа на beam search
Картинка похожа на x в степени N, где x == 2 только в лучшем случае. Типичный комбинаторный взрыв.
Как и ожидалось - какая-то непонятная никому не нужная хрень. Зачем на такое спускать дохулиард токенов - уму не постижиму, такую дичь можно генератором случайных чисел нагенерировать.
ну вот у меня тогда более понятная (и нужная мне) хрень — парольный менеджер, ибо меня не устраивал bitwarden и его экосистема + хотелось аналог hashiecorp vault, но для "маленьких". Сейчас активно всё причёсываю, думал потом может более статью написать, не про очередной "смотрите как LLM умеет", а про сам пет проджект, может кому-то тоже пригодится.
● podman-zann.service
Loaded: loaded (/etc/systemd/system/podman-zann.service; enabled; preset: ignored)
Active: active (running) since Tue 2025-12-30 13:06:39 +04; 1 week 5 days ago
Invocation: 5f9c57b203a8480382f0a639cb9808ea
Main PID: 1722521 (conmon)
IP: 10.1K in, 5.9K out
IO: 0B read, 180K written
Tasks: 1 (limit: 18808)
Memory: 608K (peak: 11.6M)
CPU: 326ms
CGroup: /system.slice/podman-zann.service
Я прям читал и плакал. Реальность несколько более прозаична: тривиальные изменения с 5 попытки, а сложные - проще самому сделать, чем объяснить ему, что не так.
Смотря у кого :)
Пока что я вижу что более 80% pull requests завершаются мержем, а не закрытием :) Как получилось, что для тебя наш бот-программист не сработал для меня пока загадка.
Сомнительный повод для гордости. Вы же понимаете что стандарты качества у набора рандомных репо на гитхабе заметно ниже, чем в любой адекватной компании?
С вероятностью, приближающейся к 100%, почти все репозитории куда приняли эти PR сделаны в стиле "хуяк-хуяк и в продакшен" людьми, прямо скажем, не очень высокой квалификации. Гордиться что у вас люди непонятной квалификации принимают любой PR пока он вроде бы что-то делает и вроде бы даже правильно - ну такое себе.
Взял первый попавшийся смерженный не совсем нетривиальный реквест: https://github.com/konard/telegram-bot/pull/8
Там два изменения: одно по теме задачи, а второе, внезапно, - какие-то адовые костыли с подавлением варнинга, вместо того, чтобы закинуть пр с фиксом в gramJS, который эти варнинги и вызывает.
del
все свои 500+ репозиториев в open‑source
«У нас есть такие приборы!..
Но мы вам про них не расскажем их не покажем.»
Показывал в комментарии выше https://habr.com/ru/articles/984026/comments/#comment_29367614. Рассказать могу - могу ответить на вопросы.
А вообще бот-программист, которого я делаю с его же собственной помощью вот тут: https://github.com/link-assistant/hive-mind
Похоже, мы работаем в одном направлении, но с абсолютно разными принципами
На мой взгляд ваша архитектура отражающая принцип, который я называю "перпетуум мобиле" имеет существенную уязвимость для промышленного решения
здесь
Скорее даже ваша архитектура противоречит вашему же манифесту в bio:
Формулировка проблемы. Этот шаг предполагает полное понимание и определение проблемы, которую необходимо решить
Issue не является "формулировкой". У вас полностью пропущен этап анализа. Либо задачи не энтерпрайз уровня, либо вы его создаете в каком-то другом флоу и формируете как issue. Мы приходим в PR непонятно с чем. С подброшенной монеткой, а не с "полным пониманием проблемы, которую необходимо решить". Может, закрыли баг с кнопкой, а может, десяток других, которые на тестах не видны, создали. Я как инженер зачем такой PR смотреть буду? Чтобы помянуть незлым тихим словом постановщика задачи?
Пост вроде должен был быть про Claude Opus 4.5 а в итоге "как я сгенерировал несколько простых приложений" - вау - вроде это можно было делать и раньше с помощью no-code платформ или для продвинутых взять из ГХ
Если это перевод, а это перевод, то почему нет ссылки на оригинал?
Почему-то все преимущества AI оказываются "я с 0 сгенерил апп", а под этот шумок предполагается что он он также хорошо работает с многолетней кодовой базой, где куча зависимостей, ничего не случайно и ничего просто так не поменять.
Я уже много раз сталкивался с тем, что ИИ просто чуть переписывает функции
Чес говоря, только с такими кодовым базами и работаю. Которым по 10-15 лет и больше.
Claude нормально с ними справляется.
Да, он получив 3000 файлов , отказывается прямо все просматривать. Но по частям за полчасика , вычищает любые конюшни. С одной среды разработки в другую переводит. Убирает старую систему логов и меняет на новую. Вычищает весь мертвый код. Пишет полную доку по архитектуре и т.д. и т.п.
Пример бы
Вероятно, у вас нет кода "так исторически сложилось, никто не знает почему именно так", где эксперты ушли и ответить не смогут, а легаси код всё же работает и вы не сможете доказать что ничего не сломается при переделке
Убирает старую систему логов и меняет на новую. Вычищает весь мертвый код. Пишет полную доку по архитектуре и т.д.
Сложность ниже среднего
На работе нужно было сделать специфичный конвертор файлов. Гемини мне сделал скрипт, но GUI не смог сделать. OPUS сделал с первой попытки, 1600 строк кода. В программировании я понимаю только как установить Python и всякие библиотеки.
А я вот сегодня долго мучал и встроенного гитхабовского агента в vscode, и cursor. Нужно было сделать простой тест "с подковырочкой". Скачать тестовый файл через socks5 прокси со "спуфленным" SNI/Host хидером. (оп-па, задачка простая, но не самая типовая). Задолбался, и сделал ручками.
Вот так и будет с любым ИИ проектом. Он будет блестеть и сверкать пока он простой, но как только возникает первая запердыка в нем - проще все с нуля переписать.
Но как без знания программирования прочесть сгенерированный код? Или запускаете так? Ведь ни один набор тестов не гарантирует корректность.
Если мы переживаем о безопасности - можно запустить в виртуальной машине. И проверять конечно же запуском, а как иначе проверять? :) И если ручной тест показывает что юнит тесты проверяют не то - значит нужно юнит тесты поправить и со всем этим Opus справляется, ему нужно только дать эту самую обратную связь о требованиях - как должно быть и как быть не должно. Тоже самое как с обычным программированием - написал код-черновик-гипотезу - запустил - проверил - понял что не то, понял почему и как не то - исправил - перезапустил.
А потом появляется статья вот почему я не читаю статьи
Работал у нас в компании один чел. Вроде аналитик. Писал ТЗ. Вот только по такому ТЗ вообще ничего сделать было нельзя. Просто бред с умными словами и терминами использующимися в компании. Интересно было бы посмотреть, что там нагенерил бы ИИ? 🤔😁
Ага, z@lупу на воротник вы себе навайбкодите и на ней повеситесь… если не дано вам код писать, то сидите и невыеживайтесь, вайбкодинг и нейронки вам не помогут
В кабинете стоматолога висела мудрая фраза: "Можно чистить не все зубы, а только те, с которыми жалко расставаться". Для меня она идеально иллюстрирует отношение к ИИ. Нелюбимые проекты, мелкие скриптики, одноразовую всякую фигню - можно делать через ИИ. Ввел задачку, пока там кофе попил - смотришь, и может быть он ее вполне себе решил.
Но любимый проект, важный, отдавать в руки ИИ....
Все что делает ИИ - удешевляет. ИИ пишет код дешевле, чем настоящий программист. И я одно время думал - есть же столько дешевых хостингов типа Hetzner, амазон по сравнению с ними - стоит очень дорого. Но потом понял, что удобства от него - ценнее. И видя биллинг в проекте, по которому работаю, я понимаю, что хостинг там - смешная доля расходов фирмы. Зачем ее сокращать? Удобство, которое дает AWS перекрывает возможную экономию на спичках и потенциальные расходы от проблем с хостингом (коих у AWS бывает меньше, хоть и тоже бывало).
Вот точно так же, если у вас есть важный проект, вы не будете экономить на "зато почти бесплатном" ИИ программисте. Проще платить мясному. Он хотя бы сможет сказать "у вас тут весь проект на прежней версии ...., она через полгода будет уже неподдерживаемая, надо все переделать".
А еще, все что делает программист на самом деле - это уточнение ТЗ. От смутного пожелания заказчика "хочу сайт по продаже холодильников, синенький" доводит до уровня конкретных строчек кода. По шагам. (На первом шаге, например, дополняя в голове подзадачей - "нужна интеграция с платежной системой"). И все это должно быть в согласии с тем, что хочет заказчик (ну и с тем, как это хочет реализовать программист). ИИ по сути сделает то же самое. Что-то у вас может быть спросит, что-то догадается по умолчанию. Но важно понимать, что вся его работа - это НЕ исполнение ТЗ, а его дописывание, уточнение, дополнение. Поэтому, все, что он там "сам догадался" - придется перепроверять. Ну или сказать "ааа, и тааак сойдеет!".
Все примеры которые привел автор не показательны.
На самом деле, в использовании агентов упираешься всегда в две проблемы:
1. Агент плохо пишет логически сложный код и нужно все равно подобные проблемы разгребать самому.
2. Если все становится слишком сложно и нужно изобрести подходящие концепции и новый уровень абстракции, чтобы все упростить, AI не осилит эту задачу хотя-бы потому что он не знает всего о проекте и задаче, и вы не сможете ему вообще все рассказать.
Вторая задача представляется пока нерешаемой.
Первая - кто знает. Во всяком случае Opus здесь очевидно лучше чем Sonet.
Прямо только что в этом убедился. У меня в коде была система для подготовки переводов слов: весь словарь языка делится на 200 порций, слово попадает в порцию в зависимости от его хэша. Дальше, каждая порцияи переводится одним промптом к AI, ответ которого сохраняется в базе под ключом, который вычисляется из хэша всего ответа.
Я спросил у Sonet что будет, если из словаря удалится одно слово и он радостно "оптимизировал" мой код, удалив хэш ответа из ключа ответа AI, "чтобы избежать ненужной перегенерации ответа при удалении одного слова". Ему не пришло в голову подумать что случится, если слово добавлено а не удалено.
Тогда я откатил и повторил тот же запрос у Opus. Он не нашел примемлемых способов оптимизации и оставил в этой части все как есть.
Т.е. выглядит так, что он умнее в плане сложной логики.
Может ли ИИ создать что-то нетривиальное и поддерживаемое? Или это будет что-то типа прототипа, чтобы показать бизнесу идею, а потом выкинуть и переписать нормально?
Перестаньте пытаться понять, какое место вы займёте в мире, где ИИ стоит на первом месте. Ответ всё тот же, что и всегда: создавайте вещи. Теперь вы можете делать это быстрее, чем когда-либо могли себе представить.
Крутой совет. Осталось выяснить, как и кому их продавать в мире, где точно такие же вещи может "навайбкодить" каждый второй - и дело в шляпе!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Claude Opus 4.5 и конец привычной разработки