The personal blog of Jean-François Moy. 2026-07-23T00:00:00+00:00 https://www.moystard.com/blog/feed.xml 2026-07-23T00:00:00+00:00 2026-07-23T00:00:00+00:00 https://www.moystard.com/blog/ai-native-delivery/

<p>A few weeks ago <a rel="nofollow noreferrer external" href="https://www.moystard.com/blog/ai-cognitive-debt">I wrote about cognitive debt</a>: the slow loss of judgement that comes from letting a model think in your place. The natural question that follows: how do you use these tools seriously, at full speed, without paying that price?</p> <p>Here is my answer, after a year of building a production fintech this way. It isn't using the tools less. It isn't trying harder to stay alert, because attention will fade when deadlines loom closer. It's structure: a delivery pipeline where human judgement focuses on the thinking and decisions that deserve it. Everything else is enforced by gates that don't rely on anyone remembering to care.</p>

<p>A few weeks ago <a rel="nofollow noreferrer external" href="https://www.moystard.com/blog/ai-cognitive-debt">I wrote about cognitive debt</a>: the slow loss of judgement that comes from letting a model think in your place. The natural question that follows: how do you use these tools seriously, at full speed, without paying that price?</p> <p>Here is my answer, after a year of building a production fintech this way. It isn't using the tools less. It isn't trying harder to stay alert, because attention will fade when deadlines loom closer. It's structure: a delivery pipeline where human judgement focuses on the thinking and decisions that deserve it. Everything else is enforced by gates that don't rely on anyone remembering to care.</p> <span id="continue-reading"></span><h1 id="the-scarce-resource-has-changed">The scarce resource has changed<a class="zola-anchor" href="#the-scarce-resource-has-changed" aria-label="Anchor link for: the-scarce-resource-has-changed" style="visibility: hidden;"></a> </h1> <p>For my whole career, engineering capacity was the constraint. Roadmaps were shaped around what the teams could carry. With agentic tooling, that constraint has clearly shifted: a small team can now produce what used to take a department.</p> <p>What hasn't moved is the supply of judgement. Someone still has to say: we are solving the wrong problem; this technical design will not scale and hurt us in a year; this edge case is the one that matters.</p> <p>I think that is now the real job of an engineering leader. It is not adopting AI; everyone has. It is about deciding where human attention goes, and building the system that encourages it and protects it.</p> <h1 id="the-initial-lag-can-fool-you">The initial lag can fool you<a class="zola-anchor" href="#the-initial-lag-can-fool-you" aria-label="Anchor link for: the-initial-lag-can-fool-you" style="visibility: hidden;"></a> </h1> <p>The dangerous thing about uncontrolled usage is that it feels great. The tools are impressive, output pours out, velocity charts point up. Nothing seems wrong.</p> <p>The bill comes later, and it compounds quietly: vicious bugs in code nobody truly read; confident implementations of acceptance criteria that were invalid, or misunderstood, because nobody challenged them before building; a team that no longer knows its own codebase, because everything was delegated and stamped. By the time the symptoms show, you don't have a bug. You have an archaeology dig, run by people who have lost the fluency to dig.</p> <p>Cognitive debt and technical debt end up collapsing into the same debt. The cost is simply deferred, invisible as it grows, and due all at once. "It's working fine so far" is not evidence. This initial lag is the trap.</p> <h1 id="what-the-structure-looks-like">What the structure looks like<a class="zola-anchor" href="#what-the-structure-looks-like" aria-label="Anchor link for: what-the-structure-looks-like" style="visibility: hidden;"></a> </h1> <p>The pipeline our team runs replicates the roles of a delivery team, sequenced so work flows from ticket to implementation to released change, with a quality gate at each handoff. Every engineer runs it the same way, each owning the judgement calls on their own tickets. They are ultimately accountable for the outcome.</p> <p>It starts before any code is written. Tickets are authored as user stories with acceptance criteria, then challenged: the system's first job is to argue with the scope, highlight misalignment with the existing system, surface the gaps, and openly ask the contentious questions. In the meantime, the engineer shapes the ticket and the technical design. Anything diagnostic follows a data-first rule: metrics, logs and data records before hypotheses.</p> <p>The implementation starts with a test-first approach against the acceptance criteria: the behaviour is pinned before a single line of production code exists. Once the implementation is complete, a suite of reviews runs in parallel, each an independent lens: one checks the change against the ticket acceptance criteria, one against the project's architecture and conventions, one for API-contract stability, one for security and the supply chain, and finally, a simplification pass whose only job is to remove complexity that doesn't pay rent. None of this depends on someone remembering to run it.</p> <p>The final brick is the live validation: an agent runs the change against a real environment, driving the actual UI, checking database side effects, and checking logs. It walks the happy path, but also pokes at the unhappy ones. The acceptance criteria are proven on a running system, beyond code testing.</p> <p>By that time, a rich PR is opened and merge-gated on clean re-review by a separate agent, green CI and explicit human sign-off.</p> <p>Our "kickoff" command carries a ticket from scope-challenge to merged PR. During that time, human attention is spent at exactly two points: shaping the work at product and engineering level before it starts, and the contentious calls the gates escalate along the way. The tiny implementation details that used to eat whole review cycles never reach a person.</p> <h1 id="why-this-keeps-judgement-sharp">Why this keeps judgement sharp<a class="zola-anchor" href="#why-this-keeps-judgement-sharp" aria-label="Anchor link for: why-this-keeps-judgement-sharp" style="visibility: hidden;"></a> </h1> <p>Cognitive debt grows when you fully delegate your judgement and the model does your thinking. Your role is to stamp its output. Our methodology reverses that twice.</p> <p>First, it concentrates the thinking that stays human. Nobody reviews boilerplate or formatting, so the judgement each engineer does exercise, on scope, design and the genuine hard calls, gets full attention. The skill you keep is the skill you use.</p> <p>Second, the gates are structural, not optional. Speed and safety stop competing the moment quality checks are steps the next stage depends on, rather than qualities someone must remember to practise. A pipeline that cannot merge without independent review, passing tests and live validation doesn't get lazier as the people get faster. This rigour pays off.</p> <p>There's a compounding layer too. The system remembers the team's conventions; lessons are taught and documented once. Preferences become guardrails instead of tribal knowledge. Every mistake and inefficiency becomes a rule, exactly once.</p> <p>These gates do not slow us down: they spend machine time, not human attention, running in parallel while we shape the next piece of work. Working this way, three engineers took a new product from concept to public launch in six weeks, on a platform that processes millions of financial events a month, in software where a wrong number in front of a customer is unacceptable. I don't believe that pace, at that bar, is reachable for a team this size any other way.</p> <h1 id="what-it-costs">What it costs<a class="zola-anchor" href="#what-it-costs" aria-label="Anchor link for: what-it-costs" style="visibility: hidden;"></a> </h1> <p>None of this is free. The harness took real time to build and tune; the gates encode our conventions and, more importantly, our architecture, and encoding them was work. That last point matters: the codebase has a purposeful shape, decided by people, and the pipeline defends it on every change. A model without that constraint will happily grow you a system with no shape at all. The whole system lives or dies on well-formed acceptance criteria: feed it vague or ambiguous scope and it will confidently build the wrong thing. That's why the scope-challenge stage exists, and why it's the one stage I would never automate away. The live-validation environment is infrastructure that needs an owner, like any other.</p> <p>And one problem I won't pretend to have solved: this model assumes seasoned judgement at the gates. How a junior grows that judgement inside a system that shields them from the grind that used to build it is, I think, the hardest problem in this new AI-era engineering leadership. This is a problem we need to collectively tackle: the future of our discipline and our companies depends on this new generation of software engineers developing their judgement.</p> <h1 id="a-message-to-engineering-leaders-and-engineers-out-there">A message to engineering leaders and engineers out there<a class="zola-anchor" href="#a-message-to-engineering-leaders-and-engineers-out-there" aria-label="Anchor link for: a-message-to-engineering-leaders-and-engineers-out-there" style="visibility: hidden;"></a> </h1> <p>Adoption of agentic programming is not a question any more; the tools are everywhere, and their impact is undeniable. The divide that matters is between teams that use them under control and teams quietly accumulating the lag-hidden debt above while their dashboards look great. The second group may not feel wrong yet. That's the point.</p> <p>For leaders, the path that works takes more design effort than either enthusiasm or caution. Decide which decisions deserve human judgement in your context and domain. Build the structure that routes those decisions to people. Make every other quality property a gate. The result is the combination everyone assumes is a trade-off: faster delivery, less debt, and engineers whose judgement sharpens with use, because it's the only thing they spend all day exercising.</p> <p>For engineers, the gates are just skills: plain files that encode what your team knows (the domain, the conventions, the architecture, the strategy behind the codebase). Anyone can write one. Champion the framework, own it, improve it, add the rule you would have needed yesterday. It isn't your manager's system; it's the team's shared memory, and everyone can contribute to it.</p> <p>One boundary worth stating plainly: everything here is about building things right. Whether you're building the right things is a different discipline, and no pipeline answers it for you.</p> <p>As the tools keep improving, the structure decides whether they make your team more capable or just more prolific.</p> 2026-06-25T00:00:00+00:00 2026-06-25T00:00:00+00:00 https://www.moystard.com/blog/ai-cognitive-debt/

