Claude Code | Techlist.io

lineApr 10, 20264 min readCurated summary

Clearing Review Bottlenecks with AI - Transforming Review Culture with PR Review Support and Internal Workshops

Orchestration Guild member Fukuyama describes how Yahoo! Places addressed PR review bottlenecks by combining AI assistance with standardized processes and team culture. Reviews had become concentrated among a few engineers, creating delays and forcing a trade-off between speed and quality. The team introduced Claude Code–based screening reviews, then expanded the approach into a broader system for improving PR creation, review accuracy, and continuous improvement. ## PR Review Bottlenecks - In late 2024, review responsibilities were concentrated on the tech lead and one other engineer. - Reviewers were simultaneously implementing features and reviewing code, causing PR queues to grow. - The main problems were: - Authors could not move to their next tasks while waiting for reviews. - Review work consumed most of the day. - Large PRs had to be reviewed quickly, increasing the risk of missed bugs. - This created a single point of failure and exposed the trade-off between thoroughness and development speed. - The launch of a dedicated frontend team in early 2025 provided an opportunity to redesign the review process. ## Introducing AI Screening Reviews - The team first tried having AI summarize PR changes before review. - Although summaries made changes easier to understand, AI did not sufficiently reduce the work of tracing dependencies or identifying hidden problems. - Manually pasting prompts for every review also made the approach inconvenient, so it was abandoned after about two weeks. - The introduction of Claude Code in summer 2025 changed the situation because reusable custom commands eliminated repetitive prompt preparation. - AI screening reviews now perform an initial inspection before a human reviewer makes the final judgment. - This changes the process from “humans inspect everything” to a two-stage model: - AI analyzes the PR, its impact, coding conventions, and possible risks. - A human reviewer validates the analysis and makes the final decision. ## Claude Code Custom Review Commands The custom command requests that Claude Code: - Summarize the PR and its affected areas. - Explain the before-and-after changes for each file. - Check coding and naming conventions. - Investigate dependent files and broader codebase impact. - Identify potential bugs, security issues, performance problems, code smells, and unintended side effects. - Suggest concise, respectful review comments for the author. - Classify comments with labels such as `[must]`, `[want]`, `[imo]`, `[ask]`, `[nits]`, and `[info]`. - Determine whether additional tests are needed based on existing project practices. The command uses GitHub CLI operations such as: - `gh pr view --json title,body,files,url` - `gh pr diff` - `gh pr view --comments` - GitHub API calls for line-level comments - `gh pr checkout` when the relevant branch is not currently checked out The review procedure is deliberately structured: 1. Confirm the review requirements. 2. Understand the PR’s overall purpose and background. 3. Review each changed file in detail. 4. Investigate dependencies across the codebase. 5. Produce a final assessment and suggested comments. The same screening process can help both reviewers and PR authors. Reviewers use it to reduce preparation time and understand impact, while authors can run it before requesting review to fix likely issues in advance. ## Expanding Beyond AI Screening After seeing benefits from screening reviews, the team created a broader improvement framework spanning technology and team culture. It was organized around four connected goals: - Improving efficiency. - Establishing a foundation for review accuracy. - Building review-oriented team culture. - Creating a mechanism for continuous improvement. The approach treats review optimization as an ongoing cycle rather than a one-time tool deployment. ## Automating PR Creation The team also uses AI to reduce the effort required to create PRs. - Git operations such as branch creation, commits, and PR creation are automated. - AI analyzes the commit diff to generate: - A PR title. - A summary of the changes. - Background and motivation. - Other required PR template fields. - Standardized and more complete PR descriptions provide better context for both human reviewers and AI screening. - Improving PR quality at the creation stage also increases the accuracy and consistency of later reviews. ## Practical Recommendation AI should support—not replace—reviewer judgment. Teams should begin by standardizing the review workflow, encode that workflow in reusable AI commands, and measure whether review time, PR waiting time, and review quality improve. Combining AI screening with better PR context, dependency analysis, clear comment conventions, and continuous process refinement offers a more sustainable solution than relying on individual reviewers.

Read original

Claude Code AI Database Design Web Development+4

figmaMar 24, 20263 min readCurated summary

Agents, Meet the Figma Canvas | Figma Blog

