Intention-Implementation Impedance, In Turn
The friction and losses when translating an intention to its implementation - an impedance - was floated from the previous week:
The leap from our mental construct into the written medium.
The written medium against the standardized domain language.
The domain language to the toolset.
The toolset to the implementation.
Impedance separates bandwidth from fidelity, and coding agents increases the former while decreasing the latter. As such, coding agents shifts the notion of impedance.
Before, the intention is gradually translated into the implementation through a single mind, preserving as much of the characteristics of said intention. Now, intention is expressed and often compressed into prose, and the agents decompresses that using its weights which are largely the statistical average of public code, not the theory-building from the team. The gap gets filled with something plausible, and plausible is the hardest to scrutinize.
Impedance implies a fixed source to measure against, but the intention in software development is rarely fixed - a greenfield project, a change in requirements. One could just 'express harder' to overcome impedance, or one could continue to keep human-in-the-loop. The discovery and handling of doing so varies according to the team set-up.
Solo or Duo
A developer or two obviously exhibits the lowest impedance, as we are closest to the 'single mind'. Coding agents get to flex their strengths because the verification loop can be closest observed by that one - or two - minds, the second serving as an independent error-checker. The classic pair programming approach - two developers, one keyboard - works well here when the keyboard is no longer the bottleneck.
What to check for is not the failure of implementation but the erosion of intention in this scenario. The people stop being the intention-holder and become a reactive approver. As the theory-building aspect atrophies, impedance arises because the intentions become blunter. This might be why some schools of thoughts propose reverting the typing back to clickety-clack keyboards, to force the silent-reading of every line of code.
A step-up
Agents doesn't significantly introduce impedance here where prior attention is already split multiple ways, and so agents get a smaller voice even in this echo chamber.
However, the varied prompts between the senior team lead and the newly onboarded developer tend to then produce jaggedly looking code - locally coherent and yet globally incoherent. A well-researched AGENTS.md can only guard so much against the unbridled march of frontier coding agents and harnesses, so the code repository might eventually end up with a subtle mix of 'best practices' from different major versions of the foundational library.
The repository used to be a slower-moving shared artifact that taught convention by being read. Convergence happened because the writing was slow enough for convention to synergize, and agents outrun that.
Review now becomes the constraint in ensuring that what lands is fit-for-purpose. This scenario is also better placed to remediate the impedance - externalizing intent into artifacts such as architecture decision records, or agent instructions - such that impedance for the people is solved in the same loop. This brings us back to Substrate in SPIRIT...
Large-scale
Traditionally, failures occur at this level because of the lack of consensus, and that is something that coding agents cannot magically work around. The writing is accelerated into a wall of online meetings, release trains, and security audit checkpoints.
Institutional knowledge lives in code someone wrote and remembers writing. "Legacy code" used to mean code without tests or written by someone who left. It can now imply code generated through someone's unobserved late-night agentic coding session, last week: owned in the org chart, understood by nobody.
The wins in this scenario are not the flashy 'feature-in-twelve-hours!' headlines but in the more mechanical implementations. Database migrations, dependency upgrades, code refactoring are the high-volume and low-ambiguity work where the intent is simple: "make this the same as that". This compresses to prose with next-to-no loss, hence low impedance at a large scale. There is more value here than in feature velocity, the part nobody demos.
Dark software factory
Simply put, removing the people in a dark software factory removes the impedance meter, and one solution is to augment the factory with a cheap mechanical oracle - the role that ascertains if the outputs are knowingly correct. Dim the lights in proportion to the quality of the oracle, not the model. A more capable model has the potential to introduce less errors but does not distinguish them as such. Being able to verify cheaply is perhaps the winning ticket to giving the factory a shot at winning.
Creating intention, consuming implementation
We will end this four-part series by finishing the mechanical oracle, and how the cycle links up with the impedance.
AI disclaimer: Have bounced ideas off, so while text is still my own, the way I arrived at some of them may contain minor influences from such interactions.