<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Writing on software engineering, AI development, and documenting a production build in real time. on Keonda</title><link>https://keonda.dev/blog/</link><description>Recent content in Writing on software engineering, AI development, and documenting a production build in real time. on Keonda</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 13 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://keonda.dev/blog/index.xml" rel="self" type="application/rss+xml"/><item><title>How to Choose Your Tech Stack When AI Can Code in Anything</title><link>https://keonda.dev/blog/how-to-choose-your-tech-stack-when-ai-can-code-in-anything/</link><pubDate>Thu, 13 Aug 2026 00:00:00 +0000</pubDate><guid>https://keonda.dev/blog/how-to-choose-your-tech-stack-when-ai-can-code-in-anything/</guid><description>&lt;p>The backend for &lt;a href="https://app.keonda.dev/login" target="_blank" rel="noopener noreferrer" class="text-teal-500 hover:text-teal-600 dark:text-teal-400 dark:hover:text-teal-300 underline underline-offset-2">Keonda&lt;/a>
 is a Java application. I know how that sounds as a &lt;strong>tech stack&lt;/strong> choice in 2026, and I know there are some strong arguments for Go, for Node, Python, etc. Here&amp;rsquo;s the thing though: AI doesn&amp;rsquo;t care which one I pick. It&amp;rsquo;ll write Go, Node, Python, or Rust equally well, with roughly the same effort either way. I made the call anyway, and I want to start here because it&amp;rsquo;s the decision I expect people to question first, and because the reasoning behind it is the same reasoning behind everything else in this article: not &amp;ldquo;what&amp;rsquo;s best in the abstract,&amp;rdquo; but &amp;ldquo;what I can honestly stand behind and review.&amp;rdquo;&lt;/p></description></item><item><title>Engineering Practices for Building Production-Ready Software With AI</title><link>https://keonda.dev/blog/article_0_series_introduction/</link><pubDate>Tue, 28 Jul 2026 00:00:00 +0000</pubDate><guid>https://keonda.dev/blog/article_0_series_introduction/</guid><description>&lt;p>I&amp;rsquo;ve been building software professionally for over 10 years. In October 2025, I left my last engineering role to travel through Asia. Since then tools like Claude Code, Codex and others have reached a level where writing code, the bulk of it anyway, stopped being the hard part.&lt;/p>
&lt;p>That shift cut the time from idea to working software dramatically. But it came with the cost of more context switching, and a lot more friction trying to stay organised across several tasks at once. It also raised a quieter problem: when code is this easy to generate, it&amp;rsquo;s easy to end up with something that works today and falls apart in six months. Architecture and long-term quality don&amp;rsquo;t take care of themselves just because the code came together fast.&lt;/p></description></item></channel></rss>