{"content_id":"zuag1vtnf2","slug":"ai-native-developer-definition-and-practices","locale":"en","schema_type":"TechArticle","category":"ai_data","category_name":"AI Data","title":"What Is an AI-Native Developer? Roles, Skills, and Agent Operating Structure","summary":"An AI-native developer designs systems that enable AI to perform implementation work while taking charge of problem definition, constraint setting, quality validation, and ultimate responsibility. This article explains documentation, agent harnesses, team adoption procedures, performance metrics, and safety principles from a practical perspective.","author":{"name":"Injoys Editorial Team","url":"https://injoys.com/ko/about"},"key_points":["The key to AI-native development is not prompt techniques but designing systems that can delegate work and validate the results.","Even if AI generates code quickly, problem definition, product judgment, architectural decisions, security reviews, and accountability are not automatically resolved.","Providing specifications, constraints, schemas, and decision records as managed documentation makes it easier for agents to work within a consistent context.","The Plan, Draft, and Review stages can be implemented with a single agent; multi-agent systems should be chosen only when the benefits of separation outweigh the costs and complexity.","The success of team adoption should be evaluated by task completion time, defect rate, rework rate, cost, and the human review burden rather than by the volume of code generated."],"content_markdown":"An AI-native developer is not simply someone who is proficient with tools such as ChatGPT, Claude Code, and GitHub Copilot. More precisely, an AI-native developer can be defined as **a developer who designs the context, tools, permissions, and evaluation criteria that enable AI to perform executable tasks, while humans remain responsible for goal-setting, verification, approval, and accountability**.\n\nHowever, “AI-native developer” is not an official certification or a standardized job title agreed upon across the industry. The scope of automation also varies according to the risk level of the organization and product, so it should not be equated with handing every decision over to AI.\n\n## Definition of an AI-Native Developer\n\nAI-native development treats AI not as an auxiliary code completion tool but as a **development execution layer**. Humans structure the work to be done and define success criteria and prohibited conditions, while AI performs exploration, drafting, execution, and modification within the permitted scope.\n\nThe core roles are divided as follows.\n\n- **Human:** Problem definition, priorities, constraints, risk classification, approval criteria, and final accountability\n- **AI agent:** Information retrieval, draft planning, code and test creation, static analysis, and iterative modification\n- **Harness:** Documentation, tools, permissions, state management, tests, logs, cost limits, and stop conditions\n\nAn AI agent generally refers to a system in which a language model uses tools and selects its next action based on intermediate results. Unlike a workflow that follows a predetermined procedure, an agent can dynamically determine the order of tasks within its permitted scope.\n\n| Category | AI-Assisted Development | AI-Native Development |\n|---|---|---|\n| Role of AI | Code completion or question-and-answer tool | Part of the work execution layer |\n| Input | Primarily short prompts | Specifications, repository context, constraints, and evaluation criteria |\n| Human role | Implement directly, then use AI for assistance | Problem design, exception handling, verification, and approval |\n| Quality management | Relies on manual developer checks | Includes tests, evaluators, and review rules in the harness |\n| Operating model | Depends on individual usage practices | Managed through reproducible team processes and policies |\n\nAn important principle is that **work can be delegated, but accountability cannot**. AI may make low-risk operational decisions, but high-impact decisions involving security, privacy, payments, healthcare, legal matters, or production changes require stronger human approval.\n\n## Coding Equalization and New Differentiators for Developers\n\nGenerative AI lowers the barriers to repetitive implementation tasks such as writing boilerplate, finding API usage examples, drafting tests, and suggesting refactoring. It has a certain equalizing effect because even less experienced developers can produce working drafts faster than before.\n\nHowever, it is inaccurate to conclude that “the gap in coding skills has disappeared.” Evaluating AI-generated results still requires the following knowledge.\n\n1. The ability to identify contradictory or missing requirements\n2. The ability to design system boundaries and data flows\n3. The ability to assess trade-offs among performance, security, cost, and maintainability\n4. The ability to identify plausible but incorrect implementations\n5. The ability to trace causes and recover when failures occur\n\nThe capabilities that create greater differentiation in the AI era include the following.\n\n- **Problem definition:** Clarify the problem users actually experience and the conditions for success.\n- **Product and UX judgment:** Evaluate user flows, comprehensibility, accessibility, and trust rather than merely the existence of features.\n- **Decomposition:** Break large goals into small, verifiable tasks.\n- **Evaluation design:** Create tests, checklists, scorecards, and approval criteria first.\n- **Context design:** Organize documentation and repositories so AI can accurately find only the information it needs.\n- **Risk judgment:** Distinguish between tasks that can be automated and those requiring human approval.\n\nUltimately, as implementation becomes faster, the ability to determine “what should be built and why” and “whether the result is good enough” becomes more valuable.\n\n## Markdown and Source-of-Truth Document Design\n\nAgents do not automatically know an organization’s tacit knowledge. If requirements and constraints are scattered across conversations, meetings, code comments, and individual memories, agents are more likely to repeat the same questions or work from different assumptions.\n\nMarkdown is useful as a practical documentation format because its change history is easy to manage in Git, and it is relatively simple for both humans to read and AI to process. More important than the file format itself, however, is **clearly designating which document is the current source of truth**.\n\n### Information to Include in the Source of Truth\n\n- Product goals, non-goals, and user scenarios\n- Functional requirements and verifiable acceptance criteria\n- Repository structure and responsibilities by module\n- API contracts, data models, and migration rules\n- Coding conventions, test commands, and deployment procedures\n- Architecture decision records and reasons for changes\n- Access permissions, prohibited actions, and human approval conditions\n- Known limitations, incident response procedures, and responsible personnel\n\nA GitHub Issue can record the task background, scope, acceptance criteria, related documents, and definition of done. Long-term architecture and operational rules should be kept in version-controlled documentation such as a `docs` directory, with Issues linking to those documents.\n\n### Example Task Specification\n\n```markdown\n# Goal\nImprove login failure messages so users know how to recover.\n\n# Scope\n- Web login screen\n- Korean and English messages\n\n# Out of Scope\n- Changes to the authentication method\n- Changes to the password policy\n\n# Acceptance Criteria\n- Do not reveal externally whether an account exists.\n- Pass accessibility checks and existing authentication tests.\n- It must be possible to revert to the original behavior if the change fails.\n\n# Verification Commands\n- npm test\n- npm run lint\n```\n\nWell-organized documentation can reduce the need for an agent to read the entire codebase each time. However, this does not necessarily reduce token usage or cost. If documentation is duplicated or outdated, it may instead cause more exploration and incorrect modifications. Documentation owners, update schedules, and automated validation rules should be established together.\n\nPasswords, API keys, actual customer data, and excessive database permissions must not be recorded in documentation. Schema examples should be de-identified, and secrets should be managed in a separate secure store.\n\n## Minimum Structure of an AI Agent Harness\n\nHarness engineering refers to designing the execution system surrounding a model. This includes system instructions, tool integrations, context retrieval, permissions, memory, tests, observability, retries, and stop conditions.\n\nA minimal execution loop can consist of Plan, Draft, and Review.\n\n| Stage | Key Question | Output | Handling Failure |\n|---|---|---|---|\n| Plan | Is this task necessary, and what are its scope and risks? | Plan, targets for change, and verification method | Request additional information or stop the task |\n| Draft | Was the plan implemented in the smallest safe unit? | Code, tests, and documentation changes | Revise a limited number of times |\n| Review | Does the result meet the requirements and quality standards? | Evaluation results, defect list, and approval recommendation | Rework or escalate to a human |\n\nAn actual harness requires the following controls.\n\n- Permitted files, commands, networks, and data scope\n- Maximum execution time, number of tool calls, and cost limits\n- Stop conditions when tests fail or uncertainty is high\n- Logs of all inputs, tool calls, changes, and approvals\n- A human approval stage before production deployment\n- Rollback procedures for returning to the original state\n\n### Single-Agent and Multi-Agent Approaches\n\nPlan, Draft, and Review do not necessarily require three separate models or agents. A single agent can perform them using stage-specific instructions and tools.\n\nIn a multi-agent structure, roles can be divided as follows.\n\n- **Planner:** Analyzes requirements and reviews the necessity, scope, and risk of a feature.\n- **Generator:** Writes code, tests, and documentation according to the plan.\n- **Evaluator:** Inspects the results using independent criteria and identifies defects and areas for improvement.\n\nRole separation can support independent criticism and parallel exploration. On the other hand, it also increases the complexity of call costs, latency, state synchronization, and tracing the causes of errors. For simple tasks, deterministic scripts or a single agent may be more reliable, and multi-agent systems should be adopted only when measured improvements justify the added complexity.\n\n## Adoption Process for Teams and Companies\n\nAI adoption announcements and training alone do not create an AI-native organization. Permitted scope, data policies, quality standards, and accountability structures must be established together.\n\n### Step 1: Establish Baselines and Policies\n\n- Measure current task duration, defect rates, review wait times, and deployment frequency.\n- Define which data cannot be entered and which tools may be used.\n- Distinguish tasks that can be executed automatically from those requiring human approval.\n\n### Step 2: Champions and a Limited Pilot\n\nDesignate champions within the team who have experience using AI and the ability to provide training. A champion’s role is not to promote tools, but to document reproducible use cases, failure cases, and safety guidelines.\n\nIt is safer to begin pilots with work whose results are easy to verify, such as test generation, internal documentation organization, and low-risk refactoring.\n\n### Step 3: Standardize Successful Patterns\n\n- Prioritize recording input documents and evaluation criteria over prompts that happened to work.\n- Create shared Issue templates and a definition of done.\n- Automate tests, linting, security checks, and review procedures.\n- Document causes of failure and points requiring human intervention.\n\n### Step 4: Operations and Expansion\n\nExpand the scope of application when pilot results improve upon the baseline. Tool selection, training, cost management, access permissions, incident response, and periodic evaluation should be connected within a single operating system.\n\n## Metrics for Measuring Performance\n\nLines of code generated or the number of times AI is used do not directly demonstrate productivity or quality. Outcome-focused metrics such as the following should be measured together.\n\n| Area | Recommended Metric | Caution When Interpreting |\n|---|---|---|\n| Speed | Time from task start to deployment | Include review and rework time. |\n| Quality | Post-deployment defect rate, test failure rate | Separate easy tasks from difficult ones. |\n| Efficiency | Model cost per task, number of tool calls | Do not exclude the cost of human review. |\n| Reliability | Rollback rate, security warnings, permission violations | Also consider the possibility of undetected issues. |\n| Adoption | Percentage of teams using it repeatedly, completed real-world work | Distinguish these from simple logins or call counts. |\n| Experience | Developer satisfaction, cognitive load, review fatigue | Fatigue may increase even when speed improves. |\n\nCompare the results of AI-using groups and conventional approaches on the same types of tasks, and observe not only short-term speed but also maintenance costs and incidents.\n\n## Security and Quality Risks\n\nBecause AI agents can read code, execute commands, and retrieve external content, they have a broader attack surface than ordinary chat systems.\n\nThe main risks include the following.\n\n- Prompt injection that causes agents to follow instructions hidden in repository documents or external pages\n- Granting unnecessary access to files, databases, or deployments\n- Incorrect code that uses nonexistent APIs or packages\n- Introduction of vulnerable dependencies or code with unclear licensing\n- Weakening the validation criteria themselves to make tests pass\n- External transmission of customer data, secret keys, and internal code\n- Unexpected cost increases from repeated execution\n\nThe principles for mitigation are least privilege, isolated execution environments, allowlists, separation of secrets, independent testing, change logs, and human approval. In particular, evaluating an agent’s implementation using only tests written by the same agent may miss shared errors, so it is better to retain existing regression tests and separate review criteria.\n\n## How to Avoid Overreacting to Tools\n\nNew models, plugins, and agent frameworks continue to emerge, but there is no need to learn every tool. Tools should be evaluated using the following questions rather than by name or popularity.\n\n1. Is the repetitive work currently being addressed clearly defined?\n2. Can the tool connect safely to the existing development environment and permission system?\n3. Can its output quality be verified automatically or manually?\n4. Can its cost, latency, and failure rate be observed?\n5. Will the specifications, tests, and documentation remain even if the tool is replaced?\n\nUsing one tool suited to the team to complete a real product improvement from start to finish and measuring the result is more valuable than superficially learning how to use multiple tools.\n\n## AI-Native Developer Practice Checklist\n\n- [ ] Document goals, non-goals, and acceptance criteria before implementation.\n- [ ] Minimize the tools and access scope available to AI.\n- [ ] Break large tasks into independently verifiable units.\n- [ ] Require tests, documentation, and rollback methods together with code.\n- [ ] Have a human review the diff and execution results for important changes.\n- [ ] Record failures, retries, costs, and human interventions.\n- [ ] Measure whether automation actually improved quality and completion time.\n- [ ] Allow the agent to reject or escalate low-value or high-risk tasks.\n\n## Conclusion\n\nThe competitive advantage of an AI-native developer does not come from a specific prompt or tool name. It comes from **the ability to define problems accurately, create an environment in which agents can execute safely, evaluate the quality of results, and take responsibility for them**.\n\nAI can quickly produce many parts of an implementation, but it does not automatically guarantee the right product direction, user experience, system safety, or final accountability. Developers should therefore not abandon coding, but expand their roles—building on their coding knowledge—to include specifications, evaluation, product judgment, and system operations.","content_html":"\u003cp\u003eAn AI-native developer is not simply someone who is proficient with tools such as ChatGPT, Claude Code, and GitHub Copilot. More precisely, an AI-native developer can be defined as \u003cstrong\u003ea developer who designs the context, tools, permissions, and evaluation criteria that enable AI to perform executable tasks, while humans remain responsible for goal-setting, verification, approval, and accountability\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eHowever, “AI-native developer” is not an official certification or a standardized job title agreed upon across the industry. The scope of automation also varies according to the risk level of the organization and product, so it should not be equated with handing every decision over to AI.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#definition-of-an-ai-native-developer\" class=\"anchor\" id=\"definition-of-an-ai-native-developer\"\u003e\u003c/a\u003eDefinition of an AI-Native Developer\u003c/h2\u003e\n\u003cp\u003eAI-native development treats AI not as an auxiliary code completion tool but as a \u003cstrong\u003edevelopment execution layer\u003c/strong\u003e. Humans structure the work to be done and define success criteria and prohibited conditions, while AI performs exploration, drafting, execution, and modification within the permitted scope.\u003c/p\u003e\n\u003cp\u003eThe core roles are divided as follows.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003eHuman:\u003c/strong\u003e Problem definition, priorities, constraints, risk classification, approval criteria, and final accountability\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eAI agent:\u003c/strong\u003e Information retrieval, draft planning, code and test creation, static analysis, and iterative modification\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eHarness:\u003c/strong\u003e Documentation, tools, permissions, state management, tests, logs, cost limits, and stop conditions\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAn AI agent generally refers to a system in which a language model uses tools and selects its next action based on intermediate results. Unlike a workflow that follows a predetermined procedure, an agent can dynamically determine the order of tasks within its permitted scope.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eCategory\u003c/th\u003e\n\u003cth\u003eAI-Assisted Development\u003c/th\u003e\n\u003cth\u003eAI-Native Development\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Category\"\u003eRole of AI\u003c/td\u003e\n\u003ctd data-label=\"AI-Assisted Development\"\u003eCode completion or question-and-answer tool\u003c/td\u003e\n\u003ctd data-label=\"AI-Native Development\"\u003ePart of the work execution layer\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Category\"\u003eInput\u003c/td\u003e\n\u003ctd data-label=\"AI-Assisted Development\"\u003ePrimarily short prompts\u003c/td\u003e\n\u003ctd data-label=\"AI-Native Development\"\u003eSpecifications, repository context, constraints, and evaluation criteria\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Category\"\u003eHuman role\u003c/td\u003e\n\u003ctd data-label=\"AI-Assisted Development\"\u003eImplement directly, then use AI for assistance\u003c/td\u003e\n\u003ctd data-label=\"AI-Native Development\"\u003eProblem design, exception handling, verification, and approval\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Category\"\u003eQuality management\u003c/td\u003e\n\u003ctd data-label=\"AI-Assisted Development\"\u003eRelies on manual developer checks\u003c/td\u003e\n\u003ctd data-label=\"AI-Native Development\"\u003eIncludes tests, evaluators, and review rules in the harness\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Category\"\u003eOperating model\u003c/td\u003e\n\u003ctd data-label=\"AI-Assisted Development\"\u003eDepends on individual usage practices\u003c/td\u003e\n\u003ctd data-label=\"AI-Native Development\"\u003eManaged through reproducible team processes and policies\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eAn important principle is that \u003cstrong\u003ework can be delegated, but accountability cannot\u003c/strong\u003e. AI may make low-risk operational decisions, but high-impact decisions involving security, privacy, payments, healthcare, legal matters, or production changes require stronger human approval.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#coding-equalization-and-new-differentiators-for-developers\" class=\"anchor\" id=\"coding-equalization-and-new-differentiators-for-developers\"\u003e\u003c/a\u003eCoding Equalization and New Differentiators for Developers\u003c/h2\u003e\n\u003cp\u003eGenerative AI lowers the barriers to repetitive implementation tasks such as writing boilerplate, finding API usage examples, drafting tests, and suggesting refactoring. It has a certain equalizing effect because even less experienced developers can produce working drafts faster than before.\u003c/p\u003e\n\u003cp\u003eHowever, it is inaccurate to conclude that “the gap in coding skills has disappeared.” Evaluating AI-generated results still requires the following knowledge.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eThe ability to identify contradictory or missing requirements\u003c/li\u003e\n\u003cli\u003eThe ability to design system boundaries and data flows\u003c/li\u003e\n\u003cli\u003eThe ability to assess trade-offs among performance, security, cost, and maintainability\u003c/li\u003e\n\u003cli\u003eThe ability to identify plausible but incorrect implementations\u003c/li\u003e\n\u003cli\u003eThe ability to trace causes and recover when failures occur\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eThe capabilities that create greater differentiation in the AI era include the following.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003eProblem definition:\u003c/strong\u003e Clarify the problem users actually experience and the conditions for success.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eProduct and UX judgment:\u003c/strong\u003e Evaluate user flows, comprehensibility, accessibility, and trust rather than merely the existence of features.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eDecomposition:\u003c/strong\u003e Break large goals into small, verifiable tasks.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eEvaluation design:\u003c/strong\u003e Create tests, checklists, scorecards, and approval criteria first.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eContext design:\u003c/strong\u003e Organize documentation and repositories so AI can accurately find only the information it needs.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eRisk judgment:\u003c/strong\u003e Distinguish between tasks that can be automated and those requiring human approval.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eUltimately, as implementation becomes faster, the ability to determine “what should be built and why” and “whether the result is good enough” becomes more valuable.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#markdown-and-source-of-truth-document-design\" class=\"anchor\" id=\"markdown-and-source-of-truth-document-design\"\u003e\u003c/a\u003eMarkdown and Source-of-Truth Document Design\u003c/h2\u003e\n\u003cp\u003eAgents do not automatically know an organization’s tacit knowledge. If requirements and constraints are scattered across conversations, meetings, code comments, and individual memories, agents are more likely to repeat the same questions or work from different assumptions.\u003c/p\u003e\n\u003cp\u003eMarkdown is useful as a practical documentation format because its change history is easy to manage in Git, and it is relatively simple for both humans to read and AI to process. More important than the file format itself, however, is \u003cstrong\u003eclearly designating which document is the current source of truth\u003c/strong\u003e.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#information-to-include-in-the-source-of-truth\" class=\"anchor\" id=\"information-to-include-in-the-source-of-truth\"\u003e\u003c/a\u003eInformation to Include in the Source of Truth\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eProduct goals, non-goals, and user scenarios\u003c/li\u003e\n\u003cli\u003eFunctional requirements and verifiable acceptance criteria\u003c/li\u003e\n\u003cli\u003eRepository structure and responsibilities by module\u003c/li\u003e\n\u003cli\u003eAPI contracts, data models, and migration rules\u003c/li\u003e\n\u003cli\u003eCoding conventions, test commands, and deployment procedures\u003c/li\u003e\n\u003cli\u003eArchitecture decision records and reasons for changes\u003c/li\u003e\n\u003cli\u003eAccess permissions, prohibited actions, and human approval conditions\u003c/li\u003e\n\u003cli\u003eKnown limitations, incident response procedures, and responsible personnel\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eA GitHub Issue can record the task background, scope, acceptance criteria, related documents, and definition of done. Long-term architecture and operational rules should be kept in version-controlled documentation such as a \u003ccode\u003edocs\u003c/code\u003e directory, with Issues linking to those documents.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#example-task-specification\" class=\"anchor\" id=\"example-task-specification\"\u003e\u003c/a\u003eExample Task Specification\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e# Goal\n\u003c/span\u003e\u003cspan\u003eImprove login failure messages so users know how to recover.\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Scope\n\u003c/span\u003e\u003cspan\u003e- Web login screen\n\u003c/span\u003e\u003cspan\u003e- Korean and English messages\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Out of Scope\n\u003c/span\u003e\u003cspan\u003e- Changes to the authentication method\n\u003c/span\u003e\u003cspan\u003e- Changes to the password policy\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Acceptance Criteria\n\u003c/span\u003e\u003cspan\u003e- Do not reveal externally whether an account exists.\n\u003c/span\u003e\u003cspan\u003e- Pass accessibility checks and existing authentication tests.\n\u003c/span\u003e\u003cspan\u003e- It must be possible to revert to the original behavior if the change fails.\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Verification Commands\n\u003c/span\u003e\u003cspan\u003e- npm test\n\u003c/span\u003e\u003cspan\u003e- npm run lint\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWell-organized documentation can reduce the need for an agent to read the entire codebase each time. However, this does not necessarily reduce token usage or cost. If documentation is duplicated or outdated, it may instead cause more exploration and incorrect modifications. Documentation owners, update schedules, and automated validation rules should be established together.\u003c/p\u003e\n\u003cp\u003ePasswords, API keys, actual customer data, and excessive database permissions must not be recorded in documentation. Schema examples should be de-identified, and secrets should be managed in a separate secure store.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#minimum-structure-of-an-ai-agent-harness\" class=\"anchor\" id=\"minimum-structure-of-an-ai-agent-harness\"\u003e\u003c/a\u003eMinimum Structure of an AI Agent Harness\u003c/h2\u003e\n\u003cp\u003eHarness engineering refers to designing the execution system surrounding a model. This includes system instructions, tool integrations, context retrieval, permissions, memory, tests, observability, retries, and stop conditions.\u003c/p\u003e\n\u003cp\u003eA minimal execution loop can consist of Plan, Draft, and Review.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eStage\u003c/th\u003e\n\u003cth\u003eKey Question\u003c/th\u003e\n\u003cth\u003eOutput\u003c/th\u003e\n\u003cth\u003eHandling Failure\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Stage\"\u003ePlan\u003c/td\u003e\n\u003ctd data-label=\"Key Question\"\u003eIs this task necessary, and what are its scope and risks?\u003c/td\u003e\n\u003ctd data-label=\"Output\"\u003ePlan, targets for change, and verification method\u003c/td\u003e\n\u003ctd data-label=\"Handling Failure\"\u003eRequest additional information or stop the task\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Stage\"\u003eDraft\u003c/td\u003e\n\u003ctd data-label=\"Key Question\"\u003eWas the plan implemented in the smallest safe unit?\u003c/td\u003e\n\u003ctd data-label=\"Output\"\u003eCode, tests, and documentation changes\u003c/td\u003e\n\u003ctd data-label=\"Handling Failure\"\u003eRevise a limited number of times\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Stage\"\u003eReview\u003c/td\u003e\n\u003ctd data-label=\"Key Question\"\u003eDoes the result meet the requirements and quality standards?\u003c/td\u003e\n\u003ctd data-label=\"Output\"\u003eEvaluation results, defect list, and approval recommendation\u003c/td\u003e\n\u003ctd data-label=\"Handling Failure\"\u003eRework or escalate to a human\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eAn actual harness requires the following controls.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ePermitted files, commands, networks, and data scope\u003c/li\u003e\n\u003cli\u003eMaximum execution time, number of tool calls, and cost limits\u003c/li\u003e\n\u003cli\u003eStop conditions when tests fail or uncertainty is high\u003c/li\u003e\n\u003cli\u003eLogs of all inputs, tool calls, changes, and approvals\u003c/li\u003e\n\u003cli\u003eA human approval stage before production deployment\u003c/li\u003e\n\u003cli\u003eRollback procedures for returning to the original state\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#single-agent-and-multi-agent-approaches\" class=\"anchor\" id=\"single-agent-and-multi-agent-approaches\"\u003e\u003c/a\u003eSingle-Agent and Multi-Agent Approaches\u003c/h3\u003e\n\u003cp\u003ePlan, Draft, and Review do not necessarily require three separate models or agents. A single agent can perform them using stage-specific instructions and tools.\u003c/p\u003e\n\u003cp\u003eIn a multi-agent structure, roles can be divided as follows.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003ePlanner:\u003c/strong\u003e Analyzes requirements and reviews the necessity, scope, and risk of a feature.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eGenerator:\u003c/strong\u003e Writes code, tests, and documentation according to the plan.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eEvaluator:\u003c/strong\u003e Inspects the results using independent criteria and identifies defects and areas for improvement.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eRole separation can support independent criticism and parallel exploration. On the other hand, it also increases the complexity of call costs, latency, state synchronization, and tracing the causes of errors. For simple tasks, deterministic scripts or a single agent may be more reliable, and multi-agent systems should be adopted only when measured improvements justify the added complexity.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#adoption-process-for-teams-and-companies\" class=\"anchor\" id=\"adoption-process-for-teams-and-companies\"\u003e\u003c/a\u003eAdoption Process for Teams and Companies\u003c/h2\u003e\n\u003cp\u003eAI adoption announcements and training alone do not create an AI-native organization. Permitted scope, data policies, quality standards, and accountability structures must be established together.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#step-1-establish-baselines-and-policies\" class=\"anchor\" id=\"step-1-establish-baselines-and-policies\"\u003e\u003c/a\u003eStep 1: Establish Baselines and Policies\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eMeasure current task duration, defect rates, review wait times, and deployment frequency.\u003c/li\u003e\n\u003cli\u003eDefine which data cannot be entered and which tools may be used.\u003c/li\u003e\n\u003cli\u003eDistinguish tasks that can be executed automatically from those requiring human approval.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#step-2-champions-and-a-limited-pilot\" class=\"anchor\" id=\"step-2-champions-and-a-limited-pilot\"\u003e\u003c/a\u003eStep 2: Champions and a Limited Pilot\u003c/h3\u003e\n\u003cp\u003eDesignate champions within the team who have experience using AI and the ability to provide training. A champion’s role is not to promote tools, but to document reproducible use cases, failure cases, and safety guidelines.\u003c/p\u003e\n\u003cp\u003eIt is safer to begin pilots with work whose results are easy to verify, such as test generation, internal documentation organization, and low-risk refactoring.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#step-3-standardize-successful-patterns\" class=\"anchor\" id=\"step-3-standardize-successful-patterns\"\u003e\u003c/a\u003eStep 3: Standardize Successful Patterns\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003ePrioritize recording input documents and evaluation criteria over prompts that happened to work.\u003c/li\u003e\n\u003cli\u003eCreate shared Issue templates and a definition of done.\u003c/li\u003e\n\u003cli\u003eAutomate tests, linting, security checks, and review procedures.\u003c/li\u003e\n\u003cli\u003eDocument causes of failure and points requiring human intervention.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#step-4-operations-and-expansion\" class=\"anchor\" id=\"step-4-operations-and-expansion\"\u003e\u003c/a\u003eStep 4: Operations and Expansion\u003c/h3\u003e\n\u003cp\u003eExpand the scope of application when pilot results improve upon the baseline. Tool selection, training, cost management, access permissions, incident response, and periodic evaluation should be connected within a single operating system.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#metrics-for-measuring-performance\" class=\"anchor\" id=\"metrics-for-measuring-performance\"\u003e\u003c/a\u003eMetrics for Measuring Performance\u003c/h2\u003e\n\u003cp\u003eLines of code generated or the number of times AI is used do not directly demonstrate productivity or quality. Outcome-focused metrics such as the following should be measured together.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eArea\u003c/th\u003e\n\u003cth\u003eRecommended Metric\u003c/th\u003e\n\u003cth\u003eCaution When Interpreting\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Area\"\u003eSpeed\u003c/td\u003e\n\u003ctd data-label=\"Recommended Metric\"\u003eTime from task start to deployment\u003c/td\u003e\n\u003ctd data-label=\"Caution When Interpreting\"\u003eInclude review and rework time.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Area\"\u003eQuality\u003c/td\u003e\n\u003ctd data-label=\"Recommended Metric\"\u003ePost-deployment defect rate, test failure rate\u003c/td\u003e\n\u003ctd data-label=\"Caution When Interpreting\"\u003eSeparate easy tasks from difficult ones.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Area\"\u003eEfficiency\u003c/td\u003e\n\u003ctd data-label=\"Recommended Metric\"\u003eModel cost per task, number of tool calls\u003c/td\u003e\n\u003ctd data-label=\"Caution When Interpreting\"\u003eDo not exclude the cost of human review.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Area\"\u003eReliability\u003c/td\u003e\n\u003ctd data-label=\"Recommended Metric\"\u003eRollback rate, security warnings, permission violations\u003c/td\u003e\n\u003ctd data-label=\"Caution When Interpreting\"\u003eAlso consider the possibility of undetected issues.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Area\"\u003eAdoption\u003c/td\u003e\n\u003ctd data-label=\"Recommended Metric\"\u003ePercentage of teams using it repeatedly, completed real-world work\u003c/td\u003e\n\u003ctd data-label=\"Caution When Interpreting\"\u003eDistinguish these from simple logins or call counts.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Area\"\u003eExperience\u003c/td\u003e\n\u003ctd data-label=\"Recommended Metric\"\u003eDeveloper satisfaction, cognitive load, review fatigue\u003c/td\u003e\n\u003ctd data-label=\"Caution When Interpreting\"\u003eFatigue may increase even when speed improves.\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eCompare the results of AI-using groups and conventional approaches on the same types of tasks, and observe not only short-term speed but also maintenance costs and incidents.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#security-and-quality-risks\" class=\"anchor\" id=\"security-and-quality-risks\"\u003e\u003c/a\u003eSecurity and Quality Risks\u003c/h2\u003e\n\u003cp\u003eBecause AI agents can read code, execute commands, and retrieve external content, they have a broader attack surface than ordinary chat systems.\u003c/p\u003e\n\u003cp\u003eThe main risks include the following.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ePrompt injection that causes agents to follow instructions hidden in repository documents or external pages\u003c/li\u003e\n\u003cli\u003eGranting unnecessary access to files, databases, or deployments\u003c/li\u003e\n\u003cli\u003eIncorrect code that uses nonexistent APIs or packages\u003c/li\u003e\n\u003cli\u003eIntroduction of vulnerable dependencies or code with unclear licensing\u003c/li\u003e\n\u003cli\u003eWeakening the validation criteria themselves to make tests pass\u003c/li\u003e\n\u003cli\u003eExternal transmission of customer data, secret keys, and internal code\u003c/li\u003e\n\u003cli\u003eUnexpected cost increases from repeated execution\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe principles for mitigation are least privilege, isolated execution environments, allowlists, separation of secrets, independent testing, change logs, and human approval. In particular, evaluating an agent’s implementation using only tests written by the same agent may miss shared errors, so it is better to retain existing regression tests and separate review criteria.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#how-to-avoid-overreacting-to-tools\" class=\"anchor\" id=\"how-to-avoid-overreacting-to-tools\"\u003e\u003c/a\u003eHow to Avoid Overreacting to Tools\u003c/h2\u003e\n\u003cp\u003eNew models, plugins, and agent frameworks continue to emerge, but there is no need to learn every tool. Tools should be evaluated using the following questions rather than by name or popularity.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eIs the repetitive work currently being addressed clearly defined?\u003c/li\u003e\n\u003cli\u003eCan the tool connect safely to the existing development environment and permission system?\u003c/li\u003e\n\u003cli\u003eCan its output quality be verified automatically or manually?\u003c/li\u003e\n\u003cli\u003eCan its cost, latency, and failure rate be observed?\u003c/li\u003e\n\u003cli\u003eWill the specifications, tests, and documentation remain even if the tool is replaced?\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eUsing one tool suited to the team to complete a real product improvement from start to finish and measuring the result is more valuable than superficially learning how to use multiple tools.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#ai-native-developer-practice-checklist\" class=\"anchor\" id=\"ai-native-developer-practice-checklist\"\u003e\u003c/a\u003eAI-Native Developer Practice Checklist\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e Document goals, non-goals, and acceptance criteria before implementation.\u003c/li\u003e\n\u003cli\u003e Minimize the tools and access scope available to AI.\u003c/li\u003e\n\u003cli\u003e Break large tasks into independently verifiable units.\u003c/li\u003e\n\u003cli\u003e Require tests, documentation, and rollback methods together with code.\u003c/li\u003e\n\u003cli\u003e Have a human review the diff and execution results for important changes.\u003c/li\u003e\n\u003cli\u003e Record failures, retries, costs, and human interventions.\u003c/li\u003e\n\u003cli\u003e Measure whether automation actually improved quality and completion time.\u003c/li\u003e\n\u003cli\u003e Allow the agent to reject or escalate low-value or high-risk tasks.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#conclusion\" class=\"anchor\" id=\"conclusion\"\u003e\u003c/a\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eThe competitive advantage of an AI-native developer does not come from a specific prompt or tool name. It comes from \u003cstrong\u003ethe ability to define problems accurately, create an environment in which agents can execute safely, evaluate the quality of results, and take responsibility for them\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eAI can quickly produce many parts of an implementation, but it does not automatically guarantee the right product direction, user experience, system safety, or final accountability. Developers should therefore not abandon coding, but expand their roles—building on their coding knowledge—to include specifications, evaluation, product judgment, and system operations.\u003c/p\u003e\n","tags":["Harness Engineering","AI Agents","AI Native","Software Development","Documentation"],"faqs":[{"question":"Are AI-native developers the same as prompt engineers?","answer":"No. Prompt writing is only one skill; AI-native developers deal with the entire execution system, including problem decomposition, context provision, tool and permission design, testing, observation, approval, and operations."},{"question":"Do AI-native developers not code themselves?","answer":"Not necessarily. The proportion of code they write themselves may decrease, but solid development knowledge is necessary to understand and debug AI-generated code and assess architecture, performance, and security issues."},{"question":"Is it okay to leave all decisions to an AI agent?","answer":"No. Low-risk, limited choices can be automated, but high-impact decisions such as data deletion, payments, security permissions, and production deployment require explicit human approval and recovery procedures."},{"question":"Do Plan, Draft, and Review necessarily require three agents?","answer":"No. A single agent or a deterministic workflow can also perform all three stages. Multi-agent systems are appropriate when the benefits of independent evaluation or parallel exploration outweigh the additional costs and operational complexity."},{"question":"Do Markdown documents always reduce token costs?","answer":"Not always. Short, structured, up-to-date documents can reduce unnecessary exploration, but duplicate or outdated documents can lead to incorrect work and additional exploration. Responsibility for updating documentation and verification procedures are also necessary."},{"question":"Where should we start with the AI-native transition?","answer":"After measuring a baseline for current performance, it is best to choose one task that is easy to verify, such as test generation, documentation cleanup, or low-risk refactoring. Expansion should follow only after checking quality, completion time, cost, and review burden in a limited pilot."},{"question":"Has AI completely leveled the playing field in coding skills?","answer":"AI lowers the barrier to entry for repetitive implementation and drafting, but it does not eliminate differences in development capabilities. The ability to analyze requirements, design architecture, debug, address security and performance, and verify results still has a major impact on quality."},{"question":"Do I need to learn multiple AI development tools to become competitive?","answer":"The number of tools itself is not a competitive advantage. It is better to first choose a tool that can reliably complete one real-world task and measure its quality and cost. Keeping specifications and tests tool-agnostic also makes it easier to switch tools later."},{"question":"How do you measure the performance of an AI-native development team?","answer":"Rather than the amount of code generated, task completion time, post-deployment defects, rework, rollbacks, model costs, review time, and developer fatigue should all be measured together. The results can be interpreted only by comparing them with the pre-adoption baseline and similar task types."}],"sources":[{"url":"https://www.anthropic.com/research/building-effective-agents","title":"Anthropic: Building effective agents","type":"source"},{"url":"https://docs.github.com/en/issues/tracking-your-work-with-issues/about-issues","title":"GitHub Docs: About issues","type":"source"},{"url":"https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/about-writing-and-formatting-on-github","title":"GitHub Docs: About writing and formatting on GitHub","type":"source"},{"url":"https://www.nist.gov/itl/ai-risk-management-framework","title":"NIST AI Risk Management Framework","type":"source"},{"url":"https://genai.owasp.org/llm-top-10/","title":"OWASP Top 10 for Large Language Model Applications","type":"source"}],"images":[{"id":461,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NTQ1NiwicHVyIjoiYmxvYl9pZCJ9fQ==--dcc52a99856a48635d1882fba812226f930329f5/ai-4dab44ed.webp","is_representative":true,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"개발자가 여러 대시보드에서 AI 에이전트의 설계, 코딩, 검증, 배포 흐름을 관리하는 다이어그램","caption":"AI 네이티브 개발자가 연결된 에이전트와 도구를 운영하는 전체 개발 구조를 보여준다.","description":null},"en":{"alt":"Developer managing AI agent design, coding, testing, security, and deployment across connected dashboards","caption":"The diagram shows an AI-native developer orchestrating connected agents and tools throughout development.","description":null},"ja":{"alt":"開発者が複数の画面でAIエージェントの設計、実装、検証、展開を管理する図","caption":"AIネイティブ開発者が連携するエージェントとツールを運用する開発構造を示している。","description":null},"es":{"alt":"Desarrollador gestionando diseño, código, pruebas, seguridad y despliegue de agentes de IA en paneles conectados","caption":"El diagrama muestra a un desarrollador nativo de IA coordinando agentes y herramientas durante el desarrollo.","description":null},"id":{"alt":"Pengembang mengelola desain, kode, pengujian, keamanan, dan penerapan agen AI lewat dasbor terhubung","caption":"Diagram ini menunjukkan pengembang native AI yang mengorkestrasi agen dan alat dalam proses pengembangan.","description":null},"pt":{"alt":"Desenvolvedor gerenciando design, código, testes, segurança e implantação de agentes de IA em painéis conectados","caption":"O diagrama mostra um desenvolvedor nativo de IA orquestrando agentes e ferramentas ao longo do desenvolvimento.","description":null},"zh-hant":{"alt":"開發者透過多個互連儀表板管理 AI 代理的設計、編碼、測試、安全與部署","caption":"此圖呈現 AI 原生開發者在開發流程中協調代理與工具的整體架構。","description":null},"de":{"alt":"Entwickler steuert Entwurf, Code, Tests, Sicherheit und Bereitstellung von KI-Agenten über vernetzte Dashboards","caption":"Das Diagramm zeigt, wie ein KI-nativer Entwickler vernetzte Agenten und Werkzeuge im Entwicklungsprozess koordiniert.","description":null}}},{"id":462,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NTQ2MiwicHVyIjoiYmxvYl9pZCJ9fQ==--9fdf22aa2cbd420f209ff5c18baea59124f816b9/ai-f15eba1a.webp","is_representative":false,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"보안 장벽 안에서 여러 AI 에이전트가 개발 모듈을 연결하고 검증하는 워크플로 다이어그램","caption":"AI 에이전트들이 코딩, 도구, 설정, 배포 단계를 협업하며 보안과 성능 지표로 검증받는 구조를 보여준다.","description":null},"en":{"alt":"Workflow diagram of AI agents connecting and validating development modules inside a secure boundary","caption":"AI agents collaborate across coding, tooling, configuration, and deployment stages with security and performance checks.","description":null},"ja":{"alt":"安全な領域内で複数のAIエージェントが開発モジュールを連携・検証するワークフロー図","caption":"AIエージェントがコーディング、ツール、設定、デプロイを分担し、セキュリティと性能を確認する構造を示している。","description":null},"es":{"alt":"Diagrama de agentes de IA que conectan y validan módulos de desarrollo en un entorno seguro","caption":"Los agentes de IA colaboran en las fases de código, herramientas, configuración y despliegue con controles de seguridad y rendimiento.","description":null},"id":{"alt":"Diagram alur agen AI yang menghubungkan dan memvalidasi modul pengembangan dalam batas aman","caption":"Agen AI berkolaborasi pada tahap pengodean, alat, konfigurasi, dan penerapan dengan pemeriksaan keamanan serta kinerja.","description":null},"pt":{"alt":"Diagrama de agentes de IA conectando e validando módulos de desenvolvimento em um ambiente seguro","caption":"Agentes de IA colaboram nas etapas de código, ferramentas, configuração e implantação com verificações de segurança e desempenho.","description":null},"zh-hant":{"alt":"多個 AI 代理在安全邊界內連接並驗證開發模組的工作流程圖","caption":"AI 代理協作完成編碼、工具、設定與部署階段，並接受安全和效能檢查。","description":null},"de":{"alt":"Workflow-Diagramm von KI-Agenten, die Entwicklungsmodule in einer sicheren Umgebung verbinden und prüfen","caption":"KI-Agenten arbeiten bei Code, Werkzeugen, Konfiguration und Bereitstellung zusammen und durchlaufen Sicherheits- und Leistungsprüfungen.","description":null}}}],"published_at":"2026-08-04T10:59:54+09:00","updated_at":"2026-08-04T10:59:54+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant","de"],"url":"https://injoys.com/en/articles/ai-native-developer-definition-and-practices"}