Writing

What I Look for in People Working With AI

Thoughts from a conversation with faculty developing an AI master’s program: judgment, mental models, product understanding, and evaluating the work.

I recently spoke with faculty at Kansas State who are developing an AI master’s program. They wanted feedback on the competencies they’re teaching and what we’re looking for in employees.

My background includes education at different levels. My past role was at Curio XR, a VR education platform, working at the university level. Now I work in software at Another Reality Studio, where a big part of what I do is helping our developers use AI safely and effectively to build what we need to build.

I’m definitely an AI and agent optimist. I want technical people and nontechnical people to make the most of this stuff. My passion is in managing human talent and helping people do that.

Looking through the program’s competencies brought up some questions about what we need people to understand, how we evaluate their work, and where their value comes from when they’re working with AI.

How do you measure the human’s competency?

One of my first questions was how they planned to measure student competency.

The first reaction to AI in education was, “Everyone’s cheating. How do we stop cheating?” Now I think we recognize that this is here to stay. But there’s still a problem: how do you know you’re measuring the student’s competency?

In a remote course about AI, everyone is going to be familiar with using agents. Ostensibly, those agents could be doing their competency testing.

I don’t even necessarily think it’s cheating to use AI for bigger and bigger classes of things we do day to day at work. If the result is what our stakeholders need, if it delivers value, and if it’s a well-built piece of software, the tools used to make that happen are part of the process. We work in robotics as well. If the robot can do the task, that matters.

So how do you evaluate the humans? And how do you make the humans maximally valuable when they’re using AI to help them?

Judgment and a mental model of what you’re building

There’s a colloquial term that has popped up: a “meat proxy.” It’s a derogatory term for someone who copies a question into AI, then pastes the response back to the person who asked, without inserting their own judgment.

The most valuable thing I find in humans now is that judgment, including being able to use AI at the right level.

There are times when I’m thinking, “Why did you spend three days working on that Excel spreadsheet? You could have given that to Claude or ChatGPT to help you with it.” We don’t want people wasting time on things we know AI is really good at.

At the same time, a competency I look for in the developers I work with is a mental model of what they’re building. That doesn’t necessarily mean code-level familiarity with variable names. I think this more mid-level understanding of what the software is doing is important.

If I ask someone, “What’s the software stack you built this prototype with?” and they say, “Let me go ask my agent,” I wish they knew that. There’s value in knowing what you’re building as you build it.

AI lets us move at a superhuman speed in a lot of domains, including software development. There’s no way you could type that amount of code in that amount of time. But it’s important to maintain a mental model of what you’re building.

At the same time, I think some experienced software developers are falling behind because they’re overly opinionated about exactly how their agents need to build things.

It’s worth taking a minute to ask, “How would you build this?” Have some curiosity. Don’t assume the way you’ve always built something is the best way to continue building it.

It’s a hard thing to build a deterministic test against. When I talk to developers, I’m trying to understand which side they’re on. Are they overly set in their ways? Or do they have no idea what’s being built underneath the hood, constantly having AI do too much without doing the research and planning themselves?

Technical people need to understand the product

Another competency I think is becoming extremely important for anyone working in software or technology is understanding the business goals and the user experience.

Historically, we’ve had roles for pure programmers: individual contributors who were essential because they knew a particular language or had the mental model of a big codebase. “We can’t lose this person because they’re the only one who knows the code.”

I think the value is shifting away from being competent in a language or an arcane technology and toward understanding the business logic, the business goals, and the user experience.

In the past, you could be a programmer working on a subsystem of a big piece of software and not even know what the end user used the app for. You got a ticket from a product manager telling you what needed to change. You changed it and submitted your code.

That’s not someone I would hire at a small company. It might still be a role elsewhere, but it’s not a role we can support at my company anymore, whereas we could in the past.

We need people who can sit in a meeting with a stakeholder, a client, or a user and understand what they want.

“Full stack” almost needs a new term, because it goes higher up the stack now. Beyond being able to implement front-end and back-end code, I also need to understand what the user wants. Technical people need to be more product-minded and user-experience-minded.

You could have all the technical competencies outlined in a program, but I’d also want to see design thinking, product thinking, and user-centered design. What’s the goal of all this stuff? It’s to serve some person in some task. Start there.

