Prompt Engineering

35 posts

toss5 min readCurated summary

Getting AI to Provide Investment Information

LLMs make it easy to generate financial content, but producing trustworthy investment information requires much more than fluent summaries. Toss Securities argues that AI must pass three gates before reaching users: selecting reliable evidence, controlling how responses are generated, and making outputs measurable and improvable. The central principle is to constrain AI autonomy where reproducibility and traceability matter, while preserving it for open-ended exploration. ## Why Investment Information Is Different - **Timeliness:** Market interpretations can change within hours due to earnings, geopolitical events, or policy news. - **Accuracy:** A company mentioned in an article may not be the company whose stock moved; it could be a subsidiary, a similarly named firm, or merely a promotional mention. - **Traceability:** Every generated claim needs supporting evidence, evaluation records, and reproducible processing. - **Non-stationarity:** Market behavior changes across earnings seasons, interest-rate events, elections, and geopolitical crises. Prompts and models tuned to one period may degrade later. LLMs and autonomous agents amplify these challenges: - LLMs can produce fluent but incorrect answers when evidence is incomplete or ambiguous. - Agents add more failure points through search, tool calls, planning, and state transitions. - Errors can propagate through different execution paths, increasing operational cost and making debugging difficult. ## Gate One: Selecting What the AI Should Say The first gate is a context-engineering process that filters and organizes evidence before it reaches the LLM. ### Classify Data at Ingestion - News, disclosures, and financial data are classified as they arrive using internally developed BERT-based models. - Metadata includes: - Taxonomy tags - Related companies and entities - Embeddings for vector search - Pre-classifying data avoids waiting until retrieval to determine whether it is relevant. ### Retrieve Broadly, Then Narrow the Candidates A hybrid retriever first prioritizes recall, after which candidates are reduced through: - **Deduplication:** Semantically similar articles are clustered so one event is not treated as many independent events. - **Reranking and filtering:** Evidence is evaluated for direct relevance to the company’s price movement. - **Taxonomy labels:** Items are categorized by explanation type, such as earnings, guidance, or corporate actions. - **Failure labels:** Promotional content, insufficient evidence, and other unsuitable sources are explicitly marked and filtered out. - **Rubrics:** Evidence is ranked according to predefined relevance criteria. ### Build Reasoning-Friendly Context The final context is arranged so the model checks: - What happened - How the event connects to the target company - Whether the evidence’s polarity matches the stock’s price direction - Whether the evidence is sufficient and current This ordering combines the filtered evidence with metadata such as the company, price direction, and time window. ## Gate Two: Controlling How Responses Are Generated The second gate limits the action space of LLMs and agents to satisfy product requirements such as cost, latency, reproducibility, and observability. ### Use Task Graphs for Clearly Defined Work Instead of leaving the entire process to an autonomous agent, Toss Securities separates it into explicit stages: - Candidate retrieval - Relevance assessment - Deduplication - Evidence construction - Final response generation Each stage has defined input and output schemas, making it a debugging and evaluation point while simplifying fallbacks and operational monitoring. ### Choose Autonomy Based on Requirement Clarity - **Autonomous agents** are useful for open-ended tasks such as discovering investment ideas or exploring possible market scenarios. - **Procedural orchestration** is better for fixed tasks, such as explaining why a specific stock moved. - Long ReAct loops increase tool calls, token usage, latency, and trace-management costs. - For structured products, deterministic pipelines let LLMs focus on summarization, rewriting, and evidence-based explanation rather than tool selection. Procedural graphs are not merely a replacement for agents. Once defined, they can become reusable tools or sub-agents that other agents call through structured interfaces, such as: ```text input: ticker, direction, time_window output: explanation, evidences, reasoning_type ``` ## Gate Three: Making the System Evaluatable Subjective judgments such as “the answer feels weak” do not provide a reliable improvement loop. The system therefore generates structured classifications alongside natural-language responses. ### Generate Rubric Categories with Each Answer - Outputs include event or reasoning types and failure categories. - Structured fields make it possible to measure: - Relevance false positives - Directional mismatches - Irrelevant evidence passing the filter - Precision, recall, and F1 score - The taxonomy must evolve as new market regimes and failure patterns appear. - Operational failures, evaluation sets, prompt versions, and model versions should be linked so improvements can be reproduced and quantified. ### Retrieve Context-Specific Few-Shot Examples Fixed few-shot examples are insufficient because event and failure types vary widely across market conditions. Instead: - Store operational samples with their decisions, failure labels, and embeddings. - Embed each new classification or verification task. - Retrieve similar positive and negative examples. - Include both successful and failed examples to show the model the decision boundary. This approach reuses production failures as future evaluation guidance and significantly improves precision and accuracy while preserving recall. Since false positives are especially damaging in investment services, filtering out unsupported explanations is more important than producing fluent text alone. ## Work Beyond Prompts and Model Training Building an investment-information AI service also requires substantial infrastructure outside the model itself: - Retrieval strategies and embedding models for finding relevant evidence - Separately trained classifiers for categorization - Evidence filtering, validation, and metadata management - Structured orchestration, monitoring, evaluation, and feedback loops The practical recommendation is to treat the LLM as one component in a controlled evidence pipeline—not as the sole decision-maker. Use autonomous agents for exploratory tasks, but rely on traceable procedural graphs, evolving taxonomies, and retrieval-based examples when the product must deliver repeatable, defensible financial information.

Read original(opens in new tab)
github2 min readCurated summary

