AI Can Solve Problems. But Who Decides What the Problem Is?

 

 

In our college computer labs, the sound of typing has changed. A year or two ago, it was the frantic clatter of students debugging syntax errors and digging through Stack Overflow. Today, half the screens have an AI assistant open, generating perfectly structured boilerplate code, database schemas, and API endpoints in seconds. It is incredibly cool to watch. But seeing my classmates—and myself—build entire mini-projects over a single weekend hackathon got me thinking.

               

 

If an AI can write the code, design the interface, and fix the bugs, what exactly is my job?

 

I bumped into the reality of this question outside the lab, while looking at my family’s transport business. For years, I’ve watched my father deal with the daily friction of the logistics industry. The issues are always the same: delayed payments from clients, severe cash-flow bottlenecks because factories take months to pay, unfair competition between local transporters, and a chaotic mess of miscommunication involving brokers and truck drivers.

 

 

As a computer science student, my brain is naturally wired to see friction and immediately think: I should build an app for that.

 

I grabbed a notebook and started sketching out a platform. I envisioned a digital system for transport brokers and transporters that would feature booking management, automated payment tracking, and a neat dashboard showing pending transactions. It felt like a solid, practical engineering project. I even prompted an AI tool to help me design the backend architecture, and it instantly spat out a beautiful, scalable framework.

 

But then I stopped. I looked at the architecture and asked myself: Am I actually solving the real problem?

 

An app would definitely make communication easier. A dashboard would look great and show pending payments in real-time. But a digital ledger does not automatically force a factory to pay on time. The real problems were a lack of trust, broken business incentives, weak accountability, and the sheer dependency on cash flow. I could build the most elegant software in the world, but it wouldn't fix the underlying relationships between factories and brokers.

 

The technology solution and the actual problem were not the same thing. AI could help me build that application ten times faster, but it couldn't tell me whether building it was actually the right intervention.

 

 

This was a slightly humbling realization. It taught me that engineering begins long before the first line of code is written. Traditional software development usually follows a predictable path: identify a problem, gather requirements, write the code, test it, and deploy it. But with AI stepping in as an ultra-fast developer, the "writing code" part is becoming dramatically easier. As a result, the workflow is shifting. It now looks more like: understanding the real-world problem, defining objectives and constraints, using AI to assist with implementation, and heavily evaluating the output before deployment.

 

This shift makes problem definition the most critical part of the job. If it becomes virtually free to build software, the immediate danger is that we will build thousands of solutions that nobody actually needs. We will have flawless code solving the wrong problems.

 

 

AI is incredibly good at solving problems when we give it clean data, a clear objective, and tight constraints. But real-world problems are rarely that clean.

 

Imagine an AI system tasked with reducing hospital waiting times. It could easily crunch historical data and generate a mathematically optimized schedule. But who decides what "success" means? Does success mean the lowest average waiting time for everyone? Does it mean the fastest possible treatment for critical emergencies, even if minor cases wait much longer? Or does it mean keeping the hospital’s operating costs as low as possible?

 

The AI will ruthlessly optimize whatever objective we hand to it. But deciding what should be optimized—and understanding the human trade-offs of that choice—is something an algorithm cannot do for us. AI can help us explore patterns and suggest alternatives, but the responsibility for the final objective remains ours.

 

 

So, where does this leave engineering students? If AI can generate a working prototype while I am still figuring out my database keys, what should I actually be studying?

 

We shouldn't stop learning to program. You cannot evaluate or debug a system if you don't understand how it is fundamentally built. But programming is becoming a tool, rather than the entire identity of an engineer.

 

Instead, we need to spend a lot more time learning system design. We need to practice talking to users, finding root causes, and identifying edge cases. We have to learn how to ask better questions and figure out who is actually experiencing a problem before we try to fix it.

 

AI is a massive accelerator. It removes the friction between having an idea and seeing it on a screen. But as the cost of implementation drops to zero, figuring out which problems are actually worth solving becomes the hardest part of the job.