<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: krishna teja</title>
    <description>The latest articles on DEV Community by krishna teja (@kteja4000).</description>
    <link>https://dev.to/kteja4000</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3994441%2F9850396f-25f0-48ce-b6a7-41913a892554.jpg</url>
      <title>DEV Community: krishna teja</title>
      <link>https://dev.to/kteja4000</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/kteja4000"/>
    <language>en</language>
    <item>
      <title>Domain Knowledge Beats Model Complexity</title>
      <dc:creator>krishna teja</dc:creator>
      <pubDate>Mon, 24 Aug 2026 13:10:40 +0000</pubDate>
      <link>https://dev.to/kteja4000/domain-knowledge-beats-model-complexity-4ch9</link>
      <guid>https://dev.to/kteja4000/domain-knowledge-beats-model-complexity-4ch9</guid>
      <description>&lt;p&gt;There is a natural tendency in ML to reach for complexity the moment performance drops. We throw more layers at it, add data augmentation, or stack another ensemble.&lt;/p&gt;

&lt;p&gt;But in ADAS decision modeling, some of the highest value moves come from better features but not more of them.&lt;/p&gt;

&lt;p&gt;Think about the metrics that actually matter on the road:&lt;br&gt;
-&amp;gt; Time-to-collision&lt;br&gt;
-&amp;gt; Lateral velocity relative to the ego path&lt;br&gt;
-&amp;gt; Lane confidence scores&lt;br&gt;
-&amp;gt; Road curvature&lt;/p&gt;

&lt;p&gt;When you encode the domain reasoning into features, decision trees can learn with less depth and more stability.&lt;/p&gt;

&lt;p&gt;A shallow tree with well engineered features is almost always more trustworthy in production than a deep tree built on raw sensor noise.&lt;/p&gt;

&lt;p&gt;Domain knowledge doesn't compete with ML. It actually makes ML work.&lt;/p&gt;

&lt;p&gt;What is the one feature that improved your model more than any architecture change?&lt;/p&gt;

</description>
      <category>ai</category>
      <category>datascience</category>
      <category>machinelearning</category>
    </item>
    <item>
      <title>Beyond Gradient Descent: How Model Optimization Determines Failure Modes</title>
      <dc:creator>krishna teja</dc:creator>
      <pubDate>Tue, 18 Aug 2026 11:28:47 +0000</pubDate>
      <link>https://dev.to/kteja4000/beyond-gradient-descent-how-model-optimization-determines-failure-modes-3j3p</link>
      <guid>https://dev.to/kteja4000/beyond-gradient-descent-how-model-optimization-determines-failure-modes-3j3p</guid>
      <description>&lt;p&gt;Everyone learns gradient descent early. It becomes the default model for how machine learning works.&lt;/p&gt;

&lt;p&gt;Then you dig into decision trees and there is no gradient descent at all.&lt;/p&gt;

&lt;p&gt;Trees learn by greedy split search. At each node, the algorithm tests thousands of thresholds, picks the one that most reduces impurity, and repeats.&lt;/p&gt;

&lt;p&gt;This matters more than it sounds.&lt;/p&gt;

&lt;p&gt;Because of the search is greedy, early splits carry massive weight. A weak top-level split where the tree first divides your data into every branch below it. You can't fix a bad root split by tuning later layers. &lt;/p&gt;

&lt;p&gt;Working in ADAS,  this introduces a major vulnerability. A small shifts in training data like a new weather condition, can produce an entirely different tree with a completely different decision structure.&lt;/p&gt;

&lt;p&gt;Optimization method determines failure mode. Knowing how a model learns tells you exactly how it will break.&lt;/p&gt;

&lt;p&gt;What’s a foundational assumption about ML optimization you held early on that you later had to unlearn?&lt;/p&gt;

&lt;h1&gt;
  
  
  MachineLearning #ADAS #AIEngineering #AutonomousVehicles #MLFundamentals
&lt;/h1&gt;

</description>
      <category>algorithms</category>
      <category>computerscience</category>
      <category>machinelearning</category>
    </item>
    <item>
      <title>Why Safety Critical AI Needs Cost Sensitive Loss Functions</title>
      <dc:creator>krishna teja</dc:creator>
      <pubDate>Wed, 12 Aug 2026 10:42:29 +0000</pubDate>
      <link>https://dev.to/kteja4000/why-safety-critical-ai-needs-cost-sensitive-loss-functions-3h53</link>
      <guid>https://dev.to/kteja4000/why-safety-critical-ai-needs-cost-sensitive-loss-functions-3h53</guid>
      <description>&lt;p&gt;Most engineers treat the loss function as a purely technical choice but in safety critical systems like ADAS, it’s actually an operational one.&lt;/p&gt;

&lt;p&gt;Take decision trees as a example. They split data by reducing impurity, and measuring how mixed outcomes are in each branch to create cleaner, are uniform groups. It's good on paper but mathematically clean splits can still be operationally dangerous which are called overfitting.&lt;/p&gt;

&lt;p&gt;If a model treats a pedestrian stepping into the road the same as one on the sidewalk, the numbers might look okay. But in a real vehicle driving scenario, that's exactly the kind of guess you can't take.&lt;/p&gt;

