The post has been translated automatically. Original language: Russian
Agile is often perceived as a set of organizational practices: short sprints, daily meetings, backlog, retrospectives, and task boards.
But these elements alone do not explain why Agile has changed software development.
The main change wasn't in task management. Agile has reduced the distance between an idea, its implementation and practical verification.
The team formulates an assumption, creates a working result, receives feedback and clarifies its understanding of the product. After that, the next cycle begins.
Therefore, Agile can be considered not only as a development method, but also as a way to continuously develop knowledge about the system.
Today, when a new participant has appeared in the development — artificial intelligence - this idea gets a natural continuation.
Before Agile: first understand everything, then implement
The traditional approach to development assumed that the system could be described in sufficient detail in advance.
First, the requirements are defined. Then the architecture is designed. After that, the program is created, tested, and the finished product is released.
This sequence looks logical if we assume that the task is already clear.
In practice, much of the knowledge appears only during implementation.
The user can formulate the problem precisely, but does not always know which solution will be convenient. A developer can build a convincing architecture, but discover its limitations only after the appearance of working code. The team can coordinate the requirements and then see that the actual usage scenarios differ from the initial assumptions.
Software development is not a simple fulfillment of a pre-determined plan.
This is a research process.
We are creating a system and at the same time we are learning what it should be like.
What has Agile changed?
Agile recognized that changing understanding is not an exception or a planning error. This is a natural part of development.
Instead of trying to describe the entire product in advance, the team creates a small working part of the system and checks it as early as possible.
The cycle looks simple:
assumption → implementation → working result → feedback → new understanding
After each cycle, not only the program changes. The team's view of the product is changing.
It becomes clearer:
- what function does the user really need?;
- which solution turned out to be too difficult;
- what restrictions were not taken into account;
- what concepts did the team members understand differently?;
- which part of the architecture needs to be changed;
- which initial idea should be abandoned.
Therefore, a working product in Agile is important not only as a result.
It is a way of testing understanding.
The code shows whether the idea has been turned into a working system. The user's reaction indicates whether the system solves the real problem. The tests show whether the program's behavior matches expectations. Refactoring helps to bring the code structure in line with a new understanding of the subject area.
Agile is about feedback management
Kent Beck, Ward Cunningham, Martin Fowler, Allister Cockburn and other participants in the formation of the Agile approach proposed different methods, but they are based on a common principle: feedback should occur as early as possible.
Extreme Programming has brought feedback directly to the code creation process.
Developers are constantly running tests, integrating changes, discussing solutions, and improving the program structure. The error is detected not after a few months, but in the current work cycle.
Scrum has organized regular feedback at the product and team levels.
The iteration ends with a working result that can be shown, verified, and discussed. The team analyzes not only the product, but also its own way of working.
Other Agile approaches organize the process in different ways, but maintain the same focus: reduce the time between an action and receiving information about its consequences.
The shorter this period, the faster the team corrects erroneous assumptions.
Programming as the development of system theory
Back in the 1980s, Peter Naur proposed considering programming as a theory building.
In his opinion, the developer creates not only the source code. In the process, he develops an internal theory of the system.:
- what task does it solve;
- why are its parts arranged that way?;
- What alternatives were considered?;
- What are the fundamental limitations?;
- what changes are allowed?;
- why is the obvious solution not suitable at first glance?
The code expresses part of this theory, but does not contain it in its entirety.
Two developers can read the source code equally well, but understand the purpose of the system differently. One knows why a certain architectural constraint is necessary. The other sees only the current implementation and can remove this limitation as seemingly redundant.
Agile helps to develop system theory by iteration.
Each cycle adds a new understanding. The team tests the theory with practice and corrects it.
In this sense, Agile combines two activities that were previously tried to separate.:
- creating a program;
- gaining knowledge about what the program should be.
New member of the development team
The advent of ChatGPT and other large language models is changing the programming process itself.
The developer can discuss requirements, architecture, and possible implementations with the AI. AI can decompose a task, suggest several options, write code, prepare tests, find a contradiction, or explain the consequences of a change.
Previously, such intelligent feedback was limited by the availability of other team members.
To discuss the decision, it was necessary to find a colleague, explain the context to him and wait for a response. Therefore, many decisions were made by the developer independently and remained only in his head.
Now the dialogue can happen all the time.
The developer formulates the idea and immediately gets questions, alternatives, and possible implementation. He checks the result, corrects the initial assumption, and starts the next cycle.
It turns out to be an even shorter form of Agile iteration.:
intention → discussion with AI → implementation → verification → refinement
In this process, ChatGPT becomes more than just a code generator. He performs the role of a permanent intellectual partner.
But here comes a new limitation.
ChatGPT knows programming, but doesn't know the specific product.
The language model has broad general knowledge. She is familiar with programming languages, architectural patterns, databases, network protocols, and testing approaches.
However, it cannot automatically know the internal theory of a particular system.
For example:
- why did the team abandon the standard file system?;
- why should a certain module have only one stream recipient?;
- what is the meaning of the term used in this particular project?;
- which architectural idea has already been considered and rejected;
- which requirements are temporary and which are fundamental;
- which decision is considered valid after the last discussion.
This information can be distributed between code, tasks, messages, meeting minutes, and participant memory.
ChatGPT can read some of these materials, but a large amount of information does not mean that there is a holistic understanding.
To fully participate in AI development, you need more than just access to documents. He needs an up-to-date product theory.
When the technological stack cannot be kept in mind
This problem is especially noticeable when creating not a separate application, but an associated technology stack.
For example, we are developing several systems that depend on each other at once.:
- Memora8 — native 32-bit processor architecture;
- Reganta microOS is an operating system designed specifically for this architecture.;
- Sekura JS is a system programming language for developing programs and modules of this stack.
Each level affects the others.
The decision made in the processor architecture determines the memory device, the data exchange mechanism, and the capabilities of the operating system. The Reganta microOS flow model affects the contracts of the system modules. The capabilities of Sekura JS must meet the limitations processor and operating system.
At the same time, the stack itself is constantly evolving.
They're changing:
- memory model;
- flow device;
- message format;
- responsibility of the core;
- boundaries of firmware and system modules;
- page ownership rules;
- contracts between software and hardware layers;
- definitions of basic architectural concepts.
It is difficult even for its author to keep this whole system of connections in his head.
A person remembers the general idea, but may forget the exact reason for the decision made a few months ago. The new idea may look right, although it has already been considered and rejected due to limitations at another stack level.
For AI, this task is even more difficult.
ChatGPT can analyze a single solution well, but in each new dialog it gets only a part of the overall context. He may not know that the definition has already changed, use a rejected model, or propose a solution that contradicts the rule from another component.
For example, a change in Reganta microOS may look local, but it actually affects:
- Memora8 processor commands;
- memory access model;
- Sekura JS execution rules;
- arrangement of system modules;
- the exchange format between the kernel and the program.
Without an explicit knowledge system, both humans and AI are forced to rebuild these connections each time.
Therefore, the more complex and original the technological stack, the less you can rely solely on the author's memory, the history of correspondence, or the AI's ability to independently assemble a complete picture.
We need a general theory of the system that can be read, tested, modified, and used in each subsequent development cycle.
From discussion history to current knowledge
Let's imagine that the team spent several days discussing an architectural solution.
There are dozens of suggestions, objections, and intermediate options in the correspondence. Some ideas were rejected. Others have changed. In the end, the team came to a decision.
The whole discussion is important for the history of the project.
But for the next development cycle, first of all, you need to know its actual result.:
- what decision has been made;
- why is it accepted;
- where it is applied;
- What restrictions must be followed?;
- which alternatives were rejected.
This knowledge differs from both the documentation and the archive of correspondence.
This is the current theory of the system.
This is exactly the task we are solving at Sekura Noda.
Instead of accumulating an unlimited number of texts, the expert formulates small canonical articles. Each article captures one accepted idea, rule, concept, or architectural solution.
For example, individual articles may define:
- size and purpose of the Memora8 memory page;
- the page ownership model;
- Reganta microOS flow device;
- responsibility of the core;
- the contract between the operating system and the firmware;
- rules for the execution of Sekura JS modules.
The articles form a related model.
The operating system level decision can be related to a limitation of the processor architecture and a language rule. When you change one part, it becomes clear which other knowledge needs to be reviewed.
Each article can have a status, an author, a scope, and connections to other knowledge. A person can read it directly, and ChatGPT can be used as a context for analysis and implementation.
Sekura Noda does not replace Agile in this model and does not manage sprints.
It preserves the results of Agile cycles in a form that is accessible to both humans and AI.
A natural extension of Agile
Agile arose as a response to the too long cycle between planning and verifying the result.
ChatGPT reduces the next gap — between the developer's question and the intelligent feedback.
Sekura Noda solves another part of the problem — it preserves the acquired understanding so that the next cycle begins not with restoring the context, but with the actual product theory.
The extended loop looks like this:
intention → ChatGPT analysis → implementation → verification → new understanding → canon update → next cycle
The person remains the central participant in the process.
He defines the goal, evaluates the options, makes a decision and is responsible for the result.
ChatGPT helps to reason and implement.
Sekura Noda preserves the accepted knowledge and provides it to the participants of the following cycles.
Using the example of Memora8, Reganta microOS, and Sekura JS, this means that ChatGPT does not receive a random selection of old discussions, but an up-to-date model of the entire stack.
It can take into account not only the current task, but also related solutions from other levels of the system.
This is not a rejection of Agile principles. On the contrary, it is their continuation.:
- Feedback is getting faster;
- interaction happens all the time;
- A working result remains a verification method.;
- changes are perceived as a natural acquisition of new knowledge.;
- a common understanding becomes available not only to the team, but also to the AI.;
- a complex technological stack develops as a single related theory.
From an Agile team to a human and AI team
The first stage of Agile development was related to the interaction of people around a working product.
The next stage is related to the inclusion of AI in this process.
But it's not enough to teach the model how to write code. It is necessary to provide her with an understanding of a particular system: its goals, concepts, limitations, connections, and decisions.
Without this, AI remains an external consultant who gets to know the project anew each time.
With the general theory of the product, he can become a full-fledged participant in the continuous development cycle.
Agile has shown that it is impossible to definitively formulate requirements once and then simply implement them.
The product develops along with the understanding of the team.
Complex projects like Memora8, Reganta microOS, and Sekura JS are developing not just one product, but a whole system of interdependent technologies. Neither a human nor an AI can keep it entirely in their head.
Sekura Noda and ChatGPT allow you to turn this limitation into a manageable process.
A person develops a plan and makes decisions. ChatGPT helps you analyze and implement. Sekura Noda retains the general theory of the technology stack.
Now, together with the program, explicit, connected and verifiable knowledge about the system is being developed — accessible to both humans and artificial intelligence.
Agile часто воспринимают как набор организационных практик: короткие спринты, ежедневные встречи, backlog, ретроспективы и доски с задачами.
Но сами по себе эти элементы не объясняют, почему Agile изменил разработку программного обеспечения.
Главное изменение произошло не в управлении задачами. Agile сократил расстояние между идеей, её реализацией и проверкой на практике.
Команда формулирует предположение, создаёт работающий результат, получает обратную связь и уточняет своё понимание продукта. После этого начинается следующий цикл.
Поэтому Agile можно рассматривать не только как метод разработки, но и как способ непрерывного развития знания о системе.
Сегодня, когда в разработке появился новый участник — искусственный интеллект, — эта идея получает естественное продолжение.
До Agile: сначала понять всё, потом реализовать
Традиционный подход к разработке предполагал, что систему можно заранее достаточно подробно описать.
Сначала определяются требования. Затем проектируется архитектура. После этого создаётся программа, проводится тестирование и выпускается готовый продукт.
Такая последовательность выглядит логично, если считать, что задача уже понятна.
На практике значительная часть знания появляется только во время реализации.
Пользователь может точно сформулировать проблему, но не всегда знает, какое решение окажется удобным. Разработчик может построить убедительную архитектуру, но обнаружить её ограничения только после появления работающего кода. Команда может согласовать требования, а затем увидеть, что реальные сценарии использования отличаются от первоначальных предположений.
Разработка программного обеспечения оказывается не простым исполнением заранее известного плана.
Это процесс исследования.
Мы создаём систему и одновременно узнаём, какой она должна быть.
Что изменил Agile
Agile признал, что изменение понимания — не исключение и не ошибка планирования. Это естественная часть разработки.
Вместо попытки заранее описать весь продукт команда создаёт небольшую работающую часть системы и как можно раньше проверяет её.
Цикл выглядит просто:
предположение → реализация → работающий результат → обратная связь → новое понимание
После каждого цикла меняется не только программа. Меняется представление команды о продукте.
Становится понятнее:
- какая функция действительно нужна пользователю;
- какое решение оказалось слишком сложным;
- какие ограничения не были учтены;
- какие понятия участники команды понимали по-разному;
- какую часть архитектуры необходимо изменить;
- от какой первоначальной идеи следует отказаться.
Поэтому работающий продукт в Agile важен не только как результат.
Он является способом проверки понимания.
Код показывает, удалось ли превратить идею в действующую систему. Пользовательская реакция показывает, решает ли система реальную задачу. Тесты показывают, совпадает ли поведение программы с ожиданиями. Рефакторинг помогает привести структуру кода в соответствие с новым пониманием предметной области.
Agile — это управление обратной связью
Кент Бек, Уорд Каннингем, Мартин Фаулер, Эллистер Кокберн и другие участники формирования Agile-подхода предлагали разные методы, но в их основе можно увидеть общий принцип: обратная связь должна происходить как можно раньше.
Extreme Programming приблизило обратную связь непосредственно к процессу создания кода.
Разработчики постоянно запускают тесты, интегрируют изменения, обсуждают решения и улучшают структуру программы. Ошибка обнаруживается не через несколько месяцев, а в текущем цикле работы.
Scrum организовал регулярную обратную связь на уровне продукта и команды.
Итерация завершается работающим результатом, который можно показать, проверить и обсудить. Команда анализирует не только продукт, но и собственный способ работы.
Другие Agile-подходы по-разному организуют процесс, но сохраняют ту же направленность: уменьшить время между действием и получением информации о его последствиях.
Чем короче этот промежуток, тем быстрее команда исправляет ошибочные предположения.
Программирование как развитие теории системы
Питер Наур ещё в 1980-х годах предложил рассматривать программирование как построение теории.
По его мысли, разработчик создаёт не только исходный код. В процессе работы у него формируется внутренняя теория системы:
- какую задачу она решает;
- почему её части устроены именно так;
- какие альтернативы рассматривались;
- какие ограничения являются принципиальными;
- какие изменения допустимы;
- почему очевидное на первый взгляд решение не подходит.
Код выражает часть этой теории, но не содержит её целиком.
Два разработчика могут одинаково хорошо читать исходный код, но по-разному понимать назначение системы. Один знает, почему определённое архитектурное ограничение необходимо. Другой видит только текущую реализацию и может удалить это ограничение как кажущееся избыточным.
Agile помогает развивать теорию системы итерациями.
Каждый цикл добавляет новое понимание. Команда проверяет теорию практикой и корректирует её.
В этом смысле Agile объединяет две деятельности, которые раньше пытались разделить:
- создание программы;
- получение знания о том, какой должна быть программа.
Новый участник разработки
Появление ChatGPT и других больших языковых моделей изменяет сам процесс программирования.
Разработчик может обсуждать с AI требования, архитектуру и возможные реализации. AI может декомпозировать задачу, предложить несколько вариантов, написать код, подготовить тесты, найти противоречие или объяснить последствия изменения.
Раньше подобная интеллектуальная обратная связь была ограничена доступностью других участников команды.
Чтобы обсудить решение, нужно было найти коллегу, объяснить ему контекст и дождаться ответа. Поэтому многие решения принимались разработчиком самостоятельно и оставались только в его голове.
Теперь диалог может происходить постоянно.
Разработчик формулирует идею и сразу получает вопросы, альтернативы и возможную реализацию. Он проверяет результат, корректирует исходное предположение и запускает следующий цикл.
Получается ещё более короткая форма Agile-итерации:
намерение → обсуждение с AI → реализация → проверка → уточнение
ChatGPT в таком процессе становится не просто генератором кода. Он выполняет роль постоянного интеллектуального партнёра.
Но здесь возникает новое ограничение.
ChatGPT знает программирование, но не знает конкретный продукт
Языковая модель обладает широкими общими знаниями. Она знакома с языками программирования, архитектурными шаблонами, базами данных, сетевыми протоколами и подходами к тестированию.
Однако она не может автоматически знать внутреннюю теорию конкретной системы.
Например:
- почему команда отказалась от стандартной файловой системы;
- почему определённый модуль должен иметь только одного получателя потока;
- какое значение термина принято именно в этом проекте;
- какая архитектурная идея уже рассматривалась и была отвергнута;
- какие требования являются временными, а какие принципиальными;
- какое решение считается действующим после последнего обсуждения.
Эта информация может быть распределена между кодом, задачами, сообщениями, протоколами встреч и памятью участников.
ChatGPT может прочитать часть этих материалов, но большой объём информации ещё не означает наличия целостного понимания.
Для полноценного участия в разработке AI нужен не просто доступ к документам. Ему необходима актуальная теория продукта.
Когда технологический стек невозможно удерживать в голове
Эта проблема особенно заметна при создании не отдельного приложения, а связанного технологического стека.
Например, мы разрабатываем сразу несколько зависимых друг от друга систем:
- Memora8 — собственную 32-битную процессорную архитектуру;
- Reganta microOS — операционную систему, спроектированную специально для этой архитектуры;
- Sekura JS — язык системного программирования для разработки программ и модулей этого стека.
Каждый уровень влияет на остальные.
Решение, принятое в архитектуре процессора, определяет устройство памяти, механизм обмена данными и возможности операционной системы. Модель потоков Reganta microOS влияет на контракты системных модулей. Возможности Sekura JS должны соответствовать ограничениям процессора и операционной системы.
При этом сам стек постоянно развивается.
Меняются:
- модель памяти;
- устройство потоков;
- формат сообщений;
- ответственность ядра;
- границы firmware и системных модулей;
- правила владения страницами;
- контракты между программным и аппаратным уровнями;
- определения основных архитектурных понятий.
Удерживать всю эту систему связей в голове сложно даже её автору.
Человек помнит общий замысел, но может забыть точную причину решения, принятого несколько месяцев назад. Новая идея может выглядеть правильной, хотя она уже рассматривалась и была отвергнута из-за ограничения на другом уровне стека.
Для AI эта задача ещё сложнее.
ChatGPT может хорошо анализировать отдельное решение, но в каждом новом диалоге получает только часть общего контекста. Он может не знать, что определение уже изменилось, использовать отвергнутую модель или предложить решение, противоречащее правилу из другого компонента.
Например, изменение в Reganta microOS может выглядеть локальным, но на самом деле затрагивать:
- команды процессора Memora8;
- модель доступа к памяти;
- правила исполнения Sekura JS;
- устройство системных модулей;
- формат обмена между ядром и программой.
Без явной системы знаний и человек, и AI вынуждены каждый раз восстанавливать эти связи заново.
Поэтому чем сложнее и оригинальнее технологический стек, тем меньше можно рассчитывать только на память автора, историю переписки или способность AI самостоятельно собрать целостную картину.
Нужна общая теория системы, которую можно читать, проверять, изменять и использовать в каждом следующем цикле разработки.
От истории обсуждений к действующему знанию
Представим, что команда несколько дней обсуждала архитектурное решение.
В переписке есть десятки предложений, возражений и промежуточных вариантов. Некоторые идеи были отвергнуты. Другие изменились. В конце команда пришла к одному решению.
Для истории проекта важна вся дискуссия.
Но для следующего цикла разработки прежде всего нужно знать её актуальный результат:
- какое решение принято;
- почему оно принято;
- где оно применяется;
- какие ограничения необходимо соблюдать;
- какие альтернативы были отклонены.
Такое знание отличается и от документации, и от архива переписки.
Это действующая теория системы.
Именно эту задачу мы решаем в Sekura Noda.
Вместо накопления неограниченного количества текстов эксперт формулирует небольшие канонические статьи. Каждая статья фиксирует одну принятую идею, правило, понятие или архитектурное решение.
Например, отдельные статьи могут определять:
- размер и назначение страницы памяти Memora8;
- модель владения страницами;
- устройство потоков Reganta microOS;
- ответственность ядра;
- контракт между операционной системой и firmware;
- правила исполнения модулей Sekura JS.
Статьи образуют связанную модель.
Решение уровня операционной системы можно связать с ограничением процессорной архитектуры и правилом языка. При изменении одной части становится видно, какие другие знания необходимо пересмотреть.
Каждая статья может иметь статус, автора, область применения и связи с другими знаниями. Человек может прочитать её напрямую, а ChatGPT — использовать как контекст при анализе и реализации.
Sekura Noda в этой модели не заменяет Agile и не управляет спринтами.
Она сохраняет результат Agile-циклов в форме, доступной и людям, и AI.
Естественное продолжение Agile
Agile возник как ответ на слишком длинный цикл между планированием и проверкой результата.
ChatGPT сокращает следующий промежуток — между вопросом разработчика и интеллектуальной обратной связью.
Sekura Noda решает ещё одну часть задачи — сохраняет полученное понимание, чтобы следующий цикл начинался не с восстановления контекста, а с актуальной теории продукта.
Расширенный цикл выглядит так:
намерение → анализ с ChatGPT → реализация → проверка → новое понимание → обновление канона → следующий цикл
Человек остаётся центральным участником процесса.
Он определяет цель, оценивает варианты, принимает решение и отвечает за результат.
ChatGPT помогает рассуждать и реализовывать.
Sekura Noda сохраняет принятые знания и предоставляет их участникам следующих циклов.
На примере Memora8, Reganta microOS и Sekura JS это означает, что ChatGPT получает не случайную подборку старых обсуждений, а актуальную модель всего стека.
Он может учитывать не только текущую задачу, но и связанные с ней решения других уровней системы.
Это не отказ от принципов Agile. Напротив, это их продолжение:
- обратная связь становится быстрее;
- взаимодействие происходит постоянно;
- работающий результат остаётся способом проверки;
- изменения воспринимаются как естественное получение нового знания;
- общее понимание становится доступно не только команде, но и AI;
- сложный технологический стек развивается как единая связанная теория.
От Agile-команды к команде человека и AI
Первый этап развития Agile был связан с взаимодействием людей вокруг работающего продукта.
Следующий этап связан с включением AI в этот процесс.
Но для этого недостаточно научить модель писать код. Необходимо предоставить ей понимание конкретной системы: её цели, понятия, ограничения, связи и принятые решения.
Без этого AI остаётся внешним консультантом, который каждый раз знакомится с проектом заново.
С общей теорией продукта он может стать полноценным участником непрерывного цикла разработки.
Agile показал, что невозможно однажды окончательно сформулировать требования и затем просто реализовать их.
Продукт развивается вместе с пониманием команды.
На сложных проектах вроде Memora8, Reganta microOS и Sekura JS развивается не один продукт, а целая система взаимозависимых технологий. Удерживать её целиком в голове не может ни человек, ни AI.
Sekura Noda и ChatGPT позволяют превратить это ограничение в управляемый процесс.
Человек развивает замысел и принимает решения. ChatGPT помогает анализировать и реализовывать. Sekura Noda сохраняет общую теорию технологического стека.
Теперь вместе с программой развивается явное, связанное и проверяемое знание о системе — доступное и человеку, и искусственному интеллекту.
Share
