ai-coding-agents

5 posts

line

What Is the Next Step in Personal AI Use? Conditions for Introducing an AIDD Organization Explored Through an AIDD Workshop at LY Corporation (opens in new tab)

LY Corporation argues that AI-driven development (AIDD) must evolve beyond individual experimentation into a repeatable organizational practice. AIDD integrates AI across requirements, design, implementation, and review, with AI producing drafts while people provide context, make decisions, and maintain accountability. Its workshop showed that successful adoption depends less on distributing tools than on preparing shared context, workflows, responsibilities, and decision-making structures. ## Defining AIDD - AIDD uses AI as a collaborator throughout the development lifecycle, from requirements clarification through code review. - It is neither fully delegating development to AI nor using AI as an isolated productivity assistant. - The intended workflow is: - AI creates an initial draft. - People provide intent, constraints, and judgment. - Results are reviewed and carried into subsequent development stages. - The central challenge is designing how people and AI work together across the entire process. ## Why LY Corporation Held the Workshop - Individual use of AI coding agents has become common for: - Code completion - Research - Testing - Documentation - Organizational adoption often stalls because: - Individual usage is not connected to team workflows. - Review standards for AI output are unclear. - Teams are unsure how to apply AI to existing products. - Successful experiments remain personal know-how. - “Convenience” does not translate into investment or adoption decisions. - The workshop aimed to move teams from personal AI usage toward organization-wide “AI Ready” conditions. - It involved 21 teams and 112 participants, including LINE Plus, who brought real work topics for evaluation. ## Why Participation Was Team-Based - AI creates value through workflow design, not just prompt-writing skill. - Teams must decide: - What information AI receives - Where human review occurs - Which output becomes the official deliverable - How feedback enters the existing process - Engineers alone cannot resolve these questions. Product, planning, design, leadership, and decision-makers contribute essential perspectives. - Team participation exposed hidden disagreements about consensus, ownership, review responsibilities, and decision boundaries. ## Workshop Structure - The two-day program combined learning with practical validation using real team projects. - Day one focused on: - Defining problems - Organizing requirements and context - Clarifying assumptions and priorities - Day two focused on autonomous experimentation and producing workflows applicable to actual work. - Orchestration Guild members, Developer Relations, and Technical Directors provided mentoring and helped make the learning reproducible across the company. - Informal conversations during breaks and meals also helped reveal issues and next steps that formal meetings often miss. ## Four Major Lessons ### The Greatest Value Often Comes Before Implementation - Teams initially focused on how quickly AI could write code. - In practice, the more important benefits came earlier in the process: - Breaking vague requirements into concrete issues - Defining requirements in clear language - Aligning team understanding - Identifying which decisions must come first - Turning decisions into manageable work units - AI can accelerate progress, but people must establish the problem definition and make critical judgments. ### Context, Not Tools, Is the Main Bottleneck - AI output quality depends heavily on the quality of its context. - Important context includes: - Specifications - Terminology - Constraints - Design intent - Relationships to existing code - Operational rules - Without this information, AI may generate plausible but impractical results, increasing review effort. - Organizing context must therefore be treated as core infrastructure for AI adoption, not optional preparation. ### Team Participation Reveals Organizational Issues - Individual experiments rarely expose the full set of coordination problems. - Working on a shared topic helps teams determine: - Where AI should be used - Who reviews its output - Which artifacts are authoritative - How AI-assisted work fits into existing processes - Collaboration across business, planning, design, engineering, and leadership makes implicit knowledge and conflicting assumptions visible. ### Decision-Maker Involvement Improves Follow-Through - Teams with leaders or decision-makers were more likely to turn workshop outcomes into concrete actions. - Organizational adoption requires decisions about: - Which areas to start with - Where to invest time - What to standardize - How deeply AI should be embedded into operations - Leadership participation prevents the workshop from ending as an interesting experiment and helps connect it to implementation. ## Conditions for Successful Adoption - Start with manageable topics, such as: - Requirements or issue clarification - Work requiring stakeholder alignment - Projects with accessible existing information - Small efforts where one complete cycle can be tested - Create lightweight entry points, such as applying AI to one feature, one requirements document, or one review checklist. - Make context preparation an official responsibility: - Document specifications, terminology, constraints, design intent, and decision rationale. - Allocate team and organizational time for this work rather than relying on individual goodwill. - Treat context organization as a long-term engineering asset that improves development even beyond AI use. The practical recommendation is to adopt AIDD incrementally through real team projects, while simultaneously improving shared context, review processes, role definitions, and leadership involvement. The goal is not merely to use more powerful tools, but to redesign the development system so AI-assisted work can be repeated and sustained across the organization.

