<?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 Zhanwei Wang</title><link>https://zhanwei.wang/en/tags/software-engineering/</link><description>Recent content in Software Engineering on Zhanwei Wang</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Thu, 09 Apr 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://zhanwei.wang/en/tags/software-engineering/index.xml" rel="self" type="application/rss+xml"/><item><title>When Documentation Stops Rotting: From Karpathy's LLM Wiki to Software Engineering Documentation</title><link>https://zhanwei.wang/en/posts/when-documentation-stops-rotting/</link><pubDate>Thu, 09 Apr 2026 00:00:00 +0800</pubDate><guid>https://zhanwei.wang/en/posts/when-documentation-stops-rotting/</guid><description>&lt;blockquote&gt;
&lt;p&gt;Humans write the original documents and make decisions. LLMs handle synthesis, updates, and consistency checks. Documentation is no longer a static artifact that rots the moment it&amp;rsquo;s written — it becomes a living knowledge base continuously maintained by LLMs.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;h2 id="an-age-old-problem"&gt;An Age-Old Problem&lt;/h2&gt;
&lt;p&gt;Every software engineer has experienced this: you join a project, open the docs, and find the README still describing a module deleted six months ago, API docs with fields that don&amp;rsquo;t match the code at all, and architecture diagrams showing a design from two versions back. You ask a colleague, who says, &amp;ldquo;Don&amp;rsquo;t bother with the docs — just read the code.&amp;rdquo;&lt;/p&gt;</description></item><item><title>Frontend-Driven Development in the Vibe Coding Era</title><link>https://zhanwei.wang/en/posts/vibe-coding-frontend-driven-development/</link><pubDate>Mon, 09 Mar 2026 10:00:00 +0800</pubDate><guid>https://zhanwei.wang/en/posts/vibe-coding-frontend-driven-development/</guid><description>&lt;p&gt;When AI becomes a routine tool in development, how should we change the way we work?&lt;/p&gt;
&lt;h2 id="the-evolution-of-three-development-models"&gt;The Evolution of Three Development Models&lt;/h2&gt;
&lt;p&gt;Before discussing frontend-driven development, let me walk through three fundamentally different development models and how they&amp;rsquo;ve evolved:&lt;/p&gt;
&lt;h3 id="1-backend-driven-development-the-traditional-way"&gt;1. Backend-Driven Development (The Traditional Way)&lt;/h3&gt;
&lt;pre tabindex="0"&gt;&lt;code&gt;Product requirements → Backend designs API (1-2 weeks) → Frontend builds pages (2 weeks) → Integration
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;&lt;strong&gt;A real pain point&lt;/strong&gt;:&lt;/p&gt;
&lt;p&gt;Last year I worked on an e-commerce admin system where the team followed this model. By the time the frontend received the API documentation, we were already in week three of the development cycle. I spent two weeks implementing the order management module according to the docs. When we demoed it to the product manager, she frowned: &amp;ldquo;Why can&amp;rsquo;t the order list be filtered by status? Users definitely need this.&amp;rdquo;&lt;/p&gt;</description></item></channel></rss>