<?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: Krish Khati</title>
    <description>The latest articles on DEV Community by Krish Khati (@krish-khati).</description>
    <link>https://dev.to/krish-khati</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%2F4170659%2F20cfc6dd-2d73-46a2-b533-9e82751c771e.jpeg</url>
      <title>DEV Community: Krish Khati</title>
      <link>https://dev.to/krish-khati</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/krish-khati"/>
    <language>en</language>
    <item>
      <title>Manual review as a reminder</title>
      <dc:creator>Krish Khati</dc:creator>
      <pubDate>Wed, 14 Oct 2026 14:49:17 +0000</pubDate>
      <link>https://dev.to/krish-khati/manual-review-as-a-reminder-149f</link>
      <guid>https://dev.to/krish-khati/manual-review-as-a-reminder-149f</guid>
      <description>&lt;p&gt;I switched the repository back to draft mode today, just to make sure the next release goes through a manual review step. The change itself is a single line in the CI config, but it reminded me how often I rely on automation to push code forward without stopping to look at the output. In a project that mixes AI model serving with a small web front‑end, the temptation is to let the pipeline run unchecked because it saves time. Yet the moment I add a manual gate, I notice the small things that would otherwise be missed: documentation drift, version mismatches, or a model that was retrained but not re‑exported.&lt;/p&gt;

&lt;p&gt;This pause forces me to think about the balance between speed and safety. Speed is attractive when you’re trying to ship features quickly, especially as an indie developer juggling multiple responsibilities. Safety, on the other hand, protects the credibility of the tool when users start depending on it. I’m not looking for a perfect solution; I’m looking for a habit that keeps the codebase honest.&lt;/p&gt;

&lt;p&gt;I also see a parallel with the content I publish about my work. Draft mode on the repo feels like the draft stage of an article—something you can share with a trusted few before announcing it broadly. The discipline of reviewing my own words before they go public is the same discipline I need for code. I’ll keep treating both as iterative processes that benefit from occasional manual checks. I will keep iterating on the workflow.&lt;/p&gt;

</description>
      <category>github</category>
      <category>ai</category>
      <category>automation</category>
    </item>
    <item>
      <title>Live Publishing Unlocked – My First Quality‑Checked Deploy</title>
      <dc:creator>Krish Khati</dc:creator>
      <pubDate>Tue, 13 Oct 2026 17:28:30 +0000</pubDate>
      <link>https://dev.to/krish-khati/live-publishing-unlocked-my-first-quality-checked-deploy-4ppk</link>
      <guid>https://dev.to/krish-khati/live-publishing-unlocked-my-first-quality-checked-deploy-4ppk</guid>
      <description>&lt;p&gt;I just pushed a tiny but mighty commit to &lt;strong&gt;ai‑deploy&lt;/strong&gt; (&lt;code&gt;Krish‑Khati/ai-deploy&lt;/code&gt;) that adds &lt;em&gt;live publishing&lt;/em&gt; with a basic quality gate. 🎉  &lt;/p&gt;

&lt;p&gt;&lt;strong&gt;What’s the commit about?&lt;/strong&gt;&lt;br&gt;&lt;br&gt;
The new code flips a flag so the app can push updates straight to production &lt;strong&gt;only if&lt;/strong&gt; a quick sanity check passes (think “does the model load? does the endpoint respond?”). It’s a single‑file tweak, but it turns a manual, error‑prone rollout into a one‑liner.&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight python"&gt;&lt;code&gt;&lt;span class="c1"&gt;# ai_deploy/publish.py
&lt;/span&gt;&lt;span class="k"&gt;def&lt;/span&gt; &lt;span class="nf"&gt;can_publish&lt;/span&gt;&lt;span class="p"&gt;():&lt;/span&gt;
    &lt;span class="c1"&gt;# Simple health check: model loads and API is reachable
&lt;/span&gt;    &lt;span class="k"&gt;return&lt;/span&gt; &lt;span class="n"&gt;model&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;load&lt;/span&gt;&lt;span class="p"&gt;()&lt;/span&gt; &lt;span class="ow"&gt;and&lt;/span&gt; &lt;span class="n"&gt;requests&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;get&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="n"&gt;HEALTH_URL&lt;/span&gt;&lt;span class="p"&gt;).&lt;/span&gt;&lt;span class="n"&gt;ok&lt;/span&gt;

