AI Thoughtmakers

A single line of code change shouldn’t take three meetings and two weeks. When it does, your architecture has an expiry problem.

In this episode of AI Thoughtmakers, we sit down with Janardan, Principal Software Engineer at Oracle and formerly at Gojek, for one of the most practically useful conversations we’ve had about software architecture — not the theoretical kind, but the kind that either lets your company grow or quietly holds it back.

From the warning signs that your architecture is about to become a bottleneck, to the hidden costs nobody puts on a balance sheet, to the one thing every CTO should do this quarter if they think their system is already struggling — this is the conversation for anyone building something that needs to last.

Key topics covered:

The two warning signs that your architecture has expired — before it breaks

Why a technically excellent architecture can still be wrong for your business

Why early-stage startups shouldn’t think about scale before their first screen works reliably

Decisions that are hard to reverse, and why the data model is a key example

What happens when a team of 5 becomes 100 — and the hidden growth tax of coordination

Three questions to ask before entering a new market

The biggest architectural mistake companies make as they grow — and the one thing CTOs should do this quarter

If you’re a founder, CTO, or engineering leader trying to figure out whether your current architecture will hold up or whether it’s quietly becoming the thing that slows you down,  this episode is the one to watch.

Subscribe for more conversations on AI, engineering, product development, and the future of software.

Connect with Janardhan:   / janardhany   

Connect with Prem:   / premgoswami   

What does it take for an AI agent to complete a task, recover from failure, and know when to ask for human approval?

In this episode of AI Thoughtmakers, we sit down with Madhumitha, Senior Machine Learning Engineer at SolarWinds. She spends her days testing whether AI systems are safe and reliable, and she explains what it takes to build AI that can think, take action, and handle problems.

Using simple stories, from a student with a laptop to a refund on a food delivery app, she shows why a good-sounding answer is not the same as a finished task, and why leaders should test before they trust.

Key topics covered:

How LLMs, AI agents, and guardrails fit together

How agents use feedback to adjust their next attempt

Handling failed refunds and preventing duplicate payments

Deciding which actions need human approval

Evaluating tool calls, task outcomes, and missing information

Testing vendor claims beyond a prepared demo

Measuring failures and accounting for human review costs

The story behind Index Zero, her app for learning data structures and algorithms

For founders and engineering leaders evaluating AI agents, this conversation offers practical questions about reliability, oversight, and production readiness.

Subscribe for more conversations on AI, engineering, product development, and the future of software.

Connect with Madhumitha:

LinkedIn -   / madhumithakolkar   

Connect with Prem: 

LinkedIn -   / premgoswami   

Your engineers are busy. AI is helping them move faster. So why isn't the product reaching customers on time?

In this episode of AI Thoughtmakers, we sit down with Santhosh, Tech Lead at Nagarro, for a practical conversation about the 90-day engineering reset. It's a short, focused period where a team keeps delivering what it has committed to, finds out where the time is really going, and fixes it.

Santhosh shares how his team discovered a critical problem. Every dashboard was green and every sprint looked successful. Then leadership asked what customers would actually get by the end of the quarter, and nobody could answer. That one question started the reset.

His big finding is simple. AI made writing code much faster, but code reviews and unclear release dates became the new slowdown.

Key topics covered:

What a 90-day engineering reset is, and why it isn't a way of blaming the team

The car service idea: keep driving while you find the problems

The one question to ask every engineer: what wastes your time every week?

Why code reviews can become the next engineering bottleneck as AI-generated code increases.

How to identify hidden blockers that traditional sprint metrics and green dashboards fail to reveal.

Whether you can still ship during a reset: keep customer commitments and pause lower-priority work

Why the first thing to stop is saying yes to new work

Why changing priorities every few weeks hurts team focus

What a decision log is and why it prevents the same debate twice

Simple habits to keep after the reset: fewer meetings and a weekly priority check

If you lead an engineering team, run a startup, or feel your team is busy but not delivering, this episode gives you simple steps to start this week.