<p>We are trading productivity for cognitive debt, and most of us have not noticed the bill.</p>

<p>We are trading productivity for cognitive debt, and most of us have not noticed the bill.</p> <span id="continue-reading"></span> <p>I have been thinking about this a lot as the recent models have grown genuinely impressive. The MIT Media Lab put a name to it this year: writers who leaned on LLMs showed measurably lower neural engagement. Cognitive debt.</p> <p>For software engineers and architects, the choice between deep and shallow understanding is not new. It used to be StackOverflow or a blog post, copy-pasted in haste, versus the slower work of understanding the problem space well enough to build something strong and context-aware.</p> <p>LLMs raise the same choice, but with a twist: their solutions always look credible and optimal. Only a seasoned engineer can specify a problem properly and judge a solution against the criteria that are specific to their company, domain, project and timing.</p> <p>And as we hand more of that thinking to the machine, the skill quietly erodes. Not overnight, but through a slow loss of comprehension, tooling instinct and programmatic and design fluency that is hard to notice until you need it and find it gone.</p> <p>So the reminder I keep giving myself: think, evaluate, challenge whatever you introduce into your systems. Keep the mind sharp and the decisions deliberate.</p> <p>This post was inspired by a great read from Igor Roztropiński: <a rel="nofollow noreferrer external" href="https://binaryigor.com/the-joy-and-power-of-understanding.html">The Joy and Power of Understanding</a>.</p> <p><em>Follow-up: <a href="/blog/ai-native-delivery">Spending judgement where it matters: how we structure AI-native delivery</a>.</em></p> 2021-02-05T00:00:00+00:00 2021-02-05T00:00:00+00:00 https://www.moystard.com/blog/koa-typings/

