Toss/Large Language Models

11 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)
toss4 min readCurated summary

LLMs Are Smart, So Why Don’t They Know How Our Company Works?

LLMs handle public knowledge well but struggle with company-specific questions because relevant evidence is scattered across documents, code, meetings, and chat—and may be outdated or contradictory. The post argues that this is not merely a search problem: organizations need a shared layer for managing trustworthy context. Topic addresses this by extracting source-aware units, linking concepts and relationships, and verifying their freshness, consistency, and evidentiary support. ## Why Search Alone Is Not Enough - Search retrieves relevant text but cannot determine whether it is current, authoritative, or consistent with other sources. - A retry-policy example might contain: - Documentation saying requests fail immediately - A meeting discussion proposing three retries - Code currently implementing two retries - Agents must still determine: - Whether the meeting produced a final decision - Which source is newer - Whether the code reflects an intentional change or an unfinished implementation - Whether different sources describe the same behavior - Topic provides a shared context layer so humans and LLMs use the same sources, relationships, freshness information, and conflict states. ## Six Dimensions of Trust Rather than compressing trust into one score, Topic evaluates six separate dimensions: - **Granularity:** Whether the context is a meaningful, independently manageable unit - **Faithfulness:** Whether the source actually supports the claim - **Staleness:** Whether the evidence remains valid - **Canonicality:** Whether different names refer to the same entity - **Consistency:** Whether sources are compatible - **Coverage:** Whether important evidence or perspectives are missing Different checks use different methods: rules and hashes for deterministic validation, LLMs for semantic interpretation, and humans for ambiguous or high-impact decisions. ## Ingesting Documents, Chat, and Code Topic normalizes information into a common `ContentUnit` containing source type, unit type, original URI, content, hashes, timestamps, and source-specific metadata. It uses different boundaries for each source rather than splitting everything into fixed-size text chunks. ### Structured Document Sections - Markdown documents are divided by heading hierarchy. - Parent headings are preserved to retain context. - Long sections are split only when necessary. - URLs, document paths, and creation or modification times remain attached to the unit. ### Conversation Threads - Entire messenger threads are treated as the semantic unit, not individual messages. - Summaries preserve: - Technical identifiers such as function names and file paths - Questions, alternatives, and final outcomes - Decisions versus unresolved issues - The system avoids inventing consensus and ignores threads containing only casual conversation. ### Code Symbols and Semantic Cards - Parsers extract functions, classes, file paths, line ranges, imports, and other symbols without using an LLM. - Multiple symbols are then grouped into **code semantic cards** describing business behavior. - Cards retain domain terms, code identifiers, source spans, and the relevant commit SHA. - LLM-generated cards are checked against actual files, line ranges, supporting spans, and duplicate-card patterns. - Cards are an intermediate layer for connecting code to business concepts, not a replacement for the code itself. ## Extracting Concepts and Relationships - Topic extracts concept candidates and supporting evidence from each content unit. - It preserves the relationship between every concept and its original evidence. - Similar names are not automatically merged merely because they appear close in meaning. - Concepts can be consolidated into canonical entities only when sufficient evidence exists. ### Human Review for Ambiguous Terminology - Normalization and embeddings can identify obvious duplicates. - Internal abbreviations and aliases may require organizational knowledge. - Topic creates synonym proposals with their supporting context. - Humans approve or reject ambiguous aliases; rejected proposals are remembered to prevent repeated suggestions. ### Typed Document–Code Relationships Topic distinguishes among: - `supported_by`: code behavior supports the document’s claim - `contradicted_by`: code behavior conflicts with the document - `mentions`: both refer to the same area, but support or contradiction is unconfirmed Embedding search first narrows possible matches, after which semantic verification is performed. Low-confidence or failed checks do not create relationships; an absent relationship means “not yet verified,” not necessarily “unrelated.” ## Incremental Verification and Change Detection - Stable identifiers and content hashes allow unchanged units to reuse previous extraction and relationship results. - Deleted sources trigger cleanup of dependent relationships. - Code anchors store the validating commit and span hash. - If an anchor disappears, it is marked orphaned. - If the span remains unchanged, semantic verification can be skipped. - If the span changes, faithfulness must be checked again. - Rule-based checks happen before LLM calls, reducing cost and limiting nondeterministic reasoning to cases that require it. Topic’s practical recommendation is to treat trustworthy internal context as a managed system rather than a search result. Preserve source structure, keep evidence attached to every claim, use automation for deterministic work, and route ambiguous organizational judgments to people.

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

