[{"data":1,"prerenderedAt":235},["ShallowReactive",2],{"nav-categories":3,"tag-reflection":7},{"pinned":4,"overflow":6},[5],"Technology",[],[8],{"id":9,"title":10,"body":11,"category":5,"date":218,"description":219,"extension":220,"image":221,"imageCredit":222,"imageCreditUrl":223,"meta":224,"navigation":225,"path":226,"seo":227,"stem":228,"tags":229,"__hash__":234},"posts\u002Fblog\u002Fan-antidote-to-speed.md","An Antidote To Speed",{"type":12,"value":13,"toc":205},"minimark",[14,18,21,24,27,30,33,36,41,44,47,50,54,62,65,68,71,77,81,84,87,90,94,97,100,103,106,109,115,118,122,125,128,136,146,149,152,157,160,163,166,169,172,175,179,188,191,194,197],[15,16,17],"p",{},"There is a particular seduction to speed. With tools like Claude Code, you can\nmove from idea to working implementation in minutes: scaffolding an API, wiring\nup a frontend, resolving a class of bugs that would have taken hours before. It\nfeels like flying. The feedback loop tightens, the backlog shrinks, and you find\nyourself shipping things you would have deferred indefinitely only a year or two\nago.",[15,19,20],{},"(Trust me on that 😉 I am something of an expert procrastinator)",[15,22,23],{},"As of late, I have been fortunate to contribute in environments where there is a\ngeneral top-down appetite for the adoption of frontier tooling.",[15,25,26],{},"The problems are varied, sometimes interesting, sometimes rote mental skirmishes\nbut often come with real scale and opportunity to optimise how one works day to\nday. Not everyone gets that, and I do not take it for granted.",[15,28,29],{},"However, speed has a shadow. The faster you move through a problem, the thinner\nyour understanding of it can become. You can find yourself holding a codebase\ntogether with solutions you didn't fully author (more often than not these\ndays), patterns you haven't internalised, and abstractions you haven't\nstress-tested mentally.",[15,31,32],{},"For me, a certain dissonance occurs when you tell your digital co-worker that\nthey are an industry expert with 450 years of experience and voilà... a codebase\nappears.",[15,34,35],{},"The code works. How much is understood? Well, that is the question.",[37,38,40],"h2",{"id":39},"the-problem-with-always-moving-fast","The Problem With Always Moving Fast",[15,42,43],{},"When a tool produces a working result almost immediately, the temptation is to\naccept it and move on. Why dwell on the implementation when the tests are green\nand the feature is deployed? The incentive to slow down disappears because there\nis no visible cost to going fast.",[15,45,46],{},"The cost shows up later. It arrives when you need to extend something and\nrealise you do not actually understand the model it was built on. It surfaces\nwhen a subtle bug appears in production, and you stare at the code as though\nreading someone else's handwriting, and it becomes visible in a code review\nwhere you cannot explain a decision you nominally made.",[15,48,49],{},"This is not unique to AI-assisted development. Senior engineers have always\ncautioned against copy-pasting Stack Overflow answers without understanding\nthem. What AI tools do is raise the ceiling on how fast you can accumulate\nsurface-level understanding. The gap between what you have shipped and what you\ntruly know can grow quickly and quietly.",[37,51,53],{"id":52},"what-slowing-down-actually-means","What Slowing Down Actually Means",[15,55,56,57,61],{},"Slowing down does not mean going back to writing every line by hand, nor does it\nmean distrusting tools that make you ",[58,59,60],"em",{},"more"," productive. It means being\ndeliberate about when you engage deeply versus when you delegate freely. Breadth\nand depth are not inherently mutually exclusive. To consider otherwise is a\npolarised philosophy.",[15,63,64],{},"There are moments in a working day that are worth protecting from speed. When\nyou encounter a new concept, be it a design pattern, a protocol, or a language\nfeature, resist the urge to generate an example and move on. Spend time with the\nprimary source, read the RFC, work through the algorithm on paper if it helps.\nBuild the toy implementation that no one will ever ship, just to feel how the\nthing actually works.",[15,66,67],{},"There are also moments when the right response to a generated solution is not\nacceptance but interrogation. Ask why the code is structured the way it is.\nRewrite it yourself without looking. Try to break it. These habits feel\ninefficient in any given moment, but they are how understanding compounds.",[15,69,70],{},"Not all ideas are meant to survive, and that is fine. One underrated quality of\nmodern tooling is how quickly it can help you stress-test a concept and discard\nit. The goal is not to preserve every generated solution but to understand why\nyou are keeping the ones you do.",[72,73,74],"blockquote",{},[15,75,76],{},"Einstein called compound interest the eighth wonder of the world. He was\ntalking about money. The same logic applies to understanding. The person who\ninvests a little comprehension every day ends up, quietly and without drama,\nin a completely different place to the one who just keeps moving.",[37,78,80],{"id":79},"the-distinction-between-speed-and-progress","The Distinction Between Speed and Progress",[15,82,83],{},"Speed and progress are not the same thing, even though they feel identical when\nyou are deep in a flow. You can move very fast and accumulate very little\nunderstanding. You can also move slowly and build a mental model that pays\ndividends for years.",[15,85,86],{},"The best engineers learn to read the difference in themselves. There is a\nparticular quality of engagement when you are genuinely learning: a slight\nfriction, a need to pause, a sense of things clicking into place. When this\nfeeling is absent for too long, it is usually a sign that you have been\nexecuting rather than thinking.",[15,88,89],{},"This is not an argument against execution. Execution is how things get built.\nBut most engineers who do this work long enough find that the periods of deep\nlearning, the weeks spent really understanding a distributed systems concept, or\na type system, or a network protocol, are the periods that most change what they\nare capable of building.",[37,91,93],{"id":92},"carving-space-in-a-world-that-rewards-output","Carving Space In A World That Rewards Output",[15,95,96],{},"Practically speaking, how do you protect time for depth when the ambient\npressure is always toward shipping? This is partly a personal discipline and\npartly a structural question about how you organise your work.",[15,98,99],{},"On the personal side, it helps to name what you are doing and be specific about\nit. There is a difference between \"I am going to build this feature\" and \"I am\ngoing to understand this concept well enough to build this class of feature\nconfidently.\" The second goal is harder to measure, which is exactly why it\ntends to get crowded out.",[15,101,102],{},"Some engineers keep a running list of things they have used but not truly\nunderstood: concepts, libraries, patterns, language features. Periodically\nrevisiting that list and picking one thing to go deep on turns a vague sense of\naccumulated debt into something manageable and intentional.",[15,104,105],{},"It also helps to notice when the tools are doing cognitive work you should\nprobably be doing yourself. If you are generating code and not reading it\ncarefully, that is a signal. If you are accepting explanations without\nquestioning them, that is another.",[15,107,108],{},"This doesn't imply line by line examination but at least understanding how any\nsystem operates is crucial for longevity of said system. This applies well\nbeyond the realm of software engineering.",[15,110,111],{},[112,113,114],"strong",{},"The tools are most valuable when they accelerate work you already understand,\nnot when they substitute for understanding you have not yet built.",[15,116,117],{},"This is why I believe it is a hard time for the up and coming younger generation\nof engineers and knowledge workers in general. And why wouldn't it be? This\nlandscape is completely uncharted. No human generation alive has been here\nbefore.",[37,119,121],{"id":120},"checkpoints-supply-lines","Checkpoints & Supply Lines",[15,123,124],{},"I have a great fondness for military history, so allow me to indulge in some\nanalogies here.",[15,126,127],{},"Abraham Wald identified a relevant trap during the Second World War. The US Army\nAir Forces analysed bullet holes on returning B-17 Flying Fortresses and B-24\nLiberators and proposed reinforcing the damaged areas. Wald pointed out the\nflaw: those were the planes that made it back. The ones hit where the holes were\nabsent never returned to be counted. Reinforce the parts that look fine, because\nthat is where the fatal hits land.",[15,129,130],{},[131,132],"img",{"alt":133,"src":134,"title":135},"Illustration of hit points","\u002Fimages\u002Fblog\u002Fbomber.png","Martin Grandjean, McGeddon, Cameron Moll — CC BY-SA 4.0",[15,137,138,139,145],{},"A detailed write-up of this counterintuitive thinking is available here\n",[140,141,142],"a",{"href":142,"rel":143},"https:\u002F\u002Fwww.warhistoryonline.com\u002Fwar-articles\u002Fabraham-wald.html",[144],"nofollow",".",[15,147,148],{},"I like to think that the same bias operates in fast-moving engineering. The\nreturning planes are your shipped features and green tests. Everything looks\nfine.",[15,150,151],{},"The vulnerabilities are in what you cannot see: the understanding you never\nbuilt, the decisions you accepted without interrogating. You do not see that\ndamage until it matters.",[153,154,156],"h3",{"id":155},"choking-an-advance","Choking An Advance",[15,158,159],{},"One of the most consistent lessons in military history is that armies which\nadvance too quickly outrun their supply lines. The front moves forward, but the\nlogistics cannot keep pace. The advance that looked like strength becomes a\nliability the moment it is tested. Choking off the supply lines leads to\nultimate failure.",[15,161,162],{},"If a concept has grown so complex due to not taking stock from time to time, the\nnatural part of us may potentially see it as a source of anxiety. The concept is\nstarving.",[15,164,165],{},"The same dynamic applies to how understanding follows velocity in software work.\nYou can push the front line faster than at any point in history, shipping\nfeatures, integrating new libraries, building on unfamiliar abstractions. But if\nyour comprehension of the ground you have covered does not keep up, you have no\nsolid base to fall back on when something breaks.",[15,167,168],{},"The answer is a blend of sane strategy and flexible tactics. Strategically, you\nhave to accept that comprehension must keep pace with output, or the whole\nadvance becomes fragile. Tactically, the mechanism is the checkpoint: a\ndeliberate pause after meaningful work to consolidate understanding before\npushing further. It is not a retreat as much as it is the thing that makes the\nnext advance sustainable.",[15,170,171],{},"In practice, this means treating the completion of a meaningful piece of work as\na trigger for reflection, not just a cue to start the next thing. Feature\nshipped, module built, system integrated: stop and ask what you actually\nunderstand about what you just built. Where are the gaps? What did you accept on\nfaith? What would you struggle to explain or reproduce without the tool's help?",[15,173,174],{},"This kind of checkpoint does not need to be long. Even ten or fifteen minutes\nspent genuinely reviewing what you built and why it is structured the way it is\ncan meaningfully close the gap between execution and understanding.",[37,176,178],{"id":177},"conclusion","Conclusion",[15,180,181,182,187],{},"The speed that AI tools make available is genuinely valuable, and there is\nnothing virtuous about going slow for its own sake. The\n",[140,183,186],{"href":184,"rel":185},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FLuddite",[144],"Luddites"," didn't really win their battle\nafter all.",[15,189,190],{},"The goal is not to resist these tools but to use them well, which means staying\nhonest about what you understand and what you are merely executing.",[15,192,193],{},"The engineers who will do the most interesting work with these tools are not\nnecessarily the ones who use them most intensively. They are the ones who know\nwhen to put them down, sit with a hard problem, and let understanding catch up\nwith output.",[15,195,196],{},"That balance is worth protecting. In a world that increasingly rewards velocity,\nthe willingness to slow down is not a weakness. It is a discipline.",[72,198,199,202],{},[15,200,201],{},"Slow is smooth and smooth is fast.",[15,203,204],{},"Some tough guys",{"title":206,"searchDepth":207,"depth":207,"links":208},"",2,[209,210,211,212,213,217],{"id":39,"depth":207,"text":40},{"id":52,"depth":207,"text":53},{"id":79,"depth":207,"text":80},{"id":92,"depth":207,"text":93},{"id":120,"depth":207,"text":121,"children":214},[215],{"id":155,"depth":216,"text":156},3,{"id":177,"depth":207,"text":178},"2026-05-14","The case for occasionally slowing down in a world of AI-accelerated development and why your cognitive supply lines matter as much as your perceived velocity.","md","\u002Fimages\u002Fblog\u002Fdeer-eating-trees.jpg","Natalia Gutnik","https:\u002F\u002Fwww.instagram.com\u002F__dust__in__the__wind__?igsh=MTEwd28zZ2Nta3IwNQ==",{},true,"\u002Fblog\u002Fan-antidote-to-speed",{"title":10,"description":219},"blog\u002Fan-antidote-to-speed",[230,231,232,233],"ai","productivity","learning","reflection","mtu0xxGs7zSfW0G5OZHBjXE-n6v8rpUhlqC84KZBPI4",1778858904779]