Write your first prompt with the GitHub Copilot app

Starting with GitHub Copilot does not require a perfect prompt or specialized syntax. The article recommends connecting Copilot to a repository or local folder, describing a task in plain English, and refining the request interactively. Users can gradually adjust the AI model, input method, and session settings as their needs become more complex. ## Start with Project Context - Connect an agent session to: - An existing GitHub repository - A local folder on your computer - Selecting a project gives Copilot access to the code and files needed for the task. - Once the project is connected, you can submit a prompt. ## Describe Tasks in Plain English - Prompts only need to explain the desired outcome. - Example: `Add a most-funded sort option to the games list.` - Copilot can inspect the codebase and identify relevant files. - If the result is incomplete or incorrect, provide more details and ask for revisions. - Prompting is iterative, so the initial request does not need to include every requirement. ## Select an Appropriate AI Model - The app supports multiple AI models with different strengths. - More capable reasoning models may help with complex tasks, while simpler models can be faster for straightforward changes. - Beginners can use the default model without understanding every model difference. - Models can be switched later if the task becomes more demanding or the initial result is unsatisfactory. ## Use Voice Input - Built-in voice input lets users describe tasks verbally. - Speech is converted into editable text before submission. - This can be useful for explaining lengthy or complicated ideas more naturally. ## Customize Agents and Sessions - Session settings allow users to select different agents for different types of work. - Remote control enables access to a session through the web. - Users can start work locally, leave their computer, and resume the same session from another device. - These options are available when needed but are not required for a first task. ## Start Small and Iterate - Begin with a modest change in a familiar project. - Review Copilot’s work and refine the prompt as necessary. - Experiment with different models or session configurations only when the task requires them. The practical recommendation is to choose a project, describe one small task in ordinary language, and begin. Experience with iterative prompting will make model selection and other Copilot settings easier to use over time.

Read original(opens in new tab)
toss4 min readCurated summary

5. Technical Writer, A Decision to Disappear

Toss’s technical writing team argues that documentation is essential context for AI, but manually maintaining thousands of documents is impossible with only three technical writers serving roughly 4,000 people. Their solution is to automate the technical writer’s work by teaching AI the team’s implicit standards and embedding those standards into reusable Skills. The initial system supported document creation and review, but adoption remained low because users still had to install, invoke, and supply information to the AI manually. ## Why Toss Wanted to Automate Technical Writing - Documentation gives AI the organizational context it needs to work effectively. - Toss has approximately 4,000 employees but only three technical writers. - Reviewing documents individually does not scale, especially in a fast-moving organization where features change or disappear before documentation is complete. - The team’s goal to “eliminate technical writers” means transferring routine writing and editing work to AI, not abandoning documentation quality. ## Teaching AI Technical Writing Principles - The team analyzed existing technical writing review comments to identify how writers evaluate documents. - Existing writing guidelines were converted into explicit principles, such as: - Focus each page on one subject. - Present value before implementation details. - Each principle was supplemented with incorrect and correct examples so AI would understand the intent rather than apply rules mechanically. - Common document types were converted into templates. - Templates include: - Instructions explaining what each section should contain. - `(required)` markers for information that must not be omitted. - For example, an ADR template requires an overview, context, considered alternatives, decision, and rationale, while also allowing optional sections such as expected outcomes and related references. ## Skill for Writing New Documents The document-writing Skill reproduces the four stages a technical writer typically follows: - **Clarify the purpose:** Ask about the project, document goal, audience, level of detail, source materials, and expected structure. - **Design the structure:** Use a standard structure or select a relevant template, such as onboarding guides, meeting notes, or PRDs. - **Write the content:** Apply technical writing and MDX rules while using templates as structural guidance. - **Review the draft:** Check for awkward wording, missing information, and other quality issues. The Skill also distinguishes between required and optional template sections: - Required sections remain in the draft even when source information is incomplete. - Missing information is represented with questions or comments rather than guesses. - Optional sections are omitted when there is not enough source material to complete them. ## Skill for Reviewing and Improving Documents - The team initially converted past review comments into a checklist. - This produced poor results: AI overlooked important issues while generating unnecessary comments. - The problem was that good writing follows relatively stable principles, whereas bad writing can fail in many different ways. - The revised workflow lets AI independently: - Read the technical writing principles. - Analyze the document. - Identify violations. - Explain the issue and suggest revised wording. - Perform a final checklist-based review. - Previous review comments are now used as examples of how principles apply, rather than as a rigid list of required findings. - One example principle requires descriptions of parameters or properties to include their meaning, accepted format, and usage example—not merely a type such as `date: string`. ## Low Adoption Revealed a Usability Problem - Despite creating both Skills, the team found that few employees used them. - Users still had to: - Download and install the Skill manually. - Understand CLI-based setup, which was unfamiliar to non-developers. - Remember to invoke the Skill whenever they began writing documentation. - Find and provide all relevant source materials themselves. - The team concluded that improving the AI’s capabilities was not enough; the workflow also had to reduce the effort required from users. The main lesson is that AI-based documentation succeeds only when organizational knowledge, writing principles, and templates are encoded clearly—and when the system is integrated into everyday work so employees do not have to remember to use it or prepare everything manually.

Read original(opens in new tab)
toss3 min readCurated summary

If You Asked a Designer to Make Anything with AI