Figma is opening its canvas to AI agents, allowing tools such as Claude Code and Codex to create and modify designs directly in Figma files. Through the `use_figma` tool and customizable skills, agents can use a team’s components, variables, design decisions, and workflows instead of producing generic designs. The feature is free during beta but is expected to become usage-based and paid. ## Agents Work Directly on the Figma Canvas - Figma’s MCP integration lets agents read and write Figma files through the `use_figma` tool. - Agents can create or update: - Design assets - Components - Files based on existing design systems - Designs linked to established variables and conventions - Teams can move between code, the command line, and Figma while keeping design context shared. - Figma positions the canvas as the place where product decisions become visible and refined. ## Working Across Code and Canvas - The existing `generate_figma_design` tool converts HTML from live apps and websites into editable Figma layers. - The new `use_figma` tool operates directly on the canvas, using existing components and variables. - The tools are intended to work together: - `generate_figma_design` brings current implementation details into Figma. - `use_figma` edits those designs or creates new system-aligned assets. ## Skills Encode Design Intent - Skills are Markdown-based instructions that tell agents: - Which workflow steps to follow - What sequence to use - Which team conventions to respect - What quality standards and specialized knowledge to apply - Anyone can author a skill without building a plugin or writing traditional code. - The foundational `/figma-use` skill teaches agents Figma’s structure and core principles. - Teams can customize that foundation to reflect their own design systems and working methods. ## Example Skills and Workflows Figma highlights skills for tasks such as: - Generating component libraries from code - Creating designs from existing components and variables - Producing accessibility specifications for VoiceOver, TalkBack, and ARIA - Creating components from structured JSON contracts - Applying design systems to existing designs - Managing spacing through variables and fallbacks - Synchronizing design tokens between code and Figma - Running parallel, multi-agent design workflows ## More Predictable and Self-Correcting Output - Skills make AI behavior more consistent by encoding repeatable instructions and implementation rules. - Agents can use screenshots to identify mismatches and iteratively refine generated screens. - Because agents work with real Figma structure—components, variables, and auto layout—corrections affect the underlying design system rather than only the visual appearance. - Team conventions become active rules that agents apply during creation, rather than static documentation they merely reference. Figma’s agent workflow is most useful when teams invest in well-defined components, variables, and skills. During the beta, teams can experiment with `use_figma` and community skills to automate design work while preserving their existing design intent and system standards.

Read original

Claude Code Figma Design Systems AI Agents+4

tossFeb 26, 20264 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

Claude Code Large Language Models AI Agents Model Context Protocol+4

lineFeb 23, 20264 min readCurated summary

Sharing the journey of LINE DEV

AI adoption at LY Corporation has moved beyond experimentation toward learning how to use these tools effectively in real work. The LINE DEV AI Reporters program connects scattered individual and team experiences through internal sharing sessions, helping practical lessons spread across the organization. Its central conclusion is that AI productivity depends not only on tools, but also on clear specifications, sound engineering practices, and a culture of continuous sharing. ## Turning Individual Experiments into Organizational Knowledge - AI enthusiasts across LY Corporation were independently experimenting with tools such as ChatGPT and Claude Code. - These experiences often remained limited to individuals or small teams. - AI Reporters brought together members of different roles and seniority who had experience sharing AI-related work. - Their goal was to turn personal trial and error into reusable organizational knowledge. ## Starting with Informal Personal Experiments - Early AI sharing sessions emphasized accessibility rather than polished success stories. - Multimedia Platform Dev’s Choi Jeong-min shared a “one service a day” vibe-coding experiment using Claude Code and Antigravity. - The experiment demonstrated that rapid implementation increases the importance of clearly defining what to build. - Sharing failures and unfinished experiments reduced the pressure to perform and encouraged more employees to try AI themselves. ## Applying AI to Real Development Work - As interest grew, discussions shifted from fun experiments to practical workplace applications. - Data Dev4’s Lee Yun-seong shared more than a month of project experience using Claude Code, project templates, and Vibe Kanban. - Developers spent more time on planning, design, review, and coordination while agents handled implementation. - Because the current codebase becomes the context for future agent work, poor architecture and coding styles can quickly be reproduced and amplified. - Continuous testing, refactoring, documentation, interface management, and architectural cleanup are therefore essential. - Skipping automated tests before commits led to increasing numbers of broken changes during later merges. - Humans remain responsible for ensuring that AI-generated code actually contributes to the project. - The most valuable skills increasingly involve task design, project management, system context, and meta-programming rather than implementation alone. - Developers can work in parallel with agents by planning the next task, researching requirements, and reviewing completed code while agents execute current work. ## Expanding from Teams to Organization-Wide Programs - Fintech Engineering organized a hands-on workshop covering the full path from idea to deployment. - Participants connected ChatGPT, Claude Code, and Stitch AI to plan, design, build, and complete a working service. - The integrated workflow helped participants understand how AI tools can support an entire product-development process, not just prototyping. - The GAI Study Group in the advertising organization broadened discussions to AI strategy, trends, agent behavior, developer workflows, and business applications. - Topics included: - AI agent reliability - Implementing interactions between PyTorch-based LLMs and MCP servers - Senior and junior developers’ vibe-coding workflows - NotebookLM-based RAG using wiki pages and Slack conversations - One session examined MCP internals by implementing JSON-RPC messaging and session-state management directly, revealing complexities hidden by libraries such as FastMCP. - Sessions were opened to participants and presenters from other teams, with some content published online for wider access. ## Building a Culture of Continuous Sharing - The most useful AI knowledge came from real workplace attempts, failures, and revisions—not only from polished documentation or external trends. - AI Reporters made existing but scattered experiences visible and connected them through presentations, Slack discussions, and monthly meetings. - Informal conversations such as “I tried this—how did it work for you?” helped normalize experimentation and learning from mistakes. - AI adoption is treated as an ongoing practice because tools and workflows continue to change. LY Corporation’s experience suggests that organizations should create lightweight, recurring forums where employees can share practical AI experiments. The combination of rapid experimentation, disciplined engineering, and open knowledge exchange allows individual discoveries to become lasting organizational capability.