Subscribe to GeekyAnts for more conversations on AI, software engineering, engineering leadership, product development, and the future of software.

Connect with Santhosh:

LinkedIn -   / santhosh-murthy-bk   

Connect with Prem:

LinkedIn -   / premgoswami   

Your dashboard is green. Your team is shipping. But is anyone actually better off?

In this episode of AI Thoughtmakers, we sit down with Yasuhiro, co-founder of a Japanese AI startup based in Osaka, for an honest conversation about how to tell whether an engineering team is truly healthy. AI can now produce code faster than ever, but more code doesn't mean better software.

Yasuhiro builds products for large Japanese companies, where quality expectations are extremely high. His team is spread across Japan and India, and he shares the simple habits that keep them focused on results instead of just staying busy.

Key topics covered:

• How a healthy team differs from one that only looks busy

• The one question he asks any engineering team: what is 100% quality, and what are your acceptance criteria?

• Why every task needs clear, measurable acceptance criteria before work starts

• How his team uses an AI agent to check that every task has them

• Why a green dashboard can still hide real problems

• What to do when everything is urgent, and why changing priorities without explaining them frustrates teams

• AI is great at doing the work. Deciding what the goal should be is a leadership job

• How to spot when too much knowledge sits with just one or two leaders

• Why his team meets in person every quarter in Bangalore or Tokyo

• How to build a team around people's strengths

• Two kinds of team goals: effort (how much was done) and outcome (what changed for the customer), reviewed together every quarter

• Why numbers are only a signal, and why you should always ask the person behind them

If you lead an engineering team, run a startup, or want a clearer way to judge whether your team is doing well, this episode gives you simple things you can try this week.

Subscribe for more conversations on AI, engineering, product development, and the future of software.

Connect with Yasuhiro:   / yasuhiro-nose-63845369   

Connect with Prem:   / premgoswami   

We spend a lot of time teaching AI agents how to act: when to send the email, when to fix the pipeline, when to write the code. But what if the smartest thing an agent can do is stop?

In this episode of AI Thoughtmakers, we sit down with Manu Muraleedharan, Solution Architect at ServerlessGuru, for a practical conversation on building AI systems that know when not to act. With 20+ years in software and the last two focused on AI, Manu shares what his team learned after putting agents into DevOps and data pipelines.

From the three questions that decide whether an agent should act, to why loan approvals and hiring decisions need a human in the loop, this is the episode for engineers, founders, and leaders who are giving AI agents more responsibility every month.

Key topics covered:

Why knowing when not to act is critical for AI agents

Why AI is trained to finish tasks, and why that makes "stop" hard to learn

When an AI agent should ask a human for help

How AI confidence scores can influence autonomous decisions

The three checks an AI agent should make before taking action: risk, reversibility, and confidence

How to limit risk by giving agents only the access they need, with a checking layer in between

Why AI could do 90% of the work while humans own the final 10%

Should AI approve loans? Why the answer is "it depends"

Why "more decisions made" is a bad way to measure an AI agent

The one kind of decision AI should never make

Why you should welcome an agent that says no

Where AI agents are heading over the next five years

If you're building with AI agents, managing a team that relies on them, or deciding how much freedom to give them, this episode gives you a clear way to think about it.

Subscribe for more conversations on AI, engineering, product development, and the future of software.

Connect with Manu:

LinkedIn -   / manumuraleedharan  

Connect with Prem:

LinkedIn -   / premgoswami   

There's a point where an AI agent stops being a tool your team uses — and starts being something your team depends on. That shift changes everything.

In this episode of AI Thoughtmakers, we sit down with Harsimranjit Singh Kler, R&D Specialist and Platform Architect at Nokia, for one of the most practically grounded conversations we've had about what happens when AI agents stop being productivity tools and become part of how engineering actually gets done.

