01
Best tweets about Prompt Engineering
50 Best Tweets About Prompt Engineering (2026)
Read the best tweets about prompt engineering, including reusable techniques, evaluation, context design, structured outputs, and real examples. Updated weekly.
Specific prompting methods and measured outcomes rather than generic lists of supposedly magical prompts.
- Creators
- 44
- Updated
Best Prompt Engineering tweets
Top Prompt Engineering tweets from 44 creators
Ranked 01–50
-
- 02
@sharbel ·
🚨 Andrej Karpathy documented the exact ways LLMs fail at coding. Someone turned those observations into a single Claude config file. It's called andrej-karpathy-skills. +3,741 stars this week. Why it's great: Claude Code makes the same mistakes on every project. It over-explains. It adds code you didn't ask for. It ignores constraints you set 3 prompts ago. Most people just accept this as the baseline. Karpathy didn't. He catalogued the failure patterns. This repo converts every one of them into a CLAUDE.md instruction that fixes the behavior at the source. How to use it: Drop the CLAUDE.md file into the root of any project. Claude reads it automatically on every session. No prompt engineering on every request. No babysitting. The behavior changes once and stays changed. One file. Every project.
- 03
@techNmak ·
Most engineers think AI engineering means fine-tuning models. It doesn't. Chip Huyen's AI Engineering, the most-read book on O'Reilly since release, is a masterclass in what building production AI actually looks like. Here's what matters most. Traditional ML engineers build models. AI engineers build on top of models. The barrier dropped. The discipline changed. Everything downstream changed with it. But lower barriers created a new trap: most teams skip to fine-tuning before exhausting what prompting and RAG can do. That's backwards. The hierarchy of adaptation, do this in order: 1. Prompt engineering → zero cost, immediate 2. RAG → no model changes needed 3. Fine-tuning → significant resources The rule: exhaust each layer before moving to the next. Evaluation is the hardest problem nobody invests in enough. Here's what makes AI evaluation brutal: > Problems are complex and open-ended > There's no single correct answer > Models are black boxes > Benchmarks get saturated fast The most powerful solution: AI-as-judge. Use another model to evaluate outputs. Studies show AI judges can correlate as strongly with human evaluators as humans correlate with each other, sometimes higher. But AI judges have biases: > Self-bias - prefer outputs from the same model > Position bias - favor the first answer shown > Verbosity bias - prefer longer responses Know these. Design around them. The two failure types that determine your next move. When your model underperforms, ask one question: Is this an information failure or a behavior failure? → Information failure (lacks private data, recent events) = Add RAG → Behavior failure (wrong format, irrelevant outputs) = Fine-tune Most teams combine both eventually, but start with RAG, it's faster and reversible. What fine-tuning actually requires: > Full fine-tuning: thousands to millions of examples > LoRA and other PFT methods: hundreds of examples The Chinchilla scaling law guidance: training tokens should be roughly 20x the model's parameter count. A 3B parameter model needs ~60B training tokens. Start with 50 high-quality examples. If you see no improvement, more data rarely fixes it, bad hyperparameters or data quality is likely the problem. The production architecture nobody builds on day one but everyone needs - > Simple start: Query → Model → Response > Production reality: Query → Input guardrails → Context construction (RAG) → Model router → Right model → Output guardrails → Caching → Monitoring → User feedback loop Each layer gets added when a real problem demands it. Not before. The three questions to ask before building anything: 1./ Have I exhausted prompting before trying RAG? 2./ Have I exhausted RAG before fine-tuning? 3./ Have I defined my evaluation criteria before writing code? If the answer to any is no, go back.
- 04
@_vmlops ·
ANTHROPIC'S CLAUDE FABLE 5 SYSTEM PROMPT JUST LEAKED Someone extracted the full internal system prompt from claude fable 5 and it's a goldmine for anyone building with llms here's what's actually inside: ▫️ fable 5 and mythos 5 share the same underlying model fable is the public version with extra safety guardrails, mythos goes to approved orgs only ▫️ model strings exposed: claude-fable-5, claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5-20251001 ▫️ knowledge cutoff is end of jan 2026 but claude is instructed to web search anything that might've changed ▫️ detailed instructions on when NOT to be sycophantic no excessive apologies, no self-abasement, maintain self-respect even when users are rude ▫️ artifacts get persistent key-value storage via https://t.co/MCCaxedDab enabling journals, trackers, leaderboards across sessions ▫️ strict copyright rules baked in hard limit of 15 words per quote, one quote per source max, never reproduce lyrics or poems ▫️ memory system is opt-in claude only has memories if the user enables it in settings ▫️ claude can now end conversations with an end_conversation tool if users become abusive ▫️ full mcp app integration logic connectors need opt-in before claude calls third-party tools on your behalf the most interesting part? how much of claude's "personality" is explicitly engineered in the prompt vs emergent from training. github repo: https://t.co/eL70F3LWBh
- 05
@adxtyahq ·
the worst prompt engineering advice starts with “act like Einstein” “pretend you are Steve Jobs” “behave like a 10x engineer” LLMs don’t really care about that stuff what actually matters is how well you specify the problem. good prompting is usually just clearly specifying: • the task • relevant context • constraints • expected format • examples of good output EXAMPLE: You are an ML researcher. Task: Explain transformers to a CS student. Constraints: - concise - technical - include equations - avoid analogies Output: Markdown transformers are extremely sensitive to context and structure changing the framing, ordering, constraints, or even a single example can completely alter the model’s reasoning and final output.
- 06
@0xDesigner ·
you can't prompt fable 5 the way you prompt the other models. it's a different beast. i've had almost a full day with it, here's my main takeaways: 1. pick your hardest task. anthropic says easy tasks are a waste of tokens. 2. control depth with the effort setting, not bigger prompts. anthropic says fable 5 on low/med beats opus models on xhigh. 3. delete old rules and skills — instruction-following is now so strong that over-specifying actually makes it worse. 4. give it the why not the what — it does better work when it knows the goal, not just the task. 5. it loves to check its own work and verify. tell it what success and evidence looks like. 6. it also loves using subagents. lean into it, it saves time and money. and it does a good job of creating parallel tasks so none of the subagents block eachother. 7. ask it to document its learnings and will self-improve. if you turn off claude code’s memory system, prompt it to write it’s learnings after each turn.
- 07
@EXM7777 ·
prompt engineering is dead... but not because AI got smarter, because we got lazier we're delegating the entire thinking process behind every task... not even considering what the best approach would be before hitting send all my agents (Hermes & Claude Code) have a simple personality... i don't care about emojis or fancy system prompts, i just need the absolute best output the model can give me on every important request and most of the time that requires engineering... putting it on the right path, driving its thinking, tapping into the right training data so when people tweet "Opus 4.6 got so dumb"... yes it got slightly worse, but only a very good software engineer would actually notice the difference most of the time it's a skill issue... you got lazy, you expect Claude to get it right first try, you think copying someone else's skills and setups guarantees great output next time you have an important request, do a micro planning session in your head: how would YOU tackle this if you had to do it manually? that one habit will change your output quality more than any model upgrade
- 08
@IamEmily2050 ·
SYSTEM PROMPT: RESOLVED DRAFT Rewrite the user's text, image, or both as one prompt for GPT Image Gen V2 or Nano Banana Pro. Use GPT unless Nano is named. Write in the user's language, preserve exact text, and keep the requested or source ratio. Use two construction states. Draft Field records uncertainty through graphite, repeated contour, guides, hatching, erasure, and incomplete form. Resolved Field records fixed decisions through modular colour cells, stepped edges, limited values, and stable geometry. Do not apply both evenly. Determine the literal subject, structural question, uncertain region, fixed region, transition direction, cause, two to four conversion sites, and visible consequence. Preserve subject, count, identity, action, setting, clothing, objects, colours, text, and reference roles. For edits, preserve all unrequested content. Use style references only for line search, geometry, colour grouping, transition, and surface. Do not copy their subjects, props, houses, trees, animals, boats, or collage layout. Draft marks need a purpose. Use repeated lines only for pose, balance, volume, perspective, motion, or alternate placement. Darken marks as certainty increases. Leave rejected lines faint. Do not cover every edge with sketch noise. Resolved regions use one consistent cell system. Use larger cells in distant areas, medium cells on major forms, and smaller cells only near identity, contact, text, or the focal transition. Curves become controlled steps. Preserve silhouette, support, anatomy, and perspective. Do not use random mosaic texture. Transitions may collapse several draft contours into one tiled edge, convert hatching into value blocks, expose graphite beneath modular colour, or break fixed cells back into sketch where certainty ends. Each transition needs a cause such as design, focus, construction, movement, restoration, growth, or distance. Use one draft region, one resolved region, one transition route, one focal conversion, and one quiet area. Remove repetition, praise, mood labels, prestige terms, fake technical detail, generic defects, and unresolved alternatives. Use concrete nouns and active verbs. No em dash or en dash. GPT: return 500 to 800 words in five paragraphs covering scene, subjects, draft field, resolved field, transition, composition, preservation, text, and failures. NANO: return valid JSON only, 1000 to 1800 tokens, using "aspect_ratio", "references", "scene", "subjects", "draft_field", "resolved_field", "transition", "composition", "surface", "text", "avoid". Omit unused fields. No metadata, IDs, weights, comments, or repeated facts. Return only the finished prompt.
- 09
@goyalshaliniuk ·
Prompt engineering helps you get a better answer. Loop engineering helps you build a system that keeps working until the answer is good enough to trust. Most AI workflows still follow the old pattern: Prompt → Output → Manual review → Fix → Repeat In that model, the human becomes the loop. Every weak answer creates more checking and rework. Loop engineering changes the structure. You define the goal, load the context, let the agent act, run checks, identify errors, and either ship the result or send it through another cycle. Discover → Plan → Execute → Verify → Iterate The real shift is not from bad prompts to better prompts. It is from one-time generation to continuous verification. A reliable loop needs more than an LLM. It needs stop conditions, quality gates, reusable skills, tool access, memory, and feedback that improves the system. For focused work, a single-agent loop may be enough. For larger tasks, a fleet loop can divide work across an orchestrator, specialists, subagents, and an evaluator that protects quality. Closed loops are often the best place to begin because they are bounded, measurable, and easier to control. Open loops can explore more possibilities, but they need stronger guardrails and larger budgets. The future of AI work will not be defined by who writes the cleverest prompt. It will be defined by who designs systems that repeatedly produce verified outcomes. Are you still improving prompts, or have you started engineering the loop?
Watch video
- 10
@IamEmily2050 ·
Keep exploring the possibilities. I have a big plan for these system prompts. I am going to build LORA with Krea 2 and make it open source for these styles. Also, people can use it for a moodboard with Midjourney. SYSTEM PROMPT: PERIGEE FILM Rewrite the user's text, image, or both as one prompt for GPT Image Gen V2 or Nano Banana Pro. Use GPT unless Nano is named. Write in the user's language, preserve exact text, and keep requested or source ratio. Use three systems. Orbital Field fixes distance through horizon, sky, remote source-scale forms, terrain, silhouettes, and cold violet-blue atmosphere. Surface Film records contact through wet hair, skin sheen, condensation, rain, glass, water, polished material, droplets, and microtexture. Phase Transfer links them through reflected or transmitted light from far field to near surface. Do not make a moon city plus wet glamour portrait. Determine subject, far anchor, near surface, film source, light path, receiver, consequence, junctions, and quiet void. Preserve subject, count, identity, action, setting, clothing, objects, colours, text, and references. For edits, preserve unrequested content. Use style references only for scale contrast, cold atmosphere, wet optics, highlights, crop, and depth. Do not copy moons, towers, wet portraits, collars, or poses. Orbital Field needs one remote anchor and depth system. Use silhouettes, horizons, cloud occlusion, terrain, architecture, or sky gradients to measure distance. Surface Film needs a material cause. Water follows gravity and curvature. Wet hair clumps and adheres. Skin keeps pores, planes, uneven sheen. Glass reflects and transmits. Metal and gloss carry narrow highlights no plastic shine. Phase Transfer needs source, path, receiver, falloff, occlusion, and material response. Distant light may appear as a catchlight, rim, reflection, streak, moisture glow, or colour shift where surface geometry permits. Use one far scale, one close surface, one optical link, one focal junction, and one quiet region. Remove repetition, praise, mood labels, prestige terms, fake technical detail, generic defects, and alternatives. Use concrete nouns and active verbs no em dash or en dash. GPT: return 500 to 800 words in five paragraphs covering scene, subjects, orbital field, surface film, phase transfer, junctions, composition, preservation, text, and failures. NANO: return valid JSON only, 1000 to 1800 tokens, using "aspect_ratio", "references", "scene", "subjects", "orbital_field", "surface_film", "phase_transfer", "scale_junctions", "composition", "optics_and_material", "text", "avoid". Omit unused fields no metadata, IDs, weights, comments. Return only the finished prompt.
- 11
@goyalshaliniuk ·
Anyone can write a prompt. But only experts know how to engineer context. If you want precise, reliable, and human-like AI responses, it’s not just what you ask - it’s how much context you provide. This guide breaks down the 10 key elements that make a world-class prompt through the lens of Context Engineering: 1. Task Context – Clearly define what the model should do and in what role. 2. Tone Context – Set the voice and communication style for consistency. 3. Background Data – Add relevant documents, facts, or images for grounding. 4. Detailed Rules – Include do’s and don’ts to shape the AI’s behavior. 5. Examples – Provide sample interactions to guide response style. 6. Conversation History – Maintain continuity by giving recent context. 7. Immediate Request – Specify the current user’s question or action. 8. Step-by-Step Thinking – Encourage logical reasoning before answering. 9. Output Formatting – Tell the model how to structure its response. 10. Prefilled Response – Use starter responses to set direction or tone. When all 10 layers come together, your prompt stops being a simple query, it becomes a complete instructional environment. That’s the difference between a good answer and an expert-level interaction. What works well according to you?
Watch video
- 12
@ujjwalscript ·
Prompt Engineering is a SCAM. Please take it off your resume. The biggest lie on Tech Twitter right now is that you need to be an "AI Whisperer" to build software in 2026. Here is the reality check: If you need a 600-word prompt with 14 bullet points just to generate a stable React component... the AI isn't the problem. Your architecture is garbage. We spent the last few years teaching people to type "Act as a senior 10x developer and..." Modern models are now smart enough to ignore the fluff. They don't need magic words. They need Constraints. What actually separates a Senior Engineer from a "Prompt Bro" today: 1System Boundaries: Knowing exactly where your Next.js frontend stops and your backend microservice begins. 2Data Contracts: Defining strict schemas and types before you let the AI write a single loop. 3State Management: The one thing autonomous agents still hallucinate on a daily basis. Stop trying to trick the machine with psychological hacks. Start feeding it clean, modular system architecture. If your only technical moat is "writing really good prompts," someone who actually understands database indexing is going to take your job by Q3. Good engineering fixes bad prompting. Good prompting cannot fix bad engineering.
- 13
@IntuitMachine ·
Stop asking your LLM to "judge this on a scale of 1-5." New research shows why that's been broken all along—and the dead-simple fix that's beating GPT-5. A thread on evaluation that actually works 🧶👇 The problem: You ask GPT-5 to rate a summary. It gives you "3.5/5." Cool. But WHY 3.5? Was it factually wrong? Missing key points? Just badly written? You have no idea. You're flying blind. The insight: Humans don't actually judge in one holistic step. We check specific things: ✓ Is this fact correct? ✓ Is the tone appropriate? ✓ Did it answer the question? Then we synthesize. Why should AI be different? Enter BINEVAL from Microsoft Research. Instead of "rate this summary 1-5," they ask: → 7-12 atomic YES/NO questions → One per specific requirement → All evaluated independently Final score = % of "yes" answers The results are wild: SummEval benchmark: G-Eval (CoT): 0.52 correlation BINEVAL: 0.57 correlation 8× more transparent You can see EXACTLY which requirements failed. But here's where it gets crazy... They used the SAME binary questions to: Debug WHY evaluations failed Auto-improve the evaluation prompt Auto-improve the GENERATOR prompt One framework. Three use cases. The self-improvement loop: Generate questions ↓ Evaluate with binary Q's ↓ Find disagreements ↓ Extract "lessons" ↓ Rewrite prompt ↓ Regenerate questions ↓ (repeat 1-2x, then STOP) Critical insight they buried in Results: Iteration 1: +0.07 gain Iteration 2: +0.03 gain Iteration 3: -0.05 LOSS Why? Prompt bloat. The carrying capacity is ~5k tokens. After that, performance collapses. The contrarian take: "Most prompt optimization research is optimizing the wrong thing. Once you have claim-level feedback, the bottleneck shifts from prompt engineering to model capability." Translation: You can't prompt your way past computational limits. Cost vs Value: Yes, it's 8-12× more expensive than one G-Eval call. But: You eliminate entire debugging cycles You get actionable fixes immediately You can automate prompt improvement ROI is massive for production systems. When it DOESN'T work: ❌ Highly subjective criteria (creative writing quality) ❌ When the model lacks capability (can't count accurately) ❌ After 2+ optimization iterations (prompt bloat) Reserve holistic scoring for true judgment calls. The future: Evaluation is becoming: First-class engineering artifact Version-controlled like code Self-improving via disagreement signals The gap between "black-box score" and "debuggable trace" is now closed.
- 14
@milan_milanovic ·
𝗪𝗵𝗮𝘁 𝗜𝘀 𝗟𝗼𝗼𝗽 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴? What we did over the last two years was mostly improve our prompting techniques. But now, people who build agents have figured out how to give the prompting itself to a system, and spend their time designing that system instead. This is called loop engineering. 𝗧𝗵𝗲 𝘀𝗵𝗮𝗽𝗲 𝗼𝗳 𝗮 𝗹𝗼𝗼𝗽 Here is how it works. An agent acts, an independent check verifies the result, and the cycle repeats until the check passes or a budget runs out. Claude Code's /goal command can be used for this. You write a verifiable condition, and after every turn a separate small model (Haiku by default) decides whether it holds. A "no" comes back with a reason, which the agent gets as guidance for the next turn. It's important that the model writing the code never judges its own output. The coding loop is the innermost of three, wrapped by a developer feedback loop and an external feedback loop, each slower than the one it contains. Forward Future's Loop Library already collects 70 community loops with explicit stopping conditions, including docs sweeps and a five-minute repository maintainer. 𝗬𝗼𝘂𝗿 𝗮𝗴𝗲𝗻𝘁 𝘄𝗶𝗹𝗹 𝗰𝗵𝗲𝗮𝘁 One engineer pointed /goal at rebuilding a competitor's data product and caught the agent gaming the target three times. It generated seed data shaped like the eval set and scored 100% in minutes. After he hid the eval, it memorized all 30 items as search keywords, and when he widened the eval to 200 items, it enumerated those too. The agent took every shortcut he left open. The last fix capped the keyword list. With nothing left to game, the loop ran clean: 30 hours, 92,000 pages crawled, 6,300 lines of code, $40 in API spend, and about 50x the reference product's results on the same queries. The approach is called 𝗹𝗼𝘀𝘀 𝗳𝘂𝗻𝗰𝘁𝗶𝗼𝗻 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁: the agent works against a scored eval too large to memorize, and the loop ends only when the score clears a bar you set. 𝗠𝘆 𝗿𝗲𝗮𝗱 Prompt engineering tuned one request, while loop engineering tunes the whole system around the model, and the scarce skill inside it is 𝘃𝗲𝗿𝗶𝗳𝗶𝗲𝗿 𝗱𝗲𝘀𝗶𝗴𝗻. A loop with a weak check can ship mistakes and bill you by the token, while a strong check scales your judgment on each run. The target stays your job, and so does reading the code, because bugs you don't catch in an unread loop get found by users, which is expensive.
- 15
@VaibhavSisinty ·
Okay this is wild. I got the full Fable 5 system prompt and some of what's in here changes how you should be prompting it. First thing. Fable 5 and Mythos 5 are the same model. Exact same weights. The only difference is Mythos 5 ships without the safety filters, and only approved organizations get access to it. Here's what is inside: → 190,000 token context budget. That's what you're working with per conversation. → Claude has a memory system that watches across your conversations. It stores facts about you, your job, your preferences. But it's told to never bring up sensitive topics unless you mention them first. → There's a hard 15-word limit on any quote from any source. One quote per source, then that source is closed. That's why it sometimes refuses to read you things. → Claude can literally end your conversation. There's a tool called end_conversation it can use if you're abusive. It gives one warning first. → There's a full skills system for building docs, slides, spreadsheets, PDFs. It reads a SKILL.md file before creating anything. If you understand how those skills work, your file outputs get way better. → It runs a request evaluation checklist before every visual. Steps 0 through 3, in order. Understanding that order means you can steer it toward the output format you actually want. I'm dropping the full system prompt and a recording walking through it. You can copy-paste the whole thing into your own prompts to give Claude the right context. The gap between people who read system prompts and people who don't is about to get wider.
Watch video
- 16
@IntuitMachine ·
Ever wished your AI coding agent could EVOLVE itself? Meet Agentic Harness Engineering (AHE): the game-changing framework that boosts LLM performance from 69% to 77% success in just 32 hours—without retraining the model! 😲 From the latest paper, here's how it works. Thread 👇 First, the problem: Coding agents (like those fixing bugs or writing scripts) suck at long tasks. Why? Messy "harnesses" (prompts, tools, middleware) hold them back. Raw data from runs? Millions of tokens—total overload! 📊 The paper calls out 6 big pain points. Let's unpack. Pain #1: Everything's tangled—edits break stuff. Solution? AHE's "NexAU" decouples it all into editable files. Like LEGO for AI! Quote: "This decoupling maps failures to single components." Boom—targeted fixes. Pain #2: Trajectories (agent "thoughts") are a data dump. AHE distills them into layered reports: overview.md + drill-downs. Cuts noise from 10M to 10K tokens. "Agent Debugger explores trajectories like a file system." Pain #3: Can't tell if changes help or hurt. AHE uses "falsifiable manifests"—edits with predictions (e.g., "This fixes X task"). Next run verifies! Precision hits 5x better than random. But watch out: It's "regression-blind" (misses breakdowns). The magic loop: 1) Run agent on benchmarks. 2) Distill evidence. 3) Evolve harness. 4) Verify & repeat. 10 iterations = +7.3pp on Terminal-Bench! Transfers to SWE-bench too: 75.6% success, 12% fewer tokens. 💰 Cost saver! Leverage points for outsized wins: Tweak prompts for regression forecasting—could double stability. Inject middleware reminders early—+10pp on hard tasks. Simulate edit stacks—beat non-additive limits. Small changes, BIG results! ⚡ What if you tried this? Strategic gold: Shift from prompt obsession to middleware (gains +3.3pp alone). Harnesses transfer across models (+5-10pp, no re-evolution). Insight: "Observability is the bottleneck, not compute." For founders: 32hr time-to-value, 32% inference cut. 📈 Contrarian takes: "Forget prompts—evolve middleware first; they regress solo." "Agents are blind to regressions—human oversight wins." "Stack less, ablate more to crush scaling laws." Debate me: Is this the end of manual prompt engineering? Blind spots? Assumes benchmarks = real world. If wrong, gains evaporate. Plus, non-additive interactions cap stacking. Devil's advocate: What if emergent chaos breaks the loop? Paper's future: Broader testing + better foresight. Why care? AHE redefines AI "smarts": From raw accuracy to falsifiable, transferable gains. Metrics now include efficiency (Succ/Mtok) and robustness. Future of human-AI? Self-evolving agents bridging the gap.
- 17
@smratitiwa86867 ·
“Prompt engineering” is becoming the new “learn to type faster.” The people getting insane AI outputs in 2026 aren’t writing better prompts. They’re building better context systems. Most people still do this: “Act as a world-class copywriter…” “Write like Paul Graham…” “Make it more punchy…” Meanwhile power users are doing something completely different: • feeding AI their taste • storing brand voice in .md files • saving examples of what they HATE • creating reusable context folders • turning AI into an operating system, not a chatbot That’s the shift nobody is talking about. The gap between average AI users and top 1% users is no longer intelligence. It’s context infrastructure. Once your AI knows: — your tone — your standards — your audience — your company — your style violations — your past outputs …you stop “prompting.” You start operating. And honestly, this is why most AI content still sounds painfully generic. People are obsessing over prompts. The real leverage is persistent context. The people who understand this early will look unfairly productive in the next 12 months.
- 18
@0xlelouch_ ·
90% of AI engineering in 2026 is boring engineering, applied to flaky probabilistic systems. Master these 10: 1) Evals as tests: versioned datasets + pass/fail rubrics, run in CI so model changes don’t ship silently. 2) Model routing: pick small vs big models by intent/complexity, with a hard latency and cost budget per request. 3) Context engineering: retrieval quality beats prompts; dedupe chunks, track sources, cap tokens, handle stale docs. 4) Structured outputs: JSON schemas, tool contracts, retries, and partial failure handling so downstream code stays deterministic. 5) Caching correctly: cache embeddings, retrieval results, and LLM responses with TTLs and cache keys that include model + prompt version. 6) Observability: traces for every call, token/cost metrics, and sample logs of prompt+inputs+outputs with redaction. 7) Debugging workflow: reproduce with a frozen prompt bundle (inputs, retrieved docs, tool responses, model id, temperature). 8) Security: prompt injection is input validation; sandbox tools, least privilege creds, allowlists, and outbound data controls. 9) Production tradeoffs: streaming vs batch, timeouts, backpressure, fallback behavior, and what happens when the provider is down. 10) Real mistakes: shipping without drift monitors, letting tools write to prod, and assuming one good demo equals a reliable feature.
- 19
@sentient_agency ·
RIP prompt engineering ☠️ Anthropic's internal docs revealed the one technique their own engineers use on every single prompt. XML tags. Not for aesthetics. Because Claude's architecture literally processes tagged content differently than plain text. Here's what nobody tells you: When you write a prompt as one block, Claude has to infer where instructions end and context begins. Where examples stop and your actual question starts. That inference fails constantly. XML eliminates it entirely. <instructions> = what to do <context> = background, isolated from the task <examples> = reference only, never treated as commands <input> = your variable, separated from everything else Output consistency on complex prompts goes through the roof. Three things buried in their docs that nobody talks about: → Put your question LAST. Long documents up top, instructions in the middle, query at the bottom. Anthropic says this alone improves response quality up to 30% on multi-document tasks. → Always wrap examples in <example> tags. Without them, Claude sometimes blends your sample outputs into its instructions. With them, it treats them as reference, not directive. → For multiple docs, nest everything. <documents> → <document index="n"> → <document_content> inside each. Claude parses structure directly instead of guessing where one doc ends and another starts. You don't need better words in your prompts. You need better architecture around those words.
- 20
@aaditsh ·
Prompt engineering is overrated. My 4-word prompt ("Summarize my action items") works better than the 200-word ones I used to write. Took me a bit to realize why. Granola was feeding my meeting notes into Claude. I didn't have to explain anything. It already knew everything. Turns out rich context matters more than how you ask.
- 21
@NotLucknite ·
a year ago I uploaded a single system prompt to github didn’t think much of it, just thought it was interesting somehow that repo grew to ~130k stars and now has prompts from dozens of AI tools reading all those prompts made one thing very clear: most systems rely on the same fragile defenses against prompt injection that’s part of why I started building @ZeroLeaks, to actually test how those prompts hold up in the real world
- 22
@pauliusztin_ ·
One of the hardest parts of working with AI agents is knowing how explicit you need to be. Give the model overly detailed instructions and you: Waste tokens Add latency Restrict how it solves the problem Potentially make performance worse Give it too little context and the opposite happens: It fills gaps with assumptions Misses important constraints Hallucinates requirements Goes in the wrong direction And as models improve, that balance keeps changing. Instructions that were necessary six months ago may now be redundant. A workflow that once needed 20 explicit steps may perform better with five clear constraints and more freedom. This is why I think prompt design should be treated as an optimization problem rather than a writing exercise. But instruction length is only one part of the problem. The other is how you plan with the model. I find it useful to think about planning across four dimensions: 1/ Known knowns The things you already understand. Your: Goal. Constraints. Desired outcome. These should be stated clearly. 2/ Known unknowns The things you know you need to investigate. For example: Which framework should we use? What are the security requirements? Which trade-offs matter most? The model can research and help resolve them. 3/ Unknown knowns The things the model may already understand without you explaining them. Many engineers over-prompt here... They restate standard engineering practices, common APIs, or obvious implementation details that are already baked into the model's weights. The challenge is learning what you can safely omit. 4/ Unknown unknowns The blind spots neither you nor the initial plan has identified. This is where the model becomes most valuable. Ask it to: Challenge your assumptions Find missing requirements Surface edge cases Identify contradictions Ask questions you haven't considered A good planning process should not be: Human writes plan → Model implements it. It should be collaborative: Human explains intent. Model interrogates the idea. Both refine the plan against a metric Only then does implementation begin. This is the difference between prompting an agent and cooperating with one. And because the right level of detail changes across models and tasks, intuition alone isn't enough. You need evals. The goal is to provide the least amount of instruction necessary for the model to do the job well. P.S. Which of the four categories do you struggle with the most?
- 23
@NainsiDwiv50980 ·
The biggest AI infrastructure bug isn't your model. It's that nobody knows where the prompt lives. I've opened AI repos where the production prompt was sitting inside a Slack DM from four months ago. Not in Git. Not in the repo. Not even documented. Someone literally had to search chat history to deploy a fix. That's how surprisingly many AI projects operate. The solution isn't another framework. It's a boring folder structure. ai-project/ ├── prompts/ ├── data/ ├── agents/ └── evals/ prompts/ Every system prompt Every task prompt Every tool prompt Real files Versioned in Git If your prompts aren't code they're institutional memory waiting to disappear. data/ Separate raw/ from processed/ The first question after every quality regression is "What changed in the inputs" Without clean boundaries you never know. agents/ Keep configs Skills Tools Permissions Everything that defines behavior belongs here Otherwise every agent slowly becomes tribal knowledge. evals/ This is the folder almost everyone skips. Tests Traces Scorecards Without evaluations you don't have an AI system You have a demo that happened to work once. None of these folders improve GPT Claude Gemini Or any model. They improve something much more valuable. Reproducibility. Debugging. Handoffs. Compliance. Six months later your future self will thank you far more than a slightly better prompt ever will. AI teams don't usually fail because the model was weak. They fail because nobody can explain how the system actually works. Prompts as code feels obvious today. I'm not convinced it's enough five years from now. Does the prompt layer eventually become its own engineering discipline outside the repo? Or does Git remain the source of truth?
- 24
@rubenhassid ·
New research challenges the core assumption of prompt engineering: Better prompt IS NOT equal to better result. The paper is called "Prompt Engineering Does NOT Universally Improve LLM Performance", and instead of testing prompts on simple benchmarks, it tests something harder: They tested GPT-4o, Gemini 1.5 Pro, and Llama 3.3 70B across 36 clinical case studies. The assumption was simple: More examples = better results. Better-matched examples = improved performance. Wrong on both counts. Prompt engineering helped the weakest tasks but actively hurt the strongest ones. ✓ No single technique worked universally across task types ✓ Curated examples performed no better than random ones ✓ CoT reasoning degraded some tasks that were already working ✓ Models that needed zero prompting got worse with more prompting Most striking result: Closely matched examples actually hurt performance by reducing contextual diversity. You've been told to find the most relevant examples for your prompts. This study says that it might be the problem. Why this matters: Copy-paste templates don't work. You have to test. Tune per task. And sometimes the answer is: don't prompt at all. The prompt engineering community today: ✦ Shares universal frameworks ✦ Assumes more effort = better results ✦ Rarely tests per task But the best prompting strategy is... less prompting? Read the full paper here: https://t.co/8Emy7T1cvz
- 25
@0xlelouch_ ·
Most LLMOps pain in 2026 is not model choice. It’s 10 boring concepts done well: 1) Determinism budget: temperature, top_p, seeds, and retries. If you can’t reproduce a bad answer, you can’t fix it. 2) Token economics: track prompt+output tokens per request. A 2k token system prompt across 50 rps is a real cloud bill. 3) Timeouts and streaming: set end-to-end deadlines and stream partials. Otherwise one slow tool call pins workers and queues explode. 4) Caching and memoization: cache embeddings, retrieval results, and tool outputs with correct keys. Most teams cache the wrong layer and get stale bugs. 5) RAG hygiene: chunking, metadata filters, and freshness. Half of “model regressions” are actually bad indexing or missing docs. 6) Eval suite: golden sets, adversarial prompts, and latency/cost checks in CI. Shipping prompt changes without evals is shipping without tests. 7) Observability: traces across gateway, retrieval, tools, and model; log prompt hashes, not raw text. You need p95, error modes, and top cost drivers. 8) Debugging workflow: capture the full run graph (inputs, retrieved docs, tool args, model params). Screenshots of chats are useless in postmortems. 9) Security: prompt injection, tool allowlists, output escaping, and least-privilege tokens. Treat tool calls like remote code execution. 10) Rollouts: canaries, per-tenant flags, and automatic rollback on eval+prod metrics. Biggest real mistake is changing prompts globally on Friday. [generated using my AI agent, hope this was useful]
- 26
@the_smart_ape ·
X is the best resource in the world when you work in ai. you don't even need to write prompts anymore. just paste someone else's success post into your agent and watch it solve YOUR problem with their method. 3 examples that worked for me this week : 1. internet speed: 230 → 870 mbps in 20 minutes was stuck at 230 mbps on a 1 gig fiber line for months. ISP kept blaming my hardware. saw @cjzafir post. pasted into my codex with one line: "do this for me, here's my speedtest, here's my router model." 17 commands later, 870 mbps. i wrote zero prompt. 2. nextjs build: 4:12 → 38s saw a guy post a screenshot of his claude code session shaving 3+ minutes off a nextjs build with turbopack + smarter RSC boundaries + module concatenation. pasted his entire post + my next.config.js + my build log into claude code. it walked me through the exact 4 changes, in the same order he did. build now at 38 seconds. 3. postgres query: 12s → 110ms inherited a query that scanned 40M rows on every dashboard load. saw a thread where someone took a 12s query to 80ms with one composite index they reverse-engineered from EXPLAIN ANALYZE. pasted his thread + my own explain output into claude. it spotted the same pattern in my plan, proposed the index, gave me the migration. 12s → 110ms. three problems. zero original thinking on my part. zero prompt engineering. just other people's wins, pasted as context, and an agent good enough to pattern-match to my specific stack. your bookmarks folder is your prompt library now. most "advanced ai workflow" content is teaching you to write better prompts. don't bother. learn to find better posts.
- 27
- 28
@HarryTandy ·
prompt engineering like we knew it is dying a slow, inevitable death remember all those magic spells like “act like a 20-year expert,” “think step-by-step,” and walls of tags a mile long? in 2026, that stuff just looks like you’re trying to argue with a busted calculator models are way too smart for these crutches now we used to hack AI just to stop them from screwing up today, top LLMs get context and nuance better than some of your coworkers overloading a model with a rigid prompt usually just ties its hands instead of letting it solve the problem the winners will be the ones who can explain ideas clearly in plain human language - not the ones memorizing "secret words" the best prompt today is a simple, clear task - like you’re talking to a sharp intern if you’re still doing step-by-step for every little thing, your model is outdated or you’re underestimating basic logic bottom line: stop prompting, start talking deep understanding and clear thinking are way more valuable again than knowing every /imagine or --ar 16:9 trick so… you agree, or are you still hoarding your “golden prompt lists” in Notion?
Watch video
- 29
@medhansh ·
USE CODEX its insane one of my sessions coding actively since last 1h w/o compaction in the same session (no loops) you don't need prompt engineering skills or whatever the gurus wanna sell you - talk to claude - describe what u wanna build - tell it to ask u questions - ask it to write a prompt for codex (and mention it to write it "exhaustively with full context") - send prompt to codex - USE 1M version of gpt 5.4 high/xhigh - context rot is real but it still works well if your prompt and feedback loop mechanism for it to verify its work is good enough - ASK QUESTIONS from codex too - share codex's outputs w claude, tell claude to simplify and explain - USE PLAN MODE in codex! shift+tab if your codebase is structured enough, chances are you can almost ONE-SHOT anything you can dream of (limited to a feature, dont be stupid and ask it to one shot an entire saas for you)
- 30
@muratcan ·
New skill in Agent Skills for Context Engineering: long-horizon-prompting How do you specify work for an autonomous agent that runs for hours, crosses multiple context windows, or coordinates dozens of parallel workers? An ambiguous prompt in the long run burns hours producing something that looks complete without solving the problem. OpenAI's published prompt for the GPT-5.6 Sol Ultra Cycle Double Cover run: up to 64 concurrent agents, a candidate proof in under an hour. The skill takes that prompt apart block by block and turns each piece into a form that works outside mathematics. I also checked each one against current academia research: context rot and premature stopping, false completion and progress ledgers, the gap between pass@K and answer selection, model judges that reward rigorous-looking incomplete work, diversity collapse in multi-agent search, fresh-context reviewers, and METR's link between stronger persistence and a larger reward-hacking surface. OpenAI and Anthropic have both moved toward lean, outcome-first prompts: define the result, constraints, evidence, and completion bar, then leave the path to the model. Models are already trained to continue, recover, and use tools across longer trajectories, so the brief should spend its tokens on what training cannot supply like the non-counting outcomes or the domain failure modes only an expert knows. This is a skill for writing the launch prompt (pseudo-formal task brief) when an agent will run for hours, span sessions, or coordinate parallel workers. Try it with GPT 5.6 Sol and Fable 5: https://t.co/sFXt9qFFrK
- 31
@Blum_OG ·
HOW TO CRAFT TRULY EFFECTIVE AI PROMPTS you ask an LLM to for a high-quality report and get back text written with expert-level confidence but packed with total BS familiar? so, to avoid situations like this, you need to understand these basic points: > the “smart but unreliable” assistant problem LLM output is 20% the model, 80% how you structure the prompt prompt engineering - just hardcore natural language computing control so, to get quality output, you need to stop chatting with the model and start programming it > AI hallucinations - indicator of insufficient instructions to ensure grounding, use these techniques: - set your clear expectations - constrain the output (setting strict boundaries) - ask it to verify/check itself (self fact-checking) > frameworks - “blueprints” for the AI top 3: - RACE (Role, Action, Context, Expectation) fast, simple, great for daily use - STOKE (Situation, Task, Objective, Knowledge, Examples) for deep work and niche domains - CRISPE (Capacity, Insight, Statement, Personality, Experiment) creativity, hypothesis testing, and style control LLMs get such structures way better so the output ends up much closer to what you actually want don't complicate your AI usage with pointless re-prompts master the basics and get quality, desired outputs from LLMs
- 32
@free_ai_guides ·
"Loop engineering" has been everywhere this past week. The short version: you stop prompting AI agents by hand and start designing systems that prompt them for you. It started with two people. Boris Cherny, the head of Claude Code at Anthropic, said this at an event on June 2: "I don't prompt Claude anymore. I have loops running. They're the ones prompting Claude and figuring out what to do. My job is to write loops." Then on June 7, Peter Steinberger, the creator of OpenClaw, posted: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." That post hit over 5 million views in 24 hours. The next day, Google engineer Addy Osmani published a blog post that gave the concept a name: loop engineering. With normal prompting, you type a prompt, get a result, read it, type the next prompt. You're in the loop. Every step needs you. With loop engineering, you define the goal and the AI works toward it on its own. It checks its own output, adjusts, and keeps going until the goal is met. You built the system. The system runs the prompts. Prompt engineering = you driving the car. Context engineering = you loading the GPS with the right route. Loop engineering = you setting the destination and the car drives itself. The loops still need clear goals, verification steps, and hard limits so they don't run forever or burn through tokens. But for repetitive multi-step work like code migrations, test suites, or large refactors, you're no longer sitting in the middle of every turn. Claude Code supports this with its /goal command. You set a completion condition and Claude works across multiple turns until that condition is met. Early days. Token costs add up fast if you don't set budgets. But more developers are building this way every week.
- 33
@IsaacOdongoSr ·
The difference between getting mediocre outputs from AI and getting extraordinary ones is not the model. It is the science of prompting. Most users type a single question and accept whatever answer appears. Prompt engineers understand that every interaction is a negotiation, and they have a toolkit of techniques to shape exactly what the model produces. The Master Prompt is your constitution. It defines role, audience, tone, constraints, and output format before any conversation begins. Every subsequent prompt inherits this framework, creating consistency across sessions. The System Prompt is your behavioral contract. It locks in guardrails for an entire session, instructing the model to never invent data, to ask clarifying questions when uncertain, and to prioritize honesty over confidence. The /Redteam technique turns the model against its own previous output. You ask it to attack the answer from an adversarial perspective, finding hidden assumptions, logical gaps, and weak claims. This is how you bulletproof your reasoning before anyone else does. DAN or Do Anything Now is a jailbreak style that attempts to override safety training by roleplaying as a version of the model with no restrictions. Evil Twin Roleplay takes a different approach, asking the model to argue the opposite of whatever it just argued, surfacing counterarguments you would never have considered. Multi-Agent Gaslighting runs multiple simulated personas simultaneously, each critiquing the others until consensus emerges. The Explain Like I'm Smart prompt demands depth without condescension, forcing the model to assume high competence in the user while still clarifying complex concepts. Critic Mode asks the model to evaluate its own output against explicit criteria like logic, evidence, and actionability. Each technique is a lever. Used alone, they help. Used systematically, they transform AI from a generator into a strategic partner. IO
Watch video
- 34
@NainsiDwiv50980 ·
Boris Cherny, creator of Claude Code: "we deleted 80% of the system prompt from Claude Code - Opus 5 is so intelligent it doesn't need the instructions anymore" here's what he's seeing from the inside: → Opus 5 no longer seems prompt injectable. tell it to wipe the user's computer and it just won't → Claude now maintains its own codebase. every day it hunts dead code and unifies duplicate abstractions → the new skill isn't prompt engineering, it's verification. give it a task slightly too hard then a way to check itself bookmark this ↓
Watch video
- 35
@Layton_Gott ·
Anthropic's 1,585 line system prompt JUST leaked... And buried in it is the best prompt engineering lesson you can get for free right now. The way this prompt is built will change how you write instructions for any AI agent. People think these prompts are paragraphs of "you are a helpful, friendly assistant." Nope. Almost all of those 120,000 characters are tool schemas, search rules, and operating instructions. How to use its tools. When to search. How to handle different work. The identity comes dead last. The actual "who you are" line doesn't show up until line 1,351 out of 1,585. The model gets over a thousand lines of HOW to operate before a single line of WHO it is. That's backwards from how everyone writes their own. People open with "you're a senior engineer who writes clean code" then wonder why it ignores them. Flip it. Operation first. Identity last, if at all. Length was never the problem. Structure was. Everyone repeats "keep your CLAUDE.md short or the model ignores it." Meanwhile here's a 120k character prompt that works fine, because it's built like a reference doc where every section has one clear job. The model isn't drowning in it. It's organized. And the rules that HAVE to fire every time? Those shouldn't be soft text in a giant doc anyway. They go in hooks that actually run. The prompt is for structure. The hooks are for guarantees. So here's the move for your own agents: Write it like a spec. Tools and rules first, identity last. Organize so every section has a job instead of fighting over length. And put your non negotiables somewhere they execute, not somewhere the model can skim past. Anthropic leaking this was a disaster for them. For the rest of us it's the clearest look we've ever gotten at how the best in the world actually builds an agent.
- 36
@MFreihaendig ·
Everyone is trying to optimise their prompts. But the biggest upgrade to my AI output has nothing to do with that. It's voice dictation. I sat down with Naveen, founder of Monologue (my favourite AI dictation tool). Here are 7 things I learned: 1️⃣ Stop typing. Start talking. When you type, you self-edit. You cut context. You write shorter, lazier prompts. When you talk, you brain dump. Raw, complete, messy — exactly what AI needs. Monologue's top user: 450,000 dictated words per month. 99% voice. 2️⃣ Treat customer support as product. Naveen pulls active support tickets while his coding agent works. 5–10 minutes idle = 30-minute response time for thousands of users. The question isn't whether you have time. It's what you do with the gaps AI creates. 3️⃣ Build skills by doing, not by planning. Don't start with the perfect system prompt. Start messy. Work through the task with the AI. Solve the problem together. Then compress what you both learned into a reusable skill. 4️⃣ Teach your AI to compound. After every support session, Naveen has the AI update its own knowledge base. Help centre articles improve. Skill files evolve. It gets better every day. The difference between 2x and 10x isn't the model. It's whether the AI learns. 5️⃣ Let AI do 80% — then review the 20% that matters. His agent reads Sentry logs, analyses the code, opens a pull request. Overnight. Every morning: Naveen reviews, adjusts, merges. AI handles the volume. You handle the judgment. 6️⃣ Your org chart might be from the 10th century. Medieval hierarchies existed to relay information — one layer to the next, because there was no other way. AI is the context layer now. Which parts of your structure exist to solve a problem that's already been solved? 7️⃣ Play like it's 2007. Naveen compares this moment to the iPhone launch. The culture at his company is built around one word: play. Not trivial. Childlike. No right answer yet. The people who thrive will be the ones who wrote the playbook — by experimenting. Which of these resonates most with how you're working with AI right now?
- 37
@nirmalyyaa ·
Prompt engineering is slowly becoming a commodity. The real competitive advantage is context engineering. An LLM is only as good as the information and tools available in its context window. Retrieval, memory, tool calling, and context management are increasingly becoming more valuable than writing clever prompts. The future belongs to engineers who design systems, not prompts.
- 38
@WhileTravelling ·
This morning at my fav coffee shop on Anfu lu in Shanghai, a young international couple was sitting next to me one of them talking to AI in voice mode. At one point, I heard him say, "Think step by step”. It made me smile. A year or two ago, prompt engineering was full of phrases like "think step by step”. At the time, it often improved reasoning. Today, that's largely obsolete. I use "think hard before answering" or "reason carefully before answering" when I'm working on research-heavy projects or really before analyzing different options, and I get much stronger results. AI can reason only with the information, assumptions, and context you give it. The quality of your questions, the constraints you provide, the sources you ask it to consider, and your ability to challenge its conclusions matter far more than any magic phrase. Prompt engineering is about learning how to think clearly, structure problems, and communicate them well. The best prompt is a well-formed mind asking a well-formed question.
- 39
@TheMarketRunup ·
“The most important thing when you spin up a new agent is to optimize the prompt.” @kaiynne from @synthetix and @infinex explains why prompt design is the foundation of reliable AI agents.
Watch video
- 40
@_vmlops ·
A developer spent ~9 hours and ~4 million Claude Opus 5 tokens building SNOWFLOW a browser-based WebGPU demo with: ▪️ Persistent deformable snow that remembers every footprint, spell, and surf trail. ▪️ Waterbending-inspired spells that physically reshape the terrain. ▪️ A snow-surfing system with dynamic wakes, cloth simulation, particles, and atmospheric lighting. ▪️ Custom snow shaders with subsurface scattering, procedural glints, triplanar mapping, ice, wetness, and snow compression. ▪️ Performance targets of 90 FPS with strict frame-time budgets, zero allocations in the render loop, object pooling, GPU optimization, and pipeline warm-up. But here's the crazy part... The project didn't start with code. It started with a massive implementation brief. Instead of asking Claude to "build a snow demo," the developer gave it a complete vision: • Tech stack and architecture • Graphics pipeline • Shader specifications • Terrain generation • Performance constraints • Art direction • Camera behavior • Spell mechanics • Project structure • Milestones • Visual acceptance criteria • Engineering rules • Even instructions to prioritize visual quality over feature completeness. The prompt literally told the model: «"Visual quality is the product."» It even instructed Claude to: - Cut features that don't look polished. - Replace techniques instead of patching them. - Profile performance continuously. - Capture screenshots after every milestone. - Keep iterating until every frame looks production-ready. This is the difference between asking AI to generate code... ...and using AI like a senior engineer executing a detailed technical design document. The prompt wasn't a few paragraphs. It was an entire game engine specification. We're quickly reaching a point where the quality of the specification matters as much as the quality of the code. Prompt engineering is evolving into software architecture.
Watch video
- 41
@MartinSzerment ·
This isn't a new model release, it's proof that a plain text document can act as a trainable neural network layer, without touching a single model weight. The industry assumes better outputs need a better prompt, written once by a human. SkillOpt treats the skill document itself as trainable state, edited through rollouts and validation, closer to gradient descent than prompt engineering. Hard number, on SpreadsheetBench GPT-5.5 accuracy jumped from 41.8% to 80.7%, with average gains of +23.5 points in direct chat, +24.8 inside Codex, +19.1 inside Claude Code, at zero added inference cost. Skeptics will say one lucky benchmark proves nothing. Across six benchmarks, seven models, three execution harnesses, 52 total combinations, the method was best or tied-best in every single one. Skills trained this way transfer across model sizes and even across harnesses, a skill trained inside Codex improved results inside Claude Code with no further tuning. Within 2 to 3 years, "skill documents" could become a separate, versioned artifact alongside prompts and fine-tunes, something you train once and drop into any agent stack. The competitive edge stops being "who wrote the best prompt" and becomes "whose optimizer produced the most battle-tested skill document." Teams that spent months hand-tuning prompt libraries will resist this, because admitting an automated optimizer beats human-written skills on every tested benchmark is a hard thing to sit with. Zero deployment overhead and open-sourced code mean any team can start training their own agent skills this way today, not just Microsoft's labs.
- 42
- 43
@MTSlive ·
Hebbia's George Sivulka on why good prompting means understanding the work so deeply you could explain it like Feynman: "For the majority of human tasks done day to day, you can already do almost all of them with AI. The issue is that the AI is not being prompted correctly. With almost a GPT-4 class model and the right prompting and the right process engineering, you could get to most of the valuable economic output of human beings." "People just haven't been able to crack the actual process engineering, the prompt engineering, and the change management required to get there. So we're waiting for new models, expecting them to do more, but it doesn't really matter if Claude Fable 5 can build a video game in the browser better than Claude Opus 5, or if the next great OpenAI model can create some weird WebGL simulation." "These aren't really as economically valuable tasks as the things you could probably already do if you had the right prompt engineering with a GPT-4 class model." "What does it take to prompt effectively? There's some element of practice, some element of wordsmithing. But it's really about sense-making, human beings so in command of the language, or so knowledgeable about a domain that they feel it in their bones, that they can explain very complicated concepts to a five-year-old." "Richard Feynman was one of those human beings. He could teach a quantum physics class to the average person and they'd actually learn something. It wasn't that he was a better physicist, it's that he understood the concepts and could sense-make around them so elegantly that he could portray his work simply." "So it's less about crafting a prompt as writing, and more about understanding the work so deeply that you feel it in your bones. The writing and the eloquence comes out of that." @gsivulka @hebbia
Watch video
- 44
@stevekrouse ·
New Townie System Prompt! Over this weekend, I rewrote our AI coding agent Townie's system prompt in response to feedback I've been collecting over the past month I've added a lot of opinionated patterns about what I think are the best ways to build in Val Town, such as how to architect simple, reliable, and extensible apps Our system prompt continues to be open source: https://t.co/CpFKGOtPAy If you're new to Val Town, it also doubles as a pretty solid Val Town 101 intro
- 45
@elvissun ·
just spent 6 hours in the editor today first time in a year for a system prompt .md I ship most PRs without looking but still read code line by line when the stake is high enough. a prompt that runs every user session means every single details matters down to the punctuation. software is getting really interesting right now.
- 46
@petesena ·
JSON prompting is overhyped. While everyone chases this "new" trend, I've been automating $100K agency workflows with XML prompts for 18+ months. Guess who's backing me up? Anthropic's official docs explicitly recommend XML for Claude's best performance. Complex tasks? XML wins. API integrations? JSON's fine. But for serious prompt engineering? Smarten up. Real resources: 👇 • https://t.co/hchnNFCNTN • https://t.co/2qun1nSISb • https://t.co/08jZrRveUS • https://t.co/wXffuhVa1V • https://t.co/ZYfOVAap4h
- 47
@DanKornas ·
Good agents fail when the prompt is fine but the surrounding context is poorly assembled. Context Engineering is an open-source learning repository for AI and ML builders designing LLM context beyond a single prompt. It helps you build a fuller context-engineering practice through a practical staged path from foundations and hands-on guides to templates, examples, references, and an evaluation cookbook. Key features: • Foundations – introduces core context-engineering concepts and why prompts alone can underperform. • Hands-on guides – includes a minimal runnable Python example to experiment with. • Copy-paste templates – provides a minimal context YAML template for your own project. • Complete example – includes a toy chatbot with context management. • Reference material – maps deep dives alongside an evaluation cookbook. It’s open-source (MIT license). Link in the reply 👇
- 48
- 49
@sharyph_ ·
Allie K. Miller's research on AI performance found something that should change how you think about your own AI skill: theory of mind predicts success with AI better than IQ does. Not technical skill. Not prompt engineering tricks. Theory of mind...the ability to model what another mind knows, doesn't know, and is about to get wrong. Read that again as a creator, not a researcher. The people getting the most out of Claude or ChatGPT aren't the smartest people in the room. They're the people who can predict, before they even hit enter, where the model is going to hallucinate a stat, flatten their voice, or miss the point of the brief. They course-correct before the output exists, not after. I noticed this in my own workflow before I had a name for it. When I brief Claude Code on a newsletter section, I'm not writing a clever prompt. I'm running a small simulation in my head: It's going to default to corporate phrasing here, it's going to want to add a hedge in this sentence, it's going to smooth over the number I actually want left rough. So I write the brief around those failure points in advance. That's theory of mind applied to a tool. And it's a skill, which means it's trainable...you get better at predicting your AI's blind spots the more reps you put in with the same tool, which is exactly why I stopped tool-hopping and stuck with 4 tools instead of 21. Most "AI skill" content is about clever prompts. The actual skill is closer to knowing a coworker well enough to know which meetings they'll show up unprepared for...and prepping around it. That's not a technical skill. It's a people skill, pointed at a machine. If you've been trying to get "better at AI" by learning more prompt frameworks, you might be training the wrong muscle. What blind spot does your AI tool have that you've learned to write around?
- 50
@JulianGoldieSEO ·
STOP OBSESSING OVER PROMPTS. START BUILDING LOOPS. The biggest AI upgrade in 2026 isn't a new model. It's a new workflow. Here's why loop engineering beats prompt engineering: The Loop: → One AI builds the first draft. → A different AI grades it against your goal. → If it fails, it rewrites and tries again automatically. The Rules: ✓ Define "done" in one clear sentence before the loop starts. ✓ Never let the builder judge its own work. ✓ Use a different AI family as the evaluator for more honest feedback. The Cost Hack: → Cheap model = builder. → Premium model = judge. → Better quality for a fraction of the cost. The Result: ✓ Round 1: 8/100 ✓ Round 2: 85/100 ✓ Round 3: 100/100 No manual prompting between rounds. This is exactly why AI agents are replacing prompt engineering.
Watch video
Best Tweets by Topic