gitlab

Confidential AI for GitLab Self-Hosted (opens in new tab)

Privatemode AI enables GitLab Duo Self-Hosted to provide modern coding agents without exposing source code to GitLab, a cloud provider, or an AI operator. It uses confidential computing and remote attestation to keep prompts, code, and completions encrypted even during inference, avoiding both the compliance risks of public AI services and the operational burden of running private GPU infrastructure. ## The productivity gap for regulated teams - GitLab Duo supports more than autocomplete, including: - Merge request reviews - Cross-file refactoring - Test generation and execution - Agentic workflows running in CI - These features normally require sending source code and prompts to an external model provider. - For organizations handling regulated software or proprietary intellectual property, that data transfer may violate contracts, regulations, or internal policy. ## Why self-hosting is difficult - Affected sectors include finance, healthcare, defense, government, and critical infrastructure. - Requirements may come from NIS2, DORA, GDPR, BaFin, BSI C5, healthcare rules, and broader data-sovereignty expectations. - Public AI SaaS is often unacceptable because code leaves the organization. - Private-cloud or VPC services reduce exposure but still require trusting the cloud and service operators with plaintext. - Running models internally preserves privacy but requires expensive GPUs, specialized staff, and ongoing model operations, while often lagging behind frontier models. ## Confidential computing as the solution - Confidential computing uses hardware-based trusted execution environments (TEEs) to encrypt data while it is being processed. - The architecture relies on technologies such as: - AMD SEV or Intel TDX for CPU protection - NVIDIA Confidential Computing for GPU protection - AES-256 encryption for data in transit and at rest - Remote attestation verifies that approved code is running inside the TEE before any data is sent. - Prompts, source code, context, and completions are decrypted only inside the protected environment. - The operator and underlying cloud provider cannot inspect the data through normal system or infrastructure access. ## Privatemode AI - Privatemode, developed by Germany-based Edgeless Systems, provides confidential inference through an OpenAI-compatible API. - Its client-side proxy manages encryption and remote attestation transparently. - Existing tools and SDKs using the standard `/v1` API can work without major changes. - The current highlighted coding model is Kimi K2.6 with a 256K context window; Kimi K3 and GLM are expected to follow. - The service is presented as production-ready and already used by public-sector, financial, defense, and regulated-industry organizations. - Its post-quantum-safe cryptography is intended to protect against “harvest now, decrypt later” attacks. ## GitLab Duo integration - GitLab Duo Self-Hosted connects to a self-hosted AI Gateway. - The Gateway forwards requests to the Privatemode proxy as an OpenAI-compatible endpoint. - The proxy: - Encrypts requests before they leave the organization’s network - Verifies the remote TEE through attestation - Forwards only after verification succeeds - Developers continue using Duo features such as Code Suggestions, Chat, Code Review, and agentic workflows without changing their experience. The recommended approach for regulated organizations is to combine GitLab Duo Self-Hosted with a confidential-computing provider such as Privatemode. This provides modern AI coding capabilities while replacing contractual privacy promises with hardware-enforced protection, without requiring the organization to operate its own LLM infrastructure.

line

Android CLI for AI Agents: Applying It to Large-Scale Mobile Development Environments (opens in new tab)