With over ten years in software engineering — watching monoliths become microservices, data engineering rise, platform engineering evolve — Harsimranjit brings a perspective that's rare: he's seen every major shift in the industry, and he's watching this one up close from inside Nokia.

Key topics covered:

The moment you know AI agents have become infrastructure — not just AI tools

What coordination actually looks like when five teams are each running their own agents

Why documentation becomes critical for reliable AI agent workflows

What should travel with an agent's output when it hands off to another team

Why "agent done" is not the same as "team done" — and the Definition of Done concept that fixes this

How AI agents are finally pulling undocumented knowledge out of senior engineers' heads

What happens when two teams share one agent and one team changes it without telling the other

Why AI agents need versioning and release notes — just like APIs do

How to properly onboard a new engineer into a team that runs on agents

Why you can't retire an AI agent the way you delete an app — and how to do it right

What "urgent" means to support, engineering, and product — and why agents need a shared definition

Why agent identity, traceability, and proper guardrails are the next big thing in agent engineering

If you're building with AI agents, managing a team that uses them, or trying to figure out how to scale agent-driven workflows without things breaking — this is the most practical episode we've done on the topic.

Subscribe for more conversations on AI, engineering, product development, and the future of software.

Connect with Harsimranjit:

 LinkedIn -   / harsimranjit-singh-kler-a7209b17  

Connect with Prem:

 LinkedIn -   / premgoswami  

At 100 customers, everything works fine. At 1,000, engineers start paying attention. At 10,000, the system starts asking serious questions.

In this episode of AI Thoughtmakers, we sit down with Ankur Gupta, Solution Architect at OceanBase, for one of the most practical and honest conversations about what actually changes — technically and financially — when a product scales from its first hundred users to a hundred thousand.

This isn't a theoretical talk. It's a straight answer to the question every growing company eventually faces: if your system was built for where you started, will it hold up where you're going?

Key topics covered:

Why the biggest change when scaling isn't technical — it's the mindset of the people running the system

Why a well-built system for 100 customers can handle 10 lakh customers — if the basics are right

What typically breaks first when an application starts growing rapidly

Why cramming everything into one system is the most common and most expensive mistake

When your database stops being your friend — and what to do about it

What changes at the API layer when traffic multiplies — and what you don't actually need to rebuild

How to design systems that handle sudden traffic spikes and high workloads

The real story behind cost explosions — and how to scale without your cloud bill running away

Why a technically beautiful architecture can actually hurt your business

What you should never change when scaling — even when panic sets in

Why you should always build for tomorrow's traffic, not today's

If you're an engineer, tech lead, CTO, or founder thinking about what it takes to build something that actually scales — this episode will save you a lot of expensive lessons.

Subscribe for more conversations on AI, engineering, product development, and the future of software.

Connect with Ankur:

LinkedIn -   / ankurgupta30   

Connect with Prem:

LinkedIn -   / premgoswami   

There's a simple way to tell if a product is truly built around AI or just using it as an add-on. Remove the AI. If the product still works fine, it was never really AI native to begin with.

In this episode of AI Thoughtmakers, we sit down with Ashita Prasad, Developer Advocate at AWS, for one of the clearest and most grounded conversations we've had about what it actually means to build applications for the AI era — from how interfaces are changing, to why the information you give AI matters more than which AI you're using.

From whether microservices are dying (they're not — they're evolving), to what a software engineer's job actually looks like today, to what question every CEO should ask before building anything with AI — this episode will change how you think about what you're building and why.

Key topics covered:

The simple test that tells you if an application is truly AI native — or just AI enabled

Why interfaces aren't disappearing — they're just changing from click-based to intent-based

What product designers actually need to be thinking about now, and in five years

Why the information you give AI matters more than which AI model you're using

What AI should remember about users — and what it should forget

Why microservices aren't going anywhere — but they do need to be redesigned around user goals

How a software engineer's job has shifted from writing code to judgment and specification

Why one product engineer with AI isn't going to outperform a whole team just yet

