<?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>Forem: Nikhil Sharma</title>
    <description>The latest articles on Forem by Nikhil Sharma (@codisfy).</description>
    <link>https://forem.com/codisfy</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.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F295694%2F6a4283bb-1552-4131-8ef5-fd1d58b877df.jpeg</url>
      <title>Forem: Nikhil Sharma</title>
      <link>https://forem.com/codisfy</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://forem.com/feed/codisfy"/>
    <language>en</language>
    <item>
      <title>For everyone trying to build something: You are planting seeds. You don't yell at a sprout for growing too slowly. You nurture it and you accept that some plants might not make it. The focus is on the *care* (fun), not just the *harvest* (result).</title>
      <dc:creator>Nikhil Sharma</dc:creator>
      <pubDate>Tue, 28 Apr 2026 12:09:30 +0000</pubDate>
      <link>https://forem.com/codisfy/for-everyone-trying-to-build-something-you-are-planting-seeds-you-dont-yell-at-a-sprout-for-5eo</link>
      <guid>https://forem.com/codisfy/for-everyone-trying-to-build-something-you-are-planting-seeds-you-dont-yell-at-a-sprout-for-5eo</guid>
      <description></description>
      <category>motivation</category>
      <category>buildinpublic</category>
    </item>
    <item>
      <title>Software Developers: Redundant or Resilient?</title>
      <dc:creator>Nikhil Sharma</dc:creator>
      <pubDate>Sat, 25 Apr 2026 23:23:14 +0000</pubDate>
      <link>https://forem.com/codisfy/software-developers-redundant-or-resilient-35b3</link>
      <guid>https://forem.com/codisfy/software-developers-redundant-or-resilient-35b3</guid>
      <description>&lt;p&gt;In the era before AI-assisted coding, my workflow for any feature followed this pattern:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;&lt;p&gt;I would analyze the business problem. Even if the Product Manager spent time on it, I would read the documentation and ask clarifying questions. This established a foundational understanding of the problem.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;After some back-and-forth discussion, I would begin planning the implementation. This deepened my understanding of the problem.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;I would review the existing codebase to identify established patterns and determine what I could reuse. This strengthened my familiarity with the codebase.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;If no existing pattern applied, I would research similar scenarios and evaluate design patterns to find the best fit for the problem. This reinforced my coding practices and potentially uncovered new solutions.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;Finally, I would start implementing. As I coded, I would continuously consider improvements and alternative approaches. This increased my familiarity with both the problem and the solution.&lt;/p&gt;&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;After completing this process, I could often recall the implementation details and logic from memory during team discussions. If a bug arose, I could usually deduce its cause without immediately inspecting the code, often because I recognized an edge case I had overlooked during implementation.&lt;/p&gt;

&lt;p&gt;Overall, this process helped me learn more, retain more knowledge, and perform more of the work myself. These were actually the most fun parts of the process. Today, I spend much of my time reviewing code. However, reviewing is not the same as writing it. As the saying goes in mathematics, you cannot learn simply by reading a textbook; you must engage with the material and put pen to paper.&lt;/p&gt;

&lt;p&gt;Maybe times have changed, and I do not even need to know all those details. But then it makes me wonder: am I redundant in this process?&lt;/p&gt;

&lt;p&gt;Some people might point out that you bring in taste and judgment. However, what stops a non-developer from showing these skills? They just have to ask AI for alternatives and pick the best solution based on their understanding.&lt;/p&gt;

&lt;p&gt;There are still a few places where AI is not as good, especially where there is any integration, whether it involves hardware devices or multiple systems stitched together. However, this mostly covers missing bridges (i.e., AI cannot click buttons on a hardware device or check multiple systems at once). These tasks are limited. Software Engineers working in novel fields might also not feel redundant, but those people are few and far between.&lt;/p&gt;

&lt;p&gt;This makes me lean toward "Redundant" as the answer for most dev jobs today. The only way forward seems to be moving to the next level, i.e., truly being an engineer (working with systems that do not exist yet) instead of being a mechanic or developer (working with known systems).&lt;/p&gt;

</description>
      <category>ai</category>
      <category>webdev</category>
      <category>programming</category>
      <category>discuss</category>
    </item>
    <item>
      <title>Claude and I aren't vibing at all</title>
      <dc:creator>Nikhil Sharma</dc:creator>
      <pubDate>Thu, 23 Apr 2026 02:48:08 +0000</pubDate>
      <link>https://forem.com/codisfy/claude-and-i-arent-vibing-at-all-2f1h</link>
      <guid>https://forem.com/codisfy/claude-and-i-arent-vibing-at-all-2f1h</guid>
      <description>&lt;p&gt;I really enjoyed working with Opus 4.6 in Copilot, especially for tasks that required a bit of creativity (e.g. it was much better at building a landing page compared to GPT-5.3-Codex), but I never got a Claude subscription. I finally did, at last.&lt;/p&gt;

&lt;p&gt;After spending 24 hours with Claude Code in VS Code, I've come to the conclusion that it is focused entirely on "vibe coding". It will absolutely do anything to get you to a working solution, even if it isn't best practice.&lt;/p&gt;

&lt;p&gt;The code is pretty sloppy. It hardcodes things it should have created configs or constants for. When I asked it to update some sidebar design, along with a change that impacted a common element used globally, I expected it to respect my structure. I have things neatly organized in &lt;code&gt;__sidebar.scss&lt;/code&gt; and &lt;code&gt;__global.css&lt;/code&gt;, but instead of using each for its own purpose, it stuffed everything into the sidebar file.&lt;/p&gt;

&lt;p&gt;It readily fills in the blanks for API calls. For example, while working with the Calendly API, it invented a couple of concepts that looked legit only until I tested them manually and they failed.&lt;/p&gt;

&lt;p&gt;Also, the rate limits are insane; you can't just work off a Pro account. Compare this to the fact that I never hit my rate limits on Codex (not even close) or on Copilot, which I was using exclusively just a couple of months ago. People coding entirely on vibes would ask for even the tiniest of things using AI, so it makes sense to extract as much value from them.&lt;/p&gt;

&lt;p&gt;Since the code is sloppy, I can imagine the state of the code in a few months. Even if you wanted to maintain it, you would need to ask AI to handle the smallest of tasks because it would be too tiring to comprehend such code.&lt;/p&gt;

&lt;p&gt;I also understand now why people need so many prompt files (skills) and whatnot with Claude. It needs a lot of prodding and prompting and has difficulty working off clear instructions at once.&lt;/p&gt;

&lt;p&gt;I will still continue giving a piece of my time to it for the next few days, but it seems to have not gotten off to a good start.&lt;/p&gt;

</description>
      <category>claude</category>
      <category>ai</category>
      <category>coding</category>
    </item>
  </channel>
</rss>
