Plain-language summary
What this guide covers
Software engineers design, build, test, review, deploy, and maintain systems. AI may help explain code, scaffold simple components, draft tests, write documentation, suggest refactoring ideas, propose debugging hypotheses, and support review checklists. It can also generate insecure code, hallucinate APIs, mishandle dependencies, expose secrets, ignore licenses, and miss deployment risks. Treat AI output as untrusted until reviewed, tested, scanned, and approved under your organization’s process.
Software affects security, privacy, accessibility, reliability, and user trust. A small code change can expose data, break a workflow, create a vulnerability, or violate licensing obligations. AI can reduce blank-page time, but it cannot replace secure development practices, code review, testing, threat modeling, provenance review, incident response, and deployment controls. The engineer remains responsible for understanding what code does and why it is safe to ship.
What you will learn
- Identify software-engineering tasks where AI can assist with explanation, scaffolding, tests, documentation, debugging, refactoring, and review.
- Recognize high-risk uses involving confidential code, credentials, dependency risk, generated vulnerabilities, prompt injection, licensing, and deployment controls.
- Use a task map to choose review levels for AI-assisted code and documentation.
- Create checkpoints for secure development, threat modeling, code review, testing, provenance, and incident response.
- Run a first-week experiment with a low-risk test-generation or documentation task.
Guide section
Why the role matters and how AI may change tasks
AI can help with drafts and explanations, but software engineering still depends on design judgment, tests, security, and accountability.
O*NET describes software developers as analyzing user needs, designing software, writing and testing code, modifying systems, and working with others on requirements and maintenance. The U.S. Bureau of Labor Statistics software page gives U.S. occupational context and 2024 labor-market data with 2024 to 2034 projections. Those sources are not predictions for any individual engineer. AI may change tasks by helping engineers understand unfamiliar code, create a simple scaffold, draft unit tests, explain errors, write documentation, or generate refactoring options. That is augmentation, not automatic reliability. A model can produce code that compiles but is insecure, unlicensed, inefficient, unmaintainable, or wrong for the system.
Secure development sources are especially important for AI-assisted coding. NIST’s Secure Software Development Framework describes practices for reducing software vulnerabilities. NIST’s Cybersecurity Framework supports risk management, and OWASP’s large language model project highlights risks such as prompt injection, insecure output handling, sensitive information disclosure, supply-chain risk, and excessive agency. For engineers, the practical rule is simple: AI output must go through the same or stronger review than human-written code. Never use AI to bypass security review, licensing review, access control, tests, or deployment gates.
Guide section
Software engineer task map
Use this map to decide whether AI should explain, draft, suggest, check, or stay out of the workflow.
Task map
| Task or workflow | Possible AI contribution | Human responsibility | Risk level or review requirement |
|---|---|---|---|
| Code explanation | Explain unfamiliar code, control flow, or API usage. | Confirm against the actual repository, tests, docs, and runtime behavior. | Medium review. High review for security-critical, legacy, or production code. |
| Scaffolding | Draft boilerplate, simple components, configuration examples, or pseudocode. | Check architecture, dependencies, secrets, error handling, accessibility, and maintainability. | High review. Do not paste confidential code into unapproved tools. |
| Tests | Draft unit tests, edge cases, mock data, and test names. | Run tests, add missing cases, verify assertions, and review coverage. | Medium to high review. Generated tests can assert the wrong behavior. |
| Documentation | Draft README sections, comments, API descriptions, and runbook notes. | Verify commands, parameters, limits, version, security warnings, and support ownership. | Medium review. High review for public or compliance documentation. |
| Refactoring ideas | Suggest simplification, decomposition, naming, or pattern alternatives. | Evaluate behavior preservation, performance, compatibility, and migration risk. | High review. Refactors need tests and peer review. |
| Debugging hypotheses | Suggest possible causes and diagnostic steps from errors or logs. | Protect logs, verify root cause, reproduce issue, and test fixes. | High review. Logs may contain secrets or personal data. |
| Review assistance | Create a checklist for security, style, performance, accessibility, and edge cases. | Conduct human code review and use approved tools for scanning and policy checks. | High review. AI review is not a substitute for accountable review. |
| Dependency research | Summarize public documentation or compare package options. | Check licensing, maintenance, vulnerabilities, provenance, and organizational approval. | High review. Dependency risk can affect the whole product. |
Guide section
Good starting tasks and unsuitable uses
Start with low-risk tasks in a sandbox or non-production branch. Avoid exposing secrets, private code, or security-sensitive context.
Lower-risk starting tasks
- Ask AI to explain a small public code example or internal code only in an approved tool.
- Generate unit-test ideas for a pure function with no secrets or production data.
- Draft README wording for a local development setup, then verify every command.
- Create pseudocode for a small refactor before touching code.
- Draft a review checklist for a pull request template.
- Explain a public library’s documented API and list questions to verify in official docs.
- Suggest edge cases for input validation without exposing real user data.
- Write comments for code you already understand, then edit for accuracy.
Unsuitable, sensitive, or high-risk uses
- Pasting confidential source code, credentials, tokens, private keys, logs, customer data, or security findings into unapproved tools.
- Using AI to bypass authentication, authorization, rate limits, logging, review, licensing, vulnerability scanning, or deployment gates.
- Shipping generated code without tests, peer review, security review, and dependency review.
- Accepting dependency recommendations without checking license, maintenance, vulnerabilities, provenance, and approval.
- Letting AI act autonomously on production systems, incidents, infrastructure, or customer data without approved controls.
- Ignoring prompt injection, insecure output handling, excessive agency, or sensitive information disclosure risks in AI-enabled features.
- Using AI-generated code with unclear licensing or copied provenance without review.
- Treating AI debugging as root-cause analysis without reproduction and evidence.
Guide section
Hypothetical workflow: draft tests for a small function
This example is hypothetical. It uses AI to suggest tests, not to decide that code is production-ready.
Example
Inputs and outputs
Inputs: small non-sensitive function, expected behavior, allowed edge cases, test framework, coding standard, and repository review policy. Outputs: draft test cases, reviewed test file, list of missing edge cases, security notes, and pull request review checklist. No credentials, production logs, customer data, or private security findings are shared with unapproved tools.
Workflow steps
- Confirm the code can be shared with the chosen tool under organizational policy.
- Describe expected behavior, boundaries, and known edge cases without including secrets or production data.
- Ask AI to propose test cases and explain why each case matters.
- Review the proposed tests for wrong assumptions, missing security cases, weak assertions, and brittle behavior.
- Write or edit the test file locally in a non-production branch.
- Run the tests, inspect failures, and add cases AI missed.
- Run approved linters, security checks, dependency checks, and coverage tools.
- Submit a pull request with human review notes, AI-use disclosure if required, and clear decision ownership before merge.
Reusable prompt for test ideas
Suggest tests for this non-sensitive function behavior: **{{function_behavior}}**. Use **{{test_framework}}**. Include normal cases, boundary cases, invalid inputs, error handling, and security-relevant edge cases. Do not assume behavior not stated here. Mark unclear requirements as **Needs engineer review**. Return test ideas first, then draft code only after the test cases are reviewed.Editable fields: function_behavior, test_framework
Guide section
Human checkpoints, escalation triggers, stop conditions, and ownership
AI-assisted code should move through normal engineering controls, not around them.
Human checkpoints
- Engineer decision owner: code understanding, implementation choices, tests, security review, and pull request readiness.
- Tech lead or reviewer decision owner: architecture fit, maintainability, review approval, and merge decision.
- Security owner decision owner: threat-model review, vulnerability handling, incident response, and security exceptions.
- Before using AI: remove secrets and confirm the tool is approved for the code or context.
- Before merging: run tests, scans, linting, dependency checks, license checks, and peer review.
- Before deployment: confirm release controls, monitoring, rollback, and incident response paths.
Escalation triggers and stop conditions
- Stop if the prompt would expose credentials, private keys, customer data, production logs, security findings, or confidential code in an unapproved tool.
- Escalate if the change touches authentication, authorization, cryptography, payments, personal data, infrastructure, or incident response.
- Stop if generated code introduces unsafe dependencies, insecure patterns, unreviewed licenses, or unclear provenance.
- Escalate if AI output conflicts with secure development standards or repository policy.
- Stop if tests do not cover failure modes, edge cases, and expected behavior.
- Escalate if an AI-enabled feature may be vulnerable to prompt injection, data leakage, excessive agency, or insecure output handling.
Guide section
Skills to build, first-week experiment, and questions to ask
The safest first use of AI in software work is bounded, testable, and easy to review.
Skills to build
- Domain knowledge: understand the product, architecture, user needs, failure modes, and operational constraints.
- Verification: read the generated code, run tests, inspect behavior, and confirm assumptions.
- Communication: write clear pull request notes, security caveats, and documentation for reviewers.
- Judgment: know when a task is safe to draft and when security, architecture, legal, or incident review is needed.
- Privacy and security: protect secrets, logs, customer data, infrastructure details, and security findings.
- Workflow thinking: connect prompt, code, tests, review, dependency checks, deployment, monitoring, and rollback.
- Licensing and provenance: review generated code, dependencies, snippets, and attribution obligations.
Playbook
First-week experiment: generate test ideas, not production code
Goal: Improve test coverage for one small, non-sensitive function. Preparation: Use an approved tool, a branch, expected behavior, and no secrets or production data. Steps: ask for test ideas, review the list, write tests locally, run them, add missed edge cases, and document AI errors. Success measures: better edge-case coverage, clear test names, no exposed secrets, and no bypassed review. Stop conditions: code cannot be shared, the function touches security or personal data, AI invents requirements, or tests assert the wrong behavior. Reflection: Which test ideas were useful? Which were wrong? What review step mattered most? What kinds of code should require security review first?
- Keep AI use in a non-production branch.
- Run the full relevant test suite.
- Document AI-assisted work if policy requires it.
- Do not merge without normal review.
Questions to ask your employer
- Which AI tools are approved for source code, logs, tickets, architecture notes, and documentation?
- What code, credentials, data, logs, or security details may never be shared with AI tools?
- How should AI-assisted code be disclosed in commits, pull requests, or records?
- What licensing and provenance checks are required for generated code and dependency suggestions?
- What testing, scanning, threat modeling, and code review steps are required before merge?
- Can AI agents modify repositories, open pull requests, run scripts, or touch infrastructure?
- What deployment controls, monitoring, rollback, and incident response steps apply?
- Who is accountable if AI-assisted code introduces a defect, vulnerability, licensing issue, or incident?
Avoidable errors
Common mistakes and better approaches
Shipping generated code because it compiles.
Better approach: Review, test, scan, and understand the code before merge or deployment.
Pasting secrets or private logs into an unapproved tool.
Better approach: Remove secrets and use approved secure systems.
Accepting dependency suggestions without review.
Better approach: Check license, maintenance, vulnerabilities, provenance, and approval.
Using AI to bypass code review or security review.
Better approach: Use AI to prepare review questions; keep accountable review intact.
Assuming AI understands the system architecture.
Better approach: Provide bounded context and verify against the actual system.
Remember this
Key takeaways
- AI-assisted code is untrusted until reviewed and tested.
- Never expose secrets, private code, logs, or customer data to unapproved tools.
- Tests generated by AI can test the wrong behavior.
- Dependency and licensing review still matter.
- Prompt injection and insecure output handling matter for AI-enabled features.
- Secure development practices should become stronger, not weaker.
- Engineers own understanding, deployment readiness, monitoring, and rollback.
Questions readers ask
Frequently asked questions
Can AI write production code?
AI can draft code, but production code still needs human understanding, tests, peer review, security review, dependency checks, licensing review, and deployment controls.
Can I paste company code into an AI tool?
Only if the tool and workflow are approved for that code. Confidential code, secrets, logs, architecture details, and security findings may be sensitive.
Can AI help debug?
Yes, it can suggest hypotheses and diagnostic steps. Engineers still need to reproduce the issue, protect logs, verify root cause, and test the fix.
What is prompt injection?
Prompt injection is when an input tries to manipulate an AI system’s instructions or behavior. It is especially important when AI features read user content, documents, web pages, or tool outputs.
Does AI remove the need to learn programming fundamentals?
No. Fundamentals are needed to understand generated code, judge tradeoffs, find bugs, test behavior, and protect users.
Sources and review notes
Sources were accessed on the dates shown. Links open the original organization’s page.
- SRC-05Software Developers (15-1252.00)U.S. Department of Labor, O*NET OnLine · Accessed 2026-06-20
- SRC-06Software Developers, Quality Assurance Analysts, and Testers: Occupational Outlook HandbookU.S. Bureau of Labor Statistics · Published 2025-08-28 · Accessed 2026-06-20
- SRC-09Generative AI and Jobs: A global analysis of potential effects on job quantity and qualityInternational Labour Organization · Published 2023-08-21 · Accessed 2026-06-20
- SRC-10AI and workOrganisation for Economic Co-operation and Development · Accessed 2026-06-20
- SRC-12Artificial Intelligence Risk Management Framework (AI RMF 1.0)National Institute of Standards and Technology · Published 2023-01-26 · Accessed 2026-06-20
- SRC-13Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence ProfileNational Institute of Standards and Technology · Published 2024-07-26 · Accessed 2026-06-20
- SRC-19SP 800-218, Secure Software Development Framework (SSDF) Version 1.1National Institute of Standards and Technology · Published 2022-02-03 · Accessed 2026-06-20
- SRC-20OWASP Top 10 for Large Language Model ApplicationsOWASP Foundation · Accessed 2026-06-20
- SRC-21Cybersecurity FrameworkNational Institute of Standards and Technology · Accessed 2026-06-20
- SRC-25Copyright and Artificial IntelligenceU.S. Copyright Office · Accessed 2026-06-20
- SRC-26GPTs are GPTs: An Early Look at the Labor Market Impact Potential of Large Language ModelsOpenAI, OpenResearch, and University of Pennsylvania authors via arXiv · Published 2023-08-21 · Accessed 2026-06-20