Andrés, fourteen years in and an awkward meeting
Andrés had been writing code for fourteen years. He knew three languages inside out, two frameworks by heart and could set up a server in twenty minutes with his eyes half closed. His wife told him he talked in his sleep and that he'd once said something about a database. He didn't remember it, but he didn't rule it out either.
One Tuesday in February, his boss pulled the team into the big room. The one with the uncomfortable chairs and the projector that always glitches. The projector didn't glitch this time. On the screen was Jensen Huang, from Nvidia, saying something Andrés didn't expect from an engineer: "Distinguish between the tasks of your job and the purpose of your job. The tasks can go away."
Andrés looked over at Lucía, next to him. Lucía didn't look at anyone.
After the meeting, at the coffee machine, Marcos said it was a joke. That there'd always be a need for people to write code.
"Sure," said Lucía, stirring her sugar without looking up. "Just like there was always a need for people to copy documents by hand."
Marcos took his coffee and left without another word.
What Huang was really saying
Huang wasn't talking about layoffs. Or robots. He was talking about something more subtle, which is what made it uncomfortable. He was saying that writing code is a task. A task that machines are getting better and better at. But building useful applications — understanding a problem, designing a solution, deciding what to build and for whom — that's a purpose. And that purpose is still human.
The distinction feels philosophical until you live it in an actual office.
Andrés wrote clean code, fast, well-documented. But if you asked him what the thing he was building was for, sometimes he'd go quiet for a beat too long. There were tasks in his backlog that had been sitting there for three sprints and nobody really knew who had asked for them or why.
Lucía, on the other hand, had a habit of asking annoying questions before writing a single line. "What's this for?" "Who's going to use it?" "What happens if we don't do it?" She wasn't very popular in planning meetings. But her projects worked. Andrés's also worked, technically. The difference was that someone actually used Lucía's.
The software no one uses
There's a statistic that floats around tech departments that nobody wants to look at head-on: between forty and sixty percent of features developed in enterprise software are never used. Ever. They're specced, designed, programmed, tested, deployed. And nobody touches them.
That's code written without a purpose. Tasks executed perfectly that solve nothing.
When someone hires a custom development and the first meeting is spent entirely understanding the business, without opening an editor, without talking about technology, some people get impatient. "When do we start building?" But that meeting is the one that separates the software that gets used from the software that ends up in a digital drawer.
The question that matters
At Andrés's company something happened. They started using AI tools to generate code. At first it was for the repetitive parts: forms, validations, database queries. Then it was for more complex things. One day, Andrés saw that an AI had written in three minutes something that would have taken him half a morning. And it was good. It worked. It passed the tests.
He sat there staring at the screen. Not exactly afraid. More like the feeling you get when you see someone drive better than you on a road you know by heart.
Marcos asked for a meeting with the boss. He wanted to know if there were going to be layoffs. The boss said no. What they were going to reduce was time spent on mechanical tasks. That now he needed people who knew what to build, not just how to build it.
Marcos asked what the difference was.
Lucía, walking past with a coffee, said without stopping:
"The difference is, before they paid you for your hands. Now they pay you for your head."
It wasn't entirely accurate. But nobody corrected her.
What's left when the task disappears
There are companies still looking for programmers who write code fast. And there are companies looking for someone who understands their problem before writing anything. The first hire tasks. The second hire purpose.
A chatbot that works doesn't start with code. It starts with someone sitting down with the business owner and asking, "What do your customers need at eleven at night that they don't have now?" A dashboard that works doesn't start with charts. It starts with someone asking, "What decision are you going to make with this number?" An automation that saves time doesn't start with workflows. It starts with someone watching how your team works for a morning and noting the things they repeat without realizing it.
Then comes the code. But the code is the task. Everything else is the work.
A small gesture
Andrés changed. Not all at once, not with a dramatic revelation. He just started doing something he hadn't been doing: before writing code, he'd call the user who was going to use it. Five minutes of conversation. "What exactly do you need?" "How do you work now?" "What gives you a headache?"
The code he wrote afterward was less elegant than before. Sometimes even shorter. But people used it.
One day his wife told him he was talking in his sleep again. That this time he'd said something about a client.
Andrés smiled. It felt like an improvement.
Does your software solve problems or just run tasks?
If you've ever felt that your company's technology works but doesn't help, maybe the problem isn't the code. A short conversation can clear up a lot.
Let's talk