<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Growth on Ou David | Systems Engineer</title><link>https://preview.vvivid.dev/tags/growth/</link><description>Recent content in Growth on Ou David | Systems Engineer</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Tue, 27 Jan 2026 12:00:00 +0700</lastBuildDate><atom:link href="https://preview.vvivid.dev/tags/growth/index.xml" rel="self" type="application/rss+xml"/><item><title>The Trap of Vibe Coding for Juniors</title><link>https://preview.vvivid.dev/posts/the_trap_of_vibe_coding_for_juniors/</link><pubDate>Tue, 27 Jan 2026 12:00:00 +0700</pubDate><guid>https://preview.vvivid.dev/posts/the_trap_of_vibe_coding_for_juniors/</guid><description>&lt;p&gt;Today I want to write about something different: &lt;strong&gt;vibe coding&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;My honest opinion is that vibe coding is risky for junior developers. Not because AI is bad at writing code. The real problem is that juniors often do not have enough experience yet to judge whether the generated solution is correct, maintainable, or safe under production pressure.&lt;/p&gt;
&lt;p&gt;That is where the trap starts. The code works once, the demo looks good, and the feature feels finished. But working code is not always good code.&lt;/p&gt;</description></item></channel></rss>