<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Lynxcontract on Dmitry Serikov</title><link>https://dmitryserikoff.com/tags/lynxcontract/</link><description>Recent content in Lynxcontract on Dmitry Serikov</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 23 Jul 2026 00:00:00 +0300</lastBuildDate><atom:link href="https://dmitryserikoff.com/tags/lynxcontract/index.xml" rel="self" type="application/rss+xml"/><item><title>How Do You Take Back Control of AI-Generated Code?</title><link>https://dmitryserikoff.com/posts/how-do-you-take-back-control-of-ai-generated-code/</link><pubDate>Thu, 23 Jul 2026 00:00:00 +0300</pubDate><guid>https://dmitryserikoff.com/posts/how-do-you-take-back-control-of-ai-generated-code/</guid><description>&lt;p>AI-generated code has a strange failure mode: it can be functionally correct
and still unaccountable. Nothing connects the requirement to the
implementation. Git records &lt;em>what&lt;/em> changed; nothing records &lt;em>why the code
exists at all&lt;/em>.&lt;/p>
&lt;p>My take: control doesn&amp;rsquo;t come from restricting the agent — it comes from a
construction in which the machine simply has no way to change the system
silently. Machine-readable contract blocks ahead of the code (Eiffel-style,
but used prospectively), tests derived from contracts rather than
implementations, explicit gap-marking when the agent lacks context, and a
deterministic graph that answers &amp;ldquo;why does this line exist?&amp;rdquo;&lt;/p></description></item></channel></rss>