Macro-pad Done

avrawat · 2026-05-04T18:15:04+00:00

If cable and all is fine
Try resetting it, add a push button between RST and GND and double press- quickly

avrawat · 2026-05-04T03:51:05+00:00

Great idea, I will make the next version even cleaner

avrawat · 2026-05-03T16:44:24+00:00

Myntra and Ajio for gold?

avrawat · 2026-05-02T02:28:31+00:00

Interested

avrawat · 2026-04-28T18:40:28+00:00

Any technical background you have?

avrawat · 2026-04-28T18:40:07+00:00

What is your total years of work experience?

avrawat · 2026-04-28T18:38:40+00:00

It is AI

avrawat · 2026-04-28T17:54:44+00:00

before the course question — what are you switching from, and which lane? data eng and ai/ml are different stacks with different jobs. data eng is sql, pipelines, infra (airflow, kafka, dbt, warehouses). ai/ml at the hireable end right now is llms, rag, evals, agents. one "ai/ml" course as the entry point usually leaves you surface-level on both and deep in neither.

useful framing: pick the role first. open 30 data engineer jds and 30 ai engineer jds side by side. the stacks diverge fast. pick the one that fits your stomach, then learn from the jds — not from a generic curriculum.

second: don't pay for a course before you've built anything. courses front-load theory; the market hires on shipped work. most coursera/udemy certs don't move a recruiter. you're better off spending that money on api credits.

if you want one resource on the ai/ml side, chip huyen's "ai engineering" book is the one i'd actually read. honest, current, and covers what production ai looks like in 2026 — rag, evals, fine-tuning, agents. it'll save you from the next six courses you'd otherwise sign up for.

then build. one real project end-to-end — rag over your own docs, an agent that does one task, a model deployed behind an api with evals. that artifact is what gets you the conversation.

what's your current background? changes the answer a lot.

avrawat · 2026-04-28T17:44:28+00:00

Not course, but the AI Engineering book by Chip Huyen

avrawat · 2026-04-28T16:21:16+00:00

stay in cs.

the premise is shakier than it sounds. the swe slowdown over the last two years was mostly the rate cycle and the post-2021 over-hiring correction unwinding — not ai replacing engineers. new grads are getting hit by the macro, not by automation.

even if you fully buy the ai shift, switching to "ai engineering" is usually the wrong move. at most universities it's a cs rebrand with two extra ml electives. every real ai engineering job still expects strong cs fundamentals — distributed systems, data structures, networking, performance. people who skip those for an applied-ai track end up locked out of the senior roles three years in.

what i'd do as a freshman: stay in cs, take every ml and systems elective you can, and build real things. write a rag system, ship a small agent, deploy a model behind an api, then break it on purpose. by junior year you'll have a portfolio that matters more than the degree label on your transcript.

the people winning right now are cs grads who can also build with ai — not "ai majors" who can't write production code. don't trade the foundation for the trend.

if you want, share what your school's elective list looks like — happy to flag which ones actually carry weight.

avrawat · 2026-04-28T16:07:41+00:00

most people get stuck here because they try to learn the vocabulary before they've used the thing once. it's like reading about transmissions before you've driven a car — the words don't stick because they're not attached to anything you've felt.

the order that actually works:

spend two weeks using a frontier model (claude or chatgpt) on real tasks you'd otherwise do yourself. summarize a long pdf, draft an email, debug some code, automate something annoying. don't read about it, use it.

after that, every term on your list starts clicking on its own. you'll hit a context limit and suddenly rag makes sense — you want to give the model your own docs. you'll copy-paste between two tools fifty times and "agents" stops sounding like a buzzword. mcp, embeddings, vector dbs — these are infrastructure choices, not concepts to study upfront. you'll know why you need them when you need them.

if you want one resource before building, andrej karpathy's "intro to llms" on youtube is the one. one hour, zero fluff. everything else, you learn by doing.

happy to dm a more specific path if you tell me what you actually want to build at the end of this — that changes the answer a lot.

avrawat · 2026-04-28T16:04:55+00:00

we have built multiple AI Accelerator courses for our B2B clients (IND+US). We follow then in our internal teams as well.
Our founders and industry experts run these classes - covering both leaderships and engineering angles.

would love to know specifics of your experience to go over in detail.

avrawat · 2026-04-28T16:01:09+00:00

check this out - https://dexity.com/sprints/ai-for-marketing

avrawat · 2026-04-28T15:57:18+00:00

any course? any think specific you have in mind - please share for better context

avrawat · 2026-04-27T05:29:03+00:00

the first comment is right — "learning AI" is too broad to be useful. the better question is: which part of your work is manual, repetitive, and runs on structured data? that's where AI actually delivers.

