The weekly letter from Systems Thinking Lab: systems thinking insights for junior engineers, framed through the seven building blocks.
Here is a ticket I use whenever someone asks me what senior actually means. Add a discount code field to checkout. It reads like twenty minutes of work: a text box, a lookup, a percentage off. You could hand that line to an agent and have working code back before your coffee cools.
Before you write anything, walk the ticket past four stops it never mentions. Three of them are ways this same ticket can quietly undercharge someone. One of them, finance's ledger, is where the other three get found out.
The first stop is the price the buyer sees. The code has to apply before tax, not after, and it has to round the same way every other price on the page rounds, or two customers checking out a minute apart see two different rules for the same 15 percent off.
Then there is the card that actually gets charged. The number on the screen and the number the processor charges have to be the same number, captured at the same moment, even if the buyer sits on that page for ten minutes with the tab open before hitting pay.
Then finance's ledger. A sale made at a discount is not a full-price sale with a note attached. Revenue, tax, and any commission owed on it all have to be calculated on what was actually paid, not on the sticker price, and the money has to get booked correctly even if "finance" is one person with a spreadsheet, or the monthly numbers stop matching the bank and someone spends an afternoon finding out why.
The fourth stop is every refund that ticket will ever cause. Six months from now, a customer who used that code returns the item. Do you refund what they paid, or the full price on the listing? Get that wrong and you have quietly become a business that sometimes pays customers more than they gave you.
None of that is written in the ticket. All of it is the part of the job that is still yours.
The same shape shows up anywhere a ticket looks smaller than it is. A field that looks like one column touches five. A toggle that looks like a single boolean touches billing, permissions, and an email that fires the moment it flips. The ticket never says any of that. Seeing it anyway, before the first line, is the job now.
An agent will happily write the discount field. It validates the code, applies the percentage, and returns a clean number to the page, because that is exactly what the ticket asked for. It has no way to know your refund window, how your finance team books discounted revenue, or what happens the day two codes are allowed to stack on the same order. That knowledge does not live in a tutorial anywhere. It lives in your product, your data, and the way your company already handles money.
That is the part of engineering a tool cannot hand you. Clean code is a skill a tool can now point at and match. Seeing the four stops before you write the first line is not.
Here is where it gets easy to measure yourself by the wrong number. If you spend the next few months grading your own worth by how clean the discount field turns out, how tight the diff is, how fast you shipped it, you are grading yourself on the part of the job that just went free. You built real things with that code, and that is a real skill. But an agent produces it now in less time than it takes you to describe the field, and if that is still where you look for your value, you will be measuring none of the leverage you are actually gaining.
I built a course around practicing exactly this: running the discount-code ticket, and ones like it, with an agent doing the typing while you do the seeing.
Shipping the field faster was never the point. Naming the four things the ticket never mentioned, before anyone has to ask, is.
P.S. The framework for spotting everything a ticket actually touches, before you write the first line, is free: https://systemthinkinglab.ai/learn/building-blocks/decision-framework/