A lot of what holds people back early isn't talent — it's a handful of wrong expectations about how building actually works, what AI is for, and how careers get made. Here's what I keep coming back to.
Watch the full mentorship session26 min · four teams, real projects, live feedbackIt's iteration zero — not version one
The first thing you build is not a solution. It's a toy. That's not an insult — it's the honest name for it, and it's completely natural.
I don't call early work “version one” or “version two.” I call it solution discovery, iteration zero. You're not validating a finished thing yet; you're building subject knowledge, aligning your thinking, and making a first attempt you can react to.
Every product you rely on started this way. Microsoft Teams isn't a one-year project — it's fifteen or twenty years of iteration. Look at the first iPhone, or the first version of any app. Look at a house built twenty years ago, then improved step by step until it finally feels like a home. You improve, you see the gaps, you improve again. Trust your ability to iterate more than any single solution.
Treat AI like a hire you train — not a program you write
Agentic AI does not mean you “program an agent” on day one. It means you work with it the way you'd work with a new team member.
When I hire someone, the first few weeks I train them. I give them context, I document how I think, I structure the work. After that, they can take decisions on their own. AI is the same: with a loose instruction it works loosely; with a better instruction it works better; with clear context up front and permission to run, it works autonomously. I ran those experiments myself and watched exactly that happen.
So set the foundation first — the actual front end, the back end, the database — then put the agent mindset on top of it. And change how you talk: it's not “the front end isn't working,” it's “my front-end agent isn't working.” When that shows up in your daily language, you've understood it.
It's not “the front end isn't working.” It's “my front-end agent isn't working.”
Depth is what happens under the hood
Nothing connects automatically. If someone tells you the database and the program “just connect” — red flag. You need to know which port the database runs on, which port the backend runs on, how the operating system handles it, what protocol sits between them, how the database was designed to take many connections or one.
You're no longer spending your effort typing the program — the machine does that. So spend it going deep. Depth means you don't just talk about what you can see on the screen. If you only talk about what you see, it tells me you're not really in the AI world yet.
Stand up from your seat
You can't grow sitting in front of a computer. The work now is to stand up and talk — to ten different professionals, to people who actually have the problem, to your neighbours, to anyone.
Go and get real data. Scrape it from Reddit, reach out to friends working in the industry, schedule a call, get the real perspective. While you're doing that, your agents are doing the typing — running the small fixes, sending you the screenshots, testing. You review, you approve. That frees you to think, and thinking is the job.
Build the real model, not your theory
If you're doing data science, I want to see a real mathematical, statistical, research model — not the theory you're holding in your head. Let the machine think, and apply the programming to that.
And where you hit a point you can't bridge with clean maths or science — where two pieces of data won't connect through a real model — that's exactly where agentic AI earns its place. Your job is to go deep enough to connect them. Take your time. Do one thing correctly, and it pulls the whole team in the right direction.
Think past “software engineer”
I don't introduce anyone on my team as “the front-end developer” or “the back-end developer.” I don't think that era is still here. Projects aren't only tech anymore — they're tech and domain.
Nobody has ever given me a project because of my tech ability. I can build an application end to end single-handedly, and it has never been the reason. They come to me with a domain problem. So build the technical foundation — it's necessary — then own the domain and own the project. If the servers are crashing, you worry about it. That ownership is what makes the work, and the business, actually run.
Study business problems, not LLM internals
I don't spend much time now on what an LLM is or how a neural network works internally. Those aren't giving me anything anymore. What I study is business problems — economics, law, regulation, identity — and then I match what I study against real data.
You are free to pick any real-world problem and point intelligence at it. That's all you need: a problem worth solving, and the ability to extract the data, build a model, and get to better answers. Keep one, two, maybe three topics — don't drift from one thing to another. Depth beats breadth here.
Market yourself, and always have a plan B
Nothing comes to you automatically — not even the smallest piece of work. Reaching a good company depends entirely on how seriously you go after it. When I wanted to reach the companies I respected, I was talking to ten different people a week: what does my résumé need, what are they really looking for, what should I point to.
I've interviewed at plenty of places and been rejected plenty of times — that's the process, not a verdict. Don't just look for a job; pick a problem and work on it, and keep a plan B and a plan C. Be independent rather than dependent. Communication and depth are the two things I look for — everything else follows from those.
The more you fail, the more you learn. I clap when you tell me you tried and it broke.
Publish your work
Write it up. Take the real project you're doing, and put it into a proper report or article — problem, journey, what you solved, a bit of the build — and publish it somewhere.
Your projects are real, so this is real exposure. It's not about whether someone approves it. It's about doing real work you can stand behind. Whatever you make the first time will be toy-style and a little rough — the first omelette always is. What matters is that you can iterate again, and again, and again.