Reimagining AAS Technical Education for an AI-Integrated Workforce
Following the August 25 National IT Innovation Center BILT meeting discussion on AI literacy knowledge and skills, one of the employer SMEs provided additional remarks on the topic. This is, of course, what every program strives for with their BILT – cultivating employer SMEs so invested in the work that they spend their free time finding ways to support the effort of aligning curriculum with workforce needs. So far, this is the third time a NITIC BILT has submitted written material after a meeting. Most remarkably, in all three instances, this extra work was not solicited. Instead, the BILT members were so invested in the topic and supportive of the work that they decided to start typing.
Read the minutes of that August 25 meeting here.
Mark Richter has spent more than forty years in the information technology space. He specializes in software development for business leaders. Most recently, Mark worked for the IT service management company Hitachi Vantara as a consultant and an IT manager. Prior to that, Mark held positions at technology companies that included Hewlett-Packard and EDS. In addition, for twenty years, Mark held a Project Management Professional certification. He has been engaged with NITIC’s BILT from the very beginning – his involvement with providing workforce guidance to NSF IT grants, in fact, stretches all the way back to 2019 when he first served on the BILT of the “IT Skill Standards” NSF project grant.
Below are Mark’s comments on “AI Literacy.” Notice that after he sent his first overview, he decided to send a second one. NITIC sends him a big thank you!
# # # #
Following Tuesday’s discussion, I have been thinking about the question of how AI should be taught: as a separate course or incorporated into the existing IT curriculum.
I wonder if the more fundamental question is not,
What AI knowledge and skills should we add?
but rather:
How does AI change the workforce outcome the curriculum is intended to produce?
I believe that question raises five related considerations:
– AI changes the nature of entry-level IT work.
– Technical fundamentals remain essential.
– Organizational context, critical thinking, communication, and AI assistance should be developed longitudinally throughout the program.
– AI can extend the capability of an entry-level employee, but it cannot replace professional judgment.
– A capstone should demonstrate that the student can integrate these capabilities in addressing a realistic organizational problem.
In the next two to three years, AI is unlikely to remain a separate technology that an IT professional occasionally uses. It will increasingly become part of the normal workflow for networking, cloud administration, cybersecurity, software development, systems administration, troubleshooting, documentation, and many other technical disciplines.
That suggests an opportunity to reconsider how the 60 credit hours available in an AAS program are used.
Technical fundamentals remain essential. A student cannot effectively evaluate an AI-generated configuration, recognize an inappropriate recommendation, diagnose a failure, or understand a security risk without understanding the underlying technology. Certifications such as CompTIA Network+ continue to provide a useful measure of that foundational knowledge. They demonstrate that a student has learned an established body of technical knowledge, but certification need not represent the full workforce outcome of the program. By graduation, students should also have repeatedly applied that knowledge in situations that increasingly resemble the problems, constraints, and responsibilities they will encounter as entry-level employees.
AI, however, may allow us to raise the level at which an entry-level graduate can operate. Historically, an entry-level IT graduate might be expected to begin primarily as a technician, learning how to perform defined tasks and gradually developing the judgment needed to participate in broader analysis and design decisions. With the right technical foundation, organizational understanding, and critical-thinking skills, AI may allow a graduate to contribute much earlier at something closer to the level of a traditional junior systems analyst: understanding requirements, helping evaluate alternatives, using AI-assisted workflows to develop solutions, and validating whether those solutions satisfy the organization’s needs.
Rather than concentrating primarily on whether a student can independently reproduce every technical procedure, we may be able to place greater emphasis on whether the student can understand the problem being solved, identify and clearly define the relevant requirements and constraints that should drive the assistance they receive from AI and other resources, critically evaluate the result, and communicate the reasoning behind the solution. This requirements-driven assistance model would help students learn to use AI as part of a disciplined technical workflow rather than as an ad hoc source of answers. Most importantly, the student needs to recognize when they need additional expertise from more senior resources.
That begins with something even more fundamental than technology: understanding the organization. An IT graduate should understand that technology exists to support the objectives of an organization rather than to define them. Different organizations will have different priorities, tolerances for risk, budgets, security requirements, regulatory obligations, availability requirements, procedures, and ways of making decisions. A graduate cannot be expected to know those things before entering an organization. What I believe we can teach is how to identify them. Ideally, a graduate should be comfortable answering an interviewer’s question with something like:
“Yes, I can work on that. I first need to understand how this organization prioritizes cost, risk, security, availability, user impact, and the other requirements that affect the decision.”
That is a different kind of readiness from simply knowing how to perform a technical task. It reflects an ability to enter an unfamiliar environment, determine what matters, and adapt existing technical knowledge to that environment.
AI potentially makes that level of capability achievable much earlier in an employee’s career by accelerating the development of professional judgment, without pretending to replace the experience that mature judgment ultimately requires. It can provide access to implementation knowledge, alternatives, documentation, troubleshooting assistance, and even design recommendations that previously might have required considerable experience. But the value of that assistance depends upon the graduate knowing what questions to ask, understanding enough of the underlying technology to evaluate the answers, and recognizing when an apparently plausible recommendation is inappropriate.
For that reason, I am increasingly convinced that AI should be considered a longitudinal capability rather than primarily a standalone subject.
The same may be true of critical thinking, communication, documentation, source control, and other professional skills that are often taught separately from technical subjects. These are difficult to develop meaningfully in isolation. They become useful when they are repeatedly applied in technical contexts throughout the program.
A networking course, for example, would still teach networking fundamentals and hands-on skills. But students might also be asked to consider the organizational requirements that drive a network decision, use AI appropriately to investigate or develop alternatives, evaluate the recommendations they receive, document their reasoning, and explain why a particular implementation is appropriate. The same habits could then be reinforced in Linux, cloud computing, virtualization, scripting, cybersecurity, storage, containers, and other courses.
By the time the student reaches a capstone, the expectation should be that these are no longer separate skills. The student would be given a realistic organizational problem requiring the integration of multiple technical disciplines and would need to establish and document requirements and constraints, identify priorities, apply requirements-driven AI assistance where appropriate, develop and implement a solution, maintain documentation and source control, communicate decisions, test the result, and explain the tradeoffs that were made.
The objective would be to graduate a technically competent critical thinker who understands why organizations use technology, possesses enough technical foundation to work safely and effectively, knows how to use AI to extend that foundation, and has developed a repeatable method for approaching problems that were not explicitly covered in the classroom.
In a large organization, that graduate could participate meaningfully as a junior member of a technical team and understand the reasoning taking place in design and operational discussions.
In a smaller organization, where layers of junior, intermediate, and senior IT staff may not exist, the same graduate may need to operate with greater independence. AI and other resources can extend the range of problems they are capable of addressing, potentially allowing them to perform work that once would have required more experienced staff. That increased independence also creates risk, making it especially important that the graduate understand the limits of their own expertise, know how to validate the assistance they receive, and recognize when outside or more senior expertise is required.
This leads to a fundamental question:
How can a two-year, 60-credit-hour program effectively develop, reinforce, and test both technical competence and critical thinking throughout the student’s entire program of study?
Answering that question may ultimately have a greater impact on graduates than determining which individual AI topics belong in a single course.
I realize this suggests a potentially fundamental change in how a two-year IT program is taught and how its outcomes are defined. I also recognize the many practical constraints involved, particularly state curriculum, program approval, and accreditation requirements. My intent is not to prescribe the solution, but to suggest that AI may have fundamentally changed both the opportunities and challenges across the entire program.
I hope this helps clarify my comments during the meeting.
# # # #
Below is Mark’s second set of remarks:
I wanted to add a little more detail in case additional questions arise.
One of the concepts I mentioned was “requirements-driven AI assistance.” What I did not expand on was how that might actually be implemented.
The approach I have in mind separates prompt engineering from requirements definition. This would involve two documents for each discipline.
The first document would be an AI instruction document. It would define how the AI is to interpret a particular class of requirements template, including the role it is to assume, the technologies involved, the expected outputs, and any model- or vendor-specific guidance needed to produce reliable results.
For example, one instruction set might tell the AI to operate as an AWS cloud engineer and produce the scripts, configuration, and infrastructure-as-code necessary to implement a design. A different instruction set could use the same underlying infrastructure requirements but ask the AI to act in an operations role and produce SOPs for administration, maintenance, troubleshooting, backup, and recovery.
This is where the detailed prompt engineering would occur.
That document would be created and maintained by experienced AI resources who understand how to work effectively with the various technologies and models being used — OpenAI, Anthropic, Google, Microsoft, or whatever succeeds them. The details of that work would be beyond what I would expect from a graduate of a two-year IT program. It is nonetheless required in order to get the AI assistant to know what to produce.
The second document would be the structured requirements template. That is the part I believe belongs in the curriculum.
Its purpose would be to give students a standardized way to describe what needs to be built, configured, secured, operated, or analyzed. Domain experts could develop templates appropriate to software development, infrastructure, cybersecurity, operations, data, and other areas.
Students would then use those templates repeatedly throughout the curriculum. The instructional emphasis would be on learning how to break down a business or technical problem, identify assumptions and missing cases, describe constraints, and express the requirement clearly enough that an AI system can act on it.
In that model, the student does not need to become an expert prompt engineer. The student needs to become good at requirements analysis.
Both documents could ultimately become part of the graduate’s professional toolkit: the structured requirements templates they know how to use, along with the AI instruction sets that allow those templates to be interpreted by the current generation of AI tools.
There may also be an opportunity for the college to add value after graduation. If the AI instruction documents are being maintained as models, vendors, and techniques evolve, then updated versions could be made available to graduates over time. That would allow alumni to continue using the requirements discipline they learned in school without having to become specialists in the rapidly changing prompt-engineering layer themselves. Employers could still tailor those instructions to their own environments, but the college could provide a maintained baseline that helps keep its graduates productive as the technology changes.
These are an attempt to help clarify how AI could be incorporated longitudinally throughout an IT curriculum, rather than treated primarily as a stand-alone course.