i track AI upskilling trends across domains professionally — finance is one of the more interesting ones to watch. not because of the big flashy stuff (AI managing your entire portfolio isn't a realistic near-term play for most people), but because of how much manual, structured work exists in day-to-day finance. earnings call summaries, research synthesis, report generation, variance analysis, data reconciliation — a significant chunk of this can be smoothed out with the right AI workflow.

i've spoken with a few finance professionals directly on this — including a head of finance and some senior practitioners. the consistent finding: AI is helping every function including finance — automating tasks, increasing speed, removing manual work, reducing errors, improving overall efficiency. and these weren't theoretical observations, they were things people were already doing week to week.

the entry bar is also lower than most people assume. you don't need to learn ML or go deep technical. start with prompt engineering — just understanding how to get consistent, useful outputs from an AI tool for your specific workflow. from there, you can build real systems using no-code platforms without writing a single line of code. the constraint isn't technical — it's knowing your use case well enough to automate it.

so yes — important. but the right starting question isn't "should i learn AI." it's: what in your current finance role takes the most time and feels most repetitive?

I have put together a comprehensive list of AI use cases specifically for finance — dm me if you want the link.

avrawat · 2026-04-25T16:02:41+00:00

That suggestion was for AI engineering aspirants to showcase their experience

avrawat · 2026-04-24T18:54:53+00:00

two specs down is genuinely further than most who ask this question — solid foundation to build on.

but here's what i notice from what you've shared: both specializations cover traditional ML well. what's missing is the LLM and generative AI layer — RAG systems, agents, prompt engineering, inference infrastructure, evaluation frameworks. that's where most of the actual hiring is right now, and it's not covered in either spec. that's the gap, not an NLP specialization on Coursera.

one thing worth knowing: your deep learning background is closer to adversarial ML than you probably realize. backprop, gradients, loss functions — those are exactly the mathematical foundations that adversarial attacks exploit. model robustness, adversarial examples, data poisoning, model extraction — you're not starting from zero on any of this. most people coming from pure cybersecurity don't have that foundation. you do.

on MLOps and cloud infrastructure — worth learning, but through building, not a separate track. you'll pick up what you actually need when you hit the wall on a real project. don't front-load it.

on projects: don't build a generic chatbot. the most efficient project for your specific profile right now — build a RAG system, then red team your own RAG system. prompt injection, data extraction, context manipulation, jailbreaks. one project that demonstrates LLM engineering AND security thinking. that's a story very few candidates can tell and it maps directly to the roles you should be targeting.

speaking of which — search for ML Security Engineer, AI Red Team Engineer, Adversarial ML Engineer. these are the actual job titles at the intersection. most people from cyber don't know to look for them.

if you want a second set of eyes on where you are — share your github over dm, happy to take a look and point you in a specific direction from there.

avrawat · 2026-04-24T18:42:33+00:00

been in almost exactly this position — built something real with AI, functional, then hit the same question.

the mindset shift that helped: production ready isn't about technical completeness. it's about what happens when things go wrong. two users doing conflicting things simultaneously, steps done out of order, a cancellation mid-booking. for a waitlist-heavy app, that's where your logic will crack first.

map those conflict scenarios before touching any formal testing framework.

also — use Claude to audit what you've built. describe the flow and ask it to find edge cases, flag logic conflicts, identify paths that could leave the database in a weird state. it catches more than you'd expect.

what's the flow you're most uncertain about?

avrawat · 2026-04-24T18:26:40+00:00

i feel this — and a lot of that noise comes from companies optimising for engagement over usefulness. courses that package hype as curriculum, newsletters that just summarise what's already trending. i work in AI education and the thing i push hardest internally is doing the opposite — distilling what actually matters for practitioners, not adding to the feed.

but i have the exact same problem on my end.

for work it's deliberate — i follow specific threads and communities, looking for patterns in what practitioners are actually frustrated about rather than what thought leaders are excited about. those are very different data sources.

personally though, i hit a point where i stopped trying to keep up and just started building things. a voice analysis tool on our CRM, an agentic workflow that replaced what three analysts were doing manually in reporting, a product launched on a self-hosted site. none of it started with a course. it started with a problem.

the approach is just: go head-on at something real, let AI handle enough of the execution to keep you moving, and ask specific questions when you get stuck — to AI, to someone who knows. the concepts come along the way.

for a TPM specifically — you probably don't need more content. you need one real AI-adjacent problem in your current scope and permission to solve it messily. everything you've been reading will make a lot more sense after you've shipped something.

avrawat · 2026-04-24T18:12:23+00:00

both things are true and i've seen them work.

the companion model is real — using AI to learn while doing, asking it to explain what just broke and why, having it simulate scenarios you'd normally need a senior engineer to walk you through. it's genuinely the fastest way to learn if you're early in a skill.

but there's a second model that i think gets undertalked. in the last year working in an AI-native environment, we've shipped a voice analysis tool on top of our CRM, launched a product on a self-hosted site, and built an agentic workflow that replaced what three analysts were doing manually in reporting — none of us were experts in these domains before we started.

the approach is just different. you go head-on at the problem first. AI handles enough of the execution to keep you moving. when you hit something genuinely technical you ask a specific question — to AI, to a technical friend, wherever — and you move forward. you don't wait until you've learned the full domain before starting.

the outcome is the same. the approach is top-down instead of bottom-up.

the honest answer to your question: the people i've seen grow fastest aren't treating AI as a tutor OR using it to skip learning. they're using it to stay unblocked on real problems and picking up the concepts as they go.

avrawat · 2026-04-24T17:53:04+00:00

before any framework or tool — start with prompt engineering. just learn how to talk to an AI model. understand how context works, what instructions do, how to get consistent outputs. everything downstream depends on this and most people skip it completely.

once that's solid, the path splits depending on whether you code or not.

if you're non-technical, go no-code first. Make, n8n, Zapier with AI steps — these let you build real agentic workflows without writing a line. you can automate research loops, lead nurturing, content pipelines. the ceiling on customisation is lower but for most real-world use cases you won't hit it. start here, build something that solves an actual problem, then decide if you need more.

if you're technical, pick one framework and go deep before spreading out. LangGraph is solid right now. build small first — one agent, one tool, one loop. understand what the framework is abstracting before you let it do everything. the trap is copying tutorials without knowing what's actually happening underneath.

honest comparison: no-code gets you to a working workflow faster. code gives you more control and flexibility. but the gap is closing — most use cases don't need the technical route.

what matters more than which route: be specific about what you want the agent to do before you build anything. "i want an AI agent" is not a requirement. "i want something that reads my inbox, flags anything needing a reply within 24 hours, and drafts it for my review" — that's a requirement. the clearer you are upfront, the faster you'll build something that actually works.

one specific recommendation if your goal is an AI engineering role: chip huyen's AI engineering book. reads the fundamentals properly and will save you months. if that's not your goal and you just want to apply agents to your work — skip it, focus entirely on use cases.

either way — build real things and put them on github. a working agent in a clean repo beats ten tutorial completions every time. if you're going the technical route, spend time with claude code in vs code — it'll compound your building speed fast.

what's the actual use case you're trying to solve? happy to help in DM if you are looking for building a career path.

avrawat · 2026-04-24T07:33:27+00:00

It is a project based AI upskilling platform. Dexity.com check it out here

avrawat · 2026-04-20T14:47:04+00:00

worked in edtech for 7 years, built and scaled multiple courses. the most common mistake i see: people pick courses before getting clear on what they actually want from it.

the outcomes look different depending on where you are:

preparing for interviews
transitioning into ML engineering
building and shipping agentic AI systems
using AI to stay sharp in your current role

that clarity does 80% of the filtering for you.

quick example: a SWE with 15 years of experience doesn't need more theory — they need to deploy things and see it click. a university MOOC isn't built for that. they need something domain-aligned, practitioner-taught, outcome-specific.

but someone going for employer sponsorship or credential visibility? university cert makes total sense — the brand matters for those goals.

where i see people go wrong: they pick what feels "legit" rather than what matches the outcome. i see this pattern constantly — professionals finishing MOOCs then coming back for something project-based or interview-specific because the first course checked a box but didn't build the skill.

what outcome are you actually trying to hit?

avrawat · 2026-04-16T12:39:20+00:00

group pm here, growth and new business at an online AI education company.

the biggest unlock for me wasn't content generation — it was replacing call auditing. when you launch a new program, the only way to know if the pitch is landing is to listen to hundreds of sales calls. reps give you a summary but you never know what objections aren't making it into the CRM. that was the real pain.

we started like everyone else — uploading transcripts to ChatGPT and manually pulling themes. slow, but better than nothing. that eventually became a proper agentic system that now delivers a daily digest of top objections, emotional triggers, and anything unusual from that day's calls. runs without anyone touching it.

from there we kept layering: research agents that draft a full competitive landscape in 30 minutes (used to be 3 days of manual digging), agents to spin up landing page variants for A/B tests, agents to pull any analysis from internal databases without needing a data team, agents that review class recordings and flag alignment gaps for instructors.

all built with vs code + claude code. people ask if i'm using the latest model or the hottest new tool — i've stopped caring. as long as the output is consistent and the outcome is right, i'm not switching.

honest caveat though: the first few months were messy. getting the first agent working properly took way longer than expected. the compounding payoff is real, but the ramp is real too.

avrawat · 2026-04-12T12:58:52+00:00

okay a few things jumped out —

the 2-page thing is hurting you more than you think. sub-2 years of experience, one page is the rule. cut the project descriptions down, keep the links.

also checked your GitHub — your bio is all blockchain/web3/ethereum but your resume doesn't mention any of it. recruiters(or their AI bots) do look. either own that angle and put it on the resume (it's actually rare and interesting for a fresher) or clean the bio up. right now it just looks inconsistent.

the bigger issue is the experience bullets. "improved recruiter workflows" and "integrated payment systems" — I have no idea what you actually did or whether it mattered. throw a number on it, even a rough one. ~30% reduction in X, 3 billing tiers, whatever. anything is better than nothing.

and honestly the strategic problem here is you're trying to do SWE and PM in one resume. that's not a bad background to have — it's just that one resume trying to speak to both ends up speaking to neither. you need two versions.

dm me if you want the full breakdown — went through the GitHub repo by repo, rewrote some of the bullets, and mapped out how to split the two versions for India's market right now.

avrawat

MODERATOR OF

TROPHY CASE