Skills Software Developers Need in AI Age
AI is changing software development faster than any technology shift I have witnessed in my career. Developers are no longer responsible only for writing code. Today, we can use AI coding agents such as Codex, Claude Code, GitHub Copilot, and others to analyze requirements, generate code, create tests, review implementations, find bugs, and even execute development workflows.
Andrew Ng recently shared an AI Engineering Skills Map for Using Coding Agents. The above map highlights several important areas:
These are valuable skills. Every software developer who wants to remain relevant should learn them.
However, they are only part of the picture.
Knowing how to operate a coding agent does not automatically mean you know how to build a successful product. AI can help developers produce code much faster, but it cannot compensate for a poorly understood customer, an incorrect workflow, weak product priorities, or a bad architecture.
In fact, AI can make these mistakes more expensive because it allows teams to build the wrong thing at unprecedented speed.
The next generation of AI engineers must learn more than how to prompt an agent. They must understand users, products, workflows, architecture, security, scalability, and business outcomes.
Coding Faster Is Not the Same as Building Better
For decades, software development was limited by the speed at which humans could design, write, test, and deploy code. AI coding agents are removing many of those limitations. A developer can now describe a feature, ask an agent to examine the repository, generate an implementation, create database migrations, write tests, and prepare a pull request. Work that once required several days may be completed in hours.
That sounds like an enormous productivity gain and it can be.
But consider this question:
What happens if the feature should never have been built?
You may save three days of coding while wasting three months building a product customers do not want.
AI increases the velocity of software development, but velocity without direction creates waste. A car moving at 100 miles per hour is useful only when it is traveling toward the correct destination.
Before asking AI to build something, engineers must determine:
Who is the user?
What problem are we solving?
How painful is that problem?
How does the user solve it today?
Where does the current process break?
What outcome does the user actually want?
Is software even the right solution?
What is the smallest useful version we can release?
How will we know whether it is working?
This is why the most valuable AI engineers will not necessarily be the developers who generate the most code. They will be the people who make the best product and architectural decisions before code is generated.
1. Learn How to Direct the Workflow
Andrew Ng’s skills map correctly emphasizes directing the workflow.
A coding agent needs more than a one-line request such as:
Build me a customer relationship management application.
That instruction leaves too much undefined. The agent does not know the intended users, their problems, the business rules, the expected user experience, the integration requirements, or the security constraints.
A better workflow breaks the problem into clear stages:
Understand the business problem.
Identify the users and their goals.
document the current workflow.
Design the improved workflow.
Define requirements and acceptance criteria.
identify technical and business risks.
Create the architecture.
Implement a small, testable increment.
Review and validate the result.
Measure real-world usage before expanding it.
The human should decide what outcome is required. The coding agent can then help determine how to achieve it. AI works best when it receives context, boundaries, examples, success criteria, and feedback. If you provide a vague destination, you should not be surprised when the agent takes the wrong road.
2. Understand Your End Users and Customers
One of the most important engineering skills is rarely taught in computer science programs: understanding the customer. A feature may be technically impressive and still be useless.
Engineers must understand the difference between the customer and the user. In enterprise software, the person purchasing the product may not be the person using it. The buyer may care about compliance, cost, reporting, and control, while the end user may care about speed, simplicity, and reducing repetitive work. You need to understand both.
Meet users. Observe them. Ask them to show you how they work instead of merely asking what features they want. Users often describe solutions based on the systems they already know. Your job is to uncover the underlying problem.
Watch for:
Repetitive manual work
Information entered more than once
Work moving between spreadsheets, email, and disconnected systems
Delays caused by approvals
Tasks users regularly forget
Places where errors are common
Workarounds created outside the official product
Features that exist but are rarely used
Decisions users cannot make because information is missing
These observations are often more valuable than a long feature-request list.
3. Become a User of the Product
Software architects and developers should use the products they build. I do not mean opening the application occasionally to confirm that it loads. I mean completing the same workflows real users must complete. Create an account. Configure the product. Import data. Perform the primary task. Make a mistake. Recover from it. Use the product on a mobile device. Try it with slow internet. Return after several days and see whether the interface still makes sense.
When you become a user, you discover problems that rarely appear in requirements documents:
Too many steps
Confusing terminology
Missing confirmation messages
Poor navigation
Unnecessary data entry
Weak error recovery
Slow screens
Inconsistent behavior
Notifications that arrive too late
Features that work individually but fail as a complete journey
Dashboards and analytics tell you what users do. Using the product helps you understand why they struggle. If the engineering team does not enjoy using its own product, customers probably will not enjoy it either.
4. Decide Which Features to Launch and When
One of the biggest product mistakes is trying to launch everything at once. AI makes this temptation worse because generating another feature appears cheap. However, every feature creates long-term costs:
The cost of a feature is not limited to building it. The real cost is owning it for years.
Teams should prioritize features by asking:
Does this solve a core customer problem?
How frequently will customers use it?
Does another feature depend on it?
What risk does it introduce?
Can we validate the idea without fully building it?
Does it help users reach the product’s primary outcome?
What happens if we postpone it?
What evidence supports the demand?
Your first release should complete one important workflow exceptionally well. It does not need to contain every possible feature. A minimum viable product should not be a collection of incomplete screens. It should be the smallest product that delivers a meaningful outcome from beginning to end.
5. Brainstorm With AI Before Building With AI
Many developers use AI as an assistant tool. They decide what they want, write a short prompt, and immediately ask the agent to generate code. That skips one of AI’s most valuable roles: becoming a thinking partner. AI is more than a code generator. AI can brainstorm and discuss your requirements with you, can suggest what users may want, discuss and review architecture. security, and scalability.
Before building anything, use AI to challenge the idea.
Ask questions such as:
What assumptions am I making?
What user types have I overlooked?
What could cause this feature to fail?
What edge cases should we consider?
What are three simpler ways to solve this problem?
What should be included in the first release?
Which requirements are ambiguous?
What security threats does this workflow introduce?
Where could performance break at scale?
What should we measure after launch?
What questions should we ask potential customers?
Argue against building this feature.
Do not use AI only to validate what you already believe. Ask it to disagree with you.
A productive AI brainstorming process might include separate discussions from the perspectives of:
AI should help expose weaknesses before they become code.
The cheapest time to correct a software problem is during the discussion. The cost increases after design, rises again after implementation, and becomes much higher after customers and systems depend on it.
6. Validate the Complete Workflow
A feature can work perfectly and still create a broken product.
For example, imagine an AI agent that automatically creates sales follow-up tasks. The feature may successfully create tasks, but the overall workflow may still fail:
Does the agent understand which contacts are important?
Can it distinguish a customer from a personal contact?
Does it create duplicate tasks?
Can the user approve recommendations before messages are sent?
What happens when the available data is outdated?
How does the user correct the agent?
Is sensitive information exposed?
Is every automated action recorded?
Can the user undo an incorrect action?
These are workflow questions, not coding questions.
Before implementation, map the journey from the first user action to the final business outcome. Include decision points, exceptions, approvals, failures, and recovery paths.
The workflow should answer:
What starts the process?
What information is required?
Who or what makes each decision?
Which actions may be automated?
Which actions require human approval?
What happens when data is missing?
What happens when an external service fails?
Can users review, edit, retry, cancel, or undo?
How is the final outcome communicated?
How is every important action audited?
An incorrect workflow becomes expensive because it spreads across the user interface, APIs, database, automation, notifications, reporting, and integrations. Fixing it later may require changing every layer of the system.
7. Enable Agent Autonomy Carefully
Coding agents can now do more than suggest code. They can inspect repositories, run commands, modify files, install packages, execute tests, interact with development tools, and prepare deployments. This autonomy can improve productivity, but it also increases risk. Autonomy should be earned, limited, and observable.
An agent may be permitted to create a branch and run tests without approval, while actions such as changing production infrastructure, deleting data, accessing secrets, or deploying to production should require explicit authorization.
A mature operating model should define:
What the agent may read
What it may change
Which commands it may execute
Which environments it may access
What requires human approval
How secrets are protected
How actions are logged
How changes are reviewed
How failures are contained
How the system can be restored
The correct level of autonomy depends on the task’s risk, reversibility, and impact. Do not give an AI agent unlimited permissions merely to save a few minutes.
8. Review the Work. Do Not Confuse Output With Correctness
AI-generated code often looks convincing. That is precisely why developers must review it carefully. Readable code can still contain incorrect assumptions, insecure implementations, hidden performance problems, missing edge cases, fabricated APIs, or poor architectural decisions.
A qualified engineer should review:
The developer remains accountable for the final result. AI can also help with review. One agent can implement a solution while another review pass looks specifically for security issues, architectural problems, missing tests, or unnecessary complexity. However, AI reviewing AI does not remove the need for human responsibility.
The final question is not, “Did the agent finish the task?” It is, “Does this implementation solve the right problem safely and correctly?”
9. Customize the Agent and Its Environment
Generic instructions produce generic results. A coding agent becomes more useful when it understands the environment in which it is working:
Teams should provide persistent project instructions so developers do not need to repeat the same context in every prompt. However, documentation must remain current. Incorrect instructions can cause an agent to produce consistent but incorrect work at scale.
The agent’s environment should also be controlled. It should have only the permissions, tools, and data required for the task. Development, staging, and production access must remain properly separated.
10. Preserve Software Engineering Fundamentals
The arrival of AI does not eliminate software-engineering fundamentals. It makes them more important. When code becomes inexpensive to generate, poorly designed systems can grow faster than teams can understand them.
AI engineers still need to understand:
Data structures and algorithms
Object-oriented and functional design
APIs and integration patterns
Databases and data modeling
Distributed systems
Cloud infrastructure
Testing strategies
DevOps and observability
Performance optimization
Security engineering
System design
Architectural trade-offs
An AI agent can generate an architecture diagram or recommend a pattern, but engineers must judge whether that recommendation fits the system. Without engineering fundamentals, a developer may accept a complicated solution because it appears sophisticated. Experienced architects often create value by removing unnecessary components, not adding more of them.
11. Design for Scalability but Do Not Overengineer
Scalability should be discussed early, but that does not mean every startup needs a highly distributed architecture on day one.
Architects should identify where growth is likely to create pressure:
The architecture should allow the system to evolve without forcing the team to pay today for scale it may never need.
Start with clear boundaries, a sound data model, stateless services where appropriate, asynchronous processing for long-running tasks, caching for repeated work, and observable performance metrics.
Do not blindly ask AI to “make the application scalable.” Scalability has no meaning without expected workloads, service-level objectives, cost limits, and failure scenarios.
A system designed for one million users may be unnecessary for a product that has not yet acquired its first hundred. At the same time, a prototype with no architectural boundaries may become impossible to evolve.
Good architecture balances present reality with future possibilities.
12. Treat Security as a Design Requirement
Security cannot be added at the end of development. AI-generated applications may introduce vulnerabilities through unsafe dependencies, incorrect authorization, exposed credentials, insecure data handling, or overly broad agent permissions.
Every system should address:
Identity and authentication
Role-based or policy-based authorization
Encryption in transit and at rest
Secret management
Input validation
Data isolation
Dependency security
Audit logs
Rate limiting
Backup and recovery
Incident response
Privacy and data-retention requirements
AI applications introduce additional concerns. What data is being sent to the model? Is customer information included in prompts? Is that data retained? Can malicious content manipulate an agent’s instructions? Can an agent perform actions outside the user’s authority? Can generated output expose private information?
For AI-driven actions, teams should consider human approval, limited permissions, traceability, confidence thresholds, and reversible operations. Security is not a feature. It is a property of the entire system.
13. Learn to Shape What Gets Built
One of the most interesting items in Andrew Ng’s map is “shaping the build.”
This is where experienced engineers, architects, and product thinkers will create the greatest value. Shaping means converting an unclear idea into something that can be built, tested, used, and measured. It includes:
Defining the real problem
Narrowing the scope
Identifying constraints
Modeling the workflow
Resolving ambiguity
Choosing trade-offs
Designing boundaries
Establishing success criteria
Planning incremental delivery
AI agents can participate in this work, but humans must provide judgment. An agent can list ten possible architectures. A software architect must understand which one matches the organization’s team, budget, timeline, risk, and expected growth.
The technically most advanced solution is not always the best solution.
A More Complete Skills Map for AI Engineers
Andrew Ng’s coding-agent skills are an important layer of modern AI engineering. I would expand the map into four broader categories.
1. Customer and Product Skills
Understanding customers and end users
Becoming a user of the product
Identifying high-value problems
Prioritizing features
Planning releases
Gathering feedback
Measuring product outcomes
2. AI Collaboration Skills
Brainstorming with AI
Writing clear instructions
Providing context and constraints
Directing multi-step workflows
Selecting the appropriate model or agent
Managing agent autonomy
Evaluating AI-generated work
3. Software Engineering and Architecture Skills
System design
Data modeling
API design
Testing
Integration architecture
Scalability
Reliability
Observability
Maintainability
Cost management
4. Governance and Risk Skills
Security
Privacy
Compliance
Human approvals
Permission management
Auditability
Failure recovery
Responsible automation
The strongest AI engineers will operate across all four areas.
The New Role of the Developer
The developer’s role is moving from code producer to system director.
Writing code will remain important, but more of the developer’s value will come from:
Asking the right questions
Understanding customers
defining the correct workflow
Breaking large problems into manageable tasks
Directing AI agents
Reviewing generated work
Making architectural trade-offs
Managing risk
Connecting technology to business outcomes
The future does not belong to people who simply type code faster. AI already does that.
The future belongs to people who know what should be built, why it should be built, how it should work, and how to guide AI to build it responsibly.
Final Thoughts
Andrew Ng’s AI Engineering Skills Map provides a useful foundation for developers learning to work with coding agents. Directing workflows, enabling autonomy, reviewing work, customizing environments, and understanding agent foundations are essential skills.
But they are not enough.
Before building anything, understand the customer. Become a user. Validate the workflow. Decide which features matter and when they should launch. Use AI to brainstorm and challenge assumptions. Design for scalability based on realistic needs. Treat security as part of the architecture from the beginning.
AI can make software teams dramatically more productive. It can also help them create the wrong product, with the wrong workflow and the wrong architecture, much faster.
The competitive advantage will not come from having access to a coding agent. Nearly everyone will have access to similar tools.
The advantage will come from judgment.
It will come from understanding people, products, systems, risks, and trade-offs—and knowing how to combine those skills with AI.
That is the real skill map for the next generation of AI engineers.
Join the conversation! Your thoughts help the community grow.