Earlier today, during the South Florida TechGateway Steering Committee meeting, a discussion broke out around recent college graduates, emerging tech talent, and how fast the ground is shifting under our feet.
One committee member shared an observation from the field: recent graduates are arriving armed with generative coding tools like Claude Code, and they can produce working software in a fraction of the time it used to take. But on the back end, their projects often lack fundamental structure. Things are not buttoned up. The speed is astonishing, but the architectural and procedural rigor is missing.
That observation captures the single biggest transformation and the most critical leadership opportunity in technology education today.
For decades, technical training focused almost entirely on the mechanics of building: how to write syntax, how to implement an algorithm, how to construct a function. In construction terms, our schools and bootcamps trained bricklayers. We evaluated people on how cleanly and quickly they could lay one brick next to another.
Generative AI changed that equation overnight. Today, anyone can sit down in front of an AI model and generate working code, draft a legal agreement, or design an operational workflow. The friction of creation has collapsed.
We are no longer bricklayers. We are suddenly foremen.
And that introduces a fundamental question: if anyone can build, what actually matters?
The Illusion of Completion
The danger of generative AI is not that it produces bad work. The danger is that it produces work that looks finished before it has been engineered.
When you ask an AI tool to build an application, generate a database schema, or draft a complex document, it produces an impressive artifact in seconds. The natural human reaction is relief: It worked. It is done.
As I shared with the committee:
"What I love that [Claude Code] and all these tools as they kind of democratize building, right; you may not be a software developer, but now all of a sudden you can build software. Doesn't mean you're going to build it right, and doesn't mean you know how to manage a process around software development."
Laying bricks is only a small slice of constructing a building. A building requires structural engineering, foundation soil testing, electrical load planning, fire-code compliance, and regular inspections. If you know how to lay bricks but know nothing about load-bearing walls or structural safety, having an automated machine that lays ten thousand bricks an hour does not make you a master builder. It just lets you build an unsafe structure ten times faster.
Managing the Process
True software engineering was never merely about typing lines of code into an editor. It has always been about managing a rigorous lifecycle:
"Software development has a quality assurance process, it's got software testing, it's got all kinds of different steps to it. And whether you're using AI to build the software or whether you're using humans or a hybrid of the two, if you don't know the process, you can't be an effective manager of that process. All of a sudden you're using a tool to build something that you really don't understand, and so you can't maintain it, you can't build it safely, you can't build it in a secure way."
When someone does not understand how the underlying system works, they cannot maintain it when it breaks. They cannot identify hidden security vulnerabilities. They cannot anticipate edge cases or evaluate failure modes.
A foreman does not have to lay every brick by hand, but a foreman must know exactly what a level wall looks like, how mortar cures under humidity, and what happens when weight shifts across an archway. If the foreman cannot inspect the work, the foreman cannot ensure the building stands.
A Horizontal Shift Across Every Discipline
This is not isolated to software engineering. It is a horizontal shift across every knowledge discipline:
"It's not just software development. It's horizontal, right; whether you're in manufacturing or whether you're in software... Now all of a sudden we can all build, we can all write papers, we can all draft contracts. Well, what does a quality review from a lawyer look like so that we can manage that process, as opposed to just thinking the first time we throw it off and Claude told us it's done, it's done? You know, there's testing."
Consider the parallels:
- In Law: Anyone can prompt an LLM to generate a commercial lease or a partnership agreement. But without an understanding of indemnification, liability caps, or jurisdiction clauses, managing legal risk is impossible.
- In Manufacturing: Generative design tools can output CAD geometries instantly. But without understanding material fatigue, stress tolerances, and thermal expansion, there is no way to validate whether the part will hold under load.
- In Operations and Business: Anyone can generate financial models or strategic plans. But without stress-testing assumptions and auditing formulas, leaders are steering organizations on untested projections.
In every field, AI has automated the execution layer while drastically elevating the stakes of the verification layer.
What We Should Be Teaching for AI
If universities, colleges, and training programs continue to center on syntax and memorization, they are preparing students for jobs that were transformed yesterday.
Having these powerful tools is not a problem. It is a tremendous gift. It unleashes human creativity and lets small teams punch far above their weight. But our educational framework should evolve to meet this new horizon.
Rather than training people to be manual laborers in digital systems, we should be teaching them how to direct, inspect, and manage the full process:
- Adversarial Testing and Quality Assurance: We should teach students how to design tests that actively probe for failure in AI-generated work, verifying correctness rather than accepting plausible answers.
- System Architecture and Constraints: We should teach how individual modules interact, showing where performance bottlenecks, security boundaries, and data integrity risks emerge.
- Lifecycle Maintenance and Observability: We should teach how to monitor, debug, and sustain a system six months down the road, long after the initial prompt has faded.
- Domain Governance and Critical Review: We should cultivate the judgment required for rigorous professional review in law, finance, engineering, and operations, instilling the standards of a seasoned practitioner into every AI interaction.
Anyone is a builder now. Anyone can generate code, prose, and designs at the touch of a button.
The durable value will not belong to those who merely prompt a tool to lay bricks. It will belong to the foremen who understand how to design, test, inspect, and steward the entire structure. That is what we should be building into our classrooms and organizations today.