Toss Design Chapter’s AI Contest invited designers to build anything with AI, resulting in 122 projects over one month. The examples show that designers primarily used AI to improve existing work—making it faster, more persuasive, and higher quality—rather than creating entirely new kinds of work. The article recommends starting with a frustrating, repetitive task or a frequently repeated communication problem. ## Automating Repetitive Work - A color-extraction tool automatically identifies and adjusts colors from images for use in UI. - Color extraction had been an unresolved challenge at Toss because results varied widely by image. - Designers used AI to draft the logic, test it against many sample images, and rapidly refine it. - The resulting system is now used for product-card colors in Toss Shopping. ## Reducing Collaboration Costs with a Personal Bot - A Slack bot was trained on a designer’s knowledge, past discussions, and reference materials. - It creates draft answers to the many design and requirements questions the designer receives each day. - Team members can send the draft as-is or revise it before responding. - The bot learns from those revisions, improving its answers to similar questions over time. - The designer described the result as feeling like becoming “1.5 people,” and other Toss designers began creating their own bots. ## Persuading Through Interactive Prototypes - A designer built a functioning prototype of a stock-trading desktop interface instead of presenting only static screens. - Users could drag panels, rearrange them, and resize windows, with the interface responding accordingly. - Showing the intended interactions directly reduced the risk that design ideas would be misunderstood during development. - The working prototype helped align designers and developers and persuade the product owner. ## Pushing Quality Within Tight Deadlines - AI-generated motion graphics were created for the key visual of Toss Bank’s recruitment website. - Each job category needed its own animation despite a very short schedule. - The designer created the foundational images manually and repeatedly refined Kling prompts to achieve the desired results. - Human-designed starting and ending frames combined with AI-generated motion allowed all category animations to be completed in a single day. ## Four Ways to Start Using AI - **Efficiency:** Hand off one especially annoying repetitive task to AI. - **Replication:** Build a bot to answer questions you repeatedly handle yourself. - **Persuasion:** Turn designs that require verbal explanation into working prototypes. - **Quality:** Use AI to reach a higher level of polish within a limited timeframe. The practical recommendation is to begin with an existing task rather than searching for an entirely new AI application. Choose one area where AI can save time, communicate intent more clearly, or help raise the final quality.

Read original(opens in new tab)
figma2 min readCurated summary

Turning Prompts into Five Scalable Workflows with Figma Weave | Figma Blog

Figma Weave presents AI creation as a scalable, editable workflow rather than a one-off prompt. Its canvas connects AI models and processing nodes so creators can branch, refine, and reuse each step while maintaining control over imagery, video, audio, and 3D output. The article introduces five workflows, beginning with a method for deriving a reusable visual style from multiple reference images. ## Figma Weave as a Creative Workflow Canvas - Figma Weave evolved from Weavy, which Figma acquired to expand its capabilities in: - Image and video generation - Animation and motion design - Audio and 3D creation - VFX and professional editing - Users can chain prompts and AI nodes together, moving from references to finished assets without losing the ability to revise intermediate steps. - Figma has published more than 20 Community templates covering tasks such as: - Turning images into videos - Generating 3D models - Combining visual references - Comparing image-generation models ## Why Workflows Are More Scalable Than Single Prompts - A single prompt produces one interpretation of a style. - A workflow lets creators independently adjust how strongly each reference influences the result. - Individual stages can be reshaped, reused, and applied across multiple assets and channels. - The example brand, Epoch, demonstrates how the system can support a consistent visual identity based on distorted textures and 3D natural forms. ## Combining Two Images into a Reusable Style Guide - The first workflow combines a hibiscus flower and a rock face from Epoch’s existing visual references. - Each image is processed through an **Image Describer node**, which extracts attributes such as: - Texture - Color - Lighting - Composition - The resulting text descriptions can be edited and merged into a new style definition. - The balance between the two references can be adjusted until the desired blend is achieved. - The combined style can then be tested across different image-generation models, helping the team validate the look at scale. - The output is treated as a reusable style system rather than a single prompt for one image. The practical recommendation is to build visual direction as a modular workflow: analyze existing references, combine and tune their characteristics, and preserve the resulting style definition for reuse in future assets.

Read original(opens in new tab)
github3 min readCurated summary

How Squad runs coordinated AI agents inside your repository