LINE’s Android app is a large monorepo with hundreds of Gradle modules and developers, making unrestricted AI-agent searches expensive and unreliable. Generic tools such as `grep` and `glob` often return excessive, semantically weak results, causing agents to waste tokens and retry. The team therefore built thin wrappers, skills, and prompts around Android CLI to provide efficient documentation lookup and Android Studio’s semantic capabilities across multiple agents. ## Why Generic Search Breaks Down at Scale - Large repositories can return huge numbers of search results from a single request. - Search output consumes agent context and increases costs. - Text search cannot reliably answer semantic questions such as: - Where a symbol is declared or used - Whether a file contains IDE-detectable problems - Whether code is unused - As the number of modules grows, agents are more likely to rely on irrelevant results and repeat searches. ## Replacing MCP Documentation Search with Android CLI - The team first adopted Android CLI for official documentation search. - It provides current documentation for Android, Jetpack Compose, AndroidX, Firebase, and related technologies. - This helps reduce hallucinations caused by outdated pretrained knowledge. - Android CLI’s `docs` commands are exposed through the `get-android-dev-knowledge` skill: - `docs search` finds relevant documentation. - `docs fetch` retrieves the document body from its Knowledge Base URL. - Compared with the previous Google Cloud Knowledge MCP setup, Android CLI eliminates: - Per-developer Google Cloud authentication - An authentication proxy - Quota-management and workaround logic - The result is fresher documentation with fewer tokens and less supporting infrastructure. ## Bundling the Android CLI Binary The team stores the Android CLI binary in the repository and invokes it from a fixed path such as `.agents/tools/android-cli/android`. - **Consistent environments** - Developers, CI systems, and agent hosts use the same pinned version. - Installation differences in version, path, and platform are reduced. - **Security enforcement** - The wrapper automatically adds `--no-metrics`. - This prevents agents from accidentally omitting the company-required telemetry setting. - A fixed binary location makes reliable wrapper enforcement possible. - **Manageable repository cost** - Existing use of Git LFS makes storing the binary relatively inexpensive. ## Handling the Android CLI Metrics Bug - Android CLI 1.0 initializes metrics tracking before honoring `--no-metrics`. - It may still attempt to write under `~/.android/cli`. - In restricted sandboxes, this causes a multi-page Java stack trace, wasting agent context. - The wrapper now probes write access before invoking the CLI: - It creates `~/.android/cli`. - It attempts to create a temporary probe file. - If writing is blocked, it emits a concise, parseable error explaining the required permission. - This converts a noisy failure into an actionable one-line message. ## Android Studio Integration Android CLI 1.0 added integration with running Android Studio instances, enabling IDE-level semantic operations from the command line. - `studio check` - Verifies that Android Studio is running. - Confirms that the target project is open and indexing is complete. - `analyze-file` - Runs IDE inspections on a single file without a build. - Detects semantic issues such as unused code. - `find-declaration` - Locates symbol declarations in the project and inside `.aar` or `.jar` dependencies. - `find-usages` - Finds references to a symbol. - `render-compose-preview` - Renders Compose `@Preview` functions as PNG images. ## Wrapping Studio Features as Skills - The team does not expose raw Android CLI behavior directly to agents. - Each capability is wrapped in a lightweight script and presented as an agent skill. - The first skill created was `studio-check`. - This follows the same design used for documentation search and ensures failures are concise, predictable, and easier for agents to interpret. ## Practical Recommendation For large Android repositories, use Android CLI behind repository-pinned wrappers and agent skills rather than exposing generic search or raw CLI commands directly. Enforce security flags, validate filesystem prerequisites early, and prefer IDE-backed semantic operations when agents need declarations, usages, inspections, or Compose previews.

line

Transitioning from a Legacy Project to an AI-Driven Project: The AX Roadmap (opens in new tab)

AI transformation (AX) is not achieved by simply adding AI tools; it requires redesigning the team’s development system around AI. The post proposes a four-stage roadmap for turning legacy projects into AI-driven projects, beginning with security and standardization and progressing toward specification-based development automation. Its central recommendation is to introduce AI gradually, with clear documentation, human approval gates, and measurable outcomes. ## What an AI-Driven Project Means - AI participates throughout the development lifecycle, including: - Specification writing - Code generation - Testing - Code review - Pull request creation and merging - Developers focus more on direction, judgment, and business decisions rather than repetitive implementation work. - The key methodology is **spec-driven development (SDD)**: - Requirements and implementation specifications are defined before code. - AI generates, tests, and reviews code against those specifications. - Structured specifications compensate for AI’s difficulty in interpreting ambiguous intent. ## Stage 1: AI-Ready — Establish Security and Compliance The first stage creates a safe foundation for using AI with project context and company data. - Remove hardcoded secrets such as API keys, database passwords, and internal IP addresses. - Use secret-management services to inject credentials dynamically at runtime. - Protect personally identifiable information by masking or tokenizing names, emails, phone numbers, and similar data before sending it to AI systems. - Separate or restrict access to critical intellectual property, including proprietary algorithms and sensitive architecture. - Define minimum compliance requirements first rather than delaying adoption until every security improvement is complete. - Use sandboxing, system prompts, filesystem restrictions, and network isolation to limit AI access. - Validate that isolation mechanisms actually prevent sensitive-data exposure. Expected benefits include safer AI usage, faster debugging and repetitive coding, and accumulated team experience that supports later adoption stages. ## Stage 2: AI-Assist — Standardize Team Usage This stage addresses teams where individuals already use AI but follow inconsistent practices. - Create project-level AI guidelines covering: - Project context - Coding conventions - Architecture principles - Domain terminology - Establish shared prompts, skills, or plugins for activities such as: - Brainstorming - Writing implementation plans - Code review - Subagent-driven development - Integrate AI into CI/CD for automated first-pass code reviews. - Let AI identify style violations, likely bugs, and security issues. - Reserve human review for complex business logic, architecture, and policy decisions. - At this stage, AI assists with human-written code rather than independently implementing features. Possible KPIs include: - A reduction in repetitive human review comments. - Increased test coverage. - Improved deployment reliability and system stability. - More consistent adherence to team conventions. ## Stage 3: AI-Development — Automate Implementation The third stage connects specifications directly to working code through an automated pipeline. - The pipeline includes three human approval gates: 1. **Specification review:** Confirm requirements, scope, edge cases, and validation criteria. 2. **Implementation and test-plan review:** Approve the AI-generated execution and testing plans. 3. **Code review:** Approve the final implementation before merging. - AI uses documented domain knowledge and architecture context to generate project-specific code. - A new file in a directory such as `/specs` can trigger CI automation. - CI can generate an implementation plan, execute coding tasks through independent subagents, run tests, and create a pull request. - Approval steps ensure that AI cannot proceed to the next stage without human authorization. To improve adoption, the post recommends expanding AI’s responsibilities gradually: - Begin with unit- and integration-test generation for existing logic. - Move progressively toward boilerplate and broader implementation work. - Avoid delegating critical business logic immediately, since poor early results can undermine team trust. ## Overall Adoption Principles - Each roadmap stage provides value independently; teams do not need to complete all four stages at once. - The appropriate target depends on team maturity, risk tolerance, domain complexity, and adoption speed. - Documentation is essential because AI needs structured project and business context. - Human oversight remains important, especially for requirements, architecture, business rules, and final code approval. - Security controls, common workflows, and measurable KPIs should develop alongside AI usage. Teams should start with the safest achievable stage, standardize practices before automating implementation, and expand AI’s role only as documentation, testing, and review processes become reliable.