How Do TAMs Solve Problems in Fast-Moving Organizations?

TAM CONNECT 2025 brought together Technical Account Managers from Toss and Kakao Pay to compare how they connect technology, business, customers, and internal teams. Although their organizations differ, they face similar challenges: operational complexity, cross-team coordination, recurring incidents, and the need to improve customer experience. The event framed TAMs not as basic support staff, but as technology-driven problem solvers whose role is expanding through automation and AI. ## The Scope of a TAM’s Role - TAMs resolve partner integration issues and advise on API adoption. - They coordinate multiple teams during incidents and improve operational processes. - Their work includes automating recurring problems and influencing product and platform design. - Depending on the situation, a TAM may act like a developer, product manager, or incident leader. - At Toss, their responsibilities span authentication, Face Connect, financial platforms, online and offline payments, and partner APIs. ## Reducing Alert Noise and Preventing Recurring Problems - Toss’s Dayoung Park presented a problem-solving framework that began by redefining which alerts truly require attention. - Excessive notifications can obscure serious incidents, so the team focused on identifying meaningful operational signals. - They structured incident patterns, detected recurring issues automatically, and analyzed the root causes of settlement discrepancies. - The goal was not merely to resolve incidents faster, but to build systems that prevent them from recurring. ## Making Operations Independent of Individual Owners - PayToss’s Gimun Lee discussed reducing dependency on specific people’s knowledge. - Response histories and operational information were shared transparently so anyone could handle an issue. - Their Discord developer community used n8n workflows, LLM-based log analysis, and automatically generated incident-cause and resolution suggestions. - These tools helped the team maintain an average response time of under ten minutes. ## Using Customer Experience to Improve TAM Work - Toss’s Seongmin Chun drew on previous experience working for a customer organization. - Understanding customer frustrations and the information needed during incidents influenced his communication and support practices. - The team used the PDCA cycle to continually improve integration guides, standardize repeated communications, and structure operational processes. - Effective TAM work means not only solving current problems but also ensuring the same problems do not happen again. ## Shared Challenges Across Companies - TAMs must balance customer expectations with internal development teams. - They operate in rapidly changing services with increasingly complex systems. - The role requires simultaneous understanding of technology, business priorities, and customer needs. - TAMs often appear to sit ambiguously between support, operations, development, and business, but their actual work involves structuring complex problems and mobilizing multiple teams. - The event characterized TAMs as technology-based problem solvers rather than simple support personnel. ## AI and the Future of TAM Work - AI is already being applied to: - Log analysis - Incident-cause recommendations - Operations guide generation - Automated responses to recurring inquiries - Anomaly detection - Document search and summarization - As AI handles repetitive responses, TAMs are likely to focus more on complex problem-solving, structural improvements, cross-team coordination, customer-experience design, and operational strategy. TAM CONNECT demonstrated that TAM organizations can learn significantly from one another. As technology and services become more complex, TAMs will likely become increasingly strategic, combining automation and AI with the judgment needed to improve systems, processes, and customer experiences.

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

Rubric Design and System Implementation for Skill Quality Management

