Coding is no longer the bottleneck I optimize for
Leslie: Coding is no longer the bottleneck I optimize for.
Me: (Gulp.)
That's what Leslie de Jesus told me about thirty seconds into our conversation. She is a Sr. Director of Engineering at Vantor, formerly Maxar Puerto Rico, and has personally recruited hundreds of engineers over 25 years. So when she says she doesn't care about coding, that is not a hot take. That is a hiring manager telling you what she actually screens for.
What follows is our conversation, lightly edited.
Me: How has hiring changed for you?
Leslie: I stopped screening for frameworks, languages, or even algorithms five to seven years ago. I hire for problem-solving, critical thinking, beginner's mind and growth mindset. Even at fifteen years of experience, if you walk in pretending you know everything, it doesn't work.
Then in the last 18 months, AI hit. And I don't optimize for coding anymore.
Me: (Gulp.)
Me: How can you say that?
Leslie: Because the heavy work now is upstream. Requirements. Design. Architecture. Spec-driven intent. The human iterates with the agent until the spec is clean, then planning, then ticket-to-PR. Everything is so segmented and so well-digested that , for a large class of problems, code is becoming a commodity.
If you did the early work well, the code is simple. Same rule of thumb we always gave developers: spend the time on analysis and design, and development becomes straightforward.
Me: Where did the bottleneck go?
Leslie: It used to be execution. Now? In teams with meaningful AI adoption, I’ve seen execution stop being the primary bottleneck. The constraint shifts upstream. The bottleneck is in the definition of what you want.
Me: What you want.
Leslie: What you want. Yep.
Me: When you say "human in the loop," do you mean line-by-line review?
Leslie: Not realistic. Once you get comfortable, you move from line-by-line review to trust backed by guardrails, good requirements, adversarial agents and validation. The discipline has to be upstream. Adversarial agents that challenge the spec. Specific guardrails: "use DRY," "follow clean code," "no class over 100 lines." You validate that the guardrails were respected. You don't read every line.
Me: Has this changed how you measure performance?
Leslie: Yes. And honestly, I'm still refining it. The old velocity metrics don’t quite fit anymore. What I’ve added so far is AI spend, just to put some guardrails around usage. Remember being on a compute quota in the university lab? Same idea. You can’t just scale model usage without intention. When the cloud arrived, everyone went crazy spinning up big instances until the bills showed up. Then governance followed. I think we’re in that same phase now. The metrics will catch up, but they’ll look different.
Me: How do you handle the spread on your team, enthusiasts on one end, skeptics on the other?
Leslie: I have both extremes. The enthusiasts ask everything to a model and experiment like crazy. The skeptics and conservatives worry about quality and societal cost. With the skeptical-by-experience ones, I start small, a mockup service on the roadmap, something low-stakes, so they can build comfort. The morally skeptical ones are harder. I don't fully know how to reach them yet.
Me: I've started thinking spec-driven development is actually management. Planning, work breakdown, verification loops. Context engineering is cognitive engineering. McDonald's can take a 16-year-old and make them productive. It's the system, not the person. The senior engineer's job has moved from craftsmanship to a managerial mentality. But we didn't hire for that.
Leslie: Exactly. The analogy I use: you are now the director of the orchestra. But you also wrote the music. You compose it and you conduct it. You make sure each agent and skill is doing its job.
That’s the interesting part. Seniors tend to have the mindset already. Juniors are still used to tickets that ask for A, B, or C, so there’s a mindshift happening. I’m experimenting, but the opportunity is real and they can get there faster than we expect.
I told her CS just made the top 10 of the most unemployable degrees. She didn't flinch.
Me: Why should leaders listen to you?
Leslie: Because I'm a computer scientist at heart. I've worked in national laboratories. I worked when the human genome was a project. I worked with cyclotrons. I've done two startups…consulted across multiple industries. I grew one engineering org from employee 12 to over 100. I’ve been lucky to see this from different angles. And in the last decade I discovered something I didn't know about myself: I have a real passion for helping people grow.
Me: Where's the puck going?
Leslie: Within twelve months we hit the brakes. Not because the technology stops, but because we have to rebalance: cost, quality, governance. Same way the cloud era went.
Also: individuals are going to own a lot of products. Teenagers are going to build a lot of things. There are going to be a lot more companies.
Me: Where do the wheels come off?
Leslie: Tech debt. We’re shipping a lot of code fast, and the problems show up in production six to twelve months later. Code that used to be expensive to fix now feels easier, so the temptation to go faster is higher. We’re going to learn from that, and put the right guardrails in place.
The bottleneck moved to you. Your intent. Your decision rate. Whether you know what you want. That’s the shift. The leverage is no longer in execution, it’s in judgment.
A bit chaotic, but a defining time to be part of this transformation.
Leslie de Jesus is a strategic technology and leadership advisor, angel investor, and Sr. Director of Engineering at Vantor. She writes Quiet Thesis on leadership, technology, and capital.