Read original

Claude Code AI PostgreSQL Chatgpt+4

spotifyFeb 19, 20263 min readCurated summary

Background Coding Agents: Predictable Results Through Strong Feedback Loops (Honk, Part 3) | Spotify Engineering

Spotify argues that unsupervised coding agents become reliable only when surrounded by strong, automated feedback loops. Its “Honk” system uses component-specific verifiers, mandatory pre-PR checks, and an LLM judge to catch build failures, test failures, scope creep, and functionally incorrect changes. The conclusion is that constrained, sandboxed agents with rich verification are more predictable than flexible agents operating independently. ## Failure Modes at Scale - Agents may fail to produce a pull request, which is inconvenient but usually manageable. - They may produce PRs that fail CI, leaving engineers to repair incomplete work. - Most seriously, they may produce PRs that pass CI but are functionally wrong and potentially reach production. - These failures are more likely when components lack tests, agents modify code beyond the prompt, or agents cannot correctly run builds and tests. - Reviewing invalid or nonsensical PRs can become a significant engineering time sink. ## Verification Loops - Honk uses independent verifiers that provide incremental feedback while the agent works. - Verifiers activate automatically based on the repository contents; for example, a Maven verifier runs when a root-level `pom.xml` is present. - The agent sees an abstract MCP tool rather than the implementation details of Maven, test runners, or build systems. - Verifiers handle formatting, compilation, testing, and output parsing, returning concise error messages instead of consuming the agent’s context with raw logs. - All applicable verifiers run before a PR is opened. In Claude Code, this is enforced with a stop hook. - If verification fails, the PR is blocked and the user receives an error. ## An LLM as a Judge - Deterministic checks cannot detect every problem, especially when an agent makes unnecessary refactors or disables flaky tests. - Honk therefore sends the original prompt and proposed diff to a separate LLM judge. - The judge runs after the regular verifiers and can veto changes that exceed the requested scope. - Across thousands of sessions, the judge rejects roughly one quarter of proposed changes. - Agents successfully correct about half of the vetoed changes. - Spotify has not yet built formal evaluations for the judge, but observed that scope violations are its most common reason for rejection. ## Constrained Agents and Sandboxing - The agent has limited responsibilities: inspect the relevant code, edit files, and invoke verification tools. - Surrounding infrastructure handles prompt creation, pushing code, and user communication through systems such as Slack. - Restricting the agent’s capabilities improves predictability and provides security benefits. - Agents run in heavily sandboxed containers with limited permissions, few installed binaries, and almost no access to surrounding systems. - Spotify reports that agents solve increasingly complex tasks reliably when these feedback loops are present, but often produce unusable code without them. ## Future Expansion - Spotify plans to support more hardware and operating systems. - Current verifiers run only on Linux x86, limiting support for systems that require macOS, such as iOS applications, or ARM64 environments. - The company also intends to integrate Honk more deeply with existing CI/CD pipelines. The practical recommendation is to treat autonomous coding as an infrastructure and verification problem, not merely a prompting problem: keep agents narrowly scoped, isolate them securely, and require layered automated checks before accepting their changes.