Squad is an open-source GitHub Copilot project that places a preconfigured team of AI agents directly inside a repository. Rather than relying on a single chatbot or complex orchestration infrastructure, it coordinates specialized agents for design, implementation, testing, documentation, and review. Its core argument is that repository-native, versioned context makes multi-agent development more accessible, inspectable, and resilient. ## Coordinating Specialized Agents - Install Squad with `npm install -g @bradygaster/squad-cli`, then run `squad init` in a repository. - The setup creates roles such as lead, frontend developer, backend developer, tester, and documentation specialist. - A coordinator interprets natural-language requests, loads repository context, and assigns work to specialists. - Agents can work in parallel, create files and branches, write tests, and open pull requests. - They use shared decisions and project history rather than requiring every detail to be repeated in prompts. - Testing and review happen within the workflow: - Testers evaluate implementations and reject failing code. - A rejected author is prevented from revising its own work. - Another agent must address the problems, providing a more independent review. - Developers still answer questions, correct assumptions, and review and merge pull requests; Squad is collaborative orchestration rather than full autonomy. ## Repository-Based Shared Memory - Squad uses a “drop-box” model instead of depending on live chat synchronization or complex vector databases. - Architectural decisions, library choices, and conventions are appended to a versioned `decisions.md` file. - This creates: - Persistent shared knowledge - An understandable audit trail - Recovery after disconnects or restarts - Memory that can be reviewed and changed like code ## Replicating Context Across Agents - The coordinator remains a thin router instead of attempting to manage all implementation work. - Each specialist runs in its own inference call with an independent context window. - This replicates relevant repository context across agents rather than splitting one limited context among multiple roles. - Parallel, independent contexts reduce the risk that project-management instructions and other agents’ reasoning crowd out the actual coding task. - Supported models may provide context windows of up to 200,000 tokens. ## Versioned Agent Identities and History - Each agent’s behavior is primarily defined by repository files: - A charter describing its role and responsibilities - A history recording previous work - Shared team decisions - These files live in `.squad/` alongside the application code. - Cloning a repository also restores the team’s accumulated knowledge, making the agents effectively pre-onboarded. - Keeping memory in plain text makes it inspectable, versioned, and independent of hidden model state. ## Lowering the Barrier to Multi-Agent Development Squad’s main goal is to make agentic workflows practical without requiring users to build orchestration layers, configure databases, or master advanced prompt engineering. Its repository-native design favors simple setup, transparent memory, independent review, and recoverable project context. Developers interested in this approach can install Squad and experiment with it directly in the project repository.

Read original(opens in new tab)
figma2 min readCurated summary

5 Design Skills To Sharpen in the AI Era | Figma Blog

AI is changing product creation by accelerating experimentation and expanding who can participate in design. Figma argues that designers should strengthen adaptable, technology-oriented skills rather than rely only on traditional craft. The first priority is becoming fluent with AI tools and learning to prompt them effectively, while maintaining human judgment and design fundamentals. ## AI Fluency and Prompting - AI skills are becoming essential for designers and increasingly important in non-design roles such as product management, development, and marketing. - More than half of designers and hiring managers consider AI design capabilities—such as rapid prototyping and “vibe coding”—important hiring skills. - Among designers who adopted AI during the past year: - 91% say it helps them create better designs. - 89% say it helps them work faster. - AI can support many activities, including: - Editing images directly within a workflow. - Building prototypes instead of writing traditional product requirements documents. - Testing assumptions and creating tangible artifacts for team alignment. ## Writing Better Prompts - Clear, structured prompts produce more reliable AI-generated results. - Figma recommends organizing prompts around: - The task - Context - Required elements - Behavior - Constraints - Prompting is presented as a repeatable design practice, not merely a way to get a one-off output. - Strong prompts help turn AI into a consistent design partner rather than an unpredictable experimentation tool. ## Broader Changes to Design Work - AI is lowering barriers to participation and blurring boundaries between product roles. - Designers are increasingly expected to work across disciplines and use AI to extend their capabilities. - Prototyping is becoming a faster way to communicate ideas, validate assumptions, and build momentum than relying solely on written documentation. Designers should build practical fluency with AI tools, practice structured prompting, and use prototypes to make ideas concrete—while applying their own judgment to guide and evaluate the results.

Read original(opens in new tab)
github3 min readCurated summary

How to scan for vulnerabilities with GitHub Security Lab’s open source AI-powered framework

GitHub Security Lab’s open-source Taskflow Agent uses AI-driven, multi-step auditing workflows to find high-impact vulnerabilities in web applications and open-source projects. The authors report more than 80 vulnerabilities, including authorization bypasses and private-data disclosures, with about 20 already disclosed. They argue that carefully designed taskflows and prompts can give LLMs enough freedom to discover vulnerabilities while reducing hallucinations and false positives. ## Running the Audits - The taskflows are available in the [`seclab-taskflows`](https://github.com/GitHubSecurityLab/seclab-taskflows) repository. - To run an audit: 1. Start a Codespace for the repository. 2. Wait for initialization. 3. Run `./scripts/audit/run_audit.sh myorg/myrepo`. - Audits may take one or two hours on a medium-sized repository. - Results are stored in SQLite and can be inspected in the `audit_results` table. - Rows marked with a check in `has_vulnerability` indicate potential findings. - A GitHub Copilot license and premium model requests are required. - The same repository should be audited multiple times because LLM results are nondeterministic; using different models may reveal different vulnerabilities. - Private repositories require changes to the Codespace configuration to grant access. ## How Taskflows Work - Taskflows are YAML files defining ordered tasks and dependencies for an LLM. - The `seclab-taskflow-agent` runs tasks sequentially and passes their results between stages. - Repository audits begin by dividing the codebase into functional components. - For each component, context is gathered, including: - Untrusted-input entry points - Intended privilege levels - Component purposes and behavior - This context is stored in a database for later auditing tasks. - Separate tasks can: - Suggest generic security issues - Carefully verify each suggested issue - Focus on specific vulnerability classes - Tasks can be reused across many components asynchronously through templated prompts and component-specific substitutions. ## Why Use Multiple Tasks - A single large prompt is less reliable because LLMs may omit steps in complex, multi-stage investigations. - Taskflows help control, debug, and structure the process even when models provide large context windows. - Breaking work into stages allows each result to be reviewed and reused as context for subsequent analysis. - Repeated task execution across components makes the approach scalable for large repositories. ## General Security Auditing - The team initially used the framework to triage CodeQL alerts, where strict instructions and predefined criteria helped limit false positives. - General auditing is more difficult because the LLM must search broadly for vulnerabilities rather than evaluate known alerts. - Greater freedom increases the risk of hallucinations and unexploitable findings. - The authors’ approach uses taskflow design and prompt engineering to preserve a high true-positive rate while allowing the model to investigate diverse security issues. ## Reported Vulnerabilities - The taskflows have found more than 80 vulnerabilities in open-source projects. - Many reported issues are high-impact, including: - Authorization bypasses - Information disclosure - Logging in as another user - Accessing private user data - Examples include exposing personally identifiable information in ecommerce shopping carts and authenticating to a chat application with arbitrary passwords. - The authors manually verify findings before reporting them and maintain an advisories page as disclosures become public. The practical recommendation is to run the open-source taskflows on your own projects, repeat audits with different models, and manually validate every result. The framework is intended to improve through shared taskflows, prompts, and findings across the security community.