&lt;span class="k"&gt;if&lt;/span&gt; &lt;span class="nf"&gt;can_publish&lt;/span&gt;&lt;span class="p"&gt;():&lt;/span&gt;
    &lt;span class="nf"&gt;publish_live&lt;/span&gt;&lt;span class="p"&gt;()&lt;/span&gt;
&lt;span class="k"&gt;else&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt;
    &lt;span class="nf"&gt;print&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="sh"&gt;"&lt;/span&gt;&lt;span class="s"&gt;❌ Quality check failed – aborting deploy&lt;/span&gt;&lt;span class="sh"&gt;"&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;&lt;strong&gt;Why care?&lt;/strong&gt;&lt;br&gt;&lt;br&gt;
In fast‑moving AI projects, waiting for a full CI pipeline can stall experimentation. This commit gives us a &lt;strong&gt;fast‑track&lt;/strong&gt; path for low‑risk changes while still catching glaring issues. It’s not a replacement for full tests, but it’s a handy safety net for quick demos or internal spikes.&lt;/p&gt;

&lt;p&gt;Bottom line: a few lines, a tiny gate, and suddenly our CI feels a lot less like a bottleneck. Give it a spin and let me know if you spot edge cases—happy to iterate!&lt;/p&gt;

</description>
      <category>github</category>
      <category>ai</category>
      <category>automation</category>
    </item>
    <item>
      <title>I Taught Myself to Code Using AI Tools — Here's What Actually Worked (and What Didn't)</title>
      <dc:creator>Krish Khati</dc:creator>
      <pubDate>Sun, 11 Oct 2026 12:21:53 +0000</pubDate>
      <link>https://dev.to/krish-khati/i-taught-myself-to-code-using-ai-tools-heres-what-actually-worked-and-what-didnt-40c6</link>
      <guid>https://dev.to/krish-khati/i-taught-myself-to-code-using-ai-tools-heres-what-actually-worked-and-what-didnt-40c6</guid>
      <description>&lt;p&gt;_A year ago, I only knew Python and C. No CS degree, no bootcamp, just a laptop and a stubborn idea that I wanted to build real things. Today I've shipped a government-scheme-finder assistant, a voice-enabled AI assistant, a chatbot powered by Groq, and a 3D animated portfolio site — almost all of it with AI tools sitting right next to me as a pair programmer.&lt;/p&gt;

&lt;p&gt;Here's the honest version of what that journey looked like.&lt;/p&gt;

&lt;p&gt;The myth: "AI writes the code for you"&lt;/p&gt;

&lt;p&gt;It doesn't. What AI actually does is compress the time between not knowing and knowing. I'd ask it to explain a concept, break a bug, or scaffold a feature — but I still had to read every line, understand why it worked, and fix what it got wrong. The skill I ended up building wasn't "prompting." It was debugging faster because I had a tireless rubber duck that could also write code.&lt;/p&gt;

&lt;p&gt;What actually moved the needle&lt;br&gt;
Building real projects, not tutorials. Tutorials teach you syntax. Projects teach you how things break.&lt;br&gt;
Using AI as a reviewer, not just a generator. Asking "what's wrong with this" taught me more than asking "write this for me."&lt;br&gt;
Picking one tool and going deep instead of jumping between five AI coding assistants every week.&lt;br&gt;
Shipping in public — even small, unpolished projects — because feedback loops beat perfectionism.&lt;br&gt;
What I'd tell someone starting today&lt;/p&gt;

&lt;p&gt;You don't need to know every language. You don't need a CS degree. You need to build something — even something small and ugly — and let AI help you understand why it works, not just that it works. The gap between "I know Python" and "I shipped a product" closes a lot faster than people think, if you're willing to actually read the code AI gives you instead of copy-pasti_ng blind.__&lt;/p&gt;

</description>
      <category>ai</category>
      <category>beginners</category>
      <category>learning</category>
      <category>programming</category>
    </item>
  </channel>
</rss>
