A reflection on AI-assisted development, intelligent agents and ethics
In pAIr coding the AI is the driver and the human is the navigator.
The human navigator should focus on the architectural design, the modular
structure, the strategic direction, problem anticipation, edge cases, and
systematic testing. And often to hold back the programming eagerness of the
AI driver, who wants to start generating code at full speed. The AI driver's
goal is to code at full speed, detect the errors pointed out by the human
navigator, and follow their instructions.
The speed of pAIr coding can be x50 of human pair programming. Unlike human
pair programming there is no role switching in pAIr coding. A x50 speed with
role switching would be brain draining for the human navigator because the AI
driver generates code at a dizzying speed. Then it is good for pAIr coding
projects that the human navigator mixes the project with other different
activities. My x50 speed measurement already includes the delays from this
recommended mix for the human navigator.
Without human fatigue the speed could be x100.
Vibe coding could be more relaxing for the human at the beginning
but could lead to human desperation at the end. Then vibe coding is for
small or one-use software, and pAIr coding for big and important software.
But if you lack experience in code development then vibe coding is
the only alternative since you cannot act as navigator.
Vibe coding is sprint-and-stall coding, very fast at the beginning
and the speed decreases with size, like programming in Excel: very fast for
tiny projects and a nightmare with the spreadsheet two years later. And unlike
vaporware, sprint-and-stall coding does leave something behind: twenty
interconnected Excel sheets that nobody dares to touch, just poking cells
to see if it still works.
pAIr coding is steady coding, slower than sprint-and-stall vibe coding
in the first week but faster in the next months, with the speed gap growing
each month.
Use vibe coding or pAIr coding depending on the size and criticality of the
project. The smaller and less critical, the more vibe coding. The bigger and
more critical, the more pAIr coding. But if you lack the experience and
technical knowledge to perform well your role as human navigator then use
vibe coding.
For example, when developing code for computing forensics tests, short and
quick code for tests that will most likely lead nowhere, use vibe coding.
But when one of those tests yields results, switch to pAIr coding so the
resulting code is clear, precise, objective and can be delivered to the
parties for their verification.
In vibe coding you can get results at the first prompt. In pAIr coding you
can spend the first day or two in interaction with the AI defining the
initial approach, requirements, specifications, definitions, modules, code
organisation, language selection, programming style samples, the way the AI
should write comments, and how the AI itself must write auditable code so
the human navigator can verify that the AI is doing exactly what was asked.
And during all that time the AI will ask you eagerly every other moment
if it can start coding now.
There is a third way: AId coding. The human does most of the work,
designs, codes, comments and tests, but calls the AI for those pieces of
special difficulty, not so much for their algorithmic complexity but for
their technical requirements. A regular expression, a specific API call, a
cryptographic routine, a parsing edge case. The roles are reversed compared
to pAIr coding: here the human is the developer and the AI is the guru. The
human assembles the final result.
A clear example is any development delivered to a client who will review and
audit every line of code. The human developer owns the full codebase and is
responsible for it. But when one specific piece requires deep technical
expertise outside the developer's comfort zone, whether cryptographic
handshaking, a complex regular expression, a low level system call or a
specific protocol implementation, the AId of an AI can save the entire
development.
Finally there is an idea that deserves its own article. The extreme case of
vibe coding is building intelligent agents that invoke AI at runtime for
each decision. The pAIr coding approach is the opposite: using AI to build
intelligent agents whose logic is already hardcoded, programmed, wired into
the code. When the agent makes a mistake you can find the reason and
reprogram it. No hallucinations, no model changes, no unsettling surprises
at 3am.
Curiously I have been unable to build intelligent agents the first way.
They always come out the second way. Maybe it is
about prudence, explainability, supervision and error correction. And when
the agent's activity affects people, ethics.
