Introduction

Over the past few months, I have almost completely stopped writing code by hand. I had heard that more and more people were working this way, but I never expected it to happen to me so soon.

At NearMe, we began incorporating AI coding into our development workflow around last year. What we are seeing now feels like a dramatic paradigm shift toward AI-led development.

In this article, I will explain how we think about levels of AI adoption and the initiatives we are currently pursuing. Everything described here—including the tools and methods—is a snapshot of where we are today. The pace of change is rapid, and there is no telling what things will look like six months from now, but I believe the underlying principles will endure.

Levels of AI Adoption

Here is how I think about the different levels of AI coding adoption.

Level	Unit of work delegated to AI	What it looks like
Lv1	Code completion	A few lines of suggestions in the editor
Lv2	Function generation	Describe the requirements and have AI write a function
Lv3	Small feature development	Delegate changes spanning one to a few files
Lv4 ← We are here	Large feature development	Delegate cross-repository feature development or large-scale refactoring
Lv5	Development cycle automation	Delegate everything from requirements definition and implementation to post-release evaluation and improvement

Lv1 and Lv2 are extensions of “smart autocomplete,” providing benefits without changing the existing development workflow. Around Lv3, the assumption that people write the code begins to break down. At Lv4, development becomes AI-led, and the focus of human work shifts from writing code to designing how work is delegated and verifying the results. This is not limited to new features. AI can now also handle large-scale refactoring and feature enhancements that require a deep understanding of existing code.

Lv4 has only become practical in the past few months. Considering that we were at Lv1 or Lv2 last year, the pace of change has been remarkable. We are now working to adapt to Lv4 as an organization.

Beyond that, Lv5—the automation of the entire development cycle—is beginning to come into view. For now, we are starting by automating areas adjacent to development. We have introduced a workflow in which AI investigates inquiries submitted through Slack, provides an initial response, and creates a ticket when necessary. If the issue is a bug, we are also experimenting with taking the process all the way through implementation of the fix.

Organizational Systems That Support AI-Led Development

At Lv4, delegating a large feature to an AI agent inevitably runs into problems like these:

• The agent does not know each repository’s conventions or design principles, so it produces large amounts of code that works but does not fit the codebase’s established style
• When a large task is delegated all at once, it can go off course without anyone noticing
• The volume of generated code exceeds human review capacity
• Changes pile up without sufficiently verifying that they actually work

As long as everyone is using the same widely available models, the models themselves are unlikely to be a source of differentiation. What makes the difference is the execution environment surrounding the model—instructions, tools, permissions, and verification mechanisms. This is commonly called a harness. Continually improving the harness is essential for an organization to adapt to Lv4.

The harness does more than ensure quality. Autonomous agents carry the risk of service disruption or information leakage caused by incorrect operations. Another important role of the harness is to use permissions to control which operations agents can perform and which information they can access, while requiring human approval for operations that could affect production.

There is not yet an established best way to develop a harness. We learn from industry practices, make small changes to instructions and mechanisms, and observe how agents behave. We have no choice but to find our way through this repeated experimentation; it feels more like a chemistry experiment than programming. Below, I will introduce the organizational systems that have become part of our regular workflow through this process of trial and error.

1. Centralized Management of Agent Instructions

NearMe’s server stack consists of nearly 20 repositories, including ride-api for ride orders, user-api for users and organizations, and payment-api for payments. To have agents write high-quality code, we need to teach them the conventions of each repository—language idioms, how to use the ORM, and how to write tests. But if we write instruction files separately for every repository, the content quickly becomes duplicated and contradictory.

We therefore manage our instructions centrally as layers. We define layers by area of concern, such as “shared across all repositories,” “TypeScript,” “API servers,” and “conventions for a specific ORM,” then use a manifest to declare which combination applies to each repository. Running a synchronization command generates instruction files and on-demand skills—procedures for routine tasks—in each repository. Improving a convention in one place propagates it to agents across every repository.

The names and locations of instruction files differ by provider, such as Anthropic and OpenAI. For now, we use symbolic links and similar mechanisms to make the same content available in the format required by each provider.

The key operational principle is to keep the instructions that are loaded in every session as concise as possible. Instructions consume context too, so we limit always-loaded instructions to universal rules and move detailed, situation-specific procedures into skills that are loaded only when needed. Instruction files are not something you write once and forget; they are assets that must be continually developed.

2. Plan-Driven Implementation

Plan-driven implementation has had the greatest impact on our transition to Lv4. For large features, we do not ask the agent to start implementing immediately. We first have it write an implementation plan. The plan is a checklist-formatted Markdown document that includes the steps for each phase, the files involved, and agreed-upon design decisions. Work that cannot fit into a single plan is divided into subplans. Ultimately, how much we can delegate to AI depends on whether we can articulate and agree on a plan.