Read original(opens in new tab)
daangn5 min readCurated summary

Things I learned using 2

Karrot’s Taxonomy team built an LLM-powered system to classify marketplace posts, group activities, and local businesses into a shared category and attribute structure. After finding that manually managed taxonomies and event-only pipelines were difficult to scale, they created a configurable Taxonomy Management System using Dataflow/Beam, BigQuery, Kafka, and multiple LLM strategies. The system emphasizes scalable inference, rapid evaluation, multilingual support, and continuous taxonomy expansion. ## What a Taxonomy Is and Why It Matters - A taxonomy is a hierarchical category system, such as `Outerwear > Padding/Down > Long Padding`. - It can also include attributes that describe an item’s characteristics: - Category: long padding - Attributes: brand=Nike, color=black, material=polyester - A consistent taxonomy acts as a shared language across: - Search, including parent and child-category expansion - Recommendations and diversity controls - Advertising and targeting segments - Analytics and machine-learning features ## Karrot’s Taxonomy Challenges - Karrot manages roughly 1,400 marketplace categories across up to three levels. - Users are not required to manually select highly detailed categories because that would increase posting friction and produce unreliable labels. - Earlier systems used a Golang Kafka consumer to receive posting events and extract categories with an LLM. - This approach had several limitations: - Taxonomy definitions were managed separately by different teams. - Categories alone could not express useful properties such as season or material. - Batch processing and backfilling were difficult. - Expanding to data sources outside Kafka was inconvenient. - Quality monitoring and failure handling were insufficient. - Changes to prompts or models required slow offline and online experiments. ## The Taxonomy Management System - The new system centrally manages taxonomies, performs LLM-based classification, delivers category and attribute results, and monitors quality. - Dataflow with Apache Beam was selected because it supports: - Parallel, high-throughput LLM inference - Both streaming and large-scale batch processing - Existing team expertise compared with alternatives such as Spark or Flink - BigQuery serves as the source of truth for inference results. - Analysts and data scientists can query results directly. - Online consumers can receive results through Kafka sinks into the internal feature platform. ## Configuration-Driven and Extensible Design - Taxonomy definitions are stored in YAML, allowing different services and category trees to use the same framework. - Pipeline settings, worker sizing, Kafka topics, and BigQuery destinations are also configured through YAML. - LLM models and inference strategies can be selected through configuration, including: - Primary and evaluation models - Single-shot or two-stage categorization - Attribute extraction modes - Evaluation sampling ratios - The system is designed for multilingual taxonomies. - Large translation jobs are divided into chunks. - One LLM generates translations and another validates consistency and naturalness. - A depth-first traversal carries parent-category translations into child-category prompts to maintain terminology consistency. ## Creating and Expanding Taxonomies with LLMs - New taxonomies are developed by researching established taxonomies and generating candidate trees from real data. - Existing taxonomies are expanded by: - Classifying sampled data against the current taxonomy - Asking the LLM to suggest categories for unsuitable examples - Merging similar suggestions using LLM similarity judgments - Promoting sufficiently strong candidates for review - Candidates undergo two evaluations: - Whether the originating examples are correctly assigned to the new category - Regression testing comparing classifications under the old and new taxonomies - This process enabled the team to move beyond the existing 1,400 three-level categories and create taxonomies with more than 10,000 categories and six or more levels. ## LLM Categorization Strategies The team supports multiple strategies because the best approach depends on the model and taxonomy size: - **Single shot:** Provide all categories and ask the model to choose one. - **Hierarchical classification:** Select the best category at each depth, then continue through the chosen branch. - **Two-stage tournament:** Split categories into chunks, select candidates from each chunk, and run a second selection among those candidates. - Categorization and attribute assignment are separate modular Beam `DoFn` stages: - `Article → Category inference → Attribute inference` - New approaches can be added as interchangeable strategies without redesigning the whole pipeline. ## Evaluation with LLM-as-a-Judge - A sample of production data is processed by multiple different models. - Their labels are combined into a ground-truth label, generally through majority voting. - Each model’s output is compared against that ground truth. - Accuracy changes are tracked whenever the team modifies: - The LLM model - Prompts - Pipeline structure - Categorization or attribute strategies - The ground-truth method varies depending on whether the task involves: - A single category - Multiple categories - Multi-label attributes - Category quality is measured as a precision-at-one-style accuracy: the primary model’s category must match the ground-truth category. - Attributes are evaluated with precision and recall because a post can legitimately contain multiple attribute-value pairs. The main recommendation is to treat LLM classification as a production data pipeline rather than a one-off prompt: centralize taxonomy management, support both batch and streaming execution, make inference strategies configurable, and build automated evaluation and monitoring into the system from the beginning.

