What I Learned from a Conversation at Loyola University Chicago
Reflections on speaking with Loyola University Chicago students about AI, the future of software engineering, and what I learned from the conversation.
Last Friday, I had the opportunity to speak with students at Loyola University Chicago about a question I've been thinking about quite a bit lately: What does it mean to be a good software engineer when AI can write the code?
I've spent many years building software, leading engineering teams, and helping companies solve process + technology problems. Throughout that time, I've benefited from people willing to share their experiences and perspectives.
I enjoy opportunities to do the same, particularly with students preparing to enter a profession that's changing as quickly as mine.
I went into the seminar hoping to share some practical lessons about using AI in software engineering. I came away with a few interesting observations of my own.
Different perspectives, similar conclusions
One of the most interesting parts of the experience was the conversation with Loyola's faculty.
I hadn't workshopped or reviewed my presentation with them beforehand. My material came almost entirely from practical experience: how I'm using AI today, where I've seen it succeed, where it struggles, and what I think those observations suggest about where we're headed.
The faculty approached many of the same questions from an academic perspective. Some are studying how these models work, how people interact with them, and where their capabilities may be going.
What surprised me was how closely our conclusions aligned!
We were approaching the subject from different directions, but we shared similar views about how people should use these tools, the importance of developing deep technical understanding, and the need to evaluate AI-generated work rather than simply accepting it.
I found that encouraging.
It's easy to get caught up in the daily news cycle surrounding AI. There's a constant stream of announcements, benchmarks, predictions, and opinions about how dramatically everything will change.
Meanwhile, those of us applying these tools to real business problems are learning what they can and cannot reliably do today.
Students have legitimate concerns about their careers
Unsurprisingly, students were concerned about what AI means for their career prospects.
It's a reasonable concern.
When you're preparing to enter software engineering and much of the news suggests that AI will soon be writing all the code, it's fair to wonder where that leaves you.
I wanted to give students a more practical perspective than what they might be hearing in the news.
AI is good at explaining unfamiliar systems, exploring alternatives, generating code, and helping engineers move through tasks more quickly.
But there's still a significant gap between generating code and delivering useful, reliable software.
I used an example from a construction operations project where the initial request was essentially to replace spreadsheets with an application.
The difficult part wasn't writing an application. It was understanding how people worked, where the information came from, what problems we actually needed to solve, and whether building something new was even the right answer.
These are areas where AI can help, but a good outcome still depends heavily on the context, judgment, and validation provided by people.
I encouraged students to continue developing their technical skills, particularly debugging, testing, understanding complex systems, learning how to work with people, and most importantly knowing when something is finished and ready to use. We all know AI agents will keep the conversation going forever if you allow them to.
I can't tell them precisely what the software engineering job market will look like five years from now. Nobody can.
But I do believe that understanding how to solve real problems, and being able to demonstrate that your solutions work, will continue to matter.
A good idea doesn't have to be a new idea
We also spent some time discussing how students can build portfolios that demonstrate their abilities.
My advice was to go beyond showing a working application. Explain the problem, the decisions made along the way, the alternatives considered, and how the result was validated.
The discussion brought up something I hadn't fully considered.
Students pointed out that many of their better project ideas have challenges beyond the engineering itself. Some would require significant marketing or sales effort to reach the people who could benefit from them. Others already have similar products available.
That's an important observation I appreciated hearing.
My response was that the existence of a solution doesn't necessarily mean it's a good solution.
In my career, I've worked on plenty of problems where software already existed, but it wasn't meeting the needs of the people using it.
Sometimes the opportunity is to make something easier to use, more reliable, less expensive, or better suited to a particular set of users.
Students don't necessarily need to invent something entirely new to demonstrate good engineering judgment.
In fact, understanding why an existing solution falls short can be a much better starting point than trying to invent a product for the sake of originality.
And recognizing that a good product also needs a way to reach its users is an important lesson to learn early in your career.
Giving back is also an opportunity to learn
I've reached a point in my career where I increasingly appreciate opportunities to share what I've learned with others.
Whether that's working with emerging engineers, mentoring, or spending time with students, I think those of us who have benefited from careers in technology have a responsibility to contribute where we can.
That doesn't necessarily mean having all the answers.
Friday reminded me that these conversations go both ways. I was encouraged by the alignment between academic research and practical experience, appreciated the students' concerns about their futures, and came away thinking differently about some of the challenges they face.
I'm grateful to Loyola University Chicago for inviting me to participate and for the opportunity to contribute to Chicago's technology community.
I ended my presentation with a simple idea about what good engineering should accomplish:
A real person. A real problem. A useful improvement.
I still think that's a very good foundation for a career in technology, regardless of how much the tools and workflows change.