github

GitHub recognized as a Leader in the Gartner® Magic Quadrant™ for Enterprise AI Coding Agents for the third year in a row (opens in new tab)

GitHub argues that AI coding has made code generation easier, shifting the main bottleneck to reviewing, securing, governing, and deploying software. It presents GitHub Copilot as an agentic platform spanning the full software development lifecycle, enabling developers to assign issues to agents and focus on reviewing and approving results. Gartner named GitHub a Leader in the 2026 Magic Quadrant for Enterprise AI Coding Agents, placing it highest for ability to execute for the third consecutive year. ## The Shift from Code Generation to Software Delivery - AI coding agents are increasingly expected to handle more than writing functions. - The harder problems now involve: - Code review - Security - Governance - Testing - Deployment - GitHub describes the new workflow as “orchestrating outcomes”: developers assign work to agents, then return to steer, review, and approve it. - Gartner projects that asynchronous AI coding-agent workflows could improve engineering productivity by 30%–50% by 2028, compared with 0%–20% gains from code assistants in 2025. ## Enterprise Adoption of GitHub Copilot - Copilot is used by 140,000 organizations, nearly three times the number reported a year earlier. - Overall growth exceeded 100% year over year. - Most users work with multiple AI models. - GitHub Copilot CLI usage nearly doubled month over month. - GitHub says these figures indicate that enterprises are adopting increasingly sophisticated, agent-driven workflows. ## Gartner’s 2026 Evaluation - Gartner evaluated 12 enterprise AI coding-agent vendors according to: - Ability to execute - Completeness of vision - GitHub was positioned as a Leader and ranked highest in ability to execute. - Gartner describes Leaders as vendors combining strong execution, market-shaping vision, rapid innovation, broad software-engineering relevance, and enterprise-grade security and governance. - The report’s Leader quadrant also includes Anthropic, Cursor, and OpenAI. ## GitHub’s Claimed Differentiators - **Developer choice:** Copilot supports multiple models and providers. - **Broad availability:** It works across editors, IDEs, CLIs, and GitHub’s web, desktop, and mobile applications. - **Full-lifecycle integration:** Copilot operates across issues, pull requests, code reviews, and GitHub Actions—not only inside the editor. - **Enterprise governance:** Teams can observe, audit, and secure how AI is used in engineering workflows. ## What GitHub Plans to Build Next - GitHub says it will expand agentic workflows across more developer-facing surfaces. - Planned investments include: - Greater model choice and intelligent model routing - Deeper integrations throughout the software lifecycle - Performance improvements based on how software is actually built and maintained on GitHub GitHub’s central recommendation is to treat AI coding agents as part of an end-to-end engineering platform rather than isolated code-generation tools. The post also notes that Gartner’s recognition is not an endorsement and that its findings should be considered alongside the full research report.