Read original

Claude Code Large Language Models AI Agents CI/CD+4

figmaFeb 16, 20262 min readCurated summary

The Future of Design Is Code and Canvas | Figma Blog

The post argues that the future of product creation combines code with visual design canvases rather than treating them as separate, linear stages. Figma’s integration with Claude Code lets developers send rendered browser work into Figma as editable layers, enabling teams to explore alternatives visually and move changes back into code. The broader goal is to help builders avoid tunnel vision and choose better solutions before committing to implementation. ## Code and Canvas as Complementary Tools - Code is powerful for building and expressing ideas, while the canvas is better for comparing and navigating many possibilities. - Figma supports: - Divergent exploration of multiple approaches - Side-by-side comparison of designs - Direct manipulation of visual details - Big-picture evaluation before implementation ## Claude Code to Figma - Users can install the Figma MCP and type “Send this to Figma” in Claude Code. - The browser’s rendered state is translated into fully editable Figma layers. - After refining the design in Figma, Figma MCP can transfer design changes back into the codebase. - This creates a bidirectional workflow between production code and visual design. ## Moving Beyond Linear Workflows - Traditional product development often followed a sequence: brainstorm, design, then code. - AI and connected tools allow work to begin in a terminal, prompt box, visual interface, or sketch and move between formats. - Teams can now reconsider direction during development instead of simply advancing the first workable concept. ## Design as the Main Differentiator - As AI makes it easier to generate almost any articulated possibility, the difficult work becomes identifying the best solution. - Design judgment, craft, and point of view remain essential. - Figma positions the canvas as a space for stepping back, examining alternatives, and escaping the momentum of building the first version. The practical recommendation is to combine code-driven speed with canvas-based exploration: use code to create, Figma to compare and refine, and MCP integrations to keep both workflows connected.

Read original

Claude Code Figma AI Prototyping+2

figmaFeb 16, 20262 min readCurated summary

From Claude Code to Figma: Turning Production Code into Editable Figma Designs | Figma Blog

Claude Code to Figma lets users capture working interfaces from production, staging, or localhost and convert them into editable Figma frames. The workflow combines code’s speed for building functional prototypes with Figma’s strengths in collaboration, comparison, and exploration. Its central argument is that teams can move faster without stopping at the first working implementation. ## From Code to an Editable Canvas - Developers can capture real UI screens from Claude Code workflows. - Captured screens can be pasted into any Figma file as editable frames. - The workflow supports interfaces running in production, staging, or locally. - Multiple screens can be captured in one session, preserving flow sequence and context. ## Start Anywhere, Then Collaborate - Code-first exploration is fast but often isolated: one person manages the branch, server, and context. - Sharing screenshots, recordings, or local builds creates friction when feedback is needed. - Once imported into Figma, screens can be organized, duplicated, refined, annotated, and shared. - Teams can discuss and explore the interface without switching environments or modifying code for every idea. ## Build the Best Idea, Not Just the First One - AI makes it easier to produce an initial prototype quickly, shifting attention toward evaluating alternatives. - Figma Make supports a similar workflow by bringing generated prototypes onto the design canvas. - Claude Code to Figma extends this approach to code-created interfaces. - Both workflows aim to turn an initial tangible result into deeper design exploration. ## Explore Systems and Variations Visually - Side-by-side frames make patterns, inconsistencies, gaps, and trade-offs easier to identify. - Teams can duplicate frames, rearrange steps, and test structural changes without reimplementing code. - Keeping alternatives visible supports continued exploration, including previously rejected ideas. - Designers, engineers, and product managers can make decisions using the same high-fidelity artifact. - Shared context helps surface questions and resolve direction earlier. Claude Code to Figma is intended as a bridge between functional prototyping and collaborative design. Teams can use code to quickly discover what works, then move the result into Figma to compare options, gather feedback, and establish shared direction.

