Сообщение Re: ИИ/AI, давайте разбираться от 17.02.2026 10:32
Изменено 17.02.2026 10:51 L_G
Re: ИИ/AI, давайте разбираться
CEM>2. Идея -> [промты -> нечто] -> Код.
CEM>Тут [промты -> нечто] — это сколько-то итераций.
Верно, и это НЕЧТО в середине (а не назвать ли нам его ТехЗаданием??) должно стать предметом итеративной РАБОТЫ над ним.
И много преимуществ дала бы формализация языка для этого нечта: ведь генерирует его ИИ и человеку не нужно знать и уметь соблюдать все строгости этой формальности. Но человеку должно быть легко это нечто читать, в т.ч. потому, что оно на порядки короче/выразительнее, чем код на ЯП!
Тогда проблема "для общего понимания или конкретного исправления программисту нужно читать ТОННУ нагенерированного ИИ кода" заменяется более лёгкой —
"для понимания/исправления программисту нужно прочитать лишь формализованное ТЗ — и даже не исправлять его самому, а лишь ПОПРОСИТЬ ИИ это сделать!"
CEM>"ИИ нарисуй кота" — ИИ будет рисовать какого-то конкретного кота.
Т.е. в моём варианте ВСЁ то, что ИИ сам ДОДУМАЛ по этому краткому промпту до начала рисования — а это уже детальное ТЗ — он должен выложить человеку в текстовом виде (для ленивых — уже вместе с готовым котом, т.е. читать сгенеренное ТЗ придется только если в коте что-то не устроило.)
Естественно, такое ТЗ можно сохранить в VCS и его удобно сравнивать с предыдущими в текстовых diff-viewer'ах.
CEM>Тут [промты -> нечто] — это сколько-то итераций.
Верно, и это НЕЧТО в середине (а не назвать ли нам его ТехЗаданием??) должно стать предметом итеративной РАБОТЫ над ним.
И много преимуществ дала бы формализация языка для этого нечта: ведь генерирует его ИИ и человеку не нужно знать и уметь соблюдать все строгости этой формальности. Но человеку должно быть легко это нечто читать, в т.ч. потому, что оно на порядки короче/выразительнее, чем код на ЯП!
Тогда проблема "для общего понимания или конкретного исправления программисту нужно читать ТОННУ нагенерированного ИИ кода" заменяется более лёгкой —
"для понимания/исправления программисту нужно прочитать лишь формализованное ТЗ — и даже не исправлять его самому, а лишь ПОПРОСИТЬ ИИ это сделать!"
CEM>"ИИ нарисуй кота" — ИИ будет рисовать какого-то конкретного кота.
Т.е. в моём варианте ВСЁ то, что ИИ сам ДОДУМАЛ по этому краткому промпту до начала рисования — а это уже детальное ТЗ — он должен выложить человеку в текстовом виде (для ленивых — уже вместе с готовым котом, т.е. читать сгенеренное ТЗ придется только если в коте что-то не устроило.)
Естественно, такое ТЗ можно сохранить в VCS и его удобно сравнивать с предыдущими в текстовых diff-viewer'ах.
Re: ИИ/AI, давайте разбираться
CEM>2. Идея -> [промты -> нечто] -> Код.
CEM>Тут [промты -> нечто] — это сколько-то итераций.
Верно, и это НЕЧТО в середине (а не назвать ли нам его ТехЗаданием??) должно стать предметом итеративной РАБОТЫ над НИМ.
И много преимуществ дала бы формализация языка для этого нечта: ведь генерирует его ИИ и человеку не нужно знать и уметь соблюдать все строгости этой формальности. Но человеку должно быть легко это нечто читать, в т.ч. потому, что оно на порядки короче/выразительнее, чем код на ЯП!
А формальность хорошо способствует ОДНОЗНАЧНОСТИ соответствия "ТЗ -> программа (код на ЯП)".
Тогда проблема "для общего понимания или конкретного исправления программисту нужно читать ТОННУ нагенерированного ИИ кода" заменяется более лёгкой —
"для понимания/исправления программисту нужно прочитать лишь формализованное ТЗ — и даже не исправлять его самому, а лишь ПОПРОСИТЬ ИИ это сделать!"
CEM>"ИИ нарисуй кота" — ИИ будет рисовать какого-то конкретного кота.
Т.е. в моём варианте ВСЁ то, что ИИ сам ДОДУМАЛ по этому краткому промпту до начала рисования — а это уже детальное ТЗ — он должен выложить человеку в текстовом виде (для ленивых — уже вместе с готовым котом, т.е. читать сгенеренное ТЗ придется только если в коте что-то не устроило.)
Естественно, такое ТЗ можно сохранить в VCS и его удобно сравнивать с предыдущими в текстовых diff-viewer'ах.
CEM>Тут [промты -> нечто] — это сколько-то итераций.
Верно, и это НЕЧТО в середине (а не назвать ли нам его ТехЗаданием??) должно стать предметом итеративной РАБОТЫ над НИМ.
И много преимуществ дала бы формализация языка для этого нечта: ведь генерирует его ИИ и человеку не нужно знать и уметь соблюдать все строгости этой формальности. Но человеку должно быть легко это нечто читать, в т.ч. потому, что оно на порядки короче/выразительнее, чем код на ЯП!
А формальность хорошо способствует ОДНОЗНАЧНОСТИ соответствия "ТЗ -> программа (код на ЯП)".
Тогда проблема "для общего понимания или конкретного исправления программисту нужно читать ТОННУ нагенерированного ИИ кода" заменяется более лёгкой —
"для понимания/исправления программисту нужно прочитать лишь формализованное ТЗ — и даже не исправлять его самому, а лишь ПОПРОСИТЬ ИИ это сделать!"
CEM>"ИИ нарисуй кота" — ИИ будет рисовать какого-то конкретного кота.
Т.е. в моём варианте ВСЁ то, что ИИ сам ДОДУМАЛ по этому краткому промпту до начала рисования — а это уже детальное ТЗ — он должен выложить человеку в текстовом виде (для ленивых — уже вместе с готовым котом, т.е. читать сгенеренное ТЗ придется только если в коте что-то не устроило.)
Естественно, такое ТЗ можно сохранить в VCS и его удобно сравнивать с предыдущими в текстовых diff-viewer'ах.