<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>Software Engineering on KnightLi Blog</title>
        <link>https://www.knightli.com/en/tags/software-engineering/</link>
        <description>Recent content in Software Engineering on KnightLi Blog</description>
        <generator>Hugo -- gohugo.io</generator>
        <language>en</language>
        <lastBuildDate>Fri, 15 May 2026 08:46:23 +0800</lastBuildDate><atom:link href="https://www.knightli.com/en/tags/software-engineering/index.xml" rel="self" type="application/rss+xml" /><item>
        <title>Reject Vibe Coding: Matt Pocock&#39;s skills repo adds engineering constraints to AI coding</title>
        <link>https://www.knightli.com/en/2026/05/15/matt-pocock-skills-ai-engineering-workflow/</link>
        <pubDate>Fri, 15 May 2026 08:46:23 +0800</pubDate>
        
        <guid>https://www.knightli.com/en/2026/05/15/matt-pocock-skills-ai-engineering-workflow/</guid>
        <description>&lt;p&gt;The faster AI writes code, the faster a project can lose control. The real question is not whether a model can generate functions, but whether it understands the requirement, follows the team&amp;rsquo;s language, and makes small changes inside the existing architecture.&lt;/p&gt;
&lt;p&gt;Matt Pocock&amp;rsquo;s &lt;code&gt;mattpocock/skills&lt;/code&gt; repository points in the opposite direction of casual vibe coding: do not let AI take over the whole development process. Put it inside mature software engineering constraints.&lt;/p&gt;
&lt;p&gt;Project: &lt;a class=&#34;link&#34; href=&#34;https://github.com/mattpocock/skills&#34;  target=&#34;_blank&#34; rel=&#34;noopener&#34;
    &gt;https://github.com/mattpocock/skills&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;This is not about one magic prompt. It is a set of composable agent skills that turn requirement clarification, domain modeling, TDD, debugging, and architecture review into AI-friendly workflows.&lt;/p&gt;
&lt;h2 id=&#34;solve-alignment-failure-first&#34;&gt;Solve alignment failure first
&lt;/h2&gt;&lt;p&gt;The most common failure in AI coding is assuming the model understood the request when it merely guessed from a vague sentence.&lt;/p&gt;
&lt;p&gt;&lt;code&gt;grill-me&lt;/code&gt; flips the interaction. Before writing code, the agent acts like a demanding reviewer and keeps asking about branches, boundaries, and unresolved decisions.&lt;/p&gt;
&lt;p&gt;If you ask for a login page, it should first ask:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;How should password reset work?&lt;/li&gt;
&lt;li&gt;Should third-party login be supported?&lt;/li&gt;
&lt;li&gt;What should failed-login errors look like?&lt;/li&gt;
&lt;li&gt;Are account lockout, CAPTCHA, or risk controls in scope?&lt;/li&gt;
&lt;li&gt;Where should the user go after success?&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;This feels slower, but it prevents expensive rework later. The cheaper code generation becomes, the more costly unclear requirements become.&lt;/p&gt;
&lt;h2 id=&#34;write-domain-language-into-context&#34;&gt;Write domain language into context
&lt;/h2&gt;&lt;p&gt;Another common problem is generic vocabulary. The model does not know the team&amp;rsquo;s business terms, so names and documents drift.&lt;/p&gt;
&lt;p&gt;&lt;code&gt;grill-with-docs&lt;/code&gt; asks questions while also checking &lt;code&gt;CONTEXT.md&lt;/code&gt;, ADRs, and domain docs. Once terms and decisions are confirmed, they can be written back into shared context.&lt;/p&gt;
&lt;p&gt;This is close to the &amp;ldquo;ubiquitous language&amp;rdquo; idea in domain-driven design. If a team says customer instead of user, or transaction instead of order, the model should inherit that language.&lt;/p&gt;
&lt;p&gt;Context documents are valuable because they reduce guessing.&lt;/p&gt;
&lt;h2 id=&#34;use-tdd-to-slow-down-generation&#34;&gt;Use TDD to slow down generation
&lt;/h2&gt;&lt;p&gt;AI is risky because it is fast. Bad code used to take time to write; now hundreds of lines can appear in seconds. The problem is not speed itself, but lack of feedback loops.&lt;/p&gt;
&lt;p&gt;The &lt;code&gt;tdd&lt;/code&gt; skill brings back red-green-refactor:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Write a failing test for one behavior.&lt;/li&gt;
&lt;li&gt;Implement only enough code to pass.&lt;/li&gt;
&lt;li&gt;Refactor.&lt;/li&gt;
&lt;li&gt;Continue with the next vertical slice.&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;The key is one behavior at a time. AI executes, while humans keep control of direction and boundaries.&lt;/p&gt;
&lt;h2 id=&#34;debug-through-a-loop&#34;&gt;Debug through a loop
&lt;/h2&gt;&lt;p&gt;When facing a bug, many agents guess and patch repeatedly until the code becomes messier.&lt;/p&gt;
&lt;p&gt;&lt;code&gt;diagnose&lt;/code&gt; asks the agent to build a feedback loop:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Reproduce the issue&lt;/li&gt;
&lt;li&gt;Minimize the case&lt;/li&gt;
&lt;li&gt;Form a hypothesis&lt;/li&gt;
&lt;li&gt;Add observations or logs&lt;/li&gt;
&lt;li&gt;Fix the cause&lt;/li&gt;
&lt;li&gt;Add a regression test&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;This process is old, but it matters even more with AI. The model is good at trying things; the loop keeps it close to the root cause.&lt;/p&gt;
&lt;h2 id=&#34;review-architecture-regularly&#34;&gt;Review architecture regularly
&lt;/h2&gt;&lt;p&gt;A task passing tests does not mean the codebase is healthier. Repeated AI patches can blur module boundaries, make interfaces more complex, and make tests harder to write.&lt;/p&gt;
&lt;p&gt;Skills such as &lt;code&gt;improve-codebase-architecture&lt;/code&gt; ask the agent to step back and inspect the whole codebase:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Are responsibilities mixing across modules?&lt;/li&gt;
&lt;li&gt;Which interfaces are too complex?&lt;/li&gt;
&lt;li&gt;Which paths are hard to test?&lt;/li&gt;
&lt;li&gt;Which names conflict with domain language?&lt;/li&gt;
&lt;li&gt;Which duplicate logic should be merged?&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;This is not automatic large-scale refactoring. It is structured observation and suggested direction; humans still decide whether and how far to change.&lt;/p&gt;
&lt;h2 id=&#34;what-really-needs-limiting-is-freedom&#34;&gt;What really needs limiting is freedom
&lt;/h2&gt;&lt;p&gt;The core idea is simple: AI coding is not about letting the model improvise freely. It is about giving it clear goals, context, tests, and stopping conditions.&lt;/p&gt;
&lt;p&gt;Humans define the problem, architecture, tradeoffs, and acceptance criteria. AI generates code, fills in tests, repeats edits, and handles local refactors. Used well, AI amplifies capability; used poorly, it amplifies confusion.&lt;/p&gt;
&lt;p&gt;Software engineering fundamentals did not become obsolete because AI improved. Requirement clarity, domain language, TDD, diagnosis, and architecture review are becoming more important.&lt;/p&gt;
&lt;p&gt;More people will be able to write code. The gap will be between people who can put AI inside a maintainable, verifiable, evolving engineering system and those who cannot.&lt;/p&gt;
</description>
        </item>
        
    </channel>
</rss>