Toss’s AI DX Team created a 30-item rubric to improve the quality of internal Skills used by coding agents. The central conclusion is that deterministic defects should be checked with rules, while semantic questions—especially whether a Skill will be triggered—should be evaluated by an LLM. This separation improves accuracy, cost efficiency, and developer feedback. ## Why Skill Evaluation Is Difficult Skills are artifacts that are both invoked and read by LLMs, so they lack the compiler and test-based validation available for code. - Defects can accumulate silently: - A Skill may never be invoked. - It may be invoked but have little practical effect. - Two especially common problems are: - **Trigger failure:** Trigger conditions are placed in the Skill body instead of its description. Agents inspect the description when deciding whether to invoke a Skill; the body is read only afterward. - **Format failure:** Invalid naming conventions, mismatched folder names, or malformed metadata can prevent the agent from recognizing the Skill at all. ## Rules for Deterministic and Semantic Checks The rubric explicitly separates the 30 checks into: - **17 rule-based checks** - Use regular expressions, counts, and AST parsing. - Handle objective issues consistently and cheaply. - **13 model-based checks** - Use an LLM for meaning-dependent judgments. - Evaluate questions such as whether a description adequately communicates when the Skill should be used. Mixing the two approaches causes problems: - LLMs may overlook clear format violations. - Regular expressions produce false positives when trying to understand varied natural-language intent. - Rule checks can run on every pull request at nearly no cost. - Model checks run only after structural blockers have passed, reducing LLM expenses. ## Rubric Structure and Severity The rubric contains six sections and 30 evaluation items. - Each item is classified as: - **BLOCKER** - **MAJOR** - **MINOR** - Results are summarized using grades from **S to F**. - Any single BLOCKER automatically produces an **F**. - The grade is primarily a compact signal for authors; merge eligibility is simplified to whether the result is F or not-F. ## Validity: Does the Skill Need to Exist? The validity section contains three MAJOR checks. - It asks whether the Skill: - Has a legitimate reason to exist. - Provides recurring or reusable value. - Offers something more useful than simply asking the coding agent to perform the task directly. - This section is intended to identify Skills that should not have been created in the first place. ## Structure: Catching Format Errors The structure section has eight checks, including five BLOCKER-level checks. The rule-based implementation verifies items such as: - Presence and parseability of YAML frontmatter. - `name` following lowercase kebab-case. - Consistency between the Skill’s `name` and its folder name. - Description length between 1 and 1,024 characters. - Absence of XML tags in the body. The checks collect all failures and return them together so authors can fix multiple problems from a single pull-request comment. Only an unrecoverable frontmatter parsing failure causes an immediate return. ## Trigger Design: Making Skills Discoverable The trigger section contains six checks, including one BLOCKER. - A description must communicate both: - **WHAT** the Skill does. - **WHEN** it should be used. - A detailed “when to use” section in the body is insufficient because the agent cannot see the body during invocation selection. - The team initially tried regular expressions to detect trigger signals such as: - “when” - “use when” - Korean expressions meaning “when using” or “at the time of.” - This produced failures because trigger intent can be expressed through emojis, indirect wording, and many other forms that keyword lists cannot cover. - The final approach assigns the semantic question—whether the description covers the body’s trigger conditions—to an LLM. The resulting design favors simple, repeatable rule checks for formal correctness and model-based evaluation only where natural-language meaning is unavoidable.

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

How the Toss Team Faces the AI Wave: AI Surf Day

Toss created **AI Surf Day**, a dedicated weekly time for employees to experiment with AI, share lessons, and redesign their workflows. Running on Fridays from April through June, the initiative aims to reduce the AI gap across technical and nontechnical roles by making experimentation collaborative and accessible. Its broader conclusion is that successful AI transformation depends less on formal programs than on culture, time, and people who actively share what they learn. ## AI Surf Day’s Purpose - Employees focus on their core work Monday through Thursday and reserve Friday for AI experimentation and practical application. - The program addresses anxiety and knowledge gaps, especially among nondevelopers who may struggle to identify useful AI information or find time to learn it. - Its concept comes from Jon Kabat-Zinn’s phrase: “You can’t stop the waves, but you can learn to surf.” - The goal is to help Toss become a company that works with AI as a foundation, not merely a workplace where individuals use AI tools. ## AI Surf Club - Employees can create or join informal groups focused on AI topics; roughly 200 clubs were formed at launch. - An **AI Antipattern Study** focused on failures and mistakes, turning participants’ experiences into a practical guide for avoiding common problems. - An **LLM Wiki** group explored how to organize scattered organizational knowledge across data engineering, machine learning, and business teams. - A beginner-focused “Step 0” group helped employees overcome basic technical barriers, such as installing agent tools and asking questions they felt were too fundamental. - A customer-protection team built an external-complaint monitoring portal in one month, along with automation for complaint-response drafts and classification. - A marketing team divided AI work into roles such as: - **Builder:** creates AI-powered tools and workflows - **Curator:** collects useful examples and resources - **Operator:** applies AI to repetitive work - **Scouter:** identifies new opportunities - The clubs emphasized reusable outputs and shared confidence, rather than isolated individual experimentation. ## AI Surf Weekly - Weekly sessions share successful internal AI applications, lessons learned, and current industry insights. - Toss connected employees with similar needs across different departments, enabling them to solve problems quickly by learning from existing internal examples. - Rather than prescribing specific tools, the program presents ideas and use cases that encourage employees to adapt solutions to their own work. - Examples included connecting a sales employee with an HR colleague who had built a similar tool, and pairing a marketer with a designer experienced in AI-powered automation. ## AI Surf Evangelists - Toss selected 142 employees across its affiliated companies and teams to promote AI adoption in their own organizations. - Evangelists were chosen through peer nominations, recognizing people who already shared useful discoveries and helped colleagues overcome AI-related obstacles. - Their responsibilities over three months include: - Reporting effective AI use cases - Sharing useful insights with colleagues - Hosting at least one meetup or workshop - Toss’s Culture team provides workshop templates and facilitation support. - Many teams have conducted workshops around redesigning their existing workflows with AI. - The program treats AI adoption as a team-level workflow redesign challenge, rather than simply measuring individual proficiency with AI tools. ## OpenAI Collaboration and Mini-Hackathon - Toss held a special AI Surf Day with OpenAI on May 15. - Hands-on sessions covered: - Codex-based development workflows for developers - ChatGPT Agent-based automation for nondevelopers - A 2.5-hour hackathon produced two notable projects: - An iOS workflow where Codex implements features, operates the simulator, tests the result, iterates on problems, and produces verification footage. - An agent that classifies thousands of daily Toss Place product records, sends reviewers links, and supports approval or rejection through an admin interface. - These projects demonstrated how AI can become a reusable agentic workflow rather than a one-time assistant. ## Culture Over Programs - Toss does not claim to have a fixed answer for managing AI’s rapid evolution. - The lasting value of AI Surf Day is the protected time for learning and experimentation, along with a culture where employees openly share results and failures. - Successful examples spread naturally across teams, while evangelist-led workshops translate experimentation into concrete changes in how work is performed. Organizations pursuing AI transformation can take a similar approach: create dedicated experimentation time, encourage peer-led learning, recognize existing champions, and focus on reusable workflow improvements rather than tool adoption alone.

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