<p>With a bit of Typescript magic, it is possible to add strict typing to the body of Koa requests and responses.</p>

<p>With a bit of Typescript magic, it is possible to add strict typing to the body of Koa requests and responses.</p> <span id="continue-reading"></span> <p>Typescript and Koa users know how loose the Typescript typing is for the requests and responses of the Koa contexts. Indeed, Koa (and <a rel="nofollow noreferrer external" href="https://github.com/dlau/koa-body">Koa-Body</a>) default types use <code>any</code> for the request and response body type.</p> <p>This short blog post will show how you can add more robustness to your controllers by typing your bodies thanks to a simple generic interface.</p> <h1 id="sparkling-koa-with-genericity">Sparkling Koa with Genericity<a class="zola-anchor" href="#sparkling-koa-with-genericity" aria-label="Anchor link for: sparkling-koa-with-genericity" style="visibility: hidden;"></a> </h1> <p>We want to be able to provide the types of the request and the response body, whilst keeping the built-in flexibility. That's easy to achieve with Typescript generics as demonstrated below:</p> <pre class="giallo z-code"><code data-lang="typescript"><span class="giallo-l"><span class="z-keyword">import</span><span> {</span><span class="z-variable z-other"> Context</span><span>,</span><span class="z-variable z-other"> Request</span><span> }</span><span class="z-keyword"> from</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">koa</span><span class="z-punctuation z-definition z-string">&#39;</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">interface</span><span class="z-entity z-name"> KoaRequest</span><span>&lt;</span><span class="z-entity z-name">RequestBody</span><span class="z-keyword"> =</span><span class="z-support"> any</span><span>&gt;</span><span class="z-storage"> extends</span><span class="z-entity"> Request</span><span> {</span></span> <span class="giallo-l"><span class="z-variable"> body</span><span class="z-keyword">?</span><span class="z-keyword">:</span><span class="z-entity z-name"> RequestBody</span><span>;</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword">export</span><span class="z-storage z-type"> interface</span><span class="z-entity z-name"> KoaContext</span><span>&lt;</span><span class="z-entity z-name">RequestBody</span><span class="z-keyword"> =</span><span class="z-support"> any</span><span>,</span><span class="z-entity z-name"> ResponseBody</span><span class="z-keyword"> =</span><span class="z-support"> any</span><span>&gt;</span><span class="z-storage"> extends</span><span class="z-entity"> Context</span><span> {</span></span> <span class="giallo-l"><span class="z-variable"> request</span><span class="z-keyword">:</span><span class="z-entity z-name"> KoaRequest</span><span>&lt;</span><span class="z-entity z-name">RequestBody</span><span>&gt;</span><span>;</span></span> <span class="giallo-l"><span class="z-variable"> body</span><span class="z-keyword">:</span><span class="z-entity z-name"> ResponseBody</span><span>;</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-keyword">export</span><span class="z-storage z-type"> interface</span><span class="z-entity z-name"> KoaResponseContext</span><span>&lt;</span><span class="z-entity z-name">ResponseBody</span><span>&gt;</span><span class="z-storage"> extends</span><span class="z-entity"> KoaContext</span><span>&lt;</span><span class="z-support">any</span><span>,</span><span class="z-entity z-name"> ResponseBody</span><span>&gt;</span><span> {</span><span>}</span></span></code></pre> <p>Having typed bodies should not prevent you from runtime checking the request bodies to ensure that you were provided with a valid input. If you are composing middlewares, you probably runtime check up the chain, and having typed bodies downstream where you know the input has been validated prevents you from duplicating the checks.</p> <p>For assembling responses, having type safety at the compiler level should prove enough.</p> <p>I am actually surprised that those are not the original type definitions in <code>@types/koa</code> and <code>@types/koa-body</code> but I am sure they had their reasons.</p> <h2 id="examples">Examples<a class="zola-anchor" href="#examples" aria-label="Anchor link for: examples" style="visibility: hidden;"></a> </h2> <p>Let's put our new interfaces in practice with a couple of examples.</p> <pre class="giallo z-code"><code data-lang="typescript"><span class="giallo-l"><span class="z-keyword">import</span><span class="z-variable z-other"> Router</span><span class="z-keyword"> from</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">koa-router</span><span class="z-punctuation z-definition z-string">&#39;</span><span>;</span></span> <span class="giallo-l"><span class="z-keyword">import</span><span class="z-variable z-other"> koaBody</span><span class="z-keyword"> from</span><span class="z-punctuation z-definition z-string"> &#39;</span><span class="z-string">koa-body</span><span class="z-punctuation z-definition z-string">&#39;</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">interface</span><span class="z-entity z-name"> HelloWorldRequestDto</span><span> {</span></span> <span class="giallo-l"><span class="z-variable"> name</span><span class="z-keyword">:</span><span class="z-support"> string</span><span>;</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">interface</span><span class="z-entity z-name"> HelloWorldResponseDto</span><span> {</span></span> <span class="giallo-l"><span class="z-variable"> message</span><span class="z-keyword">:</span><span class="z-support"> string</span><span>;</span></span> <span class="giallo-l"><span>}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-storage z-type">const</span><span class="z-variable z-other z-constant"> helloRouter</span><span class="z-keyword"> =</span><span class="z-keyword"> new</span><span class="z-entity z-name"> Router</span><span>(</span><span>)</span><span>;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-variable z-other">helloRouter</span><span>.</span><span class="z-entity z-name">post</span><span>(</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">/</span><span class="z-punctuation z-definition z-string">&#39;</span><span>,</span><span class="z-entity z-name"> koaBody</span><span>(</span><span>)</span><span>,</span><span class="z-storage"> async</span><span> (</span><span class="z-variable">ctx</span><span class="z-keyword">:</span><span class="z-entity z-name"> KoaContext</span><span>&lt;</span><span class="z-entity z-name">HelloWorldRequestDto</span><span>,</span><span class="z-entity z-name"> HelloWorldResponseDto</span><span>&gt;</span><span>)</span><span class="z-storage z-type"> =&gt;</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Request body is now typed.</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span> {</span><span class="z-variable z-other z-constant"> name</span><span> }</span><span class="z-keyword"> =</span><span class="z-variable z-other"> ctx</span><span>.</span><span class="z-variable z-other">res</span><span>.</span><span class="z-variable z-other">body</span><span>;</span></span> <span class="giallo-l"><span class="z-variable z-other"> ctx</span><span>.</span><span class="z-variable z-other">res</span><span>.</span><span class="z-variable z-other">statusCode</span><span class="z-keyword"> =</span><span class="z-constant"> 200</span><span>;</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> Response body is also typed.</span></span> <span class="giallo-l"><span class="z-variable z-other"> ctx</span><span>.</span><span class="z-variable z-other">body</span><span class="z-keyword"> =</span><span> {</span></span> <span class="giallo-l"><span> message</span><span>:</span><span class="z-punctuation z-definition z-string"> `</span><span class="z-string">Hello </span><span class="z-string">${</span><span class="z-variable z-other">name</span><span class="z-string">}</span><span class="z-string">!</span><span class="z-punctuation z-definition z-string">`</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>;</span></span> <span class="giallo-l"><span>}</span><span>)</span><span>;</span></span></code></pre> <p>The compiler will error if we try to access properties not defined in the body types. Using the same DTO types, the code below would not compile:</p> <pre class="giallo z-code"><code data-lang="typescript"><span class="giallo-l"><span class="z-variable z-other">helloRouter</span><span>.</span><span class="z-entity z-name">post</span><span>(</span><span class="z-punctuation z-definition z-string">&#39;</span><span class="z-string">/</span><span class="z-punctuation z-definition z-string">&#39;</span><span>,</span><span class="z-entity z-name"> koaBody</span><span>(</span><span>)</span><span>,</span><span class="z-storage"> async</span><span> (</span><span class="z-variable">ctx</span><span class="z-keyword">:</span><span class="z-entity z-name"> KoaContext</span><span>&lt;</span><span class="z-entity z-name">HelloWorldRequestDto</span><span>,</span><span class="z-entity z-name"> HelloWorldResponseDto</span><span>&gt;</span><span>)</span><span class="z-storage z-type"> =&gt;</span><span> {</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> The compiler will fail as lastName is not defined in `HelloWorldRequestDto`.</span></span> <span class="giallo-l"><span class="z-storage z-type"> const</span><span> {</span><span class="z-variable z-other z-constant"> name</span><span>,</span><span class="z-variable z-other z-constant"> lastName</span><span> }</span><span class="z-keyword"> =</span><span class="z-variable z-other"> ctx</span><span>.</span><span class="z-variable z-other">res</span><span>.</span><span class="z-variable z-other">body</span><span>;</span></span> <span class="giallo-l"><span class="z-variable z-other"> ctx</span><span>.</span><span class="z-variable z-other">res</span><span>.</span><span class="z-variable z-other">statusCode</span><span class="z-keyword"> =</span><span class="z-constant"> 200</span><span>;</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment"> //</span><span class="z-comment"> The compiler would also fail here because we are defining a property absent from `HelloWorldResponseDto`, and `message` is absent.</span></span> <span class="giallo-l"><span class="z-variable z-other"> ctx</span><span>.</span><span class="z-variable z-other">body</span><span class="z-keyword"> =</span><span> {</span></span> <span class="giallo-l"><span> msg</span><span>:</span><span class="z-punctuation z-definition z-string"> `</span><span class="z-string">Hello </span><span class="z-string">${</span><span class="z-variable z-other">name</span><span class="z-string">}</span><span class="z-string">!</span><span class="z-punctuation z-definition z-string">`</span><span>,</span></span> <span class="giallo-l"><span> }</span><span>;</span></span> <span class="giallo-l"><span>}</span><span>)</span><span>;</span></span></code></pre> <p>The <code>KoaContext</code> interface uses default value for the generics; this allows specifying the request body type without the response's: <code>KoaContext&lt;RequestBodyType&gt;</code> will assume that the response body type is <code>any</code>. The <code>KoaResponseContext</code> allows you to specify the response body type without the request's for extra convenience.</p> <h2 id="conclusion">Conclusion<a class="zola-anchor" href="#conclusion" aria-label="Anchor link for: conclusion" style="visibility: hidden;"></a> </h2> <p>Leveraging Typescript and generics, we were able to add stricter typing to Koa. This should help you when composing middlewares, and assembling your response bodies. Happy coding!</p>