<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Retrospective on Jim's Notes</title><link>https://shizhi3620.github.io/en/tags/retrospective/</link><description>Recent content in Retrospective on Jim's Notes</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Fri, 11 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://shizhi3620.github.io/en/tags/retrospective/index.xml" rel="self" type="application/rss+xml"/><item><title>Lessons from Vibe Coding</title><link>https://shizhi3620.github.io/en/posts/vibe-coding-notes/</link><pubDate>Fri, 11 Sep 2026 00:00:00 +0000</pubDate><guid>https://shizhi3620.github.io/en/posts/vibe-coding-notes/</guid><description>&lt;h2 id="the-short-version"&gt;The short version&lt;/h2&gt;&#10;&lt;p&gt;After two or three weeks of practicing Vibe Coding, I reached a broad conclusion: large language models have dramatically lowered the barrier to programming. Anyone with basic computer literacy can now use AI to write programs and implement useful features.&lt;/p&gt;&#10;&lt;p&gt;However, those features often run only on a local computer or remain personal tools. Turning them into a service that runs on a server, serves customers, and can be continuously improved requires much stronger engineering thinking.&lt;/p&gt;&#10;&lt;p&gt;If the goal is to build independently with AI and make money through an OPC (One Person Company) model, technical implementation is only one part of the problem. The overall business model, cost structure, user needs, and competition also need to be considered.&lt;/p&gt;</description></item><item><title>A Public Project Retrospective Starts with Verifiable Records</title><link>https://shizhi3620.github.io/en/posts/notes-from-a-public-project-retrospective/</link><pubDate>Mon, 07 Sep 2026 00:00:00 +0000</pubDate><guid>https://shizhi3620.github.io/en/posts/notes-from-a-public-project-retrospective/</guid><description>&lt;p&gt;A retrospective for a public project can easily collapse into outcomes: what shipped, what feedback arrived, and what might come next. The more useful part is whether people can understand and revisit the trade-offs made along the way.&lt;/p&gt;&#10;&lt;p&gt;I separate a retrospective into three layers. The first is verifiable fact, such as public commits, documentation, issue records, and release notes. The second is the judgment at the time: why one problem came first and another option was postponed. Only the third is personal feeling. It can clarify context, but it cannot stand in for evidence.&lt;/p&gt;&#10;&lt;p&gt;This approach helps in two ways. Collaborators get a project history rather than a collection of disconnected links. I get a record of the conditions behind a choice when facing similar constraints again, instead of relying on a vague memory of success or failure.&lt;/p&gt;</description></item></channel></rss>