Coding Agents | Techlist.io

figmaAug 5, 20263 min readCurated summary

Better Code, Fewer Tokens: The Benefits of Code Connect in MCP | Figma Blog

Code Connect improves how coding agents translate Figma designs into production code by supplying real design-system components, imports, and prop values. Figma’s evaluations found that Code Connect reduced median task duration by 19.6%, lowered token usage by 29.5%, and increased code quality by one point on a 1–4 scale. The central conclusion is that better design-to-code context helps agents work faster while producing code that fits existing codebases. ## The Problem: Visually Correct but Technically Wrong Code - Without production context, agents often: - Rebuild interfaces from basic primitives. - Invent components that already exist. - Choose the wrong design-system component. - Spend extra tokens searching, debugging, and rewriting. - Figma’s MCP server normally provides a React representation of the design through `get_design_context`. - This output may match the visual design but does not explain how the design maps to a company’s actual component library. ## How Code Connect Enriches MCP Responses - Code Connect links Figma components to their real implementations in a codebase. - With Code Connect templates configured, MCP responses replace generic React markup with production-relevant snippets. - Agents receive: - Correct component imports. - Accurate component names. - Appropriate property values. - Code that reflects the company’s design system. - For example, generic markup for a tab control can be replaced with an existing component such as: ```tsx <SegmentedControl value="design" options={["Design", "Code"]} /> ``` ## Coinbase Case Study - Coinbase’s Design Systems team adopted Code Connect as engineers increasingly used coding agents. - Without Code Connect, agents sometimes fabricated alternatives, such as constructing a stepper from progress bars. - With Code Connect, agents received literal imports and accurate code representations for Coinbase Design System components. - Coinbase reported improved output quality and reduced token usage. ## Evaluation Results - Figma created an evaluation harness that ran identical design-to-code tasks: - Once without Code Connect. - Once with Code Connect templates. - The evaluation covered 27 test cases. - It measured: - Code quality. - Token consumption. - Task duration. - The tests used two React-based design systems: - Simple Design System (SDS), Figma’s example system. - Figma Pattern Library (FPL), a larger internal system. - Across the tests, Code Connect produced: - **19.6% lower median task duration** - **29.5% lower median token usage** - **A one-point increase in code quality on a 1–4 Likert scale** Teams using coding agents for design-to-code work should connect their Figma components to production implementations through Code Connect. Providing exact component context reduces guesswork and tokens while helping agents produce maintainable, design-system-compliant code.

Read original

Coding Agents Design Systems React TypeScript+2

githubAug 4, 20263 min readCurated summary

Turn one giant AI-generated pull request to a reviewable stack

Coding agents can rapidly produce complete features, but they often deliver them as enormous, shallow pull requests that are difficult to review and slow to merge. GitHub’s stacked pull requests address this by decomposing a feature into small, dependency-ordered layers. The result is a reviewable chain of changes that preserves context while reducing maintenance and merge conflicts. ## The Problem with Giant AI-Generated Pull Requests - A seemingly simple product-search feature may include: - A data model and seed data - An API route and validation - Client integration and UI states - Coding agents commonly generate all of this in a single 1,000-plus-line pull request. - Large pull requests: - Become difficult to review thoroughly - Cause reviewers to lose context - Receive lower-quality feedback - Take longer to merge - Are more likely to land under-reviewed Traditional alternatives are also imperfect: one large pull request harms reviewability, while a manually maintained chain of smaller pull requests creates synchronization work and conflict-management overhead. ## Stacked Pull Requests - Stacked pull requests break a feature into logical, dependent layers. - Each pull request focuses on one concern and remains small enough for reviewers to understand. - Later layers build naturally on earlier, already-reviewed work. - Different layers can be assigned to specialized reviewers, such as data or UI owners. For the product-search example, the proposed stack is: - **L1 – `feat/catalog-data`**: Typed catalog, seed data, validation, and data access; based on `main` - **L2 – `feat/search-api`**: Validated `/api/products/search` endpoint; based on L1 - **L3 – `feat/chat-grounding`**: Connects chat to the API and real product data; based on L2 - **L4 – `feat/grounded-ui`**: Adds product citation cards and UI states; based on L3 ## Setting Up the Stack - Choose the stack base first, because CI checks and merge rules are evaluated against it. - Place foundational work closest to the base and dependent work above it. - Install GitHub’s CLI extension: ```bash gh extension install github/gh-stack ``` - Teach coding agents how to create and manage stacks: ```bash gh skill install github/gh-stack ``` Alternatively: ```bash npx skills add github/gh-stack ``` - Ensure CI is configured, since every pull request layer is checked against the stack base. ## Assigning Agents to Layers The example uses separate agents with strict scope boundaries: - **L1:** Data modeler agent - **L2:** Backend agent - **L3:** Frontend agent - **L4:** Frontend agent This division encourages each agent to produce a focused pull request rather than reconstructing the entire feature in one pass. ## Recommended Workflow The development process starts with the foundational catalog layer and proceeds upward through the dependency chain. Agents work autonomously within their assigned scope, while each completed layer can be reviewed independently before subsequent layers are evaluated. Stacked pull requests are a practical way to preserve the productivity benefits of coding agents without sacrificing review quality. Teams should define clear layer boundaries, establish the stack base, assign appropriate reviewers or agents, and run CI for every layer.

