llm in brownfield
May. 30th, 2026 09:54 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
amaraoЕщё одно наблюдение про llm в brownfield code (старом коде, который много и долго писали и который сложный, как противоположность "greenfield", который "пойти напиши новое с нуля").
Вещь, которую современные LLM практически не могут и не делают, это удаление старого. Если в ходе работы над фичей процесс поменялся и образовались старые хвосты, то в пределах файла LLM может догадаться удалить старый код. Выше уровнем - крайне редко. Удалить рецепт (just) target (make), playbook (ansible), workflow (GH actions) и т.д. - это что-то за пределами мыслительного процесса LLM.
Что приводит к паталогическим противоречиям между оснастками. Если изначально фича была "сделай всё", а потом оказалось, что так нельзя и надо порезать фичу на три подфичи, у каждой свой глубокий внутренний мир, то LLM не способна осознать, что "сделай всё" фича мертва и все её рецепты (подготовиться к фиче, проверить фичу, почистить после тестирования фичи) надо выжечь огнём и забыть. И когда LLM начинает работать над фича3, то оно же не называется "фича3" в этот момент, это просто одна из составляющих "фича", и LLM вынуждена думать про "фича", и про слова, которые там написаны, и код, который (unsound) пытается делать то, что не может сосуществовать само с собой (это и есть причина смерти "фича" как самостоятельной сущности).
Это всё отравляет контекст и заставляет LLM идти на дикие выкрутасы.
Но это первая часть драмы.
Если человек deeply in loop, он это заметит, и либо сам сотрёт, либо скажет стереть. Но это только если человек глубоко понимает все этапы существования/тестирования фичи. В какой-то момент он начинает упускать ВСЕ этапы (потому что какая-то часть происходящего была принята как "работает и ладно"), и фрагментик этого проползает и мутирует.
Текущее состояние LLM: программирует на 5+. Планирует/реализует архитектуру на 3 (что сравнимо с многими senior architects), software engineering - not even close.
Вот эта тонкая граница, то место, где надо остановиться с LLM. Я не знаю, как её решают грандиозные метры погоняния LLM на больших проектах, но в рамках моего узенького опыта работы с ними, это то место, которое не может быть выгружено в LLM. Software engineering остаётся на человеке. Как только оно сползает в LLM, это slippery slop, который может быть спасён только (человеко-управляемым) микросервисным подходом (вон он, наконец-таки, в полный рост сияет - coding monkey сейчас AI, а человек это всё аккуратно декомпозирует), либо code janitor'ом, который всё лишнее из кода порежет, чтобы LLM было проще программировать.
... А впереди поезда должен идти человек с флагом и предупреждать всех о том, что едет поезд, чтобы лошадей убрали с дороги.
Вещь, которую современные LLM практически не могут и не делают, это удаление старого. Если в ходе работы над фичей процесс поменялся и образовались старые хвосты, то в пределах файла LLM может догадаться удалить старый код. Выше уровнем - крайне редко. Удалить рецепт (just) target (make), playbook (ansible), workflow (GH actions) и т.д. - это что-то за пределами мыслительного процесса LLM.
Что приводит к паталогическим противоречиям между оснастками. Если изначально фича была "сделай всё", а потом оказалось, что так нельзя и надо порезать фичу на три подфичи, у каждой свой глубокий внутренний мир, то LLM не способна осознать, что "сделай всё" фича мертва и все её рецепты (подготовиться к фиче, проверить фичу, почистить после тестирования фичи) надо выжечь огнём и забыть. И когда LLM начинает работать над фича3, то оно же не называется "фича3" в этот момент, это просто одна из составляющих "фича", и LLM вынуждена думать про "фича", и про слова, которые там написаны, и код, который (unsound) пытается делать то, что не может сосуществовать само с собой (это и есть причина смерти "фича" как самостоятельной сущности).
Это всё отравляет контекст и заставляет LLM идти на дикие выкрутасы.
Но это первая часть драмы.
Если человек deeply in loop, он это заметит, и либо сам сотрёт, либо скажет стереть. Но это только если человек глубоко понимает все этапы существования/тестирования фичи. В какой-то момент он начинает упускать ВСЕ этапы (потому что какая-то часть происходящего была принята как "работает и ладно"), и фрагментик этого проползает и мутирует.
Текущее состояние LLM: программирует на 5+. Планирует/реализует архитектуру на 3 (что сравнимо с многими senior architects), software engineering - not even close.
Вот эта тонкая граница, то место, где надо остановиться с LLM. Я не знаю, как её решают грандиозные метры погоняния LLM на больших проектах, но в рамках моего узенького опыта работы с ними, это то место, которое не может быть выгружено в LLM. Software engineering остаётся на человеке. Как только оно сползает в LLM, это slippery slop, который может быть спасён только (человеко-управляемым) микросервисным подходом (вон он, наконец-таки, в полный рост сияет - coding monkey сейчас AI, а человек это всё аккуратно декомпозирует), либо code janitor'ом, который всё лишнее из кода порежет, чтобы LLM было проще программировать.
... А впереди поезда должен идти человек с флагом и предупреждать всех о том, что едет поезд, чтобы лошадей убрали с дороги.