Read original

Claude Code Figma AI Prototyping+2

lineFeb 13, 20263 min readCurated summary

Claude Code Action: Platformizing AI Code

LINE NEXT transformed Claude Code from an individual productivity tool into an organization-wide code review platform integrated with GitHub Actions. The goal was to reduce review-quality variation, standardize policies, and make AI feedback part of the existing pull request workflow. Its central design separates simple repository-level invocation from centrally managed execution, prompts, permissions, and infrastructure. ## Why AI Code Review Needed to Be Platformized - As LINE NEXT’s services and repositories grew, human code review quality varied according to each reviewer’s experience and preferences. - Developers were already using Claude Code locally, but individual usage created several problems: - Inconsistent review criteria and perspectives - No organization-wide quality process - AI feedback disconnected from pull request workflows - Difficulty providing new employees with a consistent review experience - DevOps therefore treated the issue as a decentralized quality-process problem rather than merely a tooling problem. ## Why GitHub Actions and Claude Code - GitHub Actions was already the foundation for CI/CD and automation across LINE NEXT repositories. - It allowed the team to: - Apply a common workflow repository by repository - Centrally manage execution environments and permissions - Avoid requiring each service team to build additional infrastructure - Claude Code Action integrated directly with pull requests: - Developers could trigger reviews with an `@claude` mention. - Results appeared as GitHub comments or PR reviews. - Developers did not need to learn a separate interface. - A shared GitHub App Runner environment provided consistent execution and centralized security controls. ## Centralized Caller–Executor Architecture - Service repositories act as **callers**: - They invoke the standard workflow. - They provide only basic parameters such as service name and review type. - A centrally managed DevOps repository acts as the **executor**: - Stores prompts and review personas - Defines review policies and priorities - Manages permissions and authentication - Contains the actual execution logic - This design makes AI review an organization-wide platform capability rather than a separate configuration maintained by every project. ### Benefits of Central Control - **Consistent quality:** Central prompts and personas ensure common review depth, tone, security checks, stability checks, and priorities. - **Faster adoption:** New repositories need only add the standard workflow and specify a few parameters. - **Improved governance:** GitHub Apps, centrally managed secrets, and shared runners make it possible to track who accessed which code and with what permissions. - **Lower operational overhead:** Service teams use the platform without managing AI infrastructure themselves. ## Handling Fork-Based Pull Requests - The official Claude Code Action initially assumed that a PR branch existed in the base repository’s `origin`. - For pull requests created from forks, this caused failures such as: ```text couldn't find remote ref ``` - The original implementation fetched and checked out the branch by name: ```text git fetch origin <branch> git checkout <branch> ``` - This failed because fork branches exist in the external repository, not necessarily in the base repository. - From a platform perspective, this was a structural limitation because it blocked external contributors and collaboration repositories. - The proposed direction was to redesign the execution flow rather than simply add an exception, using GitHub’s special pull-request reference: ```text refs/pull/<PR number>/head ``` This approach allows the workflow to retrieve the actual pull request head commit regardless of whether the PR originated from the main repository or a fork.

Read original

Claude Code Database Design Kubernetes CI/CD+4

dropboxFeb 11, 20262 min readCurated summary

Insights from our executive roundtable on AI and engineering productivity