Read original

Coding Agents CI/CD Github API Design+2

lineJun 25, 20264 min readCurated summary

In the AI Era, Development Ability Is Determined by Verification Skills: Strategies for Rapid Validation and Local Environment Setup Learned While Developing the Flava API Gateway

AI coding agents iterate quickly, but their output can be inconsistent, make incorrect design decisions, or generate code that does not compile. Because CI runs, environment provisioning, and human review are slower, the article argues that reliable agent-assisted development requires three practices: spec-driven development, automated verification, and fast, self-contained local environments. ## Flava API Gateway and the Development Challenge - Flava API Gateway is part of LY Corporation’s private Flava cloud. - It provides a multi-tenant RESTful control-plane API for creating, deploying, and monitoring web APIs. - Kong serves as the data plane. - The team adopted agent-based coding while building the product and focused on preserving software reliability without sacrificing AI-driven speed. ## Spec-Driven Development The team found that agents became more unpredictable when implementation began before the design was settled. They use explicit specifications to reduce ambiguity and constrain implementation decisions. - OpenAPI is written before code to define the control-plane API. - Features are divided into smaller units and implemented with OpenSpec. - Specifications serve both as implementation guidance and as a standard for detecting deviations. ### Managing OpenAPI with Nickel - Raw OpenAPI YAML is repetitive and difficult to maintain manually. - Nickel is used to describe API resources declaratively and generate complete CRUD specifications. - A resource definition can specify: - Description and parent resource - Whether updates are allowed - Automatic timestamps - Property schemas - Required fields - Sorting and filtering behavior - The generator produces consistent endpoints such as `listPaths`, `createPath`, `getPath`, and `deletePath`. - Generated endpoints include pagination, sorting, filtering, ETags for optimistic locking, and standardized error responses. ### OpenSpec Workflow OpenSpec structures each change into four artifacts: - **Proposal:** Why the change is needed and what will change - **Design:** Technical decisions and trade-offs - **Delta specifications:** Behavioral requirements written as Given-When-Then scenarios - **Task list:** A step-by-step implementation checklist The developer and agent review the feature together, the agent creates these artifacts, and then implements the checklist incrementally. Once complete, the delta specification is archived into the main specification library, creating a versioned, evolving record of the system’s behavior. ## Automated Verification The team initially tried adding lists of pitfalls to prompts, but found this ineffective and potentially harmful. Instead, they made tests and tools reveal errors progressively so the agent could diagnose and correct them. - Automated tests, linters, and formatters provide precise feedback. - Failed tests identify what went wrong, allowing the agent to fix one issue before moving to the next. - Project-specific skills bundle these checks together. - `AGENTS.md` tells the agent when to load the relevant skills, avoiding unnecessary instructions on every turn. - Testing and linting are treated as essential infrastructure rather than optional activities, since agents frequently make errors during implementation. ## Fast, Independent Local Environments Relying on CI and shared test environments is too slow for agent-driven iteration. Long waits can disrupt the agent’s context and make repeated experimentation impractical. - A complete local environment provides immediate feedback. - Local dependencies make logs and state easier to inspect. - Developers avoid sending every failed attempt through a remote pipeline. - The local test suite contains 2,754 tests across three layers: - **Unit tests:** Isolated business logic - **Integration tests:** Real PostgreSQL, database constraints, triggers, soft-delete cascades, transactions, in-process HTTP, and OpenAPI compliance - **End-to-end tests:** Athenz authentication, Kong, API keys, and multi-tenant isolation - The full suite completes in roughly 15 seconds on a developer machine. - Parallel execution and strong test isolation are critical to achieving this speed. ## Practical Recommendation Agent-assisted development works best when agents are given clear behavioral contracts, immediate automated feedback, and a fast local loop. Teams should invest in specifications, comprehensive tests and linting, and realistic local dependencies so agents can correct mistakes continuously without waiting for CI.

Read original

Coding Agents PostgreSQL Automated Testing Openapi+4

tossJun 8, 20264 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

Coding Agents Large Language Models Python Yaml+3

dropboxMay 21, 20263 min readCurated summary

Introducing Nova, our internal platform for coding agents