Agents are great at saying, “Yes, I wrote the code you asked for, and the code works.” But does the user coming to use that software have a good experience? Do they accomplish their goals?

That’s the evaluation that matters. It’s becoming easier to have code that functions according to a technical specification. But it doesn’t matter if you go use the app, or the robot, and it doesn’t do what the human wanted it to do.

Technical people haven’t always had to own that part of the stack. I think the people who really excel, and the people I want to hire, are good at that. Some may be people who were already product-minded and user-experience-minded and now have technical capabilities through AI tools.

Understand what you’re building and why

We’re rethinking a lot in the software world. Every day can be a head-scratcher.

That doesn’t mean we’re throwing the baby out with the bathwater. Software architecture, clean code, SOLID principles, and lots of other principles still hold up.

But you can also send an agent off to build a prototype. You could have ten agents build ten versions of the same piece of software, then evaluate them separately. We can do that now.

If the person reviewing that work hasn’t done the work to understand the problem they’re solving, that’s still an issue.

We write software for clients, and we have our own internal products we’re building toward. The time up front to understand what you’re building and why you’re building it is important.

You’d think that would be a given, but it hasn’t always been something every person in the company had to be aligned on. That has become an emphasis now.

Evals, benchmarking, and the human bottleneck

Another competency I’d want to see explicitly is evaluations and benchmarking.

How do you measure success more objectively with software or robotics? We’ve focused more on digital twins and simulation for robotics, including evaluating a robot’s performance in a digital simulation. When we build custom agents, we also need to evaluate their output, because it’s not deterministic.

Context engineering and harness engineering are part of that. If you’re building custom agents, how do you get them the context they need to serve their end goal? That comes back to knowing what the end goal is and being able to build evaluations.

Another competency is knowing how to reduce the human bottleneck.

If you’re reviewing everything, you’re limited by how much time you have in the day. You need to identify parts of the workflow where you can build software to evaluate the work, including tests.

Knowing how much of that to keep and how much to remove is a big question. Agents write a lot of tests automatically now, sometimes without being asked. How much of that is helping us, and how much is slowing us down? How much do we need?

I don’t have the answer to that. But the whole domain of evaluating and testing software is important to explore, including having some idea of what’s useful and what can be detrimental.

Find the right model for the task

As the frontier progresses, there are many tasks where you don’t need frontier intelligence. Models from six months ago may still be all you need.

If we’re building a consumer chatbot, for example, we don’t need the biggest frontier model to answer every question. We need to fit the right model to the right task, considering compute, cost, speed, and latency.

That comes back to evaluation.

Say a new model comes out, it’s ten times cheaper, and the lab says it’s just as capable as the model we’re using in production. Let’s run an evaluation we already have and see whether that’s true for our task.

Every time a company releases a model, they say it’s the best model ever, the smartest model in the world. But your task is what matters. It might be the smartest model in the world and still be worse at the task you’re using it for. You need to be able to measure that.

AI can help with that work, too. If we’ve already built a test harness, I can give an agent the new model’s API documentation and ask it to run the evaluation and assess how the model performs.

Once we’ve done the work to build that, I don’t see a reason for me to manually open a terminal and do it myself.

Infrastructure and deployment

AI also plays a role in planning, scaling, and deployment.

The typical DevOps role involved specialized, highly valuable, difficult work. That’s an area where I’m seeing capabilities become more accessible. It wasn’t necessarily a role I was doing before; we had someone in the company whose job that was.

We’re a small company, so we have flexibility. We don’t have millions of users requiring us to move as slowly and cautiously, and we’re using AI for things before many other companies.

For planning, scaling, and deploying technology, I’m finding AI to be a very good copilot. Often, its recommendations are sound.

Infrastructure as code is a huge unlock here. It’s something I’d want people to be familiar with because these agents are great at working with it.

Staying curious

The news is crazy, but I’m an optimist. For people who are curious and excited about this, there’s a lot to work with.

I’m always asking how it can help humanity, serve people, make lives better, remove drudgery, and make our jobs more productive. It’s fun. I love it.

I also worry about education. Is it advisable to be a computer science major anymore?

If a computer science department hasn’t changed its curriculum at all from ten years ago, I’d have concerns. But if it’s keeping up with the times and adapting, then yes. A program doing this work is something I would recommend.