&lt;p&gt;The real question is not "Does this split lower the impurity score?"&lt;br&gt;
It is "Does this split actually separate the scenarios the car needs to handle differently?"&lt;/p&gt;

&lt;p&gt;In ADAS, a false negative on a pedestrian doesn't carry the same cost as a false negative on a stationary cone. A standard impurity metric doesn't know the actual difference. It just sees numbers.&lt;/p&gt;

&lt;p&gt;Your loss function has to reflect the real-world cost structure of your problem, not just not just make the training chart look pretty.&lt;/p&gt;

&lt;p&gt;How do you handle cost-sensitive decisions in your models?&lt;/p&gt;

&lt;h1&gt;
  
  
  ADAS #SafetyAI #MachineLearning #AI #AutonomousVehicles #PhysicalAI
&lt;/h1&gt;

</description>
      <category>ai</category>
      <category>computerscience</category>
      <category>data</category>
      <category>machinelearning</category>
    </item>
    <item>
      <title>AI Isn't Magic. It's Just Evidence Gathering</title>
      <dc:creator>krishna teja</dc:creator>
      <pubDate>Sat, 04 Jul 2026 16:11:42 +0000</pubDate>
      <link>https://dev.to/kteja4000/ai-isnt-magic-its-just-evidence-gathering-43ee</link>
      <guid>https://dev.to/kteja4000/ai-isnt-magic-its-just-evidence-gathering-43ee</guid>
      <description>&lt;p&gt;My career in ADAS and Autonomous Vehicles taught me something important. The machines that drive themselves are not magic. They are just highly structured, evidence gathering systems.&lt;/p&gt;

&lt;p&gt;Sensors collect data, algorithms weigh them, probabilities are computed, and decisions are made accordingly.&lt;/p&gt;

&lt;p&gt;When I started diving deeper into the broader AI space, I realized the underlying framework is exactly the same. Building a reliable LLM application isn't that different from teaching an ADAS system to distinguish between a real obstacle and a shadow.&lt;/p&gt;

&lt;p&gt;The domain changed but thinking framework didn't.&lt;/p&gt;

&lt;p&gt;I spent years in ADAS working on scenario validation, simulation testing, and analyzing how ADAS systems fail in edge cases. Now, I’m bringing that same thinking into AI engineering. I find myself asking the same questions that When does this break? What data is it missing? How does the system behave when it's wrong?&lt;/p&gt;

&lt;p&gt;I'm excited about where this leads and I plan on sharing what I learn along the way. If you made a similar pivot from hardware, robotics, or safety critical engineering into AI, I’d love to connect. &lt;/p&gt;

&lt;h1&gt;
  
  
  AutonomousVehicles #ArtificialIntelligence #ADAS #AutonomousDriving #AIEngineering
&lt;/h1&gt;

</description>
      <category>ai</category>
      <category>autonomousvehicles</category>
      <category>autonomousdriving</category>
      <category>software</category>
    </item>
    <item>
      <title>AI Is No Longer a Luxury. It's a Workspace Necessity.</title>
      <dc:creator>krishna teja</dc:creator>
      <pubDate>Sat, 20 Jun 2026 17:32:12 +0000</pubDate>
      <link>https://dev.to/kteja4000/ai-is-no-longer-a-luxury-its-a-workspace-necessity-27dk</link>
      <guid>https://dev.to/kteja4000/ai-is-no-longer-a-luxury-its-a-workspace-necessity-27dk</guid>
      <description>&lt;p&gt;I used to think AI was just hype. until a complex engineering roadblock forced me to change my mind. &lt;/p&gt;

&lt;p&gt;A while back, my team and I got completely stuck on a physics-based integration problem. We spent over a week trying to calculate a specific torque value, Nothing worked. Every approach hit a wall. Out of options, I decided to feed the right context, constraints, and data into an LLM.&lt;/p&gt;

&lt;p&gt;The solution it suggested worked beautifully and broke our deadlock.  &lt;/p&gt;

&lt;p&gt;That was my wake up call. I realized AI isn't an elite club reserved only for software purists and PhDs. It's a powerful tool for anyone eager to learn and ask the right questions.  &lt;/p&gt;

&lt;p&gt;Since then, I have pivoted from being skeptical about coding to diving into AI algorithms, MLOps, and automation every single day. I am not an expert, but I am an active builder and learner.  &lt;/p&gt;

&lt;p&gt;AI is shifting from a technical luxury to an everyday workspace necessity. It's proving that being a quick learner is far more valuable than sticking to a rigid job description.  &lt;/p&gt;

&lt;p&gt;Have you ever had a specific "lightbulb moment" where AI completely changed how you solved a tough problem at work?&lt;/p&gt;

&lt;h1&gt;
  
  
  AIInEngineering #AI #LLM #ProblemSolving #PracticalAI #GenerativeAI #TechJourney #Upskilling
&lt;/h1&gt;

</description>
      <category>ai</category>
      <category>learning</category>
      <category>llm</category>
      <category>productivity</category>
    </item>
  </channel>
</rss>
