![\"Advertisement\"](\"https:\/\/techpaathshala.com\/blog\/wp-content\/uploads\/2026\/04\/WhatsApp-Image-2026-04-20-at-11.47.35-AM-1-1.jpeg\")
<\/a><\/div>\n\n\n\n
\n\n\n\nWhat I Actually Knew About AI \u2014 Which Was Not Much<\/h2>\n\n\n\n
Let me be honest about where I was starting from, because I think this matters for anyone reading this who is in a similar position.<\/p>\n\n\n\n
I was not a data scientist. I had not taken ML courses in college \u2014 my engineering curriculum had one elective on machine learning that I had skipped in favour of a web development course. I did not know what a transformer architecture was. I had a vague conceptual understanding that neural networks existed and that they involved matrix multiplication, and that was roughly where my knowledge stopped.<\/p>\n\n\n\n
What I did know was software engineering. I understood APIs. I understood databases. I understood how to architect a system, how to handle async operations, how to write code that other people could maintain. I understood Git workflows, deployment pipelines, environment configurations, and the difference between code that works in development and code that works in production.<\/p>\n\n\n\n
I did not know it at the time, but this foundation \u2014 the full stack engineering foundation that felt so unremarkable to me \u2014 was going to be the most important thing I brought to the GenAI engineering world. Not despite the fact that I was not an ML researcher. Because of it.<\/p>\n\n\n\n
\n\n\n\nThe First Month: Everything Felt Overwhelming, Then It Didn’t<\/h2>\n\n\n\n
I gave myself a rule: one hour every evening, no exceptions, no scrolling, just learning. I started with the most obvious entry point \u2014 the OpenAI API documentation.<\/p>\n\n\n\n
The first thing that happened was reassuring in a way I had not expected. Calling the OpenAI API from Node.js looked almost identical to calling any other REST API I had ever used. POST request. JSON body. JSON response. Rate limiting and error handling patterns I already knew. The syntax was familiar. The mental model was familiar.<\/p>\n\n\n\n
import Anthropic from \"@anthropic-ai\/sdk\";\n\nconst client = new Anthropic();\n\nconst message = await client.messages.create({\n model: \"claude-opus-4-5\",\n max_tokens: 1024,\n messages: [{ role: \"user\", content: \"Explain this error: \" + errorLog }],\n});\n\nconsole.log(message.content);\n<\/code><\/pre>\n\n\n\nI had expected AI engineering to feel like entering a foreign country where everything was different. The API call felt like home. The difference was in what happened after \u2014 in understanding what to do with the model, how to structure prompts that produced reliable output, what happened when the output was wrong, and how to build something around this API that was actually useful to a real user.<\/p>\n\n\n\n
That is where the learning curve was. And that is where the first month took me.<\/p>\n\n\n\n
I spent the first two weeks building toy projects. A debugging assistant that took error logs and explained them. A commit message generator that read git diff<\/code> output and wrote conventional commit messages. A code review tool that checked for common security issues in Express.js routes. None of these were products. They were practice \u2014 a way to build intuition about what LLMs were good at, where they failed, and what the engineering around them looked like.<\/p>\n\n\n\nBy the end of the first month, I had a working intuition that I could not have gotten from reading. LLMs are excellent at pattern recognition and generation. They are unreliable on specific facts. They produce plausible-sounding wrong answers with the same confidence as correct ones. The quality of the output is almost entirely determined by the quality of the input \u2014 and “input” means not just the user’s message, but the system prompt, the context, the examples, and the constraints.<\/p>\n\n\n\n
This last insight \u2014 that prompt engineering is a real engineering discipline, not a gimmick \u2014 was the one that changed how I thought about the whole field.<\/p>\n\n\n\n
\n\n\n\nMonth Two: The Moment RAG Changed Everything<\/h2>\n\n\n\n
The second month was when I moved from “interesting toy projects” to “something that could actually be useful in a real product.”<\/p>\n\n\n\n
The project was a documentation assistant for a codebase at work. Our internal engineering wiki had grown to hundreds of pages over four years, and nobody could find anything in it. New developers spent their first two weeks asking senior developers questions that were already answered somewhere in Confluence \u2014 if only they knew where to look.<\/p>\n\n\n\n
I had the documentation. I had a working LLM integration. The problem was that the LLM did not know what was in the documentation.<\/p>\n\n\n\n
This is when I encountered RAG \u2014 Retrieval-Augmented Generation \u2014 for the first time. Not as a concept in a blog post, but as the specific solution to a specific problem I was trying to solve.<\/p>\n\n\n\n
The idea was simple enough: chunk the documentation into pieces, convert each piece into a vector embedding, store those embeddings in a vector database, and at query time, retrieve the most relevant chunks and pass them to the LLM as context. The LLM answers the question using the actual documentation content \u2014 not its training knowledge.<\/p>\n\n\n\n
The implementation took me a week of evenings to get working. LangChain for the pipeline, Pinecone for the vector store, OpenAI’s embedding model for the embeddings. I deployed it as an internal Slack bot, connected to our engineering channel.<\/p>\n\n\n\n
The day I deployed it, three senior developers used it to answer questions they would previously have pinged me about. One of them sent me a Slack message: “Did you build this? This is genuinely useful.”<\/em><\/p>\n\n\n\nThat Slack message was the moment the switch stopped feeling abstract. I had built something that solved a real problem using AI engineering patterns. The full stack skills \u2014 Node.js, API integration, deployment, error handling \u2014 had done most of the work. The new skills \u2014 RAG architecture, vector databases, prompt engineering \u2014 had been the differentiating layer on top.<\/p>\n\n\n\n
This is the pattern I would encounter repeatedly over the next months: full stack skills as foundation, AI engineering knowledge as the layer that makes the foundation suddenly capable of something new.<\/strong><\/p>\n\n\n\n
\n\n\n\nMonth Three: The Hard Part Nobody Talks About<\/h2>\n\n\n\n
Month three was harder than the first two, and I want to be honest about why.<\/p>\n\n\n\n
The first two months had the energy of novelty. Everything was new. Progress was visible every week. The learning curve was steep but the slope was upward.<\/p>\n\n\n\n
Month three was where I hit the complexity layer that YouTube tutorials and quick-start guides do not prepare you for. Not the conceptual complexity of AI \u2014 the engineering complexity of building AI features that are reliable, observable, and production-ready.<\/p>\n\n\n\n
The reliability problem.<\/strong> My RAG system worked well most of the time. But “most of the time” is not a production standard. When retrieval failed \u2014 when the wrong chunks were fetched, when the query was ambiguous, when the documentation was outdated \u2014 the system gave confidently wrong answers. I did not have a systematic way to detect when this was happening.<\/p>\n\n\n\nI spent two weeks building an evaluation framework: a set of test queries with known correct answers, automated comparison of system responses against those answers, a dashboard that tracked retrieval quality over time. This is engineering work \u2014 tedious, necessary, unglamorous \u2014 that has nothing to do with AI and everything to do with building software that can be trusted.<\/p>\n\n\n\n
The observability problem.<\/strong> When something went wrong in production, I had no visibility into which step had failed. Had the retrieval returned poor chunks? Had the prompt been too ambiguous? Had the LLM reasoned incorrectly from correct context? Without logging at every step of the pipeline, debugging was archaeology.<\/p>\n\n\n\nI rebuilt the pipeline with structured logging at every stage: what query was received, what chunks were retrieved, what prompt was constructed, what the LLM returned, what the user saw. This sounds obvious in retrospect. I had to learn it by debugging in the dark.<\/p>\n\n\n\n
The context window management problem.<\/strong> As I added more features \u2014 conversation history, larger document sets, more complex system prompts \u2014 I kept hitting context window limits. Too much context slowed responses and cost more. Too little context degraded quality. Managing what went into the context window, in what order, at what length, became a real engineering discipline.<\/p>\n\n\n\nMonth three taught me that AI engineering is not primarily about AI. It is primarily about software engineering \u2014 applied to a type of system that has probabilistic rather than deterministic behaviour, and that requires different debugging, evaluation, and monitoring approaches as a result. The developers who build the most reliable AI systems are the ones who bring strong software engineering foundations to those challenges.<\/p>\n\n\n\n
This was reassuring. I had that foundation.<\/p>\n\n\n\n
\n\n\n\nMonth Four: The First Real Interview<\/h2>\n\n\n\n
By month four, I had a portfolio. The Slack documentation bot. A customer support triage tool I had built as a side project \u2014 a system that read incoming support emails, classified them by type and urgency, generated a draft response, and flagged edge cases for human review. A simple agent built with LangGraph that could search a product catalogue and answer inventory questions.<\/p>\n\n\n\n
I started applying. Not aggressively \u2014 two or three applications a week, targeted at companies where the role description mentioned LLM integration, RAG, or AI product development rather than “experience with ML algorithms.”<\/p>\n\n\n\n
The first interview that went to the technical round was at a Mumbai FinTech company in BKC. The role was “AI Product Engineer” \u2014 a title that did not exist two years ago and was now appearing in job postings across the city.<\/p>\n\n\n\n
The technical interview had two parts. The first was a system design question: design a document processing pipeline that extracts key information from loan application PDFs and routes applications for approval based on defined criteria. The second was a code review: read a provided RAG implementation and identify its failure modes.<\/p>\n\n\n\n
I cleared both. Not because I was the most technically brilliant candidate in the pool. Because I could think like a product engineer about an AI system \u2014 asking about reliability, failure modes, user experience when the system is wrong, cost at scale, monitoring \u2014 while also being able to implement the system in code.<\/p>\n\n\n\n
The offer came three weeks after the interview. The salary was 40% higher than what I had been earning as a full stack developer. The role title was GenAI Engineer.<\/p>\n\n\n\n
I took it.<\/p>\n\n\n\n
\n\n\n\nWhat Actually Changed \u2014 and What Did Not<\/h2>\n\n\n\n
Six months into the GenAI Engineer role, I want to be precise about what the transition actually involved \u2014 because the narrative of “I changed everything” is not accurate, and the accurate version is more useful for anyone considering a similar move.<\/p>\n\n\n\n
What changed:<\/strong><\/p>\n\n\n\nThe nature of the problems I work on. Instead of building UI components and REST APIs for defined requirements, I design and build systems whose outputs are probabilistic \u2014 where the definition of “correct” is more complex, where edge cases are harder to enumerate, and where quality is a continuous dimension rather than a binary pass\/fail.<\/p>\n\n\n\n
The skills I am actively developing. Prompt engineering at a production level. RAG pipeline design. Evaluation methodology for AI systems. LLM selection and cost optimisation. Agent workflow design. These are new domains that I am still building depth in.<\/p>\n\n\n\n
The conversations I have at work. I spend significantly more time discussing product behaviour, user expectations, failure modes, and quality trade-offs than I did as a full stack developer. The intersection of AI capability and product design requires more nuanced technical-business conversation than feature development on a defined spec.<\/p>\n\n\n\n
What did not change:<\/strong><\/p>\n\n\n\nThe fundamentals. I still write Node.js. I still design API contracts. I still think about database schemas. I still care about error handling, logging, deployment, and performance. The full stack engineering foundation did not become irrelevant \u2014 it became the platform on which the AI layer is built.<\/p>\n\n\n\n
The way I approach problem-solving. I still start with the user’s actual problem. I still ask what “done” looks like before writing code. I still prefer simple solutions over clever ones. These habits, formed over four years of product engineering, are if anything more valuable in AI engineering where the temptation to over-engineer is significant.<\/p>\n\n\n\n
The importance of communication. If anything, the GenAI role has made communication more important, not less. Explaining to a product manager why an AI system will occasionally give imperfect answers \u2014 and why that is acceptable within defined bounds \u2014 requires the same skill as explaining technical debt to a non-technical stakeholder. The full stack years built this muscle.<\/p>\n\n\n\n
\n\n\n\nWhat I Would Tell the Developer Sitting at That Desk<\/h2>\n\n\n\n
If I could go back to that Tuesday evening in Powai \u2014 to the developer sitting at the desk staring at the done column feeling nothing \u2014 here is what I would say.<\/p>\n\n\n\n
Your full stack skills are not a consolation prize for not being an ML researcher.<\/strong> They are the exact skills that make AI features actually work in production. The world has enough people who can explain transformer architectures. It has far fewer people who can build reliable, observable, maintainable AI systems that real users depend on. The combination of product engineering foundation and AI engineering knowledge is genuinely rare and genuinely valuable.<\/p>\n\n\n\nStart with the API call, not the theory.<\/strong> You do not need to understand backpropagation before you build your first useful AI feature. You need to call the API, see what comes back, and start building intuition from there. The theory becomes meaningful when you have practical experience to attach it to.<\/p>\n\n\n\nBuild real things, not tutorial projects.<\/strong> The learning that sticks comes from solving actual problems \u2014 your own problems, your team’s problems, problems you care about enough to debug at 10 PM. Tutorial projects teach you the syntax. Real problems teach you the engineering.<\/p>\n\n\n\nTreat prompt engineering seriously.<\/strong> This is the skill that most determines the quality of everything built on top of LLMs. It is learnable, it is improvable, and it is undervalued by developers who assume that it is not “real” engineering. It is real engineering. Invest in it.<\/p>\n\n\n\nThe full stack to GenAI engineer career switch is not a leap.<\/strong> It is a bridge \u2014 built on skills you already have, extended into a domain that is moving faster than almost any other in the industry right now. The bridge is walkable. The other side is worth it.<\/p>\n\n\n\n
\n\n\n\nThe Mumbai Factor<\/h2>\n\n\n\n
One more thing, because place matters.<\/p>\n\n\n\n
Mumbai is a specific context for this transition. The companies hiring GenAI engineers here are not primarily AI research labs \u2014 they are FinTech companies, e-commerce platforms, logistics firms, SaaS businesses, and consulting practices that are building AI into real products for real Indian markets.<\/p>\n\n\n\n
These companies need engineers who understand LLM integration and understand product engineering. They need people who can talk to a business stakeholder about what an AI feature can and cannot reliably do, and then go build it. They need the profile that a full stack developer who has extended into GenAI engineering represents.<\/p>\n\n\n\n
The \u20b918L\u2013\u20b930L salary bracket for GenAI Engineer roles in BKC, Andheri, and Powai is not aspirational marketing. It is what the market is paying for a profile that is genuinely rare and genuinely in demand.<\/p>\n\n\n\n
The gap between where you are and where that bracket is \u2014 for a working full stack developer \u2014 is smaller than it looks from the outside. It is measured in months of deliberate learning, not years of career reinvention.<\/p>\n\n\n\n
I started on a Tuesday evening in Powai, staring at a done column.<\/p>\n\n\n\n
You can start today.<\/p>\n","protected":false},"excerpt":{"rendered":"
I remember the exact moment I decided to make the switch. It was a Tuesday evening in July 2024. I was sitting at my desk in our company’s Powai office \u2014 one of those open-plan floors where everyone can see everyone else’s screen \u2014 debugging a React component that had been broken for three days. […]<\/p>\n","protected":false},"author":1,"featured_media":822,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"ocean_post_layout":"","ocean_both_sidebars_style":"","ocean_both_sidebars_content_width":0,"ocean_both_sidebars_sidebars_width":0,"ocean_sidebar":"","ocean_second_sidebar":"","ocean_disable_margins":"enable","ocean_add_body_class":"","ocean_shortcode_before_top_bar":"","ocean_shortcode_after_top_bar":"","ocean_shortcode_before_header":"","ocean_shortcode_after_header":"","ocean_has_shortcode":"","ocean_shortcode_after_title":"","ocean_shortcode_before_footer_widgets":"","ocean_shortcode_after_footer_widgets":"","ocean_shortcode_before_footer_bottom":"","ocean_shortcode_after_footer_bottom":"","ocean_display_top_bar":"default","ocean_display_header":"default","ocean_header_style":"","ocean_center_header_left_menu":"","ocean_custom_header_template":"","ocean_custom_logo":0,"ocean_custom_retina_logo":0,"ocean_custom_logo_max_width":0,"ocean_custom_logo_tablet_max_width":0,"ocean_custom_logo_mobile_max_width":0,"ocean_custom_logo_max_height":0,"ocean_custom_logo_tablet_max_height":0,"ocean_custom_logo_mobile_max_height":0,"ocean_header_custom_menu":"","ocean_menu_typo_font_family":"","ocean_menu_typo_font_subset":"","ocean_menu_typo_font_size":0,"ocean_menu_typo_font_size_tablet":0,"ocean_menu_typo_font_size_mobile":0,"ocean_menu_typo_font_size_unit":"px","ocean_menu_typo_font_weight":"","ocean_menu_typo_font_weight_tablet":"","ocean_menu_typo_font_weight_mobile":"","ocean_menu_typo_transform":"","ocean_menu_typo_transform_tablet":"","ocean_menu_typo_transform_mobile":"","ocean_menu_typo_line_height":0,"ocean_menu_typo_line_height_tablet":0,"ocean_menu_typo_line_height_mobile":0,"ocean_menu_typo_line_height_unit":"","ocean_menu_typo_spacing":0,"ocean_menu_typo_spacing_tablet":0,"ocean_menu_typo_spacing_mobile":0,"ocean_menu_typo_spacing_unit":"","ocean_menu_link_color":"","ocean_menu_link_color_hover":"","ocean_menu_link_color_active":"","ocean_menu_link_background":"","ocean_menu_link_hover_background":"","ocean_menu_link_active_background":"","ocean_menu_social_links_bg":"","ocean_menu_social_hover_links_bg":"","ocean_menu_social_links_color":"","ocean_menu_social_hover_links_color":"","ocean_disable_title":"default","ocean_disable_heading":"default","ocean_post_title":"","ocean_post_subheading":"","ocean_post_title_style":"","ocean_post_title_background_color":"","ocean_post_title_background":0,"ocean_post_title_bg_image_position":"","ocean_post_title_bg_image_attachment":"","ocean_post_title_bg_image_repeat":"","ocean_post_title_bg_image_size":"","ocean_post_title_height":0,"ocean_post_title_bg_overlay":0.5,"ocean_post_title_bg_overlay_color":"","ocean_disable_breadcrumbs":"default","ocean_breadcrumbs_color":"","ocean_breadcrumbs_separator_color":"","ocean_breadcrumbs_links_color":"","ocean_breadcrumbs_links_hover_color":"","ocean_display_footer_widgets":"default","ocean_display_footer_bottom":"default","ocean_custom_footer_template":"","ocean_post_oembed":"","ocean_post_self_hosted_media":"","ocean_post_video_embed":"","ocean_link_format":"","ocean_link_format_target":"self","ocean_quote_format":"","ocean_quote_format_link":"post","ocean_gallery_link_images":"on","ocean_gallery_id":[],"footnotes":""},"categories":[3],"tags":[],"class_list":["post-786","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-data-analytics","entry","has-media"],"acf":[],"_links":{"self":[{"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/posts\/786","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/comments?post=786"}],"version-history":[{"count":2,"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/posts\/786\/revisions"}],"predecessor-version":[{"id":904,"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/posts\/786\/revisions\/904"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/media\/822"}],"wp:attachment":[{"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/media?parent=786"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/categories?post=786"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/tags?post=786"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}