Research / Skills map
The AI-era skills map for software engineers
Which engineering skills AI is automating, which are gaining value, and which stay with people. Our working map, version 0.1.
This is the map Techvisk trains from. It sorts the skills of a software engineer by what AI is doing to their value. It is a working document. We update it as the tools change and as we see how our students perform in real teams.
Read it as our current judgement, not as a measurement. Where we turn out to be wrong, we will change the map and say so.
The map
| Being automated | Gaining value | Staying with people |
|---|---|---|
| Writing routine code from a clear specification | Specifying the system clearly enough for it to be built | Deciding what is worth building |
| Boilerplate, glue code and standard CRUD screens | Data modelling and system architecture | Understanding the business and its users |
| Syntax recall and API lookup | Reviewing and testing AI-generated work | Accountability when something breaks |
| First-draft documentation and test cases | Debugging across system boundaries | Trust with clients, teammates and reviewers |
| Translating code between languages and frameworks | Security, reliability and cost reasoning | Ethical and risk judgement |
How to read it
Being automated does not mean worthless. You still need to read code fluently, the way an editor needs to read prose. It means that being fast at producing this work no longer sets you apart, because the tool is faster.
Gaining value is where the bottleneck has moved. When code is cheap to produce, the scarce things are a correct design to produce it from and a reliable way to tell whether the result is right. Both depend on fundamentals: you cannot model data well without understanding data, or review a concurrency fix without understanding concurrency.
Staying with people covers the work that depends on context, relationships and responsibility. A model can propose. Somebody still has to decide, and answer for the decision.
What this means for training
The middle and right columns are where Techvisk spends its time. We group them into four capabilities:
- System modelling. Data models, architecture, interactions and flows, drawn and defended before anything is built.
- Domain understanding. How the business works and what its rules are, so the software solves the real problem.
- Engineering judgement. Trade-offs, and the ability to catch work that looks right and is not.
- Ownership. Taking a problem to production and standing behind it.
The left column is not ignored. Students use AI tools for that work every day, the way working engineers do. What changes is where the teaching effort goes.
What we are still unsure about
- How fast the middle column moves left. AI tools are getting better at design and review too. We expect the map to shift, and we do not know the pace.
- How juniors build judgement without the routine work. Judgement used to come from years of doing the tasks that are now automated. Our programme replaces that with intensive, questioned project work. Whether that fully substitutes is something we are testing, not something we have proven.
- How much of this is specific to software. We started with engineering because we know it best.
If you work on these questions, or disagree with where we have placed something, tell us.