Automating Service Vulnerability Analysis using LLM #2

The post explains how Toss Security Research improved AI-driven vulnerability analysis in a research network. Its main challenges were efficiently providing large codebases to an AI and making analysis results consistent and complete. The solution combined a custom code-browsing MCP server with SAST tools used not to identify vulnerabilities directly, but to enumerate all input-to-function paths that the AI must review. ## Efficiently Providing Large Codebases - Tools such as Cursor and Claude Code can search large projects, but primarily rely on pattern matching with tools like ripgrep. - Without prebuilt indexes, they may miss relevant code or waste tokens exploring unnecessary files. - The team built an MCP server that: - Uses **ctags** to index symbol definitions. - Uses **tree-sitter** to parse function boundaries. - Allows AI to access code remotely, similar to IDE features such as “Go to Definition” and “Find References.” ### SourceCode Browse MCP The MCP server provides four main tools: - **`find_references()`** - Searches for symbols or patterns using ripgrep. - Returns file paths, line numbers, snippets, total matches, and whether results were truncated. - **`read_definition()`** - Looks up definitions through the ctags index. - Returns metadata such as file, line, symbol type, language, signature, and scope. - Uses tree-sitter to include the complete function body when requested. - **`read_source()`** - Reads a configurable number of lines before and after a target line. - Lets the AI retrieve only the relevant local context instead of entire files. - **`get_project_structure()`** - Returns the indexed project’s directory structure. - Provides the AI with a project “blueprint,” which is especially important in remote environments where it cannot inspect the repository locally. The MCP workflow is to locate relevant symbols with `find_references()` and `read_definition()`, inspect nearby code with `read_source()`, and use `get_project_structure()` to understand the overall project. ## Improving Consistency and Accuracy - AI analysis produced inconsistent results: for example, it might find all 10 XSS vulnerabilities in one run but only 8 in another. - This variability made the results difficult to trust. - The team combined AI analysis with SAST tooling to ensure complete coverage. ## Using SAST to Enumerate Review Candidates - Rather than passing SAST-detected vulnerabilities directly to the AI, the team used SAST as a candidate-generation tool. - This avoids limiting the AI to vulnerabilities that the SAST engine itself knows how to detect. - SAST extracts every location where untrusted input enters the application and tracks its possible flow to function calls. - Custom Semgrep taint rules identify sources such as: - Spring `@RequestParam` - `@PathVariable` - `@RequestHeader` - Fields read from `@RequestBody` DTOs - `@RequestPart` - `@ModelAttribute` - `@RequestAttribute` - Potential sinks include generic function calls and object method calls. - The AI then reviews every extracted source-to-sink path, combining the completeness of static analysis with the broader reasoning ability of an LLM. The overall approach is to use deterministic indexing and SAST for coverage, while relying on AI for deeper vulnerability interpretation.

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