Read original(opens in new tab)
spotify4 min readCurated summary

Inside the Archive: The Tech Behind Your 2025 Wrapped Highlights | Spotify Engineering

Spotify’s 2025 Wrapped Archive identified up to five remarkable listening days for each eligible user and turned them into personalized, LLM-generated stories. A distributed pipeline, carefully designed prompts, model distillation, and massive-scale pre-generation made it possible to create roughly 1.4 billion reports before launch. The system prioritized factual grounding, creative consistency, safety, and reliable parallel storage. ## Identifying Remarkable Listening Days - Spotify used a priority-ordered set of heuristics to evaluate each user’s full year of listening. - Straightforward categories included: - Biggest Music Listening Day - Biggest Podcast Listening Day - Biggest Discovery Day, based on first-time artists - Biggest Top Artist Day - Biggest Top Genre Day - More nuanced categories detected: - Nostalgic listening and throwback-heavy sessions - Unusual listening patterns that differed from a user’s typical taste - Contextual dates such as birthdays and New Year’s Day - Candidate days were ranked by narrative potential and statistical strength, reducing hundreds of millions of events to as many as five standout days per user. - A distributed data pipeline aggregated the results and stored listening data in object storage. - Messaging queues then moved each user’s data asynchronously into report generation. ## Prompt Engineering for Reliable Stories - Spotify spent more than three months iterating on prompts and evaluating edge cases. - The system prompt established: - Traceability to real listening behavior - A witty, sincere, and quietly playful tone - Safety constraints excluding references to drugs, alcohol, sex, violence, and offensive language - User prompts supplied: - Detailed daily listening logs - Precomputed statistics, since LLMs are unreliable at arithmetic - Overall Wrapped data - The remarkable-day category - Previously generated reports to reduce repetition - The user’s country for appropriate spelling and vocabulary - Outputs were improved through prototype comparisons, LLM-based judging, human review, and feedback from creative, technical, and safety teams. ## Distilling the Model for Scale - Larger frontier models produced strong results during prototyping but were too expensive for more than a billion generations. - Spotify generated high-quality reference outputs and curated them into a reviewed “gold” dataset. - A smaller, faster production model was fine-tuned on that dataset. - Direct Preference Optimization (DPO), based on curated human A/B evaluations, further aligned the smaller model with the preferred output style. - The resulting model achieved preference performance comparable to the larger baseline. ## Generating 1.4 Billion Reports - Approximately 350 million users were eligible, with up to five reports each. - Spotify pre-generated about 1.4 billion reports before Wrapped launch. - The system sustained thousands of model requests per second over several days. - After remarkable days were computed, snapshots were published to a pub/sub queue. - Reports were generated sequentially per user so earlier reports could inform later ones and prevent repetition. - Real-time dashboards tracked throughput, reliability, errors, and projected completion time. - The generation engine ran continuously for four days, followed by checks for missing reports, inconsistencies, and necessary re-generation. ## Designing Storage for Concurrent Writes - Completed reports were stored in a distributed, column-oriented key-value database optimized for high-throughput writes. - Each user occupied a single row, with separate columns representing completed remarkable days. - Instead of maintaining a serialized list—which could cause race conditions during read-modify-write operations—each date received its own column qualifier in `YYYYMMDD` format. - Independent reports could therefore be written concurrently to separate cells without locks or coordination. - Report content was written first, followed by lightweight metadata marking the report complete. - This ordering prevented the system from exposing a completion marker before the underlying report was safely stored. ## Practical Conclusion Building Wrapped Archive required treating creative AI generation as a large-scale production system: ground outputs in structured data, use smaller specialized models when volume demands it, evaluate continuously, and design storage schemas that make concurrency safe by default.

Read original(opens in new tab)
tossOriginal article

Will developers be replaced by AI? (opens in new tab)

The current AI hype cycle is a significant economic bubble where massive infrastructure investments of $560 billion far outweigh the modest $35 billion in generated revenue. However, drawing parallels to the 1995 dot-com era, the author argues that while short-term expectations are overblown, the long-term transformation of the developer role is inevitable. The conclusion is that developers won't be replaced but will instead evolve into "Code Creative Directors" who manage AI through the lens of technical abstraction and delegation. ### The Economic Bubble and Amara’s Law * The industry is experiencing a 16:1 imbalance between AI investment and revenue, with 95% of generative AI implementations reportedly failing to deliver clear efficiency improvements. * Amara’s Law suggests that we are overestimating AI's short-term impact while potentially underestimating its long-term necessity. * Much of the current "AI-driven" job market contraction is actually a result of companies cutting personnel costs to fund expensive GPU infrastructure and AI research. ### Jevons Paradox and the Evolution of Roles * Jevons Paradox indicates that as the "cost" of producing code drops due to AI efficiency, the total demand for software and the complexity of systems will paradoxically increase. * The developer’s identity is shifting from "code producer" to "system architect," focusing on agent orchestration, result verification, and high-level design. * AI functions as a "power tool" similar to game engines, allowing small teams to achieve professional-grade output while amplifying the capabilities of senior engineers. ### Delegation as a Form of Abstraction * Delegating a task to AI is an act of "work abstraction," which involves choosing which low-level details a developer can afford to ignore. * The technical boundary of what is "hard to delegate" is constantly shifting; for example, a complex RAG (Retrieval-Augmented Generation) pipeline built for GPT-4 might become obsolete with the release of a more capable model like GPT-5. * The focus for developers must shift from "what is easy to delegate" to "what *should* be delegated," distinguishing between routine boilerplate and critical human judgment. ### The Risks of Premature Abstraction * Abstraction does not eliminate complexity; it simply moves it into the future. If the underlying assumptions of an AI-generated system change, the abstraction "leaks" or breaks. * Sudden shifts in scaling (traffic surges), regulation (GDPR updates), or security (zero-day vulnerabilities) expose the limitations of AI-delegated work, requiring senior intervention. * Poorly managed AI delegation can lead to "abstraction debt," where the cost of fixing a broken AI-generated system exceeds the cost of having written it manually from the start. To thrive in this environment, developers should embrace AI not as a replacement, but as a layer of abstraction. Success requires mastering the ability to define clear boundaries for AI—delegating routine CRUD operations and boilerplate while retaining human control over architecture, security, and complex business logic.

