{ "archive_path": "archive/1753339533.903598", "base_url": "hazelweakly.me/blog/stop-building-ai-tools-backwards", "basename": "", "bookmarked_date": "2025-07-24 06:45", "canonical": { "archive_org_path": "https://web.archive.org/web/hazelweakly.me/blog/stop-building-ai-tools-backwards", "dom_path": "output.html", "favicon_path": "favicon.ico", "git_path": "git/", "google_favicon_path": "https://www.google.com/s2/favicons?domain=hazelweakly.me", "headers_path": "headers.json", "htmltotext_path": "htmltotext.txt", "index_path": "index.html", "media_path": "media/", "mercury_path": "mercury/content.html", "pdf_path": "output.pdf", "readability_path": "readability/content.html", "screenshot_path": "screenshot.png", "singlefile_path": "singlefile.html", "warc_path": "warc/", "wget_path": null }, "domain": "hazelweakly.me", "downloaded_at": "2025-07-24T06:45:37.565004+00:00", "downloaded_datestr": "2025-07-24 06:45", "extension": "", "hash": "13AFCFG5BEX4BXBXNZ6M", "history": { "archive_org": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://web.archive.org/save/https://hazelweakly.me/blog/stop-building-ai-tools-backwards/" ], "cmd_version": "8.10.1", "end_ts": "2025-07-24T06:47:14.868460+00:00", "index_texts": null, "output": "https://web.archive.org/web/20250724064658/https://hazelweakly.me/blog/stop-building-ai-tools-backwards/", "pwd": "/data/archive/1753339533.903598", "schema": "ArchiveResult", "start_ts": "2025-07-24T06:46:54.475029+00:00", "status": "succeeded" } ], "dom": [ { "cmd": [ "/usr/bin/chromium-browser", "--proxy-server=socks5://tor-socks-proxy:9150", "--disable-features=DarkMode", "--run-all-compositor-stages-before-draw", "--hide-scrollbars", "--autoplay-policy=no-user-gesture-required", "--no-first-run", "--use-fake-ui-for-media-stream", "--use-fake-device-for-media-stream", "--simulate-outdated-no-au='Tue, 31 Dec 2099 23:59:59 GMT'", "--headless=new", "--no-sandbox", "--no-zygote", "--disable-dev-shm-usage", "--disable-software-rasterizer", "--disable-sync", "--window-size=1440,2000", "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "--user-data-dir=/data/personas/Default/chrome_profile", "--profile-directory=Default", "--dump-dom", "https://hazelweakly.me/blog/stop-building-ai-tools-backwards/" ], "cmd_version": "131.0.6778", "end_ts": "2025-07-24T06:45:59.635619+00:00", "index_texts": null, "output": "output.html", "pwd": "/data/archive/1753339533.903598", "schema": "ArchiveResult", "start_ts": "2025-07-24T06:45:48.434132+00:00", "status": "succeeded" } ], "favicon": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--output", "favicon.ico", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://www.google.com/s2/favicons?domain=hazelweakly.me" ], "cmd_version": "8.10.1", "end_ts": "2025-07-24T06:45:41.644183+00:00", "index_texts": null, "output": "favicon.ico", "pwd": "/data/archive/1753339533.903598", "schema": "ArchiveResult", "start_ts": "2025-07-24T06:45:38.466695+00:00", "status": "succeeded" } ], "git": [], "headers": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://hazelweakly.me/blog/stop-building-ai-tools-backwards/" ], "cmd_version": "8.10.1", "end_ts": "2025-07-24T06:45:41.948582+00:00", "index_texts": null, "output": "headers.json", "pwd": "/data/archive/1753339533.903598", "schema": "ArchiveResult", "start_ts": "2025-07-24T06:45:41.700175+00:00", "status": "succeeded" } ], "htmltotext": [ { "cmd": [ "(internal) archivebox.extractors.htmltotext", "./{singlefile,dom}.html" ], "cmd_version": "0.8.5rc51", "end_ts": "2025-07-24T06:46:40.448678+00:00", "index_texts": [ "Stop Building AI Tools Backwards | Hazel Weakly (https://hazelweakly.me/manifest.json) (Atom Feed for Hazel Weakly) (/atom.xml) (RSS Feed for Hazel Weakly) (/rss.xml) (JSON Feed for Hazel Weakly) (/feed.json) (https://hachyderm.io/@hazelweakly) (/fonts/italiana-v16-latin-regular.woff2) (/fonts/zilla-slab-v11-latin-400.woff2) (/theme.css) (/theme.css) (/apple-touch-icon.png) (/favicon-32x32.png) (/favicon-16x16.png) (/fonts/zilla-slab-v11-latin-400italic.woff2) (/fonts/zilla-slab-v11-latin-700.woff2) Skip to content (/) Home (/blog/) Blog (/media/) Media Listing (/about/) About Me Color mode is now \"light\" Stop Building AI Tools Backwards I\u2019ve been reading this week about how humans learn, and effective ways of transferring knowledge. In addition, I\u2019ve also had AI in the back of my mind, and recently I\u2019ve come to the realization that not only is our industry building AI tools poorly, we\u2019re building them backwards. Which, honestly, is really depressing to me because there is so much unrealized potential that we have available\u2013is it not enough that we built the LLMs unethically, and that they waste far more energy than they return in value? On top of that, it doesn\u2019t take that much extra effort to build the tooling in a way that facilitates how humans work together; the tooling could be built to improve our capabilities by making everybody more effective, rather than by deskilling critical reasoning loops for practitioners. Here\u2019s how that might look. The Human Part First: How we learn. My favorite (evidence backed) theory on how humans learn is (https://www.learningscientists.org/blog/2024/3/7/how-does-retrieval-improve-new-learning) Retrieval Practice . The short of it is that humans don\u2019t really learn when we download info into our brain, we learn when we expend effort to pull that info out. This has some big implications for designing collaborative tooling! Second: What we learn. It turns out, the \u201cthing\u201d that we learn most effectively is not knowledge as we typically think of it, it\u2019s process . This should be intuitive, if we put into a bit of a more natural context. Imaging learning baking for a moment: Do you teach someone to bake a cake by spitting out a fact sheet of ingredients and having them memorize it? Or do you teach them the process? Third: How we level up. Humans are really bad at \u201cnovel\u201d innovation, which is a bit tragic because novel innovation seems to be the thing that the tech industry thinks of when it talks about developer productivity. We surround ourselves with the myth of the solo genius, we benchmark developers on individual contributions, and expect people to implement code by themselves. Yet, it turns out that sustained solo innovation is both extremely rare, and also not that important in the grand scheme of things. It\u2019s much more like the sprinkles on top of a cupcake, rather than the main course; simply put, it\u2019s not how innovation generally happens. However! We\u2019re really good at cumulative iteration. Humans are turbo optimized for communities, basically. This is why brainstorming is so effective\u2026 But usually only in a group. There is an entire theory in cognitive psychology about cumulative culture that goes directly into this and shows empirically how humans work in groups. Humans learn collectively and innovate collectively via copying, mimicry, and iteration on top of prior art. You know that quote about standing on the shoulders of giants? It turns out that it\u2019s not only a fun quote, but it\u2019s fundamentally how humans work. Also, innovation and problem solving? Basically the same thing. If you get good at problem solving, propagating learning, and integrating that learning into the collective knowledge of the group, then the infamous Innovator\u2019s Dilemma disappears. So, combine all of those bits of information together, what do we get? Humans learn and teach via process Processes need to take a goldilocks amount of effort to be effective Cumulative iteration > solo developer problem solving We build tools to help us think, not to think for us The AI Part Now, here\u2019s the main pattern I see AI tooling doing: Click AI button -> \u2728 magic \u2728 View data -> AI Suggestions Action prompt -> AI initiation What\u2019s missing? Human retrieval and task initiation, process reinforcement, collective knowledge transfer, and iterative improvements\u2026 Y\u2019know, the whole set of criteria that humans need in order to be effective? This is wild, we\u2019re taking the one thing humans are good at and making AI do it. But AI is bad at it! Even worse: if humans get bad at it then we\u2019ve lost the one thing we had going for us as a species! Which means we end up deskilling humans faster than we improve AI, and the humans can\u2019t improve the AI because we\u2019re no longer feeding AI the high quality data it can use to augment human excellence. It\u2019s a self-reinforcing feedback loop\u2026 Spiraling rapidly downwards into ineffective systems. I\u2019m already seeing negative consequences of this\u2013constantly\u2013and it\u2019s heartbreaking. However, a small change to how AI interactions are built can help reverse this. Building Better AI Tools Oftentimes, people try to provide an analogy of AI as an intern or as a co-worker, and candidly, I don\u2019t like either of these. This is because it doesn\u2019t, to me, convey an intuition around the right way to build (or interact with) an AI tool that will help you get better at doing what you do. So instead, as an analogy, I like to imagine AI as an \u201cabsent-minded instructor\u201d, not as a coworker. It\u2019s prone to forgetting details, but ultimately there to guide you; most importantly, the goal of the instructor is to make sure you learn and learn how to learn! If you want to be a bit snarky about it, you can alternatively think of AI as a very overconfident rubber duck that exclusively uses the Socratic method, is prone to irrelevant tangents, and is weirdly obsessed with quirky hats. Whatever floats your ducky. So, I\u2019m going to walk through one of the anti-patterns I see in AI tooling and fix it by taking an evidence-based teaching process and imagining it augmented with AI. The teaching process, by the way, is: Explain, Demonstrate, Guide, Enhance. If you\u2019ve ever been in scouting, you\u2019ll recognize this as their EDGE method with a small difference; rather than \u201cenable\u201d, I\u2019m using \u201cenhance\u201d. The reason for that is because \u201cenable\u201d is about having someone perform the action, but we are already sprinkling human actions all the way through the process. Instead, \u201cenhance\u201d is going to be about feeding that human action into the next iteration of problem solving, so that the next time someone does something, they get even better. Ideally, we want to encourage and inspire even more ambitious tasks, guiding people towards increasingly effective actions. (The theory behind EDGE and similar methodologies is (https://www.cell.com/trends/cognitive-sciences/abstract/S1364-6613(10)00208-1) Retrieval Practice . It turns out to be highly general, and there\u2019s a million ways to do it, but I picked this for the example because it matches how I would teach an early career engineer the process of managing an incident, as well as the mental models and strategies I use when thinking through said process.) The running example is gonna be incident management with observability tooling being used to diagnose and remediate the incident. While we\u2019re at it, the anti-pattern we\u2019re going to fix is \u201cGiven a prompt sent to a human, immediately initiate a response with AI.\u201d I picked this one because it\u2019s the one I see the most marketing on and it also has some of the most damaging potential for human expertise: in short, it\u2019s the one thing you absolutely don\u2019t ever, for any reason, want to implement with incident management and observability tooling. What Better AI Tooling Looks Like Let\u2019s set the stage of the story\u2026 It\u2019s way-too-late o\u2019clock and our human is fast asleep. But what\u2019s that I hear? (the author writes, ironically, being profoundly Deaf\u2026) Oh no! The pager! Something\u2019s on fire! What does the human do? Well, they\u2019re going to acknowledge that they\u2019re responding to the incident, and then\u2026 They\u2019re going to start by opening up the observability tool, right? So that\u2019s where we\u2019re going to start. The most important thing here is that when the human opens the observability tool, they have to actively, and with some effort, recall (or retrieve) the process of what to do next. This is crucial. If your process is so baroque and messed up that people can\u2019t remember what to do next, you should stop reading this article and fix that; AI can\u2019t save you from a 97-step-guide-to-hating-your-life. But alrighty, the human has recalled the process of incident management! Heck yeah! Now, we\u2019ve got our fancy AI tooling because we\u2019re living in the \u2728 future \u2728. What should AI do, here? (NO, it\u2019s not auto investigate.\" Auto fix? NOPE!) Let\u2019s walk through that EDGE (Explain, Demonstrate, Guide, Enhance) process and see what helpful, human enhancing, AI tooling looks like. Additionally, I\u2019m a little weird, so I\u2019m going to call any AI-assisted action here an \u2018interaction\u2019 to help reinforce that effective AI tooling is about amplifying human effectiveness. Remember: AI should be an amplifier, not an obfuscater. Explain Here\u2019s what some good interactions look like Suggest missing steps (ex: \u201chave you tried turning it off and on?\u201d, \u201ccan you rollback the deployment before investigating further?\u201d, \u201cdo you wanna filter?\u201d) Pull up the incident process guide (and help explain it) Here\u2019s what some bad interactions look like \u201cclick this button to perform an action\u201d \u201cexplain this error\u201d tooltips or buttons Why? Because they remove human retrieval from the process and humans have no way to interact with the interface and evolve it from providing an unhelpful interaction to providing a helpful one. This is going to be a running theme. Retrieval is something that needs constant reinforcement so that humans continue to get increasingly effective at it. Demonstrate Here\u2019s what some good interactions look like Turn human query into system query syntax (eg turning \u201cwhat are the top 10 slowest endpoints for the service I care about?\u201d into the query syntax of your observability tool) Turns human asks into UI discovery (eg a human says \u201ccan I see the SLOs for this service and the downstream customers?\u201d and the AI provides a link to the SLO page of the tool) Turn task execution questions into dynamic 15 second demos (eg a human asks \u201chow do I compare two time ranges?\u201d -> Provide a short animation of the process, or an interactive click-through-these-steps) I know, I know, it\u2019s so tempting to provide a button that says \u201cclick me to do the thing\u201d. DON\u2019T. Not only does it deskill the human, but what if you mess it up and waste everyone\u2019s time? Trust is crucial for developer tooling and you will not get it back. Lastly, think about it: when\u2019s the last time you clicked an \u201cauto do the thing\u201d button and then didn\u2019t want to do several follow-up modifications of that same process? Making humans chew through a zillion tokens in order to get a simple task done is a great way to take your friction-reducing interaction and turn it into a friction-introducing interaction. As an aside: Yes, humans should be able to add data to this. If I\u2019m pairing with a developer that I\u2019m mentoring and I\u2019m teaching them how to do a thing, I want the AI to be able to demonstrate similar things in the future using my actions as a starting point. Any human recall task is extremely high quality data for training and fine-tuning. Use it! Guide Here\u2019s what some good interactions look like \u201cYou seem stuck on X. Do you want to try investigating Y?\u201d (if and only if the human provided a high level plan of what they\u2019re going to investigate) \u201cDo you want to ping the code owner? Would you like to view the documentation for the service?\u201d human: \u201cI\u2019m stuck\u201d -> AI: \u201cwhat are you stuck on?\u201d -> (human answer) -> AI response Suggest mental model(s) for concept Z, providing references to company documentation \u201cShould we document that? Is this something we need to page another team about?\u201d or other questions a helpful human might ask during an incident \u201cCan you tell me what steps you\u2019re trying to accomplish?\u201d Validating responses by assessing how sensible they seem, cross checking information the human provides with information the AI can verify, asking the human for clarification if the AI detects inconsistencies Here\u2019s what some bad interactions look like \u201cim stuk, pls help\u201d. Make the human give you an answer before providing a response; do it socratic style if you have to Providing information humans didn\u2019t ask for Correcting human responses or doing fact-checking in an authoritative tone \u201cGuiding\u201d but it feels like backseat driving by someone who would rather do it themselves (In general: if you give someone a \u201ccontinue\u201d button, or a generic \u201cprovide next hint/step/action\u201d button, they will probably learn to just spam the button and then they will break things accidentally because it\u2019s there. It breaks the human reasoning loop.) Enhance Here\u2019s what some good interactions look like After/during an action, suggest an incremental improvement (eg: filtering by time range -> provide five-minutes-before-the-alert-fired as an option) Revealing UI: if someone performs a compound action, give them a shortcut next time (eg: click on trace -> copy trace_id? Dynamically surface a \u201ccopy trace ID\u201d button) Comparing services A and B repeatedly? Suggest split UI You can also suggest enhancements to existing Processes If the tool identifies people performing N queries to grab data? Suggest infra pipeline improvements Suggest alert refinements if the alerts aren\u2019t actionable often enough Detect manual indirect correlation (eg when people are relying on intuition), suggest instrumentation improvements Here\u2019s a real example: I had a team of people who would open an observability tool during debugging, look for slow endpoints, and then manually drill down to find abnormally slow database queries, and then intuit if it was because the database query plans had become suboptimal or that some cache had busted. Putting that information in the telemetry was not an idea they had thought about, but it was very helpful for them! Turn a scratchpad of notes into post incident learning material Notice how careful I am to avoid any enhancements that remove human reasoning from the loop? That\u2019s intentional! In fact: most enhancement suggestions are of the form of adding more recall prompts. They literally help embed micro-learning deeper into the process, organically. As a bonus: it helps people observing (https://link.springer.com/article/10.1007/s13752-020-00351-w) learn via osmosis , even if they\u2019re not actively involved in taking actions. Also, did you know there\u2019s actual real support for the idea that humans learn at the sub-action level just by observing? It\u2019s not necessarily the primary mechanism, but it contributes to the propagation of said knowledge and helps spread \u201chow we approach doing\u201d throughout teams very well. Humans are so neat, seriously. Ok, side tangent over. Describing the Pattern That was a lot of information! One thing that I want to look at, zooming back out a little bit, is that there are a general set of principles here: Reinforce human learning Help humans work better together Accelerate human execution in-process, don\u2019t remove it Never go from blank to outcome Tools should take the right amount of effort to use Incorporate team learning into the tool\u2019s output Another Example: Code Gen As a bonus, here\u2019s another example of utilizing this pattern (I\u2019ll be much briefer this time). It\u2019s a task that everyone developer does: code writing! It turns out, you shouldn\u2019t use AI to generate the code (first). Instead, work \u201cbackwards\u201d with the AI. Generate rough documentation, rough/high-level architecture diagrams, then a testing plan, then the tests, then stubbed feature-flagged code\u2026 THEN generate the code. Once the code passes the tests, work backwards over the entire process and use the existing code to improve the tests, flesh out the testing plan, polish the architecture diagrams, and finalize the documentation. Why? Because if you ask a human \u201cis this right?\u201d when they don\u2019t have a solution in mind, you\u2019re asking a validation-style question that humans can\u2019t assess. That\u2019s not retrieval, and even worse, we\u2019re really bad at it. Alternatively, if you ask socratic-shaped questions such as \u201cwhat should X do? How should it look? What\u2019s the data flow? How should it behave?\u201d Every step is retrieval! (As a bonus, LLM builders or fine-tuners now have a reliable source of extraordinarily high signal-to-noise ratio code if people follow these retrieval-driven-development patterns. Why AI tools don\u2019t heavily encourage this is beyond me, especially as they\u2019re all desperate for more high quality data.) Anyway\u2026 Untapped Potential I skimmed over cross-functional possibilities, because nobody in software engineering is super focused on that right now, unfortunately (especially in platform engineering where these types of tools are being built a lot). It makes sense: budgets are tight, team are scrambling, helping \u201cnot us\u201d out isn\u2019t the highest priority at the moment. I get it. But, truly, I think that cross-functional assistance is one of the highest impact areas of AI if done right. Here\u2019s one example of cross-functional potential. Imagine production is down, and customer support is getting a ton of emails about what\u2019s happening, what\u2019s impacted, is my stuff okay, etc Here\u2019s what could be possible, if anyone built it\u2026 Customer Support could phrase a few questions for the dev team, send 'em over, and get a two phased answer. First, an immediate rough draft from AI, saying something like \u201cHi, this is AI\u2019s guess at the answer. Don\u2019t send it to customers! But just FYI for you. Also I\u2019m pinging the devs to make sure it\u2019s correct.\u201d \u2013 Hypothetical AI response to the Customer Support team Neither Customer Support or the developer teams are stupid, if the answer that the AI is providing sounds like gibberish, it\u2019ll help the teams understand that they might need to get some face time with each other; crucially, this can be fielded by non ICs on either end if the ICs are deep in the middle of a focus crunch. As for the second phase of the answer: the developer team gets that series of questions from Customer Support. It might sound something like this \u201cHey customer support wants to know X Y and Z. Here\u2019s the answers I gave them, are they right? Is there anything you\u2019d change? Please let me know if this information is accurate enough to use for responding to customer questions.\u201d \u2013 Hypothetical AI pinging the developer team in an incident The development team (or their engineering manager, product manager, or someone else in the loop) can then review those answers and fix 'em if necessary, which is much faster than interrupting developer flow. This is an ok place for that! Also, this is still close enough to retrieval because we\u2019re actively asking developers to confirm that the information is sufficiently accurate; it\u2019s not always close enough to retrieval, but mid-incident, this shaping helps take a low priority \u201cnot now\u201d into an interaction that the team can perform without disrupting their flow. This is only the surface of the potential for improving cross-functional collaboration, however. What if the AI answer is deeply incorrect? Or the team needs to write a brand new answer? Rather than having the team perform a context heavy translation of the problem (in the moment when they\u2019d rather do literally anything else), give them the ability to write a fully technical, jargon heavy, and fragmented answer, and then use the AI to help rewrite that. Suppose the developers look at the first AI answer and reject it and reply back with \u201cyeah no. what\u2019s going on is that zk is borked, our sidekiq is backed up and redis is grumpy, we\u2019re mid thru traffic redir to a new AZ, we did blue and yellow. orange seems fine already? idk\u201d \u2013 A jargon heavy in-context summary during an incident While that\u2019s a useless reply for Customer Support as is (and probably useless to anyone not actively responding to the incident), but AI could turn that into a friendlier answer, and prompt developers for missing bits (like ETA). Plus, you probably have multiple tiers of support, too. Do you have business partners with technical experts asking through support for the \u201creal answer\u201d? What about tier-1 consumers? AI could help make it feasible to give both answers in an accurate way (after double checking with the team that the AI didn\u2019t mess up the expansion). That could then further be integrated with Customer Support software so that they see the live incident info, know when incidents are happening or resolved, and view live answers so that they aren\u2019t stuck fielding questions they don\u2019t know answers to. There\u2019s a ton of potential here, but until leadership teams begin perceiving building software for internal improvements to be as impactful, value wise, as shipping features, platform engineering teams likely won\u2019t be able to build this type of thing. In addition, without existing demand, it\u2019ll be hard to sell it or create the environmental conditions necessary for vendor integrations to start organically appearing. Sigh. /close_incident You know, it\u2019s funny. Originally, I thought to myself, \u201coh, this will be a short article and I\u2019m just going to kind of bang it out\u2026\u201d, and then it turns out that there\u2019s a reason my bio tagline says \u201cI have thoughts. Lots of thoughts. They never stop thinking. They never stop thunking.\u201d I\u2019m sure next time I\u2019ll remember to keep it concise-er. Maybe. Oh yeah, conclusion. Gotta get that catchy takeaway, right? (ahem) When it comes right down to it, we are building our AI tooling backwards. The backwards tooling is resulting in skill deficiencies and is de-skilling people by taking the one single thing that humans are really, really good at and attempting to have AI replace\u2013rather than augment\u2013that part of us. Naturally, we also managed to pick the thing that AI itself is extraordinarily bad: cumulative learning in a collaborative fashion (after all: it can neither reason, nor work collaboratively). To make matters worse, we feed those two broken processes into each other, creating a feedback loop that completely derails the effectiveness of human/computer interaction. Seriously, we need to cut that out. We don\u2019t have to do that, either! (I\u2019m not even making this up! There\u2019s evidence for this! Science!) If you build tools for collaborative learning, if you prioritize assisting and augmenting a human driven process over outputting exponential amounts of noise, then what you\u2019re going to end up doing is building tooling that helps humans get better at getting better. That, in turn, then helps the tooling get better, which then helps the humans get better; the result is the creation of a reinforcing positive feedback loop rather than reinforcing negative feedback loop. Please, y\u2019all, put the emphasis on humanity back into our tooling rather than pretending nothing matters, as if somehow humans will supposedly be irrelevant in a few years. Although, arguably, that human focus was never in our tooling in the first place\u2013I mean, let\u2019s be real here. Systems tooling is ripe for revolutionary changes in how they\u2019re imagined, how they\u2019re implemented, and how they\u2019re valued. But those changes will never materialize if we don\u2019t build them to be human-first. Don\u2019t just keep humans in the loop, remember that humans are the loop. (/calendar/) Calendar (/contact/) Contact (/resume/) R\u00e9sum\u00e9 (/speaker-rider/) Speaker Rider \u00a9 2025 Hazel Weakly " ], "output": "htmltotext.txt", "pwd": "/data/archive/1753339533.903598", "schema": "ArchiveResult", "start_ts": "2025-07-24T06:46:40.412382+00:00", "status": "succeeded" } ], "media": [ { "cmd": [ "/usr/local/bin/yt-dlp", "--restrict-filenames", "--trim-filenames", "128", "--write-description", "--write-info-json", "--write-annotations", "--write-thumbnail", "--no-call-home", "--write-sub", "--write-auto-subs", "--convert-subs=srt", "--yes-playlist", "--continue", "--no-abort-on-error", "--ignore-errors", "--geo-bypass", "--add-metadata", "--format=(bv*+ba/b)[filesize<=750m][filesize_approx<=?750m]/(bv*+ba/b)", "--skip-download", "--cache-dir=/data/yt-dlp-cache/", "--cookies=/data/yt-dlp-cache/cookies.txt", "--proxy=socks5://tor-socks-proxy:9150", "--no-playlist", "https://hazelweakly.me/blog/stop-building-ai-tools-backwards/" ], "cmd_version": "2024.10.7", "end_ts": "2025-07-24T06:46:54.415142+00:00", "index_texts": [], "output": "media/", "pwd": "/data/archive/1753339533.903598", "schema": "ArchiveResult", "start_ts": "2025-07-24T06:46:44.658857+00:00", "status": "succeeded" } ], "mercury": [ { "cmd": [ "/home/archivebox/.npm/bin/postlight-parser", "https://hazelweakly.me/blog/stop-building-ai-tools-backwards/" ], "cmd_version": "2.2.3", "end_ts": "2025-07-24T06:46:40.363843+00:00", "index_texts": null, "output": "mercury/", "pwd": "/data/archive/1753339533.903598", "schema": "ArchiveResult", "start_ts": "2025-07-24T06:46:36.911863+00:00", "status": "succeeded" } ], "pdf": [], "readability": [ { "cmd": [ "/home/archivebox/.npm/bin/readability-extractor", "/tmp/tmp2r5luzva", "https://hazelweakly.me/blog/stop-building-ai-tools-backwards/" ], "cmd_version": "0.0.11", "end_ts": "2025-07-24T06:46:14.581200+00:00", "index_texts": [ "I\u2019ve been reading this week about how humans learn, and effective ways of transferring knowledge. In addition, I\u2019ve also had AI in the back of my mind, and recently I\u2019ve come to the realization that not only is our industry building AI tools poorly, we\u2019re building them backwards. Which, honestly, is really depressing to me because there is so much unrealized potential that we have available\u2013is it not enough that we built the LLMs unethically, and that they waste far more energy than they return in value? On top of that, it doesn\u2019t take that much extra effort to build the tooling in a way that facilitates how humans work together; the tooling could be built to improve our capabilities by making everybody more effective, rather than by deskilling critical reasoning loops for practitioners. Here\u2019s how that might look.The Human PartFirst: How we learn. My favorite (evidence backed) theory on how humans learn is Retrieval Practice.The short of it is that humans don\u2019t really learn when we download info into our brain, we learn when we expend effort to pull that info out. This has some big implications for designing collaborative tooling!Second: What we learn. It turns out, the \u201cthing\u201d that we learn most effectively is not knowledge as we typically think of it, it\u2019s process. This should be intuitive, if we put into a bit of a more natural context. Imaging learning baking for a moment: Do you teach someone to bake a cake by spitting out a fact sheet of ingredients and having them memorize it? Or do you teach them the process?Third: How we level up. Humans are really bad at \u201cnovel\u201d innovation, which is a bit tragic because novel innovation seems to be the thing that the tech industry thinks of when it talks about developer productivity. We surround ourselves with the myth of the solo genius, we benchmark developers on individual contributions, and expect people to implement code by themselves. Yet, it turns out that sustained solo innovation is both extremely rare, and also not that important in the grand scheme of things. It\u2019s much more like the sprinkles on top of a cupcake, rather than the main course; simply put, it\u2019s not how innovation generally happens.However! We\u2019re really good at cumulative iteration. Humans are turbo optimized for communities, basically. This is why brainstorming is so effective\u2026 But usually only in a group. There is an entire theory in cognitive psychology about cumulative culture that goes directly into this and shows empirically how humans work in groups. Humans learn collectively and innovate collectively via copying, mimicry, and iteration on top of prior art. You know that quote about standing on the shoulders of giants? It turns out that it\u2019s not only a fun quote, but it\u2019s fundamentally how humans work.Also, innovation and problem solving? Basically the same thing. If you get good at problem solving, propagating learning, and integrating that learning into the collective knowledge of the group, then the infamous Innovator\u2019s Dilemma disappears.So, combine all of those bits of information together, what do we get?Humans learn and teach via processProcesses need to take a goldilocks amount of effort to be effectiveCumulative iteration > solo developer problem solvingWe build tools to help us think, not to think for usThe AI PartNow, here\u2019s the main pattern I see AI tooling doing:Click AI button -> \u2728 magic \u2728View data -> AI SuggestionsAction prompt -> AI initiationWhat\u2019s missing? Human retrieval and task initiation, process reinforcement, collective knowledge transfer, and iterative improvements\u2026 Y\u2019know, the whole set of criteria that humans need in order to be effective? This is wild, we\u2019re taking the one thing humans are good at and making AI do it. But AI is bad at it! Even worse: if humans get bad at it then we\u2019ve lost the one thing we had going for us as a species!Which means we end up deskilling humans faster than we improve AI, and the humans can\u2019t improve the AI because we\u2019re no longer feeding AI the high quality data it can use to augment human excellence. It\u2019s a self-reinforcing feedback loop\u2026 Spiraling rapidly downwards into ineffective systems. I\u2019m already seeing negative consequences of this\u2013constantly\u2013and it\u2019s heartbreaking.However, a small change to how AI interactions are built can help reverse this.Oftentimes, people try to provide an analogy of AI as an intern or as a co-worker, and candidly, I don\u2019t like either of these. This is because it doesn\u2019t, to me, convey an intuition around the right way to build (or interact with) an AI tool that will help you get better at doing what you do. So instead, as an analogy, I like to imagine AI as an \u201cabsent-minded instructor\u201d, not as a coworker. It\u2019s prone to forgetting details, but ultimately there to guide you; most importantly, the goal of the instructor is to make sure you learn and learn how to learn!If you want to be a bit snarky about it, you can alternatively think of AI as a very overconfident rubber duck that exclusively uses the Socratic method, is prone to irrelevant tangents, and is weirdly obsessed with quirky hats. Whatever floats your ducky.So, I\u2019m going to walk through one of the anti-patterns I see in AI tooling and fix it by taking an evidence-based teaching process and imagining it augmented with AI. The teaching process, by the way, is: Explain, Demonstrate, Guide, Enhance.If you\u2019ve ever been in scouting, you\u2019ll recognize this as their EDGE method with a small difference; rather than \u201cenable\u201d, I\u2019m using \u201cenhance\u201d. The reason for that is because \u201cenable\u201d is about having someone perform the action, but we are already sprinkling human actions all the way through the process. Instead, \u201cenhance\u201d is going to be about feeding that human action into the next iteration of problem solving, so that the next time someone does something, they get even better. Ideally, we want to encourage and inspire even more ambitious tasks, guiding people towards increasingly effective actions.(The theory behind EDGE and similar methodologies is Retrieval Practice. It turns out to be highly general, and there\u2019s a million ways to do it, but I picked this for the example because it matches how I would teach an early career engineer the process of managing an incident, as well as the mental models and strategies I use when thinking through said process.)The running example is gonna be incident management with observability tooling being used to diagnose and remediate the incident. While we\u2019re at it, the anti-pattern we\u2019re going to fix is \u201cGiven a prompt sent to a human, immediately initiate a response with AI.\u201d I picked this one because it\u2019s the one I see the most marketing on and it also has some of the most damaging potential for human expertise: in short, it\u2019s the one thing you absolutely don\u2019t ever, for any reason, want to implement with incident management and observability tooling.Let\u2019s set the stage of the story\u2026 It\u2019s way-too-late o\u2019clock and our human is fast asleep. But what\u2019s that I hear? (the author writes, ironically, being profoundly Deaf\u2026) Oh no! The pager!Something\u2019s on fire!What does the human do? Well, they\u2019re going to acknowledge that they\u2019re responding to the incident, and then\u2026 They\u2019re going to start by opening up the observability tool, right? So that\u2019s where we\u2019re going to start.The most important thing here is that when the human opens the observability tool, they have to actively, and with some effort, recall (or retrieve) the process of what to do next. This is crucial. If your process is so baroque and messed up that people can\u2019t remember what to do next, you should stop reading this article and fix that; AI can\u2019t save you from a 97-step-guide-to-hating-your-life.But alrighty, the human has recalled the process of incident management! Heck yeah! Now, we\u2019ve got our fancy AI tooling because we\u2019re living in the \u2728 future \u2728. What should AI do, here? (NO, it\u2019s not auto investigate.\" Auto fix? NOPE!)Let\u2019s walk through that EDGE (Explain, Demonstrate, Guide, Enhance) process and see what helpful, human enhancing, AI tooling looks like. Additionally, I\u2019m a little weird, so I\u2019m going to call any AI-assisted action here an \u2018interaction\u2019 to help reinforce that effective AI tooling is about amplifying human effectiveness. Remember: AI should be an amplifier, not an obfuscater.ExplainHere\u2019s what some good interactions look likeSuggest missing steps (ex: \u201chave you tried turning it off and on?\u201d, \u201ccan you rollback the deployment before investigating further?\u201d, \u201cdo you wanna filter?\u201d)Pull up the incident process guide (and help explain it)Here\u2019s what some bad interactions look like\u201cclick this button to perform an action\u201d\u201cexplain this error\u201d tooltips or buttonsWhy? Because they remove human retrieval from the process and humans have no way to interact with the interface and evolve it from providing an unhelpful interaction to providing a helpful one. This is going to be a running theme. Retrieval is something that needs constant reinforcement so that humans continue to get increasingly effective at it.DemonstrateHere\u2019s what some good interactions look likeTurn human query into system query syntax (eg turning \u201cwhat are the top 10 slowest endpoints for the service I care about?\u201d into the query syntax of your observability tool)Turns human asks into UI discovery (eg a human says \u201ccan I see the SLOs for this service and the downstream customers?\u201d and the AI provides a link to the SLO page of the tool)Turn task execution questions into dynamic 15 second demos (eg a human asks \u201chow do I compare two time ranges?\u201d -> Provide a short animation of the process, or an interactive click-through-these-steps)I know, I know, it\u2019s so tempting to provide a button that says \u201cclick me to do the thing\u201d. DON\u2019T. Not only does it deskill the human, but what if you mess it up and waste everyone\u2019s time? Trust is crucial for developer tooling and you will not get it back.Lastly, think about it: when\u2019s the last time you clicked an \u201cauto do the thing\u201d button and then didn\u2019t want to do several follow-up modifications of that same process? Making humans chew through a zillion tokens in order to get a simple task done is a great way to take your friction-reducing interaction and turn it into a friction-introducing interaction.As an aside: Yes, humans should be able to add data to this. If I\u2019m pairing with a developer that I\u2019m mentoring and I\u2019m teaching them how to do a thing, I want the AI to be able to demonstrate similar things in the future using my actions as a starting point. Any human recall task is extremely high quality data for training and fine-tuning. Use it!GuideHere\u2019s what some good interactions look like\u201cYou seem stuck on X. Do you want to try investigating Y?\u201d (if and only if the human provided a high level plan of what they\u2019re going to investigate)\u201cDo you want to ping the code owner? Would you like to view the documentation for the service?\u201dhuman: \u201cI\u2019m stuck\u201d -> AI: \u201cwhat are you stuck on?\u201d -> (human answer) -> AI responseSuggest mental model(s) for concept Z, providing references to company documentation\u201cShould we document that? Is this something we need to page another team about?\u201d or other questions a helpful human might ask during an incident\u201cCan you tell me what steps you\u2019re trying to accomplish?\u201dValidating responses by assessing how sensible they seem, cross checking information the human provides with information the AI can verify, asking the human for clarification if the AI detects inconsistenciesHere\u2019s what some bad interactions look like\u201cim stuk, pls help\u201d. Make the human give you an answer before providing a response; do it socratic style if you have toProviding information humans didn\u2019t ask forCorrecting human responses or doing fact-checking in an authoritative tone\u201cGuiding\u201d but it feels like backseat driving by someone who would rather do it themselves(In general: if you give someone a \u201ccontinue\u201d button, or a generic \u201cprovide next hint/step/action\u201d button, they will probably learn to just spam the button and then they will break things accidentally because it\u2019s there. It breaks the human reasoning loop.)EnhanceHere\u2019s what some good interactions look likeAfter/during an action, suggest an incremental improvement (eg: filtering by time range -> provide five-minutes-before-the-alert-fired as an option)Revealing UI: if someone performs a compound action, give them a shortcut next time (eg: click on trace -> copy trace_id? Dynamically surface a \u201ccopy trace ID\u201d button)Comparing services A and B repeatedly? Suggest split UIYou can also suggest enhancements to existing ProcessesIf the tool identifies people performing N queries to grab data? Suggest infra pipeline improvementsSuggest alert refinements if the alerts aren\u2019t actionable often enoughDetect manual indirect correlation (eg when people are relying on intuition), suggest instrumentation improvements Here\u2019s a real example: I had a team of people who would open an observability tool during debugging, look for slow endpoints, and then manually drill down to find abnormally slow database queries, and then intuit if it was because the database query plans had become suboptimal or that some cache had busted. Putting that information in the telemetry was not an idea they had thought about, but it was very helpful for them!Turn a scratchpad of notes into post incident learning materialNotice how careful I am to avoid any enhancements that remove human reasoning from the loop? That\u2019s intentional!In fact: most enhancement suggestions are of the form of adding more recall prompts. They literally help embed micro-learning deeper into the process, organically.As a bonus: it helps people observing learn via osmosis, even if they\u2019re not actively involved in taking actions. Also, did you know there\u2019s actual real support for the idea that humans learn at the sub-action level just by observing? It\u2019s not necessarily the primary mechanism, but it contributes to the propagation of said knowledge and helps spread \u201chow we approach doing\u201d throughout teams very well. Humans are so neat, seriously. Ok, side tangent over.Describing the PatternThat was a lot of information! One thing that I want to look at, zooming back out a little bit, is that there are a general set of principles here:Reinforce human learningHelp humans work better togetherAccelerate human execution in-process, don\u2019t remove itNever go from blank to outcomeTools should take the right amount of effort to useIncorporate team learning into the tool\u2019s outputAnother Example: Code GenAs a bonus, here\u2019s another example of utilizing this pattern (I\u2019ll be much briefer this time). It\u2019s a task that everyone developer does: code writing! It turns out, you shouldn\u2019t use AI to generate the code (first).Instead, work \u201cbackwards\u201d with the AI. Generate rough documentation, rough/high-level architecture diagrams, then a testing plan, then the tests, then stubbed feature-flagged code\u2026 THEN generate the code.Once the code passes the tests, work backwards over the entire process and use the existing code to improve the tests, flesh out the testing plan, polish the architecture diagrams, and finalize the documentation.Why? Because if you ask a human \u201cis this right?\u201d when they don\u2019t have a solution in mind, you\u2019re asking a validation-style question that humans can\u2019t assess. That\u2019s not retrieval, and even worse, we\u2019re really bad at it.Alternatively, if you ask socratic-shaped questions such as \u201cwhat should X do? How should it look? What\u2019s the data flow? How should it behave?\u201dEvery step is retrieval!(As a bonus, LLM builders or fine-tuners now have a reliable source of extraordinarily high signal-to-noise ratio code if people follow these retrieval-driven-development patterns. Why AI tools don\u2019t heavily encourage this is beyond me, especially as they\u2019re all desperate for more high quality data.)Anyway\u2026Untapped PotentialI skimmed over cross-functional possibilities, because nobody in software engineering is super focused on that right now, unfortunately (especially in platform engineering where these types of tools are being built a lot). It makes sense: budgets are tight, team are scrambling, helping \u201cnot us\u201d out isn\u2019t the highest priority at the moment. I get it. But, truly, I think that cross-functional assistance is one of the highest impact areas of AI if done right.Here\u2019s one example of cross-functional potential. Imagine production is down, and customer support is getting a ton of emails about what\u2019s happening, what\u2019s impacted, is my stuff okay, etc Here\u2019s what could be possible, if anyone built it\u2026Customer Support could phrase a few questions for the dev team, send 'em over, and get a two phased answer.First, an immediate rough draft from AI, saying something like\u201cHi, this is AI\u2019s guess at the answer. Don\u2019t send it to customers! But just FYI for you. Also I\u2019m pinging the devs to make sure it\u2019s correct.\u201d\u2013 Hypothetical AI response to the Customer Support teamNeither Customer Support or the developer teams are stupid, if the answer that the AI is providing sounds like gibberish, it\u2019ll help the teams understand that they might need to get some face time with each other; crucially, this can be fielded by non ICs on either end if the ICs are deep in the middle of a focus crunch.As for the second phase of the answer: the developer team gets that series of questions from Customer Support. It might sound something like this\u201cHey customer support wants to know X Y and Z. Here\u2019s the answers I gave them, are they right? Is there anything you\u2019d change? Please let me know if this information is accurate enough to use for responding to customer questions.\u201d\u2013 Hypothetical AI pinging the developer team in an incidentThe development team (or their engineering manager, product manager, or someone else in the loop) can then review those answers and fix 'em if necessary, which is much faster than interrupting developer flow. This is an ok place for that! Also, this is still close enough to retrieval because we\u2019re actively asking developers to confirm that the information is sufficiently accurate; it\u2019s not always close enough to retrieval, but mid-incident, this shaping helps take a low priority \u201cnot now\u201d into an interaction that the team can perform without disrupting their flow.This is only the surface of the potential for improving cross-functional collaboration, however. What if the AI answer is deeply incorrect? Or the team needs to write a brand new answer? Rather than having the team perform a context heavy translation of the problem (in the moment when they\u2019d rather do literally anything else), give them the ability to write a fully technical, jargon heavy, and fragmented answer, and then use the AI to help rewrite that. Suppose the developers look at the first AI answer and reject it and reply back with\u201cyeah no. what\u2019s going on is that zk is borked, our sidekiq is backed up and redis is grumpy, we\u2019re mid thru traffic redir to a new AZ, we did blue and yellow. orange seems fine already? idk\u201d\u2013 A jargon heavy in-context summary during an incidentWhile that\u2019s a useless reply for Customer Support as is (and probably useless to anyone not actively responding to the incident), but AI could turn that into a friendlier answer, and prompt developers for missing bits (like ETA).Plus, you probably have multiple tiers of support, too. Do you have business partners with technical experts asking through support for the \u201creal answer\u201d? What about tier-1 consumers? AI could help make it feasible to give both answers in an accurate way (after double checking with the team that the AI didn\u2019t mess up the expansion).That could then further be integrated with Customer Support software so that they see the live incident info, know when incidents are happening or resolved, and view live answers so that they aren\u2019t stuck fielding questions they don\u2019t know answers to.There\u2019s a ton of potential here, but until leadership teams begin perceiving building software for internal improvements to be as impactful, value wise, as shipping features, platform engineering teams likely won\u2019t be able to build this type of thing. In addition, without existing demand, it\u2019ll be hard to sell it or create the environmental conditions necessary for vendor integrations to start organically appearing. Sigh./close_incidentYou know, it\u2019s funny. Originally, I thought to myself, \u201coh, this will be a short article and I\u2019m just going to kind of bang it out\u2026\u201d, and then it turns out that there\u2019s a reason my bio tagline says \u201cI have thoughts. Lots of thoughts. They never stop thinking. They never stop thunking.\u201d I\u2019m sure next time I\u2019ll remember to keep it concise-er. Maybe.Oh yeah, conclusion. Gotta get that catchy takeaway, right? (ahem)When it comes right down to it, we are building our AI tooling backwards. The backwards tooling is resulting in skill deficiencies and is de-skilling people by taking the one single thing that humans are really, really good at and attempting to have AI replace\u2013rather than augment\u2013that part of us. Naturally, we also managed to pick the thing that AI itself is extraordinarily bad: cumulative learning in a collaborative fashion (after all: it can neither reason, nor work collaboratively). To make matters worse, we feed those two broken processes into each other, creating a feedback loop that completely derails the effectiveness of human/computer interaction.Seriously, we need to cut that out. We don\u2019t have to do that, either! (I\u2019m not even making this up! There\u2019s evidence for this! Science!)If you build tools for collaborative learning, if you prioritize assisting and augmenting a human driven process over outputting exponential amounts of noise, then what you\u2019re going to end up doing is building tooling that helps humans get better at getting better. That, in turn, then helps the tooling get better, which then helps the humans get better; the result is the creation of a reinforcing positive feedback loop rather than reinforcing negative feedback loop. Please, y\u2019all, put the emphasis on humanity back into our tooling rather than pretending nothing matters, as if somehow humans will supposedly be irrelevant in a few years. Although, arguably, that human focus was never in our tooling in the first place\u2013I mean, let\u2019s be real here.Systems tooling is ripe for revolutionary changes in how they\u2019re imagined, how they\u2019re implemented, and how they\u2019re valued. But those changes will never materialize if we don\u2019t build them to be human-first. Don\u2019t just keep humans in the loop, remember that humans are the loop." ], "output": "readability/", "pwd": "/data/archive/1753339533.903598", "schema": "ArchiveResult", "start_ts": "2025-07-24T06:46:03.874871+00:00", "status": "succeeded" } ], "screenshot": [], "singlefile": [], "title": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://hazelweakly.me/blog/stop-building-ai-tools-backwards/" ], "cmd_version": "8.10.1", "end_ts": "2025-07-24T06:46:00.444036+00:00", "index_texts": null, "output": "Stop Building AI Tools Backwards | Hazel Weakly", "pwd": "/data/archive/1753339533.903598", "schema": "ArchiveResult", "start_ts": "2025-07-24T06:46:00.294054+00:00", "status": "succeeded" } ], "wget": [] }, "icons": null, "is_archived": true, "is_static": false, "latest": { "archive_org": "https://web.archive.org/web/20250724064658/https://hazelweakly.me/blog/stop-building-ai-tools-backwards/", "dom": "output.html", "favicon": "favicon.ico", "git": null, "media": "media/", "pdf": null, "screenshot": null, "singlefile": null, "title": "Stop Building AI Tools Backwards | Hazel Weakly", "warc": null, "wget": null }, "link_dir": "/data/archive/1753339533.903598", "newest_archive_date": "2025-07-24T06:46:54.475029+00:00", "num_failures": 0, "num_outputs": 9, "oldest_archive_date": "2025-07-24T06:45:38.466695+00:00", "path": "/blog/stop-building-ai-tools-backwards/", "schema": "Link", "scheme": "https", "snapshot_abid": "snp_01K0XJW6MN22B29502012CYKF4", "snapshot_id": "51bcac67-4112-4cb4-bac2-022d44cf4de4", "sources": [ "/data/sources/1753339533-import.txt" ], "tags": null, "tags_str": "", "timestamp": "1753339533.903598", "title": "Stop Building AI Tools Backwards | Hazel Weakly", "url": "https://hazelweakly.me/blog/stop-building-ai-tools-backwards/" }