Embracing the Software 3.0 Era

Software 3.0 replaces hand-written rules with natural-language instructions to LLMs, but models alone cannot reliably perform real-world work. The missing piece is the harness: tools, context, and environments that connect an LLM to codebases, commands, databases, and users. Claude Code illustrates how familiar Software 1.0 architecture can guide agent design while adding a new capability—asking humans for judgment when uncertainty arises. ## From Software 1.0 to Software 3.0 - **Software 1.0:** Developers explicitly write logic using languages such as Python, Java, or C++. - **Software 2.0:** Data and training produce neural-network weights that function as the program. - **Software 3.0:** Prompts and natural-language instructions direct LLM behavior. - Karpathy’s central claim is that Software 3.0 is increasingly absorbing both traditional code and trained models. ## Harnesses Make LLMs Useful - A raw LLM cannot independently read a codebase, execute commands, modify files, or access databases. - A **harness** supplies the tools and environment needed to turn model capability into practical work. - Claude Code is presented as a harness for Claude: it transforms a language model into an agent capable of completing and shipping tasks. ## Mapping Agent Concepts to Layered Architecture The terminology of agent systems can be understood through familiar Software 1.0 design patterns: - **Slash commands → Controllers** - They serve as entry points for user requests, such as `/review` or `/refactor`. - **Sub-agents → Service layer** - They coordinate multiple skills to complete a workflow. - Each sub-agent has an independent context and acts as a self-contained unit of work. - **Skills → Domain components** - Each skill should have one focused responsibility, such as reviewing code, generating tests, or writing documentation. - **MCP → Infrastructure or adapters** - MCP provides abstraction boundaries for external systems such as APIs and databases. - **CLAUDE.md → Project constitution** - It records stable project information: technology choices, conventions, and build commands. - Frequently changing task details should be provided through the conversation or injected into an agent’s context instead. ## Agent Design Has Familiar Anti-Patterns Traditional code smells also apply to agent systems: - **Feature Envy:** A skill relies excessively on another skill’s data. - **Duplication:** Prompts are copied across multiple skills. - **Long Method:** A single sub-agent performs an overly long sequence of many skills. - Clear boundaries, single responsibility, and limited coupling remain valuable. ## The Difference: Agents Can Ask Humans Layered architecture generally requires every failure and edge case to be handled through predefined exceptions, policies, or branches. - Traditional code must decide what to do when an unusual case occurs. - An agent using human-in-the-loop interaction can pause and ask the user for clarification. - In this model, exceptions become questions, allowing the agent to continue after receiving a decision. Agents should ask when: - An action is difficult to reverse, such as deletion or deployment. - Several valid options exist without a clear best choice. - The decision has significant consequences. They should proceed automatically when: - The operation is safely repeatable. - Existing conventions provide a clear answer. - The action is easy to undo. ## What Carries Forward into Software 3.0 The new paradigm does not make established engineering practices irrelevant. - Move away from explicitly coding every possible rule and edge case. - Do not reduce LLMs to simple autocomplete tools. - Preserve layered design, single responsibility, abstraction, dependency management, and interface design. - Continue emphasizing testability, debugging, code review, and iterative improvement. The practical approach is to combine Software 3.0’s flexible reasoning with Software 1.0’s architecture and engineering discipline, while giving agents a clear way to involve humans when decisions require judgment.

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

The Software 3.0

