We all have a professional responsibility to train and educate the next cohort. Reliance on AI might produce an immediate, measurable productivity gain today at the cost of gradually eroding professional judgment. Without proper technical training and continued professional development for both early career and mid/senior-level staff, a skills gap may emerge. While an AI tool could independently produce a technically sound piece of work, a human is always needed to explain it, answer questions, and stand behind it, in front of a client, decisionmaker, or member of the public. This section lays out practical methods to avoid knowledge drain and build understanding, starting with the principles for building understanding followed by key tenets of knowledge retention.
There is also cause for optimism: rather than hindering staff development, AI could accelerate it, letting early career staff shoulder responsibility sooner and learn by observing AI-enabled processes. This view is not wrong, but it is conditional. Observing an AI tool produce work you could not produce or evaluate yourself is not learning; it is spectating. AI accelerates development for those who already have enough foundation to interrogate what they are seeing, and leaves everyone else dependent on tool outputs they don’t know how to verify. The two cases are not in conflict: the optimistic one depends on building competency first, which is what the rest of this section covers.
MnDOT: Pacing AI adoption
The Minnesota Department of Transportation (MnDOT) has treated AI as something to introduce deliberately rather than adopt wholesale. Instead of pushing tools to everyone at once, MnDOT began with training sessions and small pilot projects and built structured opportunities for teams to share what they were learning. Their approach had two distinguishing features. First, agency leaders framed AI as support for staff rather than a replacement for them and paired every application with human oversight. Second, the agency treated caution as a strength rather than a lack of enthusiasm; as its AI program manager put it, it is good for people to be cautious. The transferable lesson is not the specific tools MnDOT selected, but the posture: adoption that is paced so people stay in the loop and accountable, rather than racing to efficiency and discovering the judgment gap only after it has opened (Hanson 2026).
Guiding principles
Interviews with early career engineers revealed that AI is most commonly displacing the self-directed research that used to precede asking a senior engineer for guidance, not replacing that senior conversation itself. Therefore, while AI is accelerating access to knowledge, this is happening with less control from the organization’s experts on what that knowledge is, or if it’s really being understood. The principles below address these situations, and they assume both the junior and the senior staff member are motivated and committed to transferring understanding.
| Principle | What it means |
|---|---|
| Preserve formative friction | Some tasks are worth doing inefficiently because doing them builds the person. The clunky first pass is where conceptual understanding forms. |
| Allow/disallow AI use based on staff learning value, not just AI capability to do the task | Ask not only whether a task is risky for AI, but whether it is developmentally valuable for the person. A task can be low-risk for AI yet high-value to reserve for manual learning. |
| Make mentorship a structured responsibility | As AI erodes the small “go ask someone” moments, make deliberate decisions about how mentorship is budgeted, defined, and accounted for. |
| Document reasoning, not just outputs | As AI generates more of the deliverable, the reasoning behind it risks going uncaptured. Treat reasoning as a distinct, tool-independent record to be discussed and documented. |
| Teach staff to interrogate outputs, not just receive them | An AI's answer arrives fluent, confident, and quietly shaped by how it was asked. Early career staff need to learn that fluency is not accuracy, and that a leading question produces a leading answer. The skill to build is not writing better prompts; it is recognizing when an output may be biased. |
Putting the principles into practice
The ITE AI GIG Pulse Survey showed that most people feel very or extremely familiar with AI whereas a much lower portion feel confident they are using it appropriately. If you haven’t done it the old-fashioned way, you won’t know how to review the work or even how AI can help. The key principle is “do it manually first.” The first step to putting these principles into practice is to formally identify two to three task categories that early-career staff on your team should complete without AI assistance, at least on the first attempt. Below are four examples, which you can use as a starting point to tailor to your specific context.
| Task category | Why it’s developmental |
|---|---|
| Roadway capacity / level of service | Knowing whether a result is plausible requires having built the intuition manually. |
| Plan sets using CAD | You must get into the software and “poke around, trip over your own feet” and draw yourself before you can direct an AI tool effectively. |
| Reading standards to find which standard applies | Cities can often layer their standards on top of state/provincial guidelines such that an AI does not know the inter-relation, where to look, or how to interpret in case of conflict or even typos. |
| Get out in the field | Computers cannot perform all tasks. For many tasks, such as pole placement, visual on-site verification is irreplaceable, and teaching in the field is essential. A feel for the built environment, and observation of what actually happens, can be invaluable. Some tasks, like using aerials for data collection, could be computerized; others may never be. |
The same "do it manually first" logic applies to interrogating AI outputs, except here the manual skill is critical reading rather than technical production. Staff should practice taking an AI output and identifying what would have to be true for it to be wrong: which numbers to trace back to a source, which assumptions the phrasing smuggled in, which passages sound authoritative but are unverified. A simple, repeatable exercise is to have staff ask the same question two different ways and compare how the answers shift. When a change in framing changes the conclusion, that is the lesson, and it is far more memorable than being simply told the tool is biased. The goal is to build the reflex that an AI output is a claim to be checked, not an answer to be accepted.
Knowledge retention
Knowing who to approach for help is critical to facilitate transfer of knowledge through a human network. Trust forms when colleagues surface what they are good at. These acts must be preserved, and beyond presenting orally in group settings, knowledge worth keeping should be recorded in tool-independent form, i.e., not siloed in an AI tool. Avoid locking institutional memory away in a vendor’s chat history, as vendors come and go, and materials can get lost over time.
Mentoring time must be budgeted and preserved. Organizations that assume that efficiency converts automatically into development will be wrong. We are finding that early career staff use of AI may be consuming senior review time, not freeing senior mentorship time. AI also introduces the ability for senior staff to build complex tools and dashboards very quickly and efficiently, bypassing early career staff from their traditional role as builders. Senior staff should work to intentionally delegate the building tasks, even if less efficient, to preserve the knowledge formation that an early career staffer gains by doing.
After implementing the above principles, to see how well it’s going, ask your team:
Sources cited on this page are listed in full on the References page.