<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Explanation on vshuraeff — Infrastructure. DevOps. Cloud.</title><link>https://vshuraeff.cloud/garden/explanation/</link><description>Recent content in Explanation on vshuraeff — Infrastructure. DevOps. Cloud.</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://vshuraeff.cloud/garden/explanation/index.xml" rel="self" type="application/rss+xml"/><item><title>Why agent-first principles</title><link>https://vshuraeff.cloud/garden/explanation/why-agent-first-principles/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://vshuraeff.cloud/garden/explanation/why-agent-first-principles/</guid><description>&lt;h2 id="the-shift-in-who-reads-code"&gt;The shift in who reads code&lt;/h2&gt;
&lt;p&gt;For most of software history, design principles were written for a reader with a
particular set of limits and strengths: a human sitting in an IDE, holding a rough
mental map of the codebase, able to ask a colleague when the map runs out, and slow
enough that a little extra indirection rarely mattered. SOLID, DRY, and layered
architecture all assume that reader.&lt;/p&gt;
&lt;p&gt;That reader is no longer the primary one. In an agent-first codebase, code is written,
reviewed, and analyzed primarily by an &lt;strong&gt;agent&lt;/strong&gt; — an LLM-driven program that reads,
writes, and reviews code via tools. Humans still set intent and constraints, and still
approve the changes that matter, but they rarely read the code line by line anymore.
The code itself is authored and re-authored by agents, commit after commit, often faster
than any human could review in full.&lt;/p&gt;</description></item><item><title>The garden model</title><link>https://vshuraeff.cloud/garden/explanation/the-garden-model/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://vshuraeff.cloud/garden/explanation/the-garden-model/</guid><description>&lt;h2 id="a-codebase-as-something-tended-not-built-once"&gt;A codebase as something tended, not built once&lt;/h2&gt;
&lt;p&gt;The metaphor GARDEN takes its name from is deliberately unglamorous: a codebase is a
garden that agents continuously tend, not a building that is constructed once and then
occupied. A building, once erected, mostly just stands there; a garden left alone does
not stand still — it grows wild. Paths close over, beds run into each other, one
aggressive planting crowds out everything nearby. Tending is not a one-time setup cost;
it is an ongoing practice that has to keep pace with how fast the garden grows.&lt;/p&gt;</description></item><item><title>Relation to classic principles</title><link>https://vshuraeff.cloud/garden/explanation/relation-to-classic-principles/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://vshuraeff.cloud/garden/explanation/relation-to-classic-principles/</guid><description>&lt;p&gt;GARDEN did not invent six principles from nothing. Each one inherits from an established
line of software design thinking, and each one also weakens or rejects a specific part of
that lineage where the classic formulation assumed a reader GARDEN no longer treats as
primary: a human navigating by accumulated familiarity, in an IDE, with time to ask a
colleague. This document walks the lineage classic principle by classic principle, states
what each contributes, what is kept, what is weakened, and what is rejected, and grounds
each judgment in agent mechanics rather than taste. The condensed &amp;quot;inherits from / rejects&amp;quot;
line for each principle appears in &lt;a href="https://vshuraeff.cloud/garden/reference/principles/"&gt;GARDEN principles&lt;/a&gt;;
this file is the expanded reasoning behind it.&lt;/p&gt;</description></item></channel></rss>