Competences and Developing the Developer

Every chapter of this book so far has asked something of the developer: state the intent before opening the draft, read the change before approving it, write the oracle from the specification, know the delegation profile, be able to revert what you merged. This chapter asks what the developer must be able to do in order to meet those demands, how an organisation can know that the developer can do it, and how developers are developed when the work that once developed them is changing. It concerns all five developer functions, D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward, because competence is the condition of each of them. A developer who cannot turn a vague request into testable criteria cannot frame; one who cannot read a generated change cannot prove; one who has never reverted a release cannot steward.

The claim of the chapter is narrow and meant to be tested. The competence of a developer is a claim that needs evidence (Chapter 4), and the evidence that serves is a record of judgement exercised, assessed by someone outside the developer's line, dated and with an expiry, not a record of attendance or of tool use. The chapter sets out six groups of competence, the AI literacy duty of the AI Act and what an organisation can reasonably record to meet it, the kinds of evidence that support a statement about each group, the frameworks that can carry the baseline, the career ladder that rests on the evidence, the hiring practice that uses the same groups, and a competence record for a mid-level developer at Nordvik Region.

Developer competence: six groups, evidence, the record, the ladder and hiring

Figure 27.1: Developer competence: six groups, evidence, the record, the ladder and hiring. Evidence of judgement exercised, assessed by a second assessor, produces the competence record, which sets the development plan and opens the next rung; hiring uses the same groups and rubric; attendance and acceptance rates are bounded out.

What this chapter builds on

The chapter takes over five conclusions. Architecture as Code (Chapter 18) managed competence as a skills matrix by level, Foundation to Expert, and held that practical demonstration on real delivery shows capability (161, Nordqvist, 2025). AI Governance, Chapter 14, held that careers need a path between building and verifying and that assessment results are personal data whose use is agreed with employee representatives (162, Nordqvist, 2026). The Transformed Security Architect, Chapters 15, 21 and 22, held that keeping a craft is a design decision and that competence is evidenced by records of judgement exercised (166, Nordqvist, 2026). AI Operations, Chapter 26, gave the manual-practice interval of 90 days, the rule that the lower of the assisted and the unaided result governs, and the rule that a Level 3 class drops to Level 2 when fewer than two people hold current evidence (170, Nordqvist, 2026). AI Leader, Chapter 27, set out the competence record assessed by a second leader (174, Nordqvist, 2026).

The competence profile

The AI Act states competence as a property of a person who can be asked to show it. A deployer must assign human oversight of a high-risk AI system to natural persons who have the necessary competence, training and authority, and give them the necessary support (Article 26(2)); the provider must build the system so that those persons can remain aware of the tendency to rely automatically on its output (Article 14(4)(b)) (1, European Union, 2024). The wording shows what a regulator reads as competence: something a named person can demonstrate.

No research-based taxonomy of developer competence for a workplace that uses AI broadly has been tested against outcomes. The six groups below are the book's own synthesis, derived from the demands of Chapters 5 to 26, and they are labelled as a proposal. They are not new functions. Each is the competence that a function demands once AI takes part in the work.

Competence group What the developer can do Functions served
Frame and specify Turn a request into a problem statement, acceptance criteria and the questions that are still open, before opening any draft D1 Frame
Design and system thinking State constraints, interfaces and trade-offs; write the decision record; say what a proposed design breaks elsewhere D2 Design
Read, review and verify Read unfamiliar code; review a change, generated or not, from a first judgement; write the oracle from the specification D3 Build, D4 Prove
Delegate and bound Write a delegation profile and mandate; name the ceiling, the credentials, the stop and who holds it; see when evidence no longer supports a level D3 Build, D5 Steward
Steward Own a component so that it passes Name, Understand and Revert; operate it, revert it, carry its history D5 Steward
AI literacy for the role Know what the tools in one's own area do, what they were tested on, how they fail and what may not be delegated all five

Frame and specify

Framing is the competence of Chapter 5: to say what problem is being solved, for whom, with what acceptance criteria and which open questions, in a form that a person who did not hear the request can test. The exercise that evidences it is to take an ambiguous ticket and produce, without a draft from an assistant, the criteria, the questions to the product owner and the cases the ticket does not mention. The first statement is the developer's, because an assistant given a vague request will produce a fluent answer to a question nobody checked was the right one.

Design and system thinking

Design competence, in the sense of Chapter 6, is the ability to hold the whole in mind: which interfaces a change touches, which constraint it relaxes, what it costs in operation and what the alternatives were. It is evidenced by decision records that state options and reasons and by the developer's ability to explain them without opening the tool. The developer who cannot see the design cannot tell when a plausible generated change violates it.

Read, review and verify