A plan is both “an intermediate deliverable that people can review” and “a set of instructions that allows any agent to resume the work.” Because the agent works through a checklist, another agent can pick up where it left off even if the session is interrupted. People review the plan before the code, allowing us to correct mistakes in direction at an early stage.

Plans serve two purposes: managing work in progress and preserving the context and rationale behind design decisions. Since their role differs from human-oriented task management, we store them in docs/plans/ in the same repository as the code so that agents can access them at any time, then move completed plans to docs/plans/archive/.

Once implementation according to a plan is complete, we also reflect the changes in the functional specification documentation. We operate a mechanism that detects divergence—or drift—between the specifications and the code so that the documentation agents rely on does not become outdated.

3. The Adversarial Review Loop

At Lv4, the review bottleneck becomes a serious issue.

The idea arose after we found ourselves repeatedly going back and forth: a reviewer would use AI to review an AI-written PR, then the implementer would use AI again to address the feedback. If this exchange is going to continue through a human several times, the part up to convergence might as well run automatically from the beginning. That is the adversarial review loop.

We assign a reviewer that is independent of the implementation agent and recommend using a highly capable model for the review. The reviewer examines the changes from an adversarial perspective, asking whether there really are no bugs. The implementation agent addresses the issues raised, and the same reviewer reviews the changes again. This cycle repeats automatically—with a maximum number of iterations—until no issues remain.

In practice, even code written by a highly capable model can contain significant issues, depending on the difficulty of the task. The number of findings decreases with each iteration, and every task moves toward convergence. We have made it a rule to run this loop at every plan milestone. “Implementation → adversarial review → fixes → convergence → human review” is now our standard flow.

We have several hypotheses about why having an independent AI agent review AI-implemented code produces useful findings. One is context separation. The implementation agent performs its self-check while carrying over the history of the work and its assumptions, whereas the reviewer knows nothing about how the implementation came about and can examine the changes without sharing those assumptions. Another is that the word “adversarial” prompts the reviewer to question the premises. In our limited trials, this instruction appeared to produce more relevant findings than reviews without it. The additional inference time may also contribute. We have not tested this rigorously, but at present we believe context separation and the instruction itself have the greatest impact.

When the review process reveals a lesson that should be kept in mind for future work, we also have a skill that feeds it back into the shared instructions—the layers described earlier—on the spot. This allows us to accumulate lessons learned from failures as organizational knowledge.

4. Verifying the Real System—An Environment for Every Change

There is a gap between “the tests passed” and “it actually works.” To bridge it, we use git worktrees to run a set of services for each branch or PR alongside the main development stack. Internally, we call these environments “variants.” There are two goals: to let AI agents work on multiple features simultaneously and to speed up hands-on verification of the growing number of PRs.

Agents themselves can use a browser or API to exercise and verify the modified system. Because our development stack follows a microservices architecture, we only need to start the changed services as containers, allowing us to maintain multiple parallel environments with relatively little overhead. See our technical meetup slides for more details.

5. Handling PRs at Scale—Tools to Support Release Operations

As code generation gets faster, the number of PRs increases. To address the growing burden of checking PRs before a release, we developed a support tool that mechanically triages them. It compares release tasks in our task management tool against the actual state in GitHub—including review status, CI, conflicts, and the nature of the changes—and automatically classifies each PR into categories such as “cannot merge,” “high merge risk” (for example, changes to the database schema or generated SQL, or a large volume of code changes), and “low merge risk.”

The tool only classifies and reports; it is designed so that a human decides whether to perform the state-changing action of merging. Automation helps prioritize what to check, while people focus on the highest-risk areas. This is one way we reduce the review burden.

The ultimate bottleneck is human understanding of the code. It is important not only to prioritize checks through triage, but also to make each PR easier to understand. For example, we have agents include a numbered causal flow in every PR description, explaining how the changes connect to produce the intended behavior. This lets reviewers follow the intent of the diff without having to work out the order in which to read it.

How the Role of Engineers Is Changing

The Bottleneck Is Shifting to Review and Verification

As the cost of writing code falls dramatically and the volume of generated code grows, the bottleneck is shifting to review, testing, and verification. The systems described above are investments in increasing our development capacity itself and translating that capacity into user value while maintaining quality.

Orchestrating AI Agents and Taking Responsibility for Outcomes

This transformation also significantly shifts the focus of an engineer’s work. The role is changing from someone who writes code to someone who can take responsibility for AI-generated deliverables—someone who makes design decisions, builds verification mechanisms, and ensures final quality.