Dropbox argues that AI improves engineering productivity only when tied to measurable business outcomes rather than adopted for its own sake. The company has expanded AI use across the software development lifecycle, while recognizing trade-offs involving quality, maintenance, and organizational change. Its executive roundtable concluded that leadership, formal AI competency, and stronger outcome measurement will be central to realizing AI’s potential. ## Dropbox’s AI Adoption Strategy - Dropbox made AI adoption a company-wide priority with leadership sponsorship, enabling teams to experiment more easily and reducing delays in approving new tools. - Engineers use AI across code review, documentation, debugging, testing, and other stages of development. - Because Dropbox operates a large, multilingual monorepo, it combines commercial tools such as Claude Code and Cursor with internally built systems. - One internal tool detects failed pull-request builds and uses Dropbox’s AI platform to suggest fixes. - Most developers now use at least one AI tool. - Dropbox tracks monthly pull-request throughput per engineer and has observed higher output among developers who use AI coding tools more actively. - The company also monitors engineer sentiment, reporting increased positive sentiment and reduced negative sentiment as adoption improves. ## Focus of the Executive Roundtable Leaders from multiple companies discussed engineering productivity and AI in rotating peer groups organized around three themes: - **Measuring impact** - Identifying ways to measure AI-driven productivity gains. - Connecting engineering improvements to broader business results. - **Leadership alignment** - Establishing how executives should communicate AI deployment progress. - Determining the appropriate pace and scope of adoption. - **The human element** - Recruiting, evaluating, and developing AI-capable employees. - Applying lessons from developer productivity to help non-engineering teams work more effectively. ## Lessons About AI and Productivity - **Balance is essential:** Faster development must not come at the expense of software quality or increased long-term maintenance costs. - **Leadership sets standards:** Technical managers play a key role in defining responsible and effective AI usage norms. - **AI skills should be formalized:** Including AI competency in career frameworks demonstrates that it is a lasting strategic capability rather than a temporary trend. - **Extra capacity needs direction:** Dropbox is currently using productivity gains to address technical debt, complete migrations, and improve reliability. ## Priorities for 2026 Dropbox’s main unresolved challenge is linking engineering productivity metrics to tangible business outcomes. Its next phase will focus on mapping AI-driven gains to specific results, extending operational discipline beyond engineering, and improving end-to-end product velocity.

Read original

Claude Code AI Monorepo Software Development Lifecycle+4

tossJan 25, 2026Original 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.

Claude Code Large Language Models AI Agents Model Context Protocol+4

lineDec 30, 2025Original article

A Business Trip to Japan After Only One (opens in new tab)

Joining the Developer Relations (DevRel) team at LINE Plus, a new employee was immediately thrust into a high-stakes business trip to Japan just one week after onboarding to support major global tech events. This immersive experience allowed the recruit to rapidly grasp the company’s engineering culture by facilitating cross-border collaboration and managing large-scale technical conferences. Ultimately, the journey highlights how a proactive onboarding strategy and a culture of creative freedom enable DevRel professionals to bridge the gap between complex engineering feats and community engagement. ### Global Collaboration at Tech Week * The trip centered on participating in **Tech-Verse**, a global conference featuring simultaneous interpretation in Korean, English, and Japanese, where the focus was on maintaining operational detail across diverse technical sessions. * Operational support was provided for **Hack Day**, an in-house hackathon that brought together engineers from various countries to collaborate on rapid prototyping and technical problem-solving. * The experience facilitated direct coordination with DevRel teams from Japan, Thailand, Taiwan, and Vietnam, establishing a unified approach to technical branding and regional community support. * Post-event responsibilities included translating live experiences into digital assets, such as "Shorts" video content and technical blog recaps, to maintain engagement after the physical event concluded. ### Modernizing Internal Technical Sharing * The **Tech Talk** series, a long-standing tradition with over 78 sessions, was used as a platform to experiment with "B-grade" humorous marketing—including quirky posters and cup holders—to drive offline participation in a remote-friendly work environment. * To address engineer feedback, the format shifted from passive lectures to **hands-on practical sessions** focusing on AI implementation. * Specific technical workshops demonstrated how to use tools like **Claude Code** and **ChatGPT** to automate workflows, such as generating weekly reports by integrating **Jira tickets with internal Wikis**. * Preparation for these sessions involved creating detailed environment setup guides and troubleshooting protocols to ensure a seamless experience for participating developers. ### Scaling AI Literacy via AI Campus Day * The **AI Campus Day** was a large-scale event designed for over 3,000 participants, aimed at lowering the barrier to entry for AI adoption across all departments. * The "Event & Operation" role involved creating interactive AI photo zones using **Gemini** to familiarize employees with new internal AI tools in a low-pressure setting. * Event production utilized AI-driven assets, including AI-generated voices and icons, to demonstrate the practical utility of these tools within standard business communication and video guides. * The success of the event relied on "participation design," ensuring that even non-technical staff could engage with AI concepts through hands-on play and peer mentoring. For organizations looking to strengthen their technical culture, this experience suggests that integrating new hires into high-impact global projects immediately can be a powerful onboarding tool. Providing DevRel teams the psychological safety to experiment with unconventional marketing and hands-on technical workshops is essential for maintaining developer engagement in a hybrid work era.

Claude Code AI Generative AI Gemini+5