lineOriginal article

Building an Enterprise LLM (opens in new tab)

LY Corporation’s engineering team developed an AI assistant for their private cloud platform, Flava, by prioritizing "context engineering" over traditional prompt engineering. To manage a complex environment of 260 APIs and hundreds of technical documents, they implemented a strategy of progressive disclosure to ensure the LLM receives only the most relevant information for any given query. This approach allows the assistant to move beyond simple RAG-based document summarization to perform active diagnostics and resource management based on real-time API data. ### Performance Limitations of Long Contexts * Research indicates that LLM performance can drop by 13.9% to 85% as context length increases, even if the model technically supports a large token window. * The phenomenon of "context rot" occurs when low-quality or irrelevant information is mixed into the input, causing the model to generate confident but incorrect answers. * Because LLMs are stateless, maintaining conversation history and processing dense JSON responses from multiple APIs quickly exhausts context windows and degrades reasoning quality. ### Progressive Disclosure and Tool Selection * The system avoids loading all 260+ API definitions at once; instead, it analyzes the user's intent to select only the necessary tools, such as loading only Redis-related APIs when a user asks about a cluster. * Specific product usage hints, such as the distinction between private and CDN settings for Object Storage, are injected only when those specific services are invoked. * This phased approach significantly reduces token consumption and prevents the model from being overwhelmed by irrelevant technical specifications. ### Response Guidelines and the "Mock Tool Message" Strategy * The team distinguished between "System Prompts" (global rules) and "Response Guidelines" (situational instructions), such as directing users to a console UI before suggesting CLI commands. * Injecting specific guidelines into the system prompt often caused "instruction conflict," where the LLM might hallucinate information to satisfy a guideline while ignoring core requirements like using search tools. * To resolve these conflicts, the team utilized "ToolMessages" to inject guidelines; by formatting instructions as if they were results from a tool execution, the LLM treats the information as factual context rather than a command that might override the system prompt. To build a robust enterprise LLM service, developers should focus on dynamic context management rather than static prompt optimization. Treating operational guidelines as external data via mock tool messages, rather than system instructions, provides a scalable way to reduce hallucinations and maintain high performance across hundreds of integrated services.

figma3 min readCurated summary

Cooking with Constraints: A Designer’s Framework for Better AI Prompts | Figma Blog

Design and cooking both depend on preparation: clear inputs and intentional constraints lead to better outcomes. The article argues that AI models do not need politeness or emotional framing; they need precise instructions that reduce ambiguity. For product designers, structured prompting bridges the gap between probabilistic AI outputs and the repeatable, purposeful results design requires. ## Prompting as Mise en Place - “Mise en place,” or “everything in its place,” means preparing ingredients before cooking—and serves as a useful model for preparing AI prompts. - Effective prompts should establish: - **Clarity** - **Context** - **Constraints** - The author’s framework is **TC-EBC**: - **Task:** What should be built or accomplished? - **Context:** Who is it for and why? - **Elements:** Which features or components are required? - **Behavior:** How should the system respond to user actions? - **Constraints:** What technical, platform, accessibility, or product limits apply? - This approach aligns with broader prompt-engineering guidance emphasizing defined intent, modular construction, and predictable results. ## Why Vague Prompts Underperform - A request such as “build an app that uses pantry photos to suggest recipes” leaves too many decisions to the model. - Polite language and conversational phrasing can bury the actual task without adding useful information. - The resulting prototype may include basic functionality but remain visually generic, uninteresting, and barely beyond a wireframe. ## Applying TC-EBC to a Design Prompt For a pantry-based meal suggestion app, the structured prompt specifies: - **Task:** Build an AI-powered meal suggestion app using pantry and refrigerator photos. - **Context:** Create a home-cooking assistant for households with dietary restrictions. - **Elements:** Include camera input, pantry scanning, dietary settings, meal suggestions, and recipe cards. - **Behavior:** Let users upload photos, scan inventory, apply dietary preferences, and receive recipes. - **Constraints:** Make the experience mobile-first, support iOS and Android, provide accessible UI, and allow multiple household profiles. This structure makes the request easier to scan and gives the model explicit guidance about the app’s purpose, interface, behavior, and limitations. ## Design Requires Structured Uncertainty - LLMs are stochastic, meaning their outputs are probabilistic and variable. - Design, by contrast, depends on precision, consistency, and intentional decisions. - Structured prompts help “collapse uncertainty into structure,” much as a design system provides reusable rules and guidance. - The article presents the TC-EBC prompt as producing a substantially more purposeful prototype than the original one-shot request. A practical recommendation is to treat prompting like preparation for a complex recipe: define the task, provide relevant context, list required parts and behaviors, and state constraints before asking the AI to generate a design.

