{"id":4607,"date":"2026-07-17T17:20:13","date_gmt":"2026-07-17T17:20:13","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/07\/17\/the-cost-of-saying-yes-has-changed\/"},"modified":"2026-07-17T17:20:13","modified_gmt":"2026-07-17T17:20:13","slug":"the-cost-of-saying-yes-has-changed","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/07\/17\/the-cost-of-saying-yes-has-changed\/","title":{"rendered":"The cost of saying yes has changed"},"content":{"rendered":"

The most expensive part of a small feature request used to be writing the code. Now it\u2019s usually the meeting about whether or not to write the code.<\/p>\n

That\u2019s a real shift, and it quietly breaks a lot of engineering instincts. Engineers learn early that most \u201csmall asks\u201d aren\u2019t small: they need tests, a rollout plan, someone to think through the edge cases and own the behavior after it ships. A two-hour change can become a two-week distraction if it touches the wrong part of the system. So we push back. Is this really needed? Does it belong in this release? Does it change a contract we already agreed to? I\u2019m not giving that instinct up.<\/p>\n

But it rests on an assumption that\u2019s quietly breaking, which is that writing the first version of the code is the expensive step. For a specific class of change, it no longer is. If you can tell those changes apart from the rest, you can replace \u201cis this in scope?\u201d with a question you can answer in thirty minutes instead of a two-day debate.<\/p>\n

The debate often costs more than the patch<\/h2>\n

Here\u2019s a pattern I keep seeing. Someone asks for a small change such as surfacing a last_active_at<\/code> timestamp that already exists in the backend on a settings page. The team spends forty minutes in a thread. One person says it sounds risky. Someone remembers a related migration from two years ago. Someone mentions the deadline. Eventually we land on \u201cprobably a day or two, could be more,\u201d with low confidence, primarily because nobody has actually tried it.<\/p>\n

That process made sense when trying was the expensive part. You had to stop what you were doing, load the context into your head, make the change by hand, write the tests, then discover the second- and third-order consequences. When the first attempt is cheap, defending the boundary can cost more than crossing it.<\/p>\n

An agent can produce that first patch in the time the thread takes to warm up. It\u2019s not free and definitely not automatically correct. But it is cheap enough that the smart move is often to stop guessing and look at a real diff.<\/p>\n

The first patch is a price check, not the product<\/h2>\n

The mistake is to treat the generated patch as the deliverable. It isn\u2019t. It\u2019s a probe. It turns an abstract scope argument into a concrete artifact you can interrogate:<\/p>\n