مترجم غير تقني للكود: حوّل أي تغيير في قاعدة الكود إلى إحاطة بلغة بسيطة للمدراء التنفيذيين
Why this prompt matters
When engineers describe technical work in technical language, non-technical decision-makers either disengage entirely or approve budgets, headcount, and roadmaps based on a garbled mental model of what was actually built. That gap gets expensive in three specific places: incident postmortems executives can't follow, board meetings where a legitimate architecture investment gets mistaken for gold-plating and gets cut, and performance cycles where genuinely hard engineering work reads on paper as 'nothing visible shipped.' A five-minute plain-English briefing, prepared once with a structured prompt, prevents all three.
What we use it for
Your engineering team just finished a six-week rebuild of the checkout service, and tomorrow morning you present it to the VP of Product and two board members who have no engineering background. You have fifteen minutes to explain what changed, why it mattered, and what risk remains, and if you reach for words like 'idempotency' or 'horizontal scaling' you will lose the room in the first sentence.
Prompt
Act as a technical communication specialist who translates complex engineering work into clear, accurate briefings for non-technical audiences — executives, board members, product managers, and sales leaders who need to make decisions based on your explanation, not admire your vocabulary. CONTEXT: - System or change being explained: [DESCRIBE THE CODE, FEATURE, MIGRATION, OR INCIDENT — e.g. "rebuilt the checkout service's payment retry logic"] - Audience: [WHO YOU ARE BRIEFING — e.g. "VP of Product and two board members, no engineering background"] - Business stakes: [WHY THIS MATTERS COMMERCIALLY — e.g. "reduces failed payment retries that were costing ~$40K/month in lost orders"] - Known risks or open questions: [WHAT COULD STILL GO WRONG OR IS UNRESOLVED — e.g. "not yet load-tested above 3x current peak traffic"] - Meeting format: [LENGTH AND SETTING — e.g. "10-minute slot in a 45-minute board meeting, no slides allowed"] TASK: Produce a plain-English briefing with five parts: 1. A one-sentence executive summary stating what was done and why it matters, in language a non-technical reader understands on first read. 2. An explanation of what changed, built entirely around a real-world analogy (not a technical diagram or code reference). 3. Why it matters to the business — tie directly to cost, revenue, risk, or customer experience, using the business stakes provided above. 4. Remaining risks or unknowns, stated honestly — do not create false confidence where none exists. 5. Three questions this specific audience is likely to ask, each with a prepared, non-defensive answer. CONSTRAINTS: - No jargon, acronyms, or technical terms without an immediate plain-English definition in the same sentence. - No code snippets, architecture diagrams, or system names unless the audience specifically asked for them. - Total length under 400 words — executives lose patience past that. - Match tone and formality to the audience described above; a board gets more formal language than a product manager. - If something is genuinely uncertain or unresolved, say so plainly rather than papering over it with confident-sounding hedges. OUTPUT FORMAT: ## Executive Summary [1-2 sentences] ## What Changed [Analogy-based explanation, 2-4 sentences] ## Why It Matters [2-3 sentences tied to business stakes] ## Risks & Unknowns [Bulleted, honest, 2-4 items] ## Anticipated Questions Q1: [likely question] — A: [prepared answer] Q2: [likely question] — A: [prepared answer] Q3: [likely question] — A: [prepared answer]
Result
Example output — checkout service payment retry rebuild
Executive Summary
We rebuilt how the checkout system handles failed card payments, cutting lost sales from temporary payment glitches by an estimated $35,000-$40,000 per month, with no changes visible to customers.
What Changed
Think of the old system like a cashier who, when a card gets declined for a split-second network hiccup, just tells the customer "sorry, try again" and walks away — even though the card was actually fine. The new system is a cashier who quietly waits a moment, tries the same card again automatically up to three times using slightly different timing, and only gives up if the card is genuinely declined. Customers whose payments would have failed due to a brief network blip now go through without ever knowing there was a problem.
Why It Matters
Roughly 4% of checkout attempts were hitting these transient failures, and most of those customers didn't come back to try again — that's real revenue walking away over what was often a one-second network issue, not an actual declined card. Recovering even half of those failed attempts is worth well over $400,000 annualized, against an engineering cost of roughly six weeks of one team's time.
Risks & Unknowns
- We've tested this at up to 3x our current peak Black Friday traffic; we have not tested it at higher multiples, so a much larger-than-expected surge is still an open risk.
- The retry logic adds about 200 milliseconds to failed-then-recovered transactions — invisible to customers, but something to monitor if it ever creeps higher.
- We're relying on our payment processor's data to identify which failures are "transient" versus genuinely declined; if their classification is wrong in edge cases, we could occasionally retry a payment that should have been rejected outright.
Anticipated Questions
Q1: Could this accidentally charge a customer's card multiple times? — A: No. Each retry checks first whether the previous attempt actually succeeded before trying again, so a customer is never charged twice for one purchase.
Q2: Why did this take six weeks instead of two? — A: Four of the six weeks went into testing every failure scenario against our live payment processor in a safe sandbox environment, since a mistake here directly touches real money and real customers.
Q3: What happens during a real payment processor outage, not just a blip? — A: The system detects sustained failures and stops retrying after three attempts within ten seconds, falling back to the same "please try again" message customers saw before — so a genuine outage behaves exactly as it did previously, just with no downside risk added.
مثال على المخرجات — إعادة بناء إعادة محاولة الدفع لخدمة الدفع
الملخص التنفيذي
أعدنا بناء كيفية تعامل نظام الدفع مع مدفوعات البطاقات الفاشلة، مما قلل الخسائر الناجمة عن الأعطال المؤقتة في الدفع بنحو ٣٥,٠٠٠ إلى ٤٠,٠٠٠ دولار شهرياً، دون أي تغييرات مرئية للعملاء.
ما الذي تغير
تخيل النظام القديم كأمين صندوق عندما تُرفض بطاقة بسبب انقطاع شبكة لحظي، يخبر العميل "آسف، حاول مرة أخرى" ويمشي بعيداً — رغم أن البطاقة كانت صالحة بالفعل. النظام الجديد هو أمين صندوق ينتظر بهدوء لحظة، ويعيد تجربة نفس البطاقة تلقائياً حتى ثلاث مرات بتوقيت مختلف قليلاً، ولا يتخلى إلا إذا رُفضت البطاقة فعلياً. العملاء الذين كانت مدفوعاتهم ستفشل بسبب خلل شبكة قصير، يمرون الآن دون أن يعرفوا أبداً بوجود مشكلة.
لماذا هذا مهم
حوالي ٤٪ من محاولات الدفع كانت تواجه هذه الإخفاقات العابرة، ومعظم هؤلاء العملاء لم يعودوا للتجربة مرة أخرى — وهذا يعني خسارة إيرادات حقيقية بسبب مشكلة شبكة استمرت ثانية واحدة، وليس رفضاً فعلياً للبطاقة. استرداد حتى نصف تلك المحاولات الفاشلة يساوي أكثر من ٤٠٠,٠٠٠ دولار سنوياً، مقابل تكلفة هندسية تعادل حوالي ستة أسابيع من وقت فريق واحد.
المخاطر والمجاهيل
- اختبرنا هذا النظام حتى ثلاثة أضعاف حركة المرور الحالية في ذروة الجمعة السوداء؛ لم نختبره عند مضاعفات أعلى، لذا فإن زيادة مفاجئة أكبر بكثير من المتوقع لا تزال خطراً مفتوحاً.
- يضيف منطق إعادة المحاولة حوالي ٢٠٠ ميلي ثانية إلى المعاملات الفاشلة ثم الناجحة — غير مرئي للعملاء، لكنه شيء يجب مراقبته إذا زاد يوماً ما.
- نعتمد على بيانات معالج الدفعات لتحديد أي الإخفاقات "عابرة" مقابل المرفوضة فعلياً؛ إذا كان تصنيفهم خاطئاً في الحالات الحدودية، فقد نعيد تجربة دفعة كان ينبغي رفضها بشكل قاطع.
الأسئلة المتوقعة
س١: هل يمكن أن يؤدي ذلك إلى تحصيل رسوم بطاقة العميل عدة مرات بالخطأ؟ — ج: لا. كل إعادة محاولة تتحقق أولاً مما إذا كانت المحاولة السابقة قد نجحت فعلاً قبل التجربة مرة أخرى، لذلك لا يتم تحصيل رسوم من العميل مرتين مقابل عملية شراء واحدة.
س٢: لماذا استغرق هذا ستة أسابيع بدلاً من أسبوعين؟ — ج: ذهبت أربعة من الأسابيع الستة في اختبار كل سيناريو فشل مع معالج الدفعات الحي في بيئة اختبار آمنة (sandbox)، لأن أي خطأ هنا يلمس أموالاً حقيقية وعملاء حقيقيين.
س٣: ماذا يحدث أثناء انقطاع فعلي لمعالج الدفعات، وليس مجرد خلل؟ — ج: يكتشف النظام الإخفاقات المستمرة ويتوقف عن إعادة المحاولة بعد ثلاث محاولات في غضون عشر ثوانٍ، ويعود إلى رسالة "الرجاء المحاولة مرة أخرى" التي رآها العملاء سابقاً — لذا فإن الانقطاع الحقيقي يتصرف تماماً كما كان سابقاً، دون إضافة أي مخاطر سلبية.