Read original(opens in new tab)
daangnOriginal article

Daangn's GenAI Platform (opens in new tab)

Daangn has scaled its Generative AI capabilities from a few initial experiments to hundreds of diverse use cases by building a robust, centralized internal infrastructure. By abstracting model complexity and empowering non-technical stakeholders, the company has optimized API management, cost tracking, and rapid product iteration. The resulting platform ecosystem allows the organization to focus on delivering product value while minimizing the operational overhead of managing fragmented AI services. ### Centralized API Management via LLM Router Initially, Daangn faced challenges with fragmented API keys, inconsistent rate limits across teams, and the inability to track total costs across multiple providers like OpenAI, Anthropic, and Google. The LLM Router was developed as an "AI Gateway" to consolidate these resources into a single point of access. * **Unified Authentication:** Service teams no longer manage individual API keys; they use a unique Service ID to access models through the router. * **Standardized Interface:** The router uses the OpenAI SDK as a standard interface, allowing developers to switch between models (e.g., from Claude to GPT) by simply changing the model name in the code without rewriting implementation logic. * **Observability and Cost Control:** Every request is tracked by service ID, enabling the infrastructure team to monitor usage limits and integrate costs directly into the company’s internal billing platform. ### Empowering Non-Engineers with Prompt Studio To remove the bottleneck of needing an engineer for every prompt adjustment, Daangn built Prompt Studio, a web-based platform for prompt engineering and testing. This tool enables PMs and other non-developers to iterate on AI features independently. * **No-Code Experimentation:** Users can write prompts, select models (including internally served vLLM models), and compare outputs side-by-side in a browser-based UI. * **Batch Evaluation:** The platform includes an Evaluation feature that allows users to upload thousands of test cases to quantitatively measure how prompt changes impact output quality across different scenarios. * **Direct Deployment:** Once a prompt is finalized, it can be deployed via API with a single click. Engineers only need to integrate the Prompt Studio API once, after which non-engineers can update the prompt or model version without further code changes. ### Ensuring Service Reliability and Stability Because third-party AI APIs can be unstable or subject to regional outages, the platform incorporates several safety mechanisms to ensure that user-facing features remain functional even during provider downtime. * **Automated Retries:** The system automatically identifies retry-able errors and re-executes requests to mitigate temporary API failures. * **Region Fallback:** To bypass localized outages or rate limits, the platform can automatically route requests to different geographic regions or alternative providers to maintain service continuity. ### Recommendation For organizations scaling AI adoption, the Daangn model suggests that investing early in a centralized gateway and a no-code prompt management environment is essential. This approach not only secures API management and controls costs but also democratizes AI development, allowing product teams to experiment at a pace that is impossible when tied to traditional software release cycles.

lineOriginal article

We held AI Campus Day to improve (opens in new tab)

LY Corporation recently hosted "AI Campus Day," a large-scale internal event designed to bridge the gap between AI theory and practical workplace application for over 3,000 employees. By transforming their office into a learning campus, the company successfully fostered a culture of "AI Transformation" through peer-led mentorship and task-specific experimentation. The event demonstrated that internal context and hands-on participation are far more effective than traditional external lectures for driving meaningful AI literacy and productivity gains. ## Hands-on Experience and Technical Support * The curriculum featured 10 specialized sessions across three tracks—Common, Creative, and Engineering—to ensure relevance for every job function. * Sessions ranged from foundational prompt engineering for non-developers to advanced technical topics like building Model Context Protocol (MCP) servers for engineers. * To ensure smooth execution, the organizers provided comprehensive "Session Guides" containing pre-configured account settings and specific prompt templates. * The event utilized a high support ratio, with 26 teaching assistants (TAs) available to troubleshoot technical hurdles in real-time and dedicated Slack channels for sharing live AI outputs. ## Peer-Led Mentorship and Internal Context * Instead of hiring external consultants, the program featured 10 internal "AI Mentors" who shared how they integrated AI into their actual daily workflows at LY Corporation. * Training focused exclusively on company-approved tools, including ChatGPT Enterprise, Gemini, and Claude Code, ensuring all demonstrations complied with internal security protocols. * Internal mentors were able to provide specific "company context" that external lecturers lack, such as integrating AI with existing proprietary systems and data. * A rigorous three-stage quality control process—initial flow review, final end-to-end dry run, and technical rehearsal—was implemented to ensure the educational quality of mentor-led sessions. ## Gamification and Cultural Engagement * The event was framed as a "festival" rather than a mandatory training, using campus-themed motifs like "enrollment" and "school attendance" to reduce psychological barriers. * A "Stamp Rally" system encouraged participation by offering tiered rewards, including welcome kits, refreshments, and subscriptions to premium AI tools. * Interactive exhibition booths allowed employees to experience AI utility firsthand, such as an AI photo zone using Gemini to generate "campus-style" portraits and an AI Agent Contest booth. * Strong executive support played a crucial role, with leadership encouraging staff to pause routine tasks for the day to focus entirely on AI experimentation and "playing" with new technologies. To effectively scale AI literacy within a large organization, it is recommended to move away from passive, one-size-fits-all lectures. Success lies in leveraging internal experts who understand the specific security and operational constraints of the business, and creating a low-pressure environment where employees can experiment with hands-on tasks relevant to their specific roles.