This group carries the most weight in the book, and the evidence that supports the need for it is the most direct. A controlled experiment on security tasks found that participants with access to an assistant based on a code model wrote significantly less secure code than those without, and were more likely to believe their code was secure (34, Perry et al., 2023). The study used one model generation and defined tasks, and it is a statement about that set-up, not about every tool. In a randomised study of 16 experienced open-source developers working on 246 tasks in mature repositories they knew, allowing AI tools increased the time to complete a task by 19 per cent, while the developers had expected a reduction of 24 per cent and afterwards believed they had saved 20 per cent (63, Becker et al., 2025). The setting is narrow, the tools are of early 2025, and the result is not general. What both studies bear on is the competence: belief about one's own work with an assistant is not a reliable instrument, so the developer's own sense of having verified a change cannot be the evidence that it was verified.

The same point comes from outside software. In a preregistered experiment with 758 consultants, those using a general-purpose model did better on tasks inside its capability and were 19 percentage points less likely to produce a correct solution on a task chosen to lie outside it (81, Dell'Acqua et al., 2023). A systematic review of 106 experiments with 370 effect sizes found that human and AI combinations performed on average worse than the better of the human alone or the AI alone, with losses in decision tasks and gains in content creation tasks that were not statistically significant on their own (90, Vaccaro et al., 2024). Neither study measures developers reviewing code. They support the book's conclusion that the developer cannot learn by feel where the frontier of a tool lies, because output reads equally well on both sides of it, and that verification has to be practised and evidenced as a skill of its own.

Delegate and bound

Delegation design is the competence that Chapters 4 and 8 treat as an artefact. The developer writes or reads a delegation profile, can say why a class stands at Level 1 and not Level 2 and what evidence would move it, and knows the stop and who holds it. The Level 4 prohibitions are part of the competence: a developer who can be persuaded that an agent may change its own test oracle, or merge to a production branch past a gate the change can alter, has failed the test however the proposal was argued.

Steward

Stewardship is the competence of Chapters 11 and 12: to be the named owner of a component, to understand it well enough to explain a change to it, and to revert a release without the author present. The evidence is practical: a revert drill, an unaided explanation of a module, a record of ownership that names a living person.

AI literacy for the role

AI literacy for a developer is more specific than a general course. It is the knowledge of what the coding tools in the developer's own area were evaluated on, what that evaluation did not measure, and the classes of failure that the estates of the two organisations have already shown: a secret pasted into an unapproved assistant (INC-NR-2030-0071), a dependency name that did not exist in the registry (FND-HM-2030-0012), and a share of AI-assisted lines that differed by measure (Chapter 20). The next section takes the legal duty.

AI literacy under Article 4

Article 4 of the AI Act, as adopted in 2024, obliged providers and deployers to take measures to ensure, to their best extent, a sufficient level of AI literacy of their staff and of other persons dealing with the operation and use of AI systems on their behalf, taking into account their technical knowledge, experience, education and training and the context of use (1, European Union, 2024). Regulation (EU) 2026/1744, the Digital Omnibus on AI, replaced it with a duty to take measures to support the development of AI literacy, which does not require them to guarantee a specific level for any individual (5, European Union, 2026). The Commission's non-binding guidance on Article 4 states that no certificate is needed, that an organisation may keep an internal record of trainings and other guiding initiatives, that levels and approaches may differ with the target group, and that relying on the instructions for use alone is not sufficient (97, European Commission, 2026).

Three implications follow, and they are the book's reading, not legal advice. First, Article 4 sets a duty of measures and not a level, so an organisation that records measures meets the letter of it without learning whether any developer can do anything. Second, the duty applies to developers in two capacities, as persons who use AI systems on the organisation's behalf (every developer with a coding assistant) and, where the organisation builds AI systems, as persons who operate and develop them. The guidance's remark that instructions for use alone are not sufficient is a reason for role-specific content. Third, the stronger duties sit elsewhere: Article 26(2) for persons assigned oversight, and, for Hansa Mutual, Article 13(6) of DORA, which requires financial entities to develop ICT security awareness programmes and digital operational resilience training as compulsory modules in staff training schemes, with a level of complexity matched to the functions of the staff concerned (2, European Union, 2022). A developer-specific module on secure use of coding tools, dependency provenance and secrets is the natural content of that training for a group developer.

The practical rule for both organisations is to treat Article 4 as the floor and the competence record as the instrument. The floor is a recorded measure for every developer: a role-specific module, the instructions for the tools in use and the team's delegation profile. The AI literacy group of the record is where the two meet: the entry says what the developer demonstrated about the tools in their own area, not that a module was completed.

Evidence of competence

An organisation that says its developers are competent is making a claim with a scope, a method, a date and a result, or it is making no claim (Chapter 4). The competence record is the form in which the claim is kept. Its design follows from three observations.

Attendance is not competence, and neither is tool use. A meta-analysis of leadership training, covering 335 independent samples, found positive effects on learning, transfer to behaviour and results on average, and found that the design features associated with stronger effects were needs analysis, feedback, practice, spaced sessions and face-to-face delivery that was not self-administered (111, Lacerenza et al., 2017). It concerns leaders, not developers. The book's reading is that what separates training that works from training that is merely completed lies in practice, feedback and transfer, which a completion record cannot show. Tool use is a weaker proxy still. An acceptance rate or a count of assisted lines measures how often a suggestion was taken, not whether the developer could have written, judged or reverted the code (Chapter 20), and a record that used it would also turn a competence record into a monitoring instrument (Chapter 22).

Evidence must separate assisted from unaided performance. The series states the principle for operators, architects and leaders: where both figures exist, the lower governs (170, Nordqvist, 2026). The research behind it describes the decay of unaided performance under sustained aid in other domains: pilots' retention of manual flying skills in automated cockpits (64, Casner et al., 2014) and mathematics students who performed worse once an unguarded aid was removed (66, Bastani et al., 2025). For programming, a preregistered preprint of 52 participants with more than a year of Python experience found a quiz score 4.15 points lower in the assisted group on a 27-point quiz taken without assistance, and found that the patterns of use mattered: those who asked conceptual questions or asked for code with explanations scored 65 per cent or higher, while those who delegated the code or relied on the assistant for debugging scored between 24 and 39 per cent (67, Shen & Tamkin, 2026). The studies differ in population, task and period, and the last is small and not peer reviewed. They support the label observable for the statement that unaided performance can fall after sustained aid, and the design rule that evidence is collected in both conditions.

Confidence is not evidence. A survey of 319 knowledge workers who shared 936 first-hand examples found that higher confidence in the AI was associated with less critical thinking, and higher confidence in one's own ability with more; the data are self-reported and cross-sectional (82, Lee et al., 2025). Together with the developers' forecasts and beliefs above (63, Becker et al., 2025), this is the reason why a competence record cannot be built from self-assessment alone.

Evidence expires. A record true in January says little about a developer in July who has not done the task since. This chapter uses 90 days for the competences that decay with disuse, reading and verification without the tool, and 180 days for the revert drill, the ownership explanation and the AI literacy entry, and one year for those whose structure does not decay as fast, such as framing and design records. The intervals are the book's choice, not findings, and Chapter 20 gives the defaults for adoption claims (90 days for usage, 180 days for value).

The kinds of evidence that follow are few, and each answers a different question.

Evidence What it shows What it cannot show Typical expiry
Seeded-defect review: a change with a known number of defects, reviewed with and without the assistant's comment visible Whether the developer finds defects, and whether the assistant's comment changes what is found Review on real changes under delivery pressure 90 days
Oracle from a specification: tests written before reading any draft, then compared with the assistant's Framing and independent checking Whether the specification was good 1 year
Unaided explanation: the developer explains a module or a past change in writing without opening the tool Understanding (the second test of stewardship) Whether the understanding is correct, unless the assessor knows the module 180 days
Revert drill: the developer reverts their own change in the test environment, outside the pipeline's helper, within an agreed time Revert (the third test) Behaviour under real pressure 180 days
Decision record sample: the assessor reads a sample of the developer's records of options and reasons Design judgement, dissent recorded Whether the record matches practice 1 year
Delegation explanation: the developer says without the profile open why a class stands at its level and who holds the stop Delegation design Whether the developer would hold the line under pressure 1 year
Self-assessment, acceptance rate, completion of a module The developer's view; the tool's use; attendance Competence not evidence

The second assessor matters. A record assessed by the developer's line manager alone is exposed to the pressures that make appraisal unreliable in any organisation, and a record assessed by an assistant is exposed to the failure the book keeps naming, the check that shares the failure modes of what it checks (Chapter 4). The assessor is a developer, a test engineer or a quality engineer outside the developer's line who has passed the same test. The assistant may prepare the exercise, for instance by drafting the seeded change, and the assessor checks the list of defects and holds it. The assistant does not assess.

The record is personal data

A competence record about a named developer is personal data, and the purposes and readers must be stated and kept to. Article 5(1)(b) of the GDPR requires that personal data are collected for specified, explicit and legitimate purposes and not further processed in a manner incompatible with them, and Article 88 allows Member States and collective agreements to provide more specific rules for employee data (4, European Union, 2016). In Germany, section 87(1) no. 6 of the Works Constitution Act gives the works council a right of co-determination on technical devices designed to monitor the behaviour or performance of employees (9, Germany, n.d.); in Sweden the Region negotiates before an important change under the MBL pattern. Chapter 22 treats the agreements. The rule for this chapter is that the record states what it is not used for, lists its readers, excludes coding-tool telemetry on a named person, and is agreed with the representatives before the first record is written. A record the subject has not seen and answered is not valid.

Frameworks

Four frameworks are in common use in European organisations for competence in digital work. None was written for a developer who works with AI broadly, and each is useful for a part.

The European e-Competence Framework, EN 16234-1, describes competences for ICT professionals in five areas, PLAN, BUILD, RUN, ENABLE and MANAGE, with 41 competences and five proficiency levels (23, European Committee for Standardization (CEN), 2019). It is a vocabulary for what a developer post requires and the natural reference in Hansa Mutual's group entities. SFIA 9 defines seven levels of responsibility, from Follow to Set strategy, inspire, mobilise, described in terms of autonomy, influence, complexity and accountability (59, SFIA Foundation, 2024). Its levels of responsibility describe in general terms what the book calls ownership. The European Digital Competence Framework for Citizens, DigComp 3.0, published in November 2025, describes what is needed to be digitally competent in society and is technology-neutral and non-prescriptive (112, Cosgrove & Cachia, 2025); it serves as a baseline of what any employee, including a developer, may be assumed to be able to do, and as a common vocabulary when a public authority sets the floor for its whole workforce. The ENISA European Cybersecurity Skills Framework gives role profiles for cybersecurity professionals (58, ENISA, 2022), and serves for the security-critical paths where a developer's work meets a security role.

The mapping this chapter uses is the book's own and not an official equivalence. The six groups are anchored in observed evidence at four levels, Foundation, Practitioner, Advanced and Expert, and an organisation that uses SFIA or e-CF may record next to each level the framework level that the developer's post carries. The AI Board is to adopt recommendations under Article 4(3), as replaced, taking into account European competence frameworks, according to the Commission's guidance (97, European Commission, 2026). The sensible reading is that an organisation does not need its own taxonomy to meet Article 4 and should not pretend that an external one covers the work of reviewing generated code. It adopts a framework for the baseline, uses the six groups for what the framework does not cover, and records which is which.

Career ladders

A career ladder is the published description of what a developer must show to move from one rung to the next, and it is the place where competence meets pay. Two problems arise when AI takes part broadly. The first is the rung. The entry tasks that once led from junior to mid-level, small defects, tests for existing code, chores, are the tasks assistants perform best (Chapter 13), so tenure no longer guarantees exposure. The second is the gate. If promotion depends on years in post, a developer can reach the gate having done the years and not the work. The design answer of this chapter, which is a conclusion and not a finding, is to move the gate from tenure to evidence: a developer is considered for the next post when the competence record shows current evidence at the level the post requires in the groups the post requires, assessed by a second assessor. A shorter tenure with evidence is better than a longer one without.

The ladder has three further requirements. It must keep a technical track that does not end in management, with rungs for the senior developer (Chapter 14) and above, so that a developer who is good at review and stewardship is not promoted out of it; the series has held since Architecture as Code that dual-ladder careers keep experts on technical tracks (161, Nordqvist, 2025). It must carry the path between building and verifying that AI Governance proposed (162, Nordqvist, 2026), so that the review and oracle work of Chapters 9 and 14 counts as advancement and not as a detour. And it must satisfy the law on pay structures. Directive (EU) 2023/970 requires that pay structures enable the assessment of whether workers are in a comparable situation in regard to the value of work on the basis of objective, gender-neutral criteria, which shall include skills, effort, responsibility and working conditions and shall not be based directly or indirectly on workers' sex (Article 4(4)) (138, European Union, 2023). A criterion such as the share of AI-assisted lines is neither a skill nor a responsibility. It is the kind of measure that the works agreements of both organisations rule out, and the ladder should state the groups and levels instead.

An evidence ladder makes the supply of seniors measurable: the board can ask how many developers hold current evidence at Practitioner or above in each group for each critical component, against the posts that will fall vacant in the next two years, and not how many seats a programme filled.

Hiring and interviewing

Hiring uses the same groups with the same rubric. A developer hired from outside has no record in the organisation, and the interview is the first evidence. The question for this section is what an interview can show when candidates use assistants, and what the research on selection says.

The best-supported general finding is that structure helps. A re-estimation of the validity of selection procedures, which corrected for the overcorrection for range restriction in earlier meta-analyses, reported lower validity estimates than before and found structured interviews to be the top-ranked procedure (136, Sackett et al., 2022). It concerns personnel selection in general and not developers. The specific finding on technical interviews is about stress. In a randomised trial with 48 computer science students, performance on whiteboard coding tasks was reduced by more than half when an interviewer was watching, compared with solving privately, and stress and cognitive load were significantly higher in the watched condition; the authors argue that such interviews can mix performance anxiety into the assessment of problem solving (137, Behroozi et al., 2020). The sample was students and the task a whiteboard, so the result is a caution about a format and not a measure of a profession.

No study known to this book has measured the validity of any interview format for developers who will work with AI assistants. That absence is stated plainly, and the design below is the book's own reasoning from the groups, labelled expected until tested.

The interview has three parts. In the first, the reading and review exercise, the candidate reviews a change of about 60 lines with a stated number of seeded defects, once with and once without a comment from an assistant, and says what would need to be true for the change to merge. It shows the group read, review and verify directly and tells the panel whether the assistant's comment changes what the candidate finds. In the second, the framing exercise, the candidate receives an ambiguous ticket and writes the acceptance criteria and the questions to the product owner; it shows frame and specify. In the third, a structured interview asks every candidate the same questions about past work, with a rubric anchored on observable behaviour: a decision they reversed, a change they could not explain, a time they declined to approve. The candidate may use an assistant in the framing exercise if the panel records how, since use is a thing to see, and not in the first part, so that unaided and assisted figures can be compared.

Three rules protect candidates. The panel does not use an AI system to filter, rank or evaluate candidates: a system intended for the recruitment or selection of natural persons, including filtering applications and evaluating candidates, is a high-risk AI system under Annex III, point 4(a), of the AI Act (1, European Union, 2024), and both organisations choose not to add that obligation for a gain nobody has measured. The interview is conducted privately or with a retrospective explanation, not under watch, where the format permits, following the finding on stress. And the selection guidelines are agreed with the representatives: in Germany, section 95 of the Works Constitution Act makes guidelines on personnel selection in hiring subject to the consent of the works council (148, Germany, n.d.).

A competence record

Practical guide: writing a competence record and development plan for a mid-level developer

Purpose. Give an organisation a record of what a named developer can do, on evidence, for development and for the planning of the route to the next rung, not for ranking, pay setting or discipline.

Roles. The developer is the subject and reads the record first. The tech lead sponsors it. A second assessor from outside the line assesses, usually a quality engineer or a test engineer. A mentor outside the line follows the plan. The engineering manager owns the plan and its time. HR owns the format and the retention. The employee representatives are informed or consulted as the law of the entity requires. The data protection officer checks the purposes and the readers.

Inputs. The role charter (ROLE-*) and the team's delegation profile (DLG-*); the chosen framework for the baseline; the last record, if any; samples of the developer's decision, specification and review records; the seeded changes prepared for the exercises.

Steps.

  1. State the purposes, the readers and what the record is not used for, and record the agreement with the representatives in a decision record before the first assessment.
  2. Choose the groups the post needs. A mid-level developer needs all six at Practitioner; a platform engineer or tech lead may weight them differently, which the charter states.
  3. For each group choose the evidence from the table above and agree with the developer what is assessed and when. The assistant may draft the exercise and does not assess.
  4. Run the exercises. The second assessor observes or checks and writes what was seen. Where an assistant took part, record the result with and without it.
  5. Set the level per group from the lower of the assisted and the unaided evidence, and state the evidence date and the expiry.
  6. Record the developer's comment. Set the development plan: one or two gaps, the means, the date, and protected time.
  7. Review at expiry. A group whose evidence has lapsed is shown as lapsed, not as the last level reached.

Artefact. The record CMP-* in version control with access limited to its stated readers.

Worked example: CMP-NR-2030-DEV-01

Illustrative. Sofia Hedlund is a mid-level developer in the integration and data team of Nordvik Region, five years in the Region, working on the gateway to the national registers under the tech lead Anders Falk. Her post is ROLE-NR-DEV-03 (mid-level developer, a new charter in the series of ROLE-NR-DEV-01 for the senior and ROLE-NR-DEV-02 for the junior). She uses the pilot assistant NR-DEV-001. The purposes and readers of competence records were agreed within the negotiation MBA-NR-2030-03 (Chapter 22) and recorded as AIDR-1127, dated 2030-12-09. The quality engineer Saga Edvardsson assessed the groups on verification and the revert drill; the Region's enterprise architect read the specification and decision samples.

# competence/records/CMP-NR-2030-DEV-01.yaml (illustrative)
competence_record:
  id: CMP-NR-2030-DEV-01
  person_ref: NR-EMP-31877
  role: ROLE-NR-DEV-03               # mid-level developer, integration and data team
  decision: AIDR-1127                # purposes and readers, 2030-12-09
  delegation_profile: DLG-NR-DEV-01
  assessed_on: 2031-01-28
  assessors: [saga_edvardsson_quality_engineer, enterprise_architect]
  purposes: [development_plan, input_to_ladder_step]
  not_used_for: [ranking, pay_setting, disciplinary_process, tool_telemetry]
  readers: [record_subject, mentor, tech_lead, head_of_applications_and_integration]
  framework_baseline: {digcomp: "3.0 baseline for all staff", sfia_responsibility_level: 3}
  groups:                            # the lower of assisted and unaided evidence governs
    - {id: frame,     level: practitioner, evidence_date: 2030-12-12, expires: 2031-12-12,
       evidence: "ambiguous register-lookup ticket: 9 criteria and 4 questions written before any draft; 3 of 4 questions changed the scope"}
    - {id: design,    level: practitioner, evidence_date: 2030-12-16, expires: 2031-12-16,
       evidence: "3 decision records sampled: options and reasons present in 3, dissent in 1"}
    - {id: verify,    level: foundation,   evidence_date: 2031-01-14, expires: 2031-04-14,
       evidence: "seeded change, 5 defects: 4 found unaided, 3 found with the assistant comment visible (it covered 2 of the 5)"}
    - {id: delegate,  level: practitioner, evidence_date: 2031-01-21, expires: 2032-01-21,
       evidence: "explained without the profile why test is Level 1 and who holds the stop; could not say what evidence would move generate"}
    - {id: steward,   level: practitioner, evidence_date: 2031-01-21, expires: 2031-07-20,
       evidence: "reverted her own change in the test environment in 22 minutes against 30 agreed; unaided explanation of the gateway module: 1 gap"}
    - {id: ai_literacy, level: practitioner, evidence_date: 2031-01-28, expires: 2031-07-27,
       evidence: "stated what NR-DEV-001 was measured on (31 per cent acceptance, survey of 9 of 12, no delivery time) and 2 failure classes"}
  findings:
    - "Strong framing; the questions she asks change scope."
    - "Verification is the weakest group on the lower of the two figures: the assistant's comment anchored her on 2 of 5 defects."
  subject_comment: "Agrees. Asks for time on real reviews, not another course."
  development_plan:
    - {group: verify, target: practitioner, by: 2031-04-14,
       means: "monthly seeded change; first judgement written before the assistant comment on 1 review in 5; mentor reviews 2 per month"}
    - {group: steward, target: advanced, by: 2031-09-30,
       means: "named deputy owner of the register gateway repository (OWN record); one quarter on the case platform support rotation, shadowed"}
  protected_time: {hours_per_week: 3, from: 2031-02-03, owner: gunilla_roos}

The record does not rank Hedlund. It says that her strongest group is framing and her weakest, on the evidence, is the check she performs most often, and the lower figure came with the assistant's comment in view, the condition under which most reviews are done. The result is one exercise on one day and a claim about that day, not about her. It still bears on the delegation profile: if the human review is the control, the control is as good as the reviewer's figure with the comment visible. The development plan is deliberately small, one gap and one stretch, with time and a date.

Developing the developer

The training research cited above supports the design of the plan: needs analysis, feedback, practice and sessions spread over time (111, Lacerenza et al., 2017), and a meta-analysis of workplace coaching found positive effects on performance and skills (96, Jones et al., 2016). Four instruments follow.

Mentoring with a second assessor. The mentor is a senior developer outside the line who reads the record and reviews real work with the developer. Chapter 13 gave the rule for juniors, and Chapter 14 the budget of the senior's time that mentoring needs.

Seeded-defect drills. A short regular exercise in which the developer reviews a change with a known number of defects is the cheapest source of evidence for verification. The defects are held by the assessor and the exercise is varied so that it cannot be learned by rote. The figure reported upwards is the number of developers with current evidence, not any individual's score.

Days with the assistant off. The practice of AI Operations, Chapter 26: one defined task in the quarter, such as tracing a defect in a legacy module or writing an oracle from a specification, is done with the assistants off, observed or checked by a second assessor (170, Nordqvist, 2026). The purpose is to keep the unaided performance that the Understand and Revert tests rely on. Chapter 28 treats the developer's own mind and how the practice fits with workload.

Rotation. A developer spends a quarter on the support rotation of a service or deputises as owner of a component. Rotation builds stewardship and produces a second evidenced holder, which a Level 3 class needs. The rule of AI Operations applies here: when evidence lapses and a class has fewer than two evidenced holders, the class drops a level (170, Nordqvist, 2026).

Observable, expected, speculation

  • Observable. The AI literacy duty of Article 4, in its form as replaced, and the duty of Article 26(2) to assign oversight to persons with the necessary competence, training and authority are in the text as cited, and the Commission's guidance states that no certificate is needed and that an internal record may be kept. Studies on code security, on experienced developers in their own repositories and on knowledge workers show that belief about performance with an assistant can diverge from measurement, on stated conditions, and that unaided performance can fall after unguarded aid.
  • Expected. That verification competence will appear in job profiles and ladders of organisations that work with generated code, because the delegation profiles of both organisations already make human review the control and a control needs a person who can perform it. That supervisors and auditors, asking what a deployer means by competent oversight, will ask for evidence of what the person can do and not for a list of courses. Both are the book's reasoning from the wording of the instruments and from the practice in other regimes, not a statement of any supervisor's plan.
  • Speculation. That automated assessment of developers, by an AI system scoring pull requests, interviews or tool telemetry, will replace the second assessor. No study known to this book has measured such a substitution; a system that evaluates people at work would fall within Annex III, point 4(b), of the AI Act (1, European Union, 2024); and the stewardship principle makes an assessment of a named person a human decision.

Across the usage modes

The table sets the use of assistants in the development of developers against the usage modes and the highest degree of delegation each has been allowed in the two organisations. The competence record, the level of a person, the assessment and any decision that follows from it concern a named person's work and are not delegated.

Usage mode Use in developing the developer Highest degree of delegation What stays with the developer and the assessor
Mode 0 Ambient AI Completion in the IDE; its setting is recorded for exercises Level 0 Advisory for any assessment purpose Exercises state whether completion is on or off
Mode 1 Enterprise assistant Drafting a seeded change and its defect list Level 1 Assisted The assessor checks the list and holds it
Mode 2 IDE assistant (NR-DEV-001, HM-DEV-001) Explanations and practice tasks, after an attempt is logged Level 1 Assisted The developer writes the first judgement; no assessment by the tool
Mode 3 Agentic tools Preparing an agent-opened pull request as a review exercise Level 1 Assisted The assessor selects and signs the exercise; the agent does not review the reviewer
Mode 4 Built applications (HM-DEV-002, HM-DEV-003) None for assessment; learning aids only if a mandate says so Level 0 Advisory A learning aid that gives answers before an attempt is not used in exercises
Mode 5 Autonomous production agents None (neither organisation has a coding agent at this mode) Not applicable Setting the level of a person, promotion, pay or discipline: not delegated, Level 4 prohibited

Nordvik Region and Hansa Mutual

Nordvik Region ties competence to the grades of the Region's IT pay scale, agreed with the unions (illustrative): developer posts sit in three grades, junior, developer and senior, with the charters ROLE-NR-DEV-02, ROLE-NR-DEV-03 and ROLE-NR-DEV-01. Before 2031 the step from developer to senior depended on years in post and on the head of unit's judgement. Under AIDR-1127 (2030-12-09) the Region adds a record: from the first quarter of 2031 the step is considered on a record showing current evidence at Practitioner or above in all six groups and at Advanced in at least two, assessed by a second assessor from the quality function or the platform team. The IT representative Tomas Ekblad received the template before the first record was written, and the purposes and readers follow MBA-NR-2030-03 (Chapter 22). With 18 developers and 22 consultants whose code the Region reviews only in part, the Region's first board-level measure is the number of its own developers holding current evidence in the verification group, and for the consultants a clause in the next call-off asking suppliers for evidence of the same kind. AIDR-1128 (2031-02-10) sets the interview for the 2031 intake of two juniors as the three-part design above, with no AI filtering of applications.

Hansa Mutual has a group engineering career framework with six levels, from junior at level 1 to principal at level 6 (illustrative): level 1 is ROLE-HM-DEV-02, level 4 ROLE-HM-DEV-01, and the group records next to each level an SFIA level of responsibility, the mapping being the group's own. About 290 developers make the framework a matter of scale. AIDR-1177 (2031-02-04) adds the competence record to the promotion criteria of levels 3 to 5 and fixes its purposes and readers within the developer annex KBV-IT-2024-DEV-01 and the interim agreements, with the Polish and Dutch representatives receiving the same terms (Chapter 22). The first-quarter plan APR-HM-2030-01 of Aylin Demir (Chapter 13) feeds her record CMP-HM-2030-DEV-02 at Foundation level. The Level 3 Bounded class of patch-level dependency updates (MND-HM-DEV-01) now depends on the record: the class stands only while at least two developers in the repositories it covers hold current verification evidence, and drops to Level 2 when they do not. For the policy administration platform SVC-HM-003 the group counts the developers with current evidence in the steward group for each batch component, against the named deputies that AIDR-1164 requires of the senior (Chapter 14); the first count of February 2031 is a count and not a conclusion, since twelve people maintain 6.5 million lines and five are within eight years of retirement. AIDR-1178 (2031-02-11) fixes the group's interview practice: the reading and review exercise, a structured interview, private rather than watched solving where the format allows, selection guidelines agreed with the Betriebsrat under section 95 of the BetrVG, and no AI ranking of candidates.

The comparison shows a trade-off that neither organisation has resolved. A common framework, as at Hansa, gives comparability and a shared floor across entities and risks a form that does not fit a local post. A grade structure tied to a collective agreement, as at Nordvik, fits the post and the law on pay but changes slowly, and the second assessor is harder to find in a team of 18 than in a group of 480.

Summary

This chapter concerned all five developer functions, D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward, through the competence they demand. It proposed six groups, frame and specify, design and system thinking, read, review and verify, delegate and bound, steward, and AI literacy for the role, as the book's own synthesis from the earlier chapters, with Articles 4, 14 and 26 of the AI Act as the legal anchor and Article 13(6) of DORA for financial entities. It argued that the competence of a developer is a claim that needs evidence: a record of judgement exercised, separating assisted from unaided performance, assessed by a second assessor outside the line, dated and with an expiry, and limited by purpose and reader because it is personal data.

The evidence is limited and was labelled. Studies on security tasks, on experienced developers in their own repositories and on knowledge workers show that confidence and belief diverge from measured performance; unaided performance can fall after unguarded aid in other domains and, in a small preprint, in programming. None of it measures a European public authority or an insurer. The frameworks, e-CF, SFIA, DigComp and ECSF, serve for a baseline and a vocabulary; none was written for a developer who reviews generated code. A ladder built on the record moves the gate from tenure to evidence and meets the requirement of Directive (EU) 2023/970 that criteria of work be objective and gender-neutral. Hiring uses the same groups, a structured interview and a reading and review exercise, and does not use AI to rank candidates.

The outlook is labelled. That Article 4 and Article 26(2) set duties of measures and of competent oversight is observable; that verification competence will appear in job profiles and that supervisors will ask for evidence of what a person can do is expected; that automated assessment of developers will replace the second assessor is speculation, and the people class is not delegated. For the reader who wants one thing to do: take a mid-level developer in the team, run one seeded-defect review with the assistant's comment visible and one without, and write the lower figure and its date into a record the developer has read and answered. Chapter 28 turns to the developer's own mind, which this record cannot see: craft, flow, cognitive offloading and the practice that keeps skill alive.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
  2. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (2, European Union, 2022)
  3. European Parliament and Council of the European Union. Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (4, European Union, 2016)
  4. European Parliament and Council of the European Union. Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 (Digital Omnibus on AI). Official Journal of the European Union, 24 July 2026. (5, European Union, 2026)
  5. Federal Republic of Germany. Betriebsverfassungsgesetz (BetrVG), section 87 (Mitbestimmungsrechte). gesetze-im-internet.de. (9, Germany, n.d.)
  6. Federal Republic of Germany. Betriebsverfassungsgesetz (BetrVG), sections 5, 58, 76, 77, 80, 90, 95 and 111. gesetze-im-internet.de. (148, Germany, n.d.)
  7. European Committee for Standardization (CEN) (2019). EN 16234-1:2019 e-Competence Framework (e-CF), Part 1: Framework. (23, European Committee for Standardization (CEN), 2019)
  8. European Union Agency for Cybersecurity (2022). European Cybersecurity Skills Framework (ECSF) Role Profiles. ENISA. (58, ENISA, 2022)
  9. SFIA Foundation (2024). SFIA 9: the global skills and competency framework for the digital world. (59, SFIA Foundation, 2024)
  10. Becker, J., Rush, N., Barnes, E. & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089. (63, Becker et al., 2025)
  11. Casner, S. M., Geven, R. W., Recker, M. P. & Schooler, J. W. (2014). The Retention of Manual Flying Skills in the Automated Cockpit. Human Factors 56(8). (64, Casner et al., 2014)
  12. Bastani, H. et al. (2025). Generative AI without guardrails can harm learning: Evidence from high school mathematics. PNAS 122(26). (66, Bastani et al., 2025)
  13. Shen, J. H. & Tamkin, A. (2026). How AI Impacts Skill Formation. arXiv:2601.20245. (67, Shen & Tamkin, 2026)
  14. Dell'Acqua, F. et al. (2023). Navigating the Jagged Technological Frontier. Harvard Business School Working Paper 24-013. (81, Dell'Acqua et al., 2023)
  15. Lee, H.-P. et al. (2025). The Impact of Generative AI on Critical Thinking. CHI 2025. (82, Lee et al., 2025)
  16. Vaccaro, M., Almaatouq, A. & Malone, T. (2024). When combinations of humans and AI are useful: A systematic review and meta-analysis. Nature Human Behaviour 8(12). (90, Vaccaro et al., 2024)
  17. Jones, R. J., Woods, S. A. & Guillaume, Y. R. F. (2016). The effectiveness of workplace coaching. Journal of Occupational and Organizational Psychology 89(2). (96, Jones et al., 2016)
  18. European Commission. AI Literacy: Questions and Answers. Shaping Europe's digital future, 20 October 2026. (97, European Commission, 2026)
  19. Lacerenza, C. N. et al. (2017). Leadership training design, delivery, and implementation: A meta-analysis. Journal of Applied Psychology 102(12). (111, Lacerenza et al., 2017)
  20. Cosgrove, J. & Cachia, R. (2025). DigComp 3.0: European Digital Competence Framework (Fifth Edition). Joint Research Centre. (112, Cosgrove & Cachia, 2025)
  21. Nordqvist, G. (2025). Architecture as Code. The Architecture as Code Series, Book 1. (161, Nordqvist, 2025)
  22. Nordqvist, G. (2026). AI Governance. The Architecture as Code Series, Book 2. (162, Nordqvist, 2026)
  23. Nordqvist, G. (2026). The Transformed Security Architect. The Architecture as Code Series, Book 6. (166, Nordqvist, 2026)
  24. Nordqvist, G. (2026). AI Operations. The Architecture as Code Series, Book 10. (170, Nordqvist, 2026)
  25. Nordqvist, G. (2026). AI Leader. The Architecture as Code Series, Book 11. (174, Nordqvist, 2026)
  26. Sackett, P. R., Zhang, C., Berry, C. M. & Lievens, F. (2022). Revisiting meta-analytic estimates of validity in personnel selection: Addressing systematic overcorrection for restriction of range. Journal of Applied Psychology 107(11), 2040-2068. (136, Sackett et al., 2022)
  27. Behroozi, M., Shirolkar, S., Barik, T. & Parnin, C. (2020). Does Stress Impact Technical Interview Performance? ESEC/FSE 2020. (137, Behroozi et al., 2020)
  28. Perry, N., Srivastava, M., Kumar, D. & Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? ACM CCS 2023. (34, Perry et al., 2023)
  29. European Parliament and Council of the European Union (2023). Directive (EU) 2023/970 to strengthen the application of the principle of equal pay for equal work or work of equal value between men and women through pay transparency and enforcement mechanisms. OJ L 132, 17.5.2023. (138, European Union, 2023)