Ask AmirBahador Bahadori who he is, and the CV comes second. “What really gets me up in the morning is a relatively complex challenge that's important for the team or the people — something that impacts people's lives,” he says. “If it's just complex but has no impact, that's not fun. But if it's impactful, important and hard — that's where I come in.” It's a small line, but it's the same one that explains why, alongside seven or eight years as a software engineer across DevOps, backend and frontend work — “whatever each startup needs” — he has quietly built a second practice: mentoring people he's never worked with, on problems that aren't his to solve, for no reason beyond the belief that it matters.
“I always believe it doesn't matter where you are in the hierarchy of knowledge — you can always help people with less experience.”
“Even when I had three years of experience, I mentored people with less.” That's not a humblebrag about generosity; it's closer to a working principle. The mentoring itself goes back years — at university, on his YouTube channel, and anywhere else people could reach him; ADPList is only a recent addition, though it took quickly, with a run of warm reviews and a Top 10 mentor recognition in AI/ML engineering within months of joining. Across all of it he tries to talk to at least three people a week — and the range is the point, not a side effect. “This week I talked to a PhD graduate working in AI research who was struggling in his own area, and right after that a really junior front-end engineer trying to figure out HTML and CSS. I try to be useful across that whole range.” A senior researcher and someone just learning what a div is get the same attention, in the same week, from the same person — because the hierarchy of knowledge, in his telling, was never really a ladder.
The engineer underneath the mentor is, unsurprisingly, the same person. At Smartlane, a B2B startup, he leads engineering across the database (correctness, state), observability (tracing and logging pitched to answer questions nobody thought to ask in advance), and analytics (the read on user behaviour, always treated as a hypothesis rather than a verdict) — three concepts he's deliberate about never collapsing into one.
“AI should never be the driving person. It should not have the wheel.”
And on the newest question every engineering team is asking — how far to let AI run on its own — his answer sounds exactly like his answer about mentoring: presence, not absence. “It could help you tremendously as an assistant to do what you tell it, but it should not be autonomous.” He'll have AI review code, read logs, flag issues — the same way he'll point a mentee toward the right question — but the call, and the ownership of what happens next, stays with a person. “I must have somebody to take ownership,” he says. “If it's just AI, and it destroys my company and tells me ‘oh, I made a mistake' — that's not going to happen.” Whether it's a junior engineer, a PhD researcher, or a model with a pull request open, the discipline is the same: show up, guide, and never hand over the final decision to something that can't actually own it.