The post argues that teams using the same LLM can achieve very different results because individual knowledge of context engineering varies widely. Claude Code’s plugins and marketplace could help turn personal LLM techniques into shared, executable team workflows, raising the organization’s productivity floor. The author presents this as a forward-looking hypothesis rather than a proven success story. ## The Frictionless Harness - LLM adoption loses effectiveness when developers must switch between terminals, browsers, and chat tools. - Claude Code’s terminal-based TUI reduces context switching by combining natural-language instructions and code in the developer’s existing environment. - This low-friction experience makes it easier to distribute standardized workflows across a team. ## Executable Single Source of Truth - Wikis and Notion pages become outdated because they are designed primarily for human reading. - Claude Code plugins can serve as “executable SSOT”: - Humans can read them as guidelines and manuals. - LLMs can interpret them as precise system instructions. - Updating a plugin can immediately change how team agents behave, keeping operational knowledge aligned with current practices. ## Raising the Team’s Productivity Floor - Teams have significant differences in LLM literacy, independent of coding ability. - Generic open-source plugins can provide shared best practices, but they lack company- and domain-specific context. - Each domain needs its own rules for: - Tasks the AI can perform autonomously. - Tasks requiring human approval through HITL processes. - The goal is to minimize human intervention while preserving approval at critical points. ## Extending Platform Engineering into Software 3.0 - AI workflows resemble traditional internal platform components such as authentication, logging, and payment libraries. - The analogy is: - Common software modules → AI workflow plugins - Library distribution → Marketplace publishing - The implementation changes from traditional code to prompts and agent logic. - AI workflows should receive the same quality practices as software modules, including review, optimization, and feedback on token usage and failure cases. - Marketplace-based collaboration could turn individual prompting techniques into shared organizational intelligence. ## Why Use a Marketplace Instead of Only RAG? - RAG systems can make it difficult to predict which context will be retrieved due to search, reranking, and indexing behavior. - Plugins provide more explicit and controllable instructions and code. - Developers can modify and test workflows locally in the TUI without deploying a server. - With the Claude Agent SDK, workflows validated locally could also run in server environments, improving development-production parity. - The marketplace could become the shared source of truth between experimentation and production. ## Marketplace as a Workflow Distribution Platform - Teams could package coding conventions, Git strategies, lint rules, and testing policies into private plugins or registries. - Hooks could actively correct behavior rather than merely reject violations—for example, preventing commits on `main` and creating a `feature/` branch instead. - Slash commands could distribute the best engineer’s workflow to everyone: - `/new-feature` gathers requirements. - Creates a Jira issue and branch. - Produces an implementation plan for approval. - Implements the feature and opens a pull request. - This allows less experienced users to follow a reliable, high-quality process without reproducing it manually. ## Layered Context Architecture The author proposes separating plugin knowledge into three layers: - **Global layer:** Organization-wide security rules and coding standards. - **Domain layer:** Business-specific knowledge for areas such as payments, settlement, or membership. - **Local layer:** Repository-specific implementation details and conventions. This structure avoids overwhelming the LLM with irrelevant information and creates a “living knowledge base” made of maintainable prompts and code rather than static documents. ## The Data Flywheel Hypothesis - Standardized plugins could generate high-quality instruction-tuning data. - Accumulated workflow data might eventually support domain-specific model fine-tuning. - Existing workflows could also provide evaluation criteria for those models. - Success would require sustained data collection, quality controls, and long-term organizational investment. - The proposed flywheel is: more usage creates more data, better data improves models, and better models encourage further usage. The practical recommendation is to treat LLM expertise as an organizational system rather than an individual skill. Teams should begin packaging their implicit knowledge, approval rules, and proven workflows into versioned, domain-aware plugins that can be tested, reviewed, and distributed through a marketplace or private registry.

Read original(opens in new tab)
tossOriginal article

Welcoming the Era of (opens in new tab)

