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:

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:

  1. Understand the business problem.

  2. Identify the users and their goals.

  3. document the current workflow.

  4. Design the improved workflow.

  5. Define requirements and acceptance criteria.

  6. identify technical and business risks.

  7. Create the architecture.

  8. Implement a small, testable increment.

  9. Review and validate the result.

  10. 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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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

2. AI Collaboration Skills

3. Software Engineering and Architecture Skills

4. Governance and Risk Skills

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:

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.