The post has been translated automatically. Original language: Russian
Pair programming has long been perceived as one of the most unusual practices of Extreme Programming.
Two developers work on the same computer. One writes the code, the other watches, asks questions, notices errors and helps to keep the big picture. After a while, they switch roles.
At first glance, this approach seems ineffective. Why would two specialists do a job that technically can be done by one?
But the point of pair programming has never been to increase the speed of code typing.
Its value lay elsewhere: the development turned from a single production of text into a continuous dialogue about the system.
Today, this principle is naturally continued. A new participant has appeared next to the developer — artificial intelligence.
ChatGPT can discuss a task, suggest options, write code, create tests, look for contradictions, and explain the consequences of decisions. It is available almost constantly and is able to participate in short development cycles.
This does not mean that AI replaces the second developer. But the very principle of collaborative programming goes beyond the previous boundaries.
We are moving from pair programming to programming with AI.
The code was not the main result of the pair
Extreme Programming appeared as a response to the problems of development in the face of constant changes.
Kent Beck, Ward Cunningham, Ron Jeffries, and others in the movement suggested bringing feedback directly to the program creation process.
The tests must be run continuously. The changes should be integrated quickly. The architecture needs to be improved as understanding develops. Requirements should be checked with a working result, not just documents.
Pair programming has become a part of this system.
In a classic pair, one participant acts as the driver. He works with the code and solves a local problem. The second one acts as an observer or navigator. He follows the direction of the solution, notices the missing conditions and thinks about the next steps.
These roles are not important on their own. A constant transition between two levels of thinking is important.:
- What exactly are we writing now;
- Why do we write it this way?;
- does the solution match the overall architecture;
- Have we forgotten an important limitation?;
- is it possible to express the idea more simply;
- what will break after this change?;
- how to check the result.
A developer working alone also asks himself these questions. But he has to simultaneously maintain the local implementation and the general model of the system.
The dialog shares this burden.
One person concentrates on the current action. The second one helps not to lose the context.
Therefore, the result of pair programming is not only code. Participants form a common understanding of the system.
Ward Cunningham and the collective understanding of the Program
Ward Cunningham is known not only as one of the authors of the Agile Manifesto and the creator of the first wiki. His work is related to the idea that software develops through constant refinement of the common language of the team.
Developers should equally understand the basic concepts, module boundaries, and purpose of solutions.
If each participant builds their own internal model, the code gradually turns into a set of locally correct but poorly coordinated solutions.
Pair programming helps to synchronize these models.
When working together, developers are forced to explain to each other:
- What are they going to do;
- what problem is being solved;
- why choose a specific approach;
- what assumptions are used?;
- what consequences are expected.
An idea that cannot be explained to a partner is often not yet well understood by the author himself.
The explanation becomes part of the design.
That's why a good programming partner doesn't just check the syntax. It helps to make the reasoning explicit.
What has ChatGPT changed?
Before the advent of modern language models, constant dialogue about code was an expensive resource.
Another developer might be busy. He needed to explain the context. His competencies could relate to another part of the system. In a small team or a single author's project, there might not be a suitable interlocutor at all.
ChatGPT has made the intellectual dialogue almost continuous.
The developer can at any time:
- formulate a task;
- show a code snippet;
- ask to find weak points;
- check the architectural idea;
- get multiple implementation options;
- prepare the tests;
- to sort out the error;
- ask to explain the solution in other words;
- to compare the new approach with the existing constraints.
At the same time, AI is able to quickly change the level of consideration.
In one post, we discuss a specific feature. The following is the device of the module. Then we return to the architecture of the entire product or to the meaning of a single concept.
A new cycle of work is emerging:
intention → discussion → implementation → verification → clarification
It is similar to the short cycle of Extreme Programming, but it can be repeated much more often.
It is no longer necessary for a developer to bring an idea to completion on their own, and then show the result to colleagues. He can discuss an idea that has not yet been formed.
AI becomes a participant in the very process of thinking.
AI as a navigator
In pair programming, the navigator does not have to write every line. His task is to see what the driver might miss.
ChatGPT often performs a similar role.
The developer describes the intention:
I want to change the stream model so that each stream has one recipient.
AI can ask questions right away:
- how will the branching be organized?;
- who is responsible for creating a new thread;
- can one module read multiple streams?;
- how will the change affect the descriptors?;
- who owns the pages;
- how the termination of the stream will be handled.
Such issues are not a ready-made solution. They expand the analysis space.
The developer then refines the model. AI offers a data structure or pseudocode. The person checks the offer and rejects some of the assumptions. After that, a more accurate version appears.
Thus, AI helps to maintain the direction of reasoning while a person retains responsibility for architecture.
This is an important difference.
AI can offer a solution, but it does not automatically know which solution corresponds to the project's intent. He is able to convincingly implement an incorrect assumption.
Therefore, programming together with AI should not turn into handing over a task to a code generator.
This is a collaborative cycle in which a person defines the theory of a system, and AI helps to verify and implement it.
AI as a driver
Roles can change.
Sometimes a person formulates an architectural solution, and ChatGPT writes an implementation. In this case, the AI conditionally becomes the driver.
He creates:
- data structures;
- interfaces;
- functions;
- tests;
- error handling;
- migrations;
- comments;
- technical descriptions.
The person takes the navigator's position.
He checks:
- is the task understood correctly?;
- does the code match the architecture;
- are there any extra abstractions added?;
- are the restrictions being followed;
- has the meaning of the terms changed;
- are there enough tests;
- is it possible to accept the result?
This changes the usual organization of programming.
Previously, the developer first wrote the code, and then conducted its internal review.
Now he can first determine the direction, get the implementation from the AI and focus on analyzing the result.
However, this approach only works when a person is able to evaluate the created solution.
The transfer of AI typing does not negate engineering responsibility. On the contrary, the faster the code appears, the more important it becomes to be able to verify its compliance with the system.
Why is ChatGPT not an ordinary second developer?
The similarity to pair programming is useful, but it shouldn't hide the differences.
The person in the pair gradually accumulates a stable understanding of the project. He participates in previous discussions, remembers the reasons for the decisions and notices changes in the plan.
ChatGPT works differently.
He gets the context that available in the current interaction. Some of the past discussions may be missing. Some definitions may have changed. The old decision could have been reversed, but continued to be found in documents or code.
A model can reason very convincingly based on an incomplete picture.
She can:
- suggest an already rejected architecture;
- use the old definition;
- not noticing the limitation of another module;
- optimize the local part at the cost of violating the general concept;
- mix a hypothesis with a decision.;
- fill in the gap with a plausible but incorrect assumption.
An ordinary partner might say, "We already discussed this three months ago and rejected this option."
The AI will be able to do the same only if the result of the previous discussion is available to it explicitly.
Therefore, good prompta is not enough for joint programming with AI.
We need a shared project memory.
When one conversation is not enough
On a small application, part of the context can be transmitted in a message each time.
But this method quickly stops working as the system grows.
This is especially noticeable in our own technology stack.:
- Memora8 is a 32-bit processor architecture;
- Reganta microOS is a micro—operational system for this architecture;
- Sekura JS — a system programming language;
- Sekura Noda is a canonical knowledge management system.
In Memora8, processor commands, memory model, pages, banks, access windows, data ownership, and exchange between components must be taken into account simultaneously.
The Reganta microOS must meet the processor's limitations. Its model of threads, system modules, firmware, core, and inter-module exchange does not exist separately from Memora8.
Sekura JS, in turn, should provide an understandable programming model without hiding the fundamental properties of the architecture and operating system.
A local change can go through the entire stack.
For example, deciding how a module receives a data page may affect:
- hardware mechanisms of Memora8;
- responsibility of the Reganta core;
- the format of the stream descriptor;
- page ownership rules;
- module execution model;
- constructions of the Sekura JS language;
- compiler checks;
- tests and documentation.
It is difficult for a person to keep all this in working memory.
Even the author of the system can remember the general direction, but forget the exact wording of the rule or the reason for the old decision.
AI faces an even tougher limitation. He sees only the part of the painting that has been transferred to him.
Therefore, in a complex project, you cannot start working together every time with the words: "Now I will explain the whole architecture to you again."
This method does not scale.
From the common screen to the general theory
In classical pair programming, the overall context was created physically.
Two people were sitting in front of the same screen, looking at the same code and discussing one change. They saw the same state of the program.
When working with AI, a shared screen is not enough.
A person and a model need a general theory of the project:
- precise definitions;
- architectural decisions made;
- current restrictions;
- connections between components;
- rejected options;
- areas of responsibility;
- the status of each statement.
This theory should not exist only in long documentation or chat history.
The document can contain both old and new solutions. Correspondence preserves the path of reasoning, but does not always clearly show its outcome. The code demonstrates the implementation, but does not necessarily explain the reasons.
For the next development cycle, an up-to-date understanding result is needed.
That's why we're creating Sekura Noda.
Sekura Noda as the third member of the couple
At first glance, there are two people involved in programming along with AI:
- human;
- ChatGPT.
But in a complex system, a third element is needed — canonical knowledge of the project.
In Sekura Noda, the expert records small articles, each of which expresses one accepted idea.:
- definition;
- the rule;
- limitation;
- architectural solution;
- the contract;
- area of responsibility.
The article can be accepted, rejected, or left as a draft. It is linked to other articles and has a specific scope.
As a result, humans and AI don't just work with each other. They work with respect to the general theory of the system.
It turns out a new design:
- A person defines a goal and makes decisions.;
- ChatGPT helps you analyze and implement;
- Sekura Noda retains the current understanding of the project.
If the AI suggests a change to Reganta microOS, it can get the related Memora8 and Sekura JS rules.
If a decision is made, not only the code is updated. The new understanding is consolidated in the canon.
The next cycle begins with the updated system model.
A new cycle of collaborative programming
Classical pair programming can be represented as follows:
task → discussion → code → partner verification → general understanding
Programming with AI and Sekura Noda expands this cycle.:
human intention → canon acquisition → ChatGPT analysis → implementation → verification → decision-making → canon update
This cycle can occur at different levels.
At the function level
The person describes the required behavior. AI writes code and tests. The person checks the result.
At the module level
Interfaces, dependencies, and responsibilities are discussed. AI helps to compare the options and prepare the implementation.
At the architecture level
The AI analyzes the decision regarding the related canonical rules. The person accepts or rejects the change.
At the level of product theory
After gaining new knowledge, the canon itself changes: the concept is clarified, a restriction is added, or the relationship between the components is revised.
Thus, collaborative programming is no longer limited to code production.
It becomes a way to develop the system and knowledge about it.
Writing code faster is not enough
AI is really capable of dramatically speeding up the creation of program text.
But the speed of code generation alone does not determine the speed of product development.
The code may appear faster than a person can manage.:
- Check it out;
- Understand the consequences;
- coordinate changes;
- maintain architectural integrity;
- update the overall system model.
Then the acceleration turns into an accumulation of untested solutions.
The main limitation is not typing, but understanding management.
This fits well with the original ideas of Extreme Programming.
XP has never claimed that the goal of development is to write as much code as possible. It sought to reduce the cost of change through simplicity, testing, refactoring, communication, and short feedback.
AI enhances these capabilities, but at the same time increases the flow of possible solutions.
Therefore, the natural development of XP is not only to add a code generator.
We need to add a mechanism for saving and verifying common understanding.
What remains for a person
In programming, along with AI, the role of humans does not disappear. It's shifting.
It may take less time to create standard structures mechanically. More on what determines the integrity of the product:
- setting goals;
- choosing a direction;
- formation of concepts;
- defining constraints;
- evaluating options;
- checking the result;
- Taking responsibility;
- development of the general theory of the system.
A person is not responsible for every typed line, but for the meaning of the system being created.
This is not a reduction in the engineering role.
This is a transition from manual production to architecture, knowledge, and solution management.
For an experienced developer, AI becomes a way to test ideas faster.
For a beginner— it is a source of explanations and options that you still need to learn how to evaluate.
For the team, this is a new member who needs access to general project knowledge.
class="heading-2">A natural extension of Extreme ProgrammingPair programming has shown that code gets better when it is created in a dialog.
Collective ownership of the code has shown that the system should not exist only in the head of one author.
Continuous integration has reduced the time between a change and conflict detection.
Automated tests brought the verification closer to the moment of implementation.
Refactoring has made architecture development a constant activity.
ChatGPT naturally continues this line.:
- The dialog becomes available all the time;
- Feedback appears faster.;
- the options can be compared before implementation;
- The code and tests are created in one cycle.;
- the explanation becomes part of the development.
Sekura Noda adds the missing layer:
- accepted knowledge is preserved;
- The AI gets the relevant context;
- solutions are linked between the levels of the system;
- The next cycle does not begin with the restoration of the entire history.;
- the product theory develops along with the code.
Therefore, programming with AI is not a rejection of Extreme Programming.
This is the development of his main idea: the program is created through short feedback cycles and constant joint refinement of understanding.
Previously, two developers participated in this dialogue.
Now a person, ChatGPT, and the general canonical theory of the project can participate in it.
From a couple to a collaborative system
The name "pair programming" describes the way two people work.
But its real value has always been not in the number of participants.
It consisted of combining action and reflection, local implementation and the big picture, writing code and immediately testing the idea.
AI allows you to scale this principle.
The developer gets a permanent intellectual partner. ChatGPT gets the opportunity to participate not only in generation, but also in discussion. Sekura Noda provides both with up-to-date knowledge about the system.
On complex projects like Memora8, Reganta microOS, and Sekura JS, this model becomes more than just a convenience.
It becomes a way to maintain the integrity of the technology stack, which is already too large for one person's working memory and too specific for AI to reconstruct it from general knowledge.
The future of programming probably won't be that people stop writing code.
It will consist in the fact that development will finally become a collaborative thinking process.
A person sets the direction and makes decisions. AI accelerates analysis and implementation. Canonical knowledge preserves the theory of the system.
Pair programming has taught us to think about code together.
Now we're learning to think with AI.
Парное программирование долго воспринималось как одна из самых необычных практик Extreme Programming.
Два разработчика работают за одним компьютером. Один пишет код, второй наблюдает, задаёт вопросы, замечает ошибки и помогает удерживать общую картину. Через некоторое время они меняются ролями.
На первый взгляд такой подход кажется неэффективным. Зачем двум специалистам делать работу, которую технически может выполнить один?
Но смысл парного программирования никогда не сводился к увеличению скорости набора кода.
Его ценность заключалась в другом: разработка превращалась из одиночного производства текста в непрерывный диалог о системе.
Сегодня этот принцип получает естественное продолжение. Рядом с разработчиком появился новый участник — искусственный интеллект.
ChatGPT может обсуждать задачу, предлагать варианты, писать код, создавать тесты, искать противоречия и объяснять последствия решений. Он доступен почти постоянно и способен участвовать в коротких циклах разработки.
Это ещё не означает, что AI заменяет второго разработчика. Но сам принцип совместного программирования выходит за прежние границы.
Мы переходим от парного программирования к программированию вместе с AI.
Код был не главным результатом пары
Extreme Programming появилось как ответ на проблемы разработки в условиях постоянных изменений.
Кент Бек, Уорд Каннингем, Рон Джеффрис и другие участники движения предложили приблизить обратную связь непосредственно к процессу создания программы.
Тесты должны запускаться постоянно. Изменения должны быстро интегрироваться. Архитектуру нужно улучшать по мере развития понимания. Требования следует проверять работающим результатом, а не только документами.
Парное программирование стало частью этой системы.
В классической паре один участник выполняет роль водителя. Он работает с кодом и решает локальную задачу. Второй выполняет роль наблюдателя или навигатора. Он следит за направлением решения, замечает пропущенные условия и думает о следующих шагах.
Эти роли важны не сами по себе. Важен постоянный переход между двумя уровнями мышления:
- что именно мы пишем сейчас;
- почему мы пишем это именно так;
- соответствует ли решение общей архитектуре;
- не забыли ли мы важное ограничение;
- можно ли выразить идею проще;
- что сломается после этого изменения;
- как проверить результат.
Разработчик, работающий один, тоже задаёт себе эти вопросы. Но ему приходится одновременно удерживать локальную реализацию и общую модель системы.
Диалог разделяет эту нагрузку.
Один человек концентрируется на текущем действии. Второй помогает не потерять контекст.
Поэтому результатом парного программирования становится не только код. Участники формируют общее понимание системы.
Уорд Каннингем и коллективное понимание программы
Уорд Каннингем известен не только как один из авторов Agile Manifesto и создатель первой wiki. Его работы связаны с идеей, что программное обеспечение развивается через постоянное уточнение общего языка команды.
Разработчики должны одинаково понимать основные понятия, границы модулей и назначение решений.
Если каждый участник строит собственную внутреннюю модель, код постепенно превращается в набор локально правильных, но плохо согласованных решений.
Парное программирование помогает синхронизировать эти модели.
Во время совместной работы разработчики вынуждены объяснять друг другу:
- что они собираются сделать;
- какую проблему решают;
- почему выбирают конкретный подход;
- какие предположения используют;
- какие последствия ожидают.
Идея, которую невозможно объяснить партнёру, часто ещё недостаточно понята самим автором.
Объяснение становится частью проектирования.
Именно поэтому хороший партнёр по программированию не просто проверяет синтаксис. Он помогает сделать рассуждение явным.
Что изменил ChatGPT
До появления современных языковых моделей постоянный диалог о коде был дорогим ресурсом.
Другой разработчик мог быть занят. Ему нужно было объяснить контекст. Его компетенции могли относиться к другой части системы. В небольшой команде или проекте одного автора подходящего собеседника могло не быть вообще.
ChatGPT сделал интеллектуальный диалог почти непрерывным.
Разработчик может в любой момент:
- сформулировать задачу;
- показать фрагмент кода;
- попросить найти слабые места;
- проверить архитектурную идею;
- получить несколько вариантов реализации;
- подготовить тесты;
- разобрать ошибку;
- попросить объяснить решение другими словами;
- сопоставить новый подход с существующими ограничениями.
При этом AI способен быстро менять уровень рассмотрения.
В одном сообщении мы обсуждаем конкретную функцию. В следующем — устройство модуля. Затем возвращаемся к архитектуре всего продукта или к значению отдельного понятия.
Возникает новый цикл работы:
намерение → обсуждение → реализация → проверка → уточнение
Он похож на короткий цикл Extreme Programming, но может повторяться намного чаще.
Разработчику больше не обязательно сначала самостоятельно доводить идею до завершённого вида, а затем показывать результат коллегам. Он может обсуждать ещё не сформировавшуюся мысль.
AI становится участником самого процесса мышления.
AI как навигатор
В парном программировании навигатор не обязан писать каждую строку. Его задача — видеть то, что может пропустить водитель.
ChatGPT часто выполняет похожую роль.
Разработчик описывает намерение:
Я хочу изменить модель потоков так, чтобы у каждого потока был один получатель.
AI может сразу задать вопросы:
- как будет организовано ветвление;
- кто отвечает за создание нового потока;
- может ли один модуль читать несколько потоков;
- как изменение повлияет на дескрипторы;
- кто владеет страницами;
- как будет обрабатываться завершение потока.
Такие вопросы не являются готовым решением. Они расширяют пространство анализа.
Затем разработчик уточняет модель. AI предлагает структуру данных или псевдокод. Человек проверяет предложение и отвергает часть предположений. После этого появляется более точная версия.
Таким образом, AI помогает удерживать направление рассуждения, пока человек сохраняет ответственность за архитектуру.
Это важное различие.
AI может предложить решение, но не знает автоматически, какое решение соответствует замыслу проекта. Он способен убедительно реализовать неправильное предположение.
Поэтому программирование вместе с AI не должно превращаться в передачу задачи генератору кода.
Это совместный цикл, в котором человек определяет теорию системы, а AI помогает её проверять и воплощать.
AI как водитель
Роли могут меняться.
Иногда человек формулирует архитектурное решение, а ChatGPT пишет реализацию. В этом случае AI условно становится водителем.
Он создаёт:
- структуры данных;
- интерфейсы;
- функции;
- тесты;
- обработку ошибок;
- миграции;
- комментарии;
- технические описания.
Человек занимает позицию навигатора.
Он проверяет:
- правильно ли понята задача;
- соответствует ли код архитектуре;
- не добавлены ли лишние абстракции;
- соблюдаются ли ограничения;
- не изменился ли смысл терминов;
- достаточно ли тестов;
- можно ли принять результат.
Это меняет привычную организацию программирования.
Раньше разработчик сначала писал код, а затем проводил его внутреннюю проверку.
Теперь он может сначала определить направление, получить реализацию от AI и сосредоточиться на анализе результата.
Однако этот подход работает только тогда, когда человек способен оценить созданное решение.
Передача набора текста AI не отменяет инженерной ответственности. Наоборот, чем быстрее появляется код, тем важнее становится способность проверить его соответствие системе.
Почему ChatGPT не является обычным вторым разработчиком
Сходство с парным программированием полезно, но оно не должно скрывать различия.
Человек в паре постепенно накапливает устойчивое понимание проекта. Он участвует в предыдущих обсуждениях, помнит причины решений и замечает изменения в замысле.
ChatGPT работает иначе.
Он получает тот контекст, который доступен в текущем взаимодействии. Часть прошлых обсуждений может отсутствовать. Некоторые определения могли измениться. Старое решение могло быть отменено, но продолжать встречаться в документах или коде.
Модель может рассуждать очень убедительно, опираясь на неполную картину.
Она может:
- предложить уже отвергнутую архитектуру;
- использовать старое определение;
- не заметить ограничение другого модуля;
- оптимизировать локальную часть ценой нарушения общей концепции;
- смешать гипотезу с принятым решением;
- заполнить пробел правдоподобным, но неверным предположением.
Обычный партнёр может сказать: «Мы уже обсуждали это три месяца назад и отказались от такого варианта».
AI сможет сделать то же самое только в том случае, если результат предыдущего обсуждения доступен ему в явной форме.
Поэтому для совместного программирования с AI недостаточно хорошего промпта.
Нужна общая память проекта.
Когда одной переписки недостаточно
На небольшом приложении часть контекста можно каждый раз передавать в сообщении.
Но этот способ быстро перестаёт работать по мере роста системы.
Особенно это заметно в нашем собственном технологическом стеке:
- Memora8 — 32-битная процессорная архитектура;
- Reganta microOS — микрооперационная система для этой архитектуры;
- Sekura JS — язык системного программирования;
- Sekura Noda — система управления каноническим знанием.
В Memora8 нужно одновременно учитывать команды процессора, модель памяти, страницы, банки, окна доступа, владение данными и обмен между компонентами.
Reganta microOS должна соответствовать ограничениям процессора. Её модель потоков, системных модулей, firmware, ядра и межмодульного обмена не существует отдельно от Memora8.
Sekura JS, в свою очередь, должен предоставлять понятную модель программирования, не скрывая принципиальные свойства архитектуры и операционной системы.
Локальное изменение может пройти через весь стек.
Например, решение о том, как модуль получает страницу данных, может затронуть:
- аппаратные механизмы Memora8;
- ответственность ядра Reganta;
- формат дескриптора потока;
- правила владения страницей;
- модель исполнения модуля;
- конструкции языка Sekura JS;
- проверки компилятора;
- тесты и документацию.
Удерживать всё это в рабочей памяти сложно человеку.
Даже автор системы может помнить общее направление, но забыть точную формулировку правила или причину старого решения.
AI сталкивается с ещё более жёстким ограничением. Он видит только переданную ему часть картины.
Поэтому в сложном проекте нельзя каждый раз начинать совместную работу словами: «Сейчас я снова объясню тебе всю архитектуру».
Такой способ не масштабируется.
От общего экрана к общей теории
В классическом парном программировании общий контекст создавался физически.
Два человека сидели перед одним экраном, смотрели на один код и обсуждали одно изменение. Они видели одинаковое состояние программы.
При работе с AI общего экрана недостаточно.
Человеку и модели нужна общая теория проекта:
- точные определения;
- принятые архитектурные решения;
- действующие ограничения;
- связи между компонентами;
- отвергнутые варианты;
- области ответственности;
- статус каждого утверждения.
Эта теория не должна существовать только в длинной документации или истории чатов.
Документ может содержать одновременно старые и новые решения. Переписка сохраняет путь рассуждения, но не всегда ясно показывает его итог. Код демонстрирует реализацию, но не обязательно объясняет причины.
Для следующего цикла разработки нужен актуальный результат понимания.
Именно для этого мы создаём Sekura Noda.
Sekura Noda как третий участник пары
На первый взгляд в программировании вместе с AI участвуют двое:
- человек;
- ChatGPT.
Но в сложной системе нужен третий элемент — каноническое знание проекта.
В Sekura Noda эксперт фиксирует небольшие статьи, каждая из которых выражает одну принятую идею:
- определение;
- правило;
- ограничение;
- архитектурное решение;
- контракт;
- область ответственности.
Статья может быть принята, отклонена или оставлена как черновик. Она связана с другими статьями и имеет определённую область применения.
В результате человек и AI работают не только друг с другом. Они работают относительно общей теории системы.
Получается новая конструкция:
- человек определяет цель и принимает решения;
- ChatGPT помогает анализировать и реализовывать;
- Sekura Noda сохраняет действующее понимание проекта.
Если AI предлагает изменение в Reganta microOS, он может получить связанные правила Memora8 и Sekura JS.
Если решение принято, обновляется не только код. Новое понимание закрепляется в каноне.
Следующий цикл начинается уже с обновлённой модели системы.
Новый цикл совместного программирования
Классическое парное программирование можно представить так:
задача → обсуждение → код → проверка партнёром → общее понимание
Программирование с AI и Sekura Noda расширяет этот цикл:
намерение человека → получение канона → анализ с ChatGPT → реализация → проверка → принятие решения → обновление канона
Этот цикл может происходить на разных уровнях.
На уровне функции
Человек описывает требуемое поведение. AI пишет код и тесты. Человек проверяет результат.
На уровне модуля
Обсуждаются интерфейсы, зависимости и ответственность. AI помогает сравнить варианты и подготовить реализацию.
На уровне архитектуры
AI анализирует решение относительно связанных канонических правил. Человек принимает или отклоняет изменение.
На уровне теории продукта
После получения нового знания изменяется сам канон: уточняется понятие, добавляется ограничение или пересматривается связь между компонентами.
Таким образом, совместное программирование перестаёт ограничиваться производством кода.
Оно становится способом развития системы и знания о ней.
Быстрее писать код — недостаточно
AI действительно способен резко ускорить создание программного текста.
Но скорость генерации кода сама по себе не определяет скорость развития продукта.
Код может появляться быстрее, чем человек успевает:
- проверять его;
- понимать последствия;
- согласовывать изменения;
- сохранять архитектурную целостность;
- обновлять общую модель системы.
Тогда ускорение превращается в накопление непроверенных решений.
Главным ограничением становится не набор текста, а управление пониманием.
Это хорошо соответствует исходным идеям Extreme Programming.
XP никогда не утверждало, что задача разработки состоит в написании максимального количества кода. Оно стремилось уменьшить стоимость изменений через простоту, тестирование, рефакторинг, коммуникацию и короткую обратную связь.
AI усиливает эти возможности, но одновременно увеличивает поток возможных решений.
Поэтому естественное развитие XP заключается не только в том, чтобы добавить генератор кода.
Нужно добавить механизм сохранения и проверки общего понимания.
Что остаётся за человеком
В программировании вместе с AI роль человека не исчезает. Она смещается.
Меньше времени может уходить на механическое создание типовых конструкций. Больше — на то, что определяет целостность продукта:
- постановку цели;
- выбор направления;
- формирование понятий;
- определение ограничений;
- оценку вариантов;
- проверку результата;
- принятие ответственности;
- развитие общей теории системы.
Человек отвечает не за каждую набранную строку, а за смысл создаваемой системы.
Это не уменьшение инженерной роли.
Это переход от ручного производства к управлению архитектурой, знаниями и решениями.
Для опытного разработчика AI становится способом быстрее проверять идеи.
Для начинающего — источником объяснений и вариантов, которые всё равно необходимо научиться оценивать.
Для команды — новым участником, которому нужен доступ к общему проектному знанию.
Естественное продолжение Extreme Programming
Парное программирование показало, что код становится лучше, когда создаётся в диалоге.
Коллективное владение кодом показало, что система не должна существовать только в голове одного автора.
Непрерывная интеграция сократила время между изменением и обнаружением конфликта.
Автоматические тесты приблизили проверку к моменту реализации.
Рефакторинг сделал развитие архитектуры постоянной деятельностью.
ChatGPT естественно продолжает эту линию:
- диалог становится доступен постоянно;
- обратная связь появляется быстрее;
- варианты можно сравнивать до реализации;
- код и тесты создаются в одном цикле;
- объяснение становится частью разработки.
Sekura Noda добавляет недостающий слой:
- принятые знания сохраняются;
- AI получает актуальный контекст;
- решения связываются между уровнями системы;
- следующий цикл не начинается с восстановления всей истории;
- теория продукта развивается вместе с кодом.
Поэтому программирование вместе с AI — не отказ от Extreme Programming.
Это развитие его основной идеи: программа создаётся через короткие циклы обратной связи и постоянное совместное уточнение понимания.
Раньше в этом диалоге участвовали два разработчика.
Теперь в нём могут участвовать человек, ChatGPT и общая каноническая теория проекта.
От пары к системе сотрудничества
Название «парное программирование» описывает форму работы двух людей.
Но его настоящая ценность всегда заключалась не в числе участников.
Она заключалась в соединении действия и размышления, локальной реализации и общей картины, написания кода и немедленной проверки идеи.
AI позволяет масштабировать этот принцип.
Разработчик получает постоянного интеллектуального партнёра. ChatGPT получает возможность участвовать не только в генерации, но и в обсуждении. Sekura Noda предоставляет обоим актуальное знание о системе.
На сложных проектах вроде Memora8, Reganta microOS и Sekura JS такая модель становится не просто удобством.
Она становится способом удерживать целостность технологического стека, который уже слишком велик для рабочей памяти одного человека и слишком специфичен, чтобы AI мог восстановить его из общих знаний.
Будущее программирования, вероятно, будет состоять не в том, что человек перестанет писать код.
Оно будет состоять в том, что разработка окончательно станет совместным процессом мышления.
Человек задаёт направление и принимает решения. AI ускоряет анализ и реализацию. Каноническое знание сохраняет теорию системы.
Парное программирование научило нас думать о коде вместе.
Теперь мы учимся думать вместе с AI.
Share