Nova is Dropbox’s internal cloud platform for running coding agents across the software development lifecycle. Rather than building separate tools for coding, CI debugging, migrations, and operational tasks, Dropbox created a shared platform that supports interactive sessions and autonomous workflows within its monorepo and infrastructure. The platform grounds agent changes in real builds and tests, making AI assistance more reliable and easier to integrate into engineering workflows. ## The Case for a Shared Platform - Engineering work includes repetitive but important tasks such as: - Debugging CI failures - Updating dependencies - Improving test coverage - Fixing flaky tests - Managing migrations and operational work - Different tasks require different interaction models: - Interactive chat for developer-driven work - Asynchronous workflows for long-running remediation and automation - Dropbox’s environment has specialized requirements: - A large monorepo - Bazel for builds and tests - Caching and remote execution - On-premises infrastructure - Dropbox-specific validation workflows - Off-the-shelf coding agents were designed primarily for local development and did not naturally fit this environment. ## How Nova Runs Coding Sessions - Each session runs in an isolated environment using a specific snapshot of the codebase. - Callers provide: - The repository commit - A task description - Optional validation commands - Iteration limits and branch settings - Nova can run builds and tests after an agent proposes a change. - If validation fails, the results are sent back to the agent so it can continue troubleshooting. - This creates a feedback loop of: - Propose a change - Validate it in the real environment - Correct failures - Repeat as needed - Nova supports multiple coding agents behind a common interface. - Engineers can access it through: - A web interface - A command-line client - An API - Internal scripts and services - The platform also provides prompt evaluation, observability, feedback collection, skills, plugins, and MCP integrations for accessing systems such as logs and monitoring tools. ## Deterministic Code Publication - Nova keeps code publication outside the agent. - Each session is limited to a single branch. - This makes active work and publication status predictable. - It avoids the complexity of agents creating and managing multiple branches. - The deterministic model simplifies automation such as: - Running tests - Rebasing onto the main branch - Tracking which changes belong to each session ## Engineering Workflows Using Nova ### Developer-Driven Sessions - Engineers use Nova’s web interface for quick fixes and prototypes without disrupting local work. - Validation commands can use Bazel selectivity tools to target the relevant compile and test dependencies. - Slack discussions can be carried into Nova sessions, preserving context and reducing manual setup. ### Flaky Test Remediation - Dropbox built Deflaker, a durable workflow connected to Athena, its flaky-test detection system. - Deflaker gathers examples of a test passing and failing. - It sends the associated logs to Nova. - The agent analyzes the evidence, identifies a likely cause, and proposes a fix. - This demonstrates how Nova can combine investigation, context gathering, and code changes in a longer-running automated process. ## Practical Takeaway Dropbox’s experience suggests that coding agents are most useful when embedded in existing engineering systems rather than treated as isolated code-generation tools. A shared platform like Nova can support many workflows while preserving consistent execution, validation, context, and observability.

Read original

Coding Agents Observability CI/CD Model Context Protocol+4

googleSep 29, 2025Original article

AI as a research partner: Advancing theoretical computer science with AlphaEvolve (opens in new tab)

AlphaEvolve, an LLM-powered coding agent developed by Google DeepMind, facilitates mathematical discovery by evolving code to find complex combinatorial structures that are difficult to design manually. By utilizing a "lifting" technique, the system discovers finite structures that can be plugged into existing proof frameworks to establish new universal theorems in complexity theory. This methodology has successfully produced state-of-the-art results for the MAX-4-CUT problem and tightened bounds on the hardness of certifying properties in random graphs. ## The Role of AlphaEvolve in Mathematical Research * The system uses an iterative feedback loop to morph code snippets, evaluating the resulting mathematical structures and refining the code toward more optimal solutions. * AlphaEvolve operates as a tool-based assistant that generates specific proof elements, which can then be automatically verified by computer programs to ensure absolute mathematical correctness. * By focusing on verifiable finite structures, the agent overcomes the common "hallucination" issues of LLMs, as the final output is a computationally certified object rather than a speculative text-based proof. ## Bridging Finite Discovery and Universal Statements through Lifting * Theoretical computer science often requires proofs that hold true for all problem sizes ($\forall n$), a scale that AI systems typically struggle to address directly. * The "lifting" technique treats a proof as a modular structure where a specific finite component—such as a combinatorial gadget—can be replaced with a more efficient version while keeping the rest of the proof intact. * When AlphaEvolve finds a superior finite structure, the improvement is "lifted" through the existing mathematical framework to yield a stronger universal theorem without requiring a human to redesign the entire logical architecture. ## Optimizing Gadget Reductions and MAX-k-CUT * Researchers applied the agent to "gadget reductions," which are recipes used to map known intractable problems to new ones to prove computational hardness (NP-hardness). * AlphaEvolve discovered complex gadgets that were previously unknown because they were too intricate for researchers to construct by hand. * These discoveries led to a new state-of-the-art inapproximability result for the MAX-4-CUT problem, defining more precise limits on how accurately the problem can be solved by any efficient algorithm. ## Advancing Average-Case Hardness in Random Graphs * The agent was tasked with uncovering structures related to the average-case hardness of certifying properties within random graphs. * By evolving better combinatorial structures for these specific instances, the team was able to tighten existing mathematical bounds, providing a clearer picture of when certain graph properties become computationally intractable to verify. This research demonstrates that LLM-based agents can serve as genuine research partners by focusing on the discovery of verifiable, finite components within broader theoretical frameworks. For researchers in mathematics and computer science, this "lifting" approach provides a practical roadmap for using AI to solve bottleneck problems that were previously restricted by the limits of manual construction.

Coding Agents AI Large Language Models Gemini+5