The tech industry is shifting from Software 1.0 (explicit logic) and 2.0 (neural networks) into Software 3.0, where natural language prompts and autonomous agents act as the primary programming interface. While Large Language Models (LLMs) are the engines of this era, they require a "Harness"—a structured environment of tools and protocols—to perform real-world tasks effectively. This evolution does not render traditional engineering obsolete; instead, it demonstrates that robust architectural principles like layered design and separation of powers are essential for building reliable AI agents. ### The Evolution of Software 3.0 * Software 1.0 is defined by explicit "How" logic written in languages like Python or Java, while Software 2.0 focuses on weights and data in neural networks. * Software 3.0, popularized by Andrej Karpathy, moves to "What" logic, where natural language prompts drive the execution. * The "Harness" concept is critical: just as a horse needs a harness to be useful to a human, an LLM needs tools (CLI, API access, file systems) to move from a chatbot to a functional agent like Claude Code. ### Mapping Agent Architecture to Traditional Layers * **Slash Commands as Controllers:** Tools like `/review` or `/refactor` act as entry points for user requests, similar to REST controllers in Spring or Express. * **Sub-agents as the Service Layer:** Sub-agents coordinate multiple skills and maintain independent context, mirroring how services orchestrate domain objects and repositories. * **Skills as Domain Components:** Following the Single Responsibility Principle (SRP), individual skills should handle one clear task (e.g., "generating tests") to prevent logic bloat. * **MCP as Infrastructure/Adapters:** The Model Context Protocol (MCP) functions like the Repository or Adapter pattern, abstracting external systems like databases and APIs from the core logic. * **CLAUDE.md as Configuration:** Project-specific rules and tech stacks are stored in metadata files, acting as the `package.json` or `pom.xml` of the agent environment. ### From Exceptions to Questions * Traditional 1.0 software must have every branch of logic predefined; if an unknown state is reached, the system throws an exception or fails. * Software 3.0 introduces Human-in-the-Loop (HITL), where "Exceptions" become "Questions," allowing the agent to ask for clarification on high-risk or ambiguous tasks. * Effective agent design requires identifying when to act autonomously (reversible, low-risk tasks) versus when to delegate decisions to a human (deployments, deletions, or high-cost API calls). ### Managing Constraints: Tokens and Complexity * In Software 3.0, tokens represent the "memory" (RAM) of the system; large codebases can lead to "token explosion," causing context overflow or high costs. * Deterministic logic should be moved to external scripts rather than being interpreted by the LLM every time to save tokens and ensure consistency. * To avoid "Skill Explosion" (similar to Class Explosion), developers should use "Progressive Disclosure," providing the agent with a high-level entry point and only loading detailed task knowledge when specifically required. Traditional software engineering expertise—specifically in cohesion, coupling, and abstraction—is the most valuable asset when transitioning to Software 3.0. By treating prompt engineering and agent orchestration with the same architectural rigor as 1.0 code, developers can build agents that are scalable, maintainable, and truly useful.

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.

tossOriginal article

Automating Service Vulnerability Analysis (opens in new tab)

Toss has developed a high-precision automated vulnerability analysis system by integrating Large Language Models (LLMs) with traditional security testing tools. By evolving their architecture from a simple prompt-based approach to a multi-agent system utilizing open-source models and static analysis, the team achieved over 95% accuracy in threat detection. This project demonstrates that moving beyond a technical proof-of-concept requires solving real-world constraints such as context window limits, output consistency, and long-term financial sustainability. ### Navigating Large Codebases with MCP * Initial attempts to use RAG (Retrieval Augmented Generation) and repository compression tools failed because the LLM could not maintain complex code relationships within token limits. * The team implemented a "SourceCode Browse MCP" (Model Context Protocol) which allows the LLM agent to dynamically query the codebase. * By indexing the code, the agent can perform specific tool calls to find function definitions or variable usages only when necessary, effectively bypassing context window restrictions. ### Ensuring Consistency via SAST Integration * Testing revealed that standalone LLMs produced inconsistent results, often missing known vulnerabilities or generating hallucinations across different runs. * To solve this, the team integrated Semgrep, a Static Application Security Testing (SAST) tool, to identify all potential "Source-to-Sink" paths. * Semgrep was chosen over CodeQL due to its lighter resource footprint and faster execution, acting as a structured roadmap that ensures the LLM analyzes every suspicious input path without omission. ### Optimizing Costs with Multi-Agent Architectures * Analyzing every possible code path identified by SAST tools was prohibitively expensive due to high token consumption. * The workflow was divided among three specialized agents: a Discovery Agent to filter out irrelevant paths, an Analysis Agent to perform deep logic checks, and a Verification Agent to confirm findings. * This "sieve" strategy ensured that the most resource-intensive analysis was only performed on high-probability vulnerabilities, significantly reducing operational costs. ### Transitioning to Open Models for Sustainability * Scaling the system to hundreds of services and daily PRs made proprietary cloud models financially unviable. * After benchmarking models like Llama 3.1 and GPT-OSS, the team selected **Qwen3:30B** for its 100% coverage rate and high true-positive accuracy in vulnerability detection. * To bridge the performance gap between open-source and proprietary models, the team utilized advanced prompt engineering, one-shot learning, and enforced structured JSON outputs to improve reliability. To build a production-ready AI security tool, teams should focus on the synergy between specialized open-source models and traditional static analysis tools. This hybrid approach provides a cost-effective and sustainable way to achieve enterprise-grade accuracy while maintaining full control over the analysis infrastructure.