The first important aspect of this way of working is running agents in parallel. As tasks delegated to agents take longer, watching and waiting for a single session is inefficient. By running agents in parallel across multiple worktrees and sessions, supported by an environment where we can view and monitor them together—using a session management tool such as herdr—one person can advance several changes at once. It feels like shifting from “the person doing the work” to “the lead orchestrating multiple contributors.”

At the same time, we need to choose models appropriately and tune their reasoning levels. Our current rule of thumb is to assign the most capable models and deeper reasoning to stages where mistakes are costly, such as planning and review, while using lighter settings for routine implementation. We also routinely make adjustments such as deciding which context to provide and how to compress it once it grows too long.

To take responsibility for outcomes in this way of working, autonomy becomes more important than ever. Engineers must shift from passively following instructions to identifying problems themselves and deciding which direction to take. Since each person handles more tasks in parallel, task management skills are also increasingly necessary. And now that AI support makes it easier to venture into unfamiliar areas, it is important not to remain confined to one’s specialty, but to cross boundaries and broaden the scope of what one can build.

In AI-led development, giving AI its initial direction is also an important human responsibility. In the hierarchy of instructions, even if a frontier model currently serves as the higher-level layer that guides subagents and the implementation, humans occupy the layer above it: the topmost layer that defines the problem to solve, the constraints to uphold, and the criteria for success. The quality of the initial direction shapes everything that follows—the plan, the implementation, and the verification.

Fulfilling this role requires more than coding knowledge. The importance of broad and deep knowledge spanning the domain, infrastructure, data, and product is clearly increasing, as is the importance of communication skills: eliciting requirements, conveying them accurately to AI, and building agreement with stakeholders about the resulting deliverables. The center of gravity of the skill set is changing, but my experience is that people with these capabilities can create even more value than before.

The Assumptions and Constraints of Development Are Changing

Individual roles are not the only thing changing. The shifting bottleneck also forces us to reconsider the development process. Parts of Scrum operations—including sprint length, estimation, and task granularity—are built around the assumption of how quickly people write code. We have not yet made major changes to our Scrum process, but we see it as something that should be continually reassessed.

Some might wonder whether faster development means we will soon run out of problems to solve. In mobility, the field NearMe is tackling, there is no sign of that happening anytime soon. There are still countless opportunities to deliver value, whether through new development or by refining existing features: web and mobile apps for users, dispatch operators, and drivers; reservation systems; real-time dispatch systems that support last-minute bookings; ride-sharing and dispatch optimization; and AI agents that arrange rides and respond to inquiries.

We can also now address areas we previously hesitated to tackle because the scale or difficulty of development made them uneconomical. The range of viable business opportunities is expanding, while we are also gaining more capacity to improve our development foundation and product quality.

Expanding AI Adoption Across the Company

The potential of AI is not limited to development. As we assessed what today’s AI can do within NearMe, we saw significant potential for it to support a wide range of work across roles. We therefore provided AI accounts to every employee, including product managers, designers, sales, operations, customer support, and corporate teams, and are advancing AI adoption company-wide.

Our first priority is simply to use it in practice. The areas where AI is effective become clear more quickly by trying it than by thinking about them in the abstract.

We have also established a dedicated team to expand and embed this usage throughout the company. In addition to managing accounts and promoting adoption based on usage patterns, the team draws on the AI expertise developed in engineering to introduce harnesses into different types of work and share internal best practices.

In fact, not only engineers and product managers but even sales team members now use AI to investigate repositories, helping them triage issues and explore possible solutions. Even when an engineer’s help is ultimately required, each role can collaborate with a deeper understanding of the problem.

The significance of company-wide AI adoption goes beyond making individual tasks more efficient. The more commoditized AI-based development becomes, the more valuable firsthand, on-the-ground information becomes in relative terms. AI understands what is written in code and documentation well, but it cannot discover what is not recorded there on its own: how drivers actually operate, the exceptions that occur in airport transfers, or the frustrations users voice. A company’s competitiveness in the AI era will depend on its ability to grasp information that can only be found in the field and connect it to development quickly and accurately.

Conclusion

“The end of coding” is not the end of engineers. Adapting to an AI-led era requires more than introducing tools; it requires changing both how individuals work and the organizational systems that support them. Organizations have a responsibility to turn insights gained from individual ingenuity and failure into shared assets, continually developing their harnesses and development processes. Individuals, meanwhile, need to adapt to the evolution of AI, identify problems themselves, and draw out its full potential.

We are still only partway through our adaptation to Lv4, with Lv5 waiting beyond it. We want to remain an organization that enjoys this transformation and evolves its systems along with it.