The one question every CEO should ask before they start building

The biggest AI hype right now: autonomy without accountability

If you're a developer, product designer, tech lead, or founder trying to understand what building for the AI era actually means — this episode is one of the clearest explanations you'll find.

Subscribe for more conversations on AI, engineering, product development, and the future of software.

Connect with Ashita:

 LinkedIn -   / ashitaprasad   

Connect with Prem:

 LinkedIn -   /premgoswami   

Before AI, a team of four needed 36 to 48 hours to ship one MVP at a hackathon. Now two people can do it in eight hours. But does building faster actually mean building better? 

In this episode of AI Thoughtmakers, we sit down with Vinayak, who leads Developer Relations at Sevalla, to talk about how AI is redefining the Minimum Viable Product development. We cover what's changed since AI entered the picture, what hasn't, and why the real risk today isn't building too slowly, it's building the wrong thing very quickly. 

From the shrinking hackathon to one founder's costly lesson in skipping market research, to why "what should we not build" might be the most important question a team can ask, this is the episode for founders, product teams, and engineers rethinking how ideas become products in the AI era. 

Key topics covered: 

How AI is reducing MVP development time from days to hours

Why the fundamentals of a good MVP, like customer interviews and market research, still matter 

How non-technical founders can use AI to build and launch products

Are teams building MVPs too quickly, and what gets lost when they do 

A founder's story: shipping fast, gaining 50k+ users, then realizing the market was wrong 

Why AI hasn't reduced the need for people, just changed what teams look like 

Building a team of human members and AI agents working side by side 

Why AI helps engineers at every experience level, not just senior ones 

How enterprises should use AI for decisions: for gathering data, not for making the call 

Whether you're a founder deciding what to build next, a product manager weighing speed against validation, or an engineer curious about where judgment still matters most, this episode gives you a clearer way to think about building in the AI era. 

Subscribe for more conversations on AI, engineering, product development, and the future of software. 

Connect with Vinayak: LinkedIn -   / vinayakgavariya   

Connect with Prem: LinkedIn -   / premgoswami  

Giving your team access to AI tools doesn't make your company AI native. Not even close. Making AI work at enterprise scale requires the right engineering systems, codebase context, workflows, and measurement.

In this episode of AI Thoughtmakers, we sit down with Chaitanya Deorukhkar, Principal Engineer at Atlassian — the company behind Jira, Confluence, and Bitbucket — for one of the most honest and grounded conversations about what it actually takes to make AI work inside a large company.

Atlassian's codebase has over 500,000 files and millions of lines of code. When an AI agent steps into that environment without the right setup, it doesn't just slow down — it gets completely lost. Chaitanya breaks down exactly what that looks like, why throwing more information at AI doesn't always help, and how Atlassian built an internal tool to actually measure whether their AI setup is working or not.

This is not a conversation about hype. It's about the real, unglamorous engineering work that makes AI useful at scale.

Key topics covered:

• The difference between teams that use AI tools and teams that are truly built around AI

• Why the same AI that works great for a small startup completely breaks down in a company with 500,000+ files

• The kitchen analogy — why the environment around AI matters just as much as the AI itself

• How AI agents get lost in large codebases and waste time looking in the wrong places

• Why adding more information to AI doesn't always make it better — and can actually make things worse

• How Atlassian built an internal scoring tool to measure how well their AI agents are actually performing

• Why every team that owns a piece of the codebase should also be responsible for how well AI understands it

• How Jira, Confluence, and Bitbucket now work together so AI agents can see the full picture of what's happening in an organization

• Why writing code is no longer the hard part — and what the new bottlenecks actually are

If you're an engineer, tech lead, or anyone building AI into a real product at real scale — this episode will save you a lot of trial and error.

Subscribe for more conversations on AI, engineering, product development, and the future of software.

Connect with Chaitanya: LinkedIn -   / chaitanyadeorukhkar   

Connect with Prem: LinkedIn -   / premgoswami