<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>SoftwareEngineering on Calyntro Blog</title><link>https://calyntro.com/blog/tags/softwareengineering/</link><description>Recent content in SoftwareEngineering on Calyntro Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 21 Apr 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://calyntro.com/blog/tags/softwareengineering/index.xml" rel="self" type="application/rss+xml"/><item><title>AI + TDD: A Shortcut to the Goal or a Loss of Insight?</title><link>https://calyntro.com/blog/posts/ai-tdd-shortcut-or-loss-of-insight/</link><pubDate>Tue, 21 Apr 2026 09:00:00 +0200</pubDate><guid>https://calyntro.com/blog/posts/ai-tdd-shortcut-or-loss-of-insight/</guid><description>&lt;p&gt;Test-Driven Development has always been slightly misunderstood — even by people who practice it.&lt;/p&gt;
&lt;p&gt;The name doesn&amp;rsquo;t help. &amp;ldquo;Test-Driven&amp;rdquo; sounds like it&amp;rsquo;s primarily about tests. Coverage metrics. Regression safety. The QA team&amp;rsquo;s peace of mind. But anyone who has worked seriously with TDD, or spent time with practitioners like Emily Bache, knows that tests are almost a side effect. The real output is &lt;em&gt;understanding&lt;/em&gt;.&lt;/p&gt;
&lt;p&gt;TDD, done well, is a method for thinking your way through a problem one small step at a time. You don&amp;rsquo;t start with a complete picture of the solution. You start with the smallest possible question: &lt;em&gt;what is the simplest behavior this code should exhibit?&lt;/em&gt; You write a test for that. You make it pass. And in the process of making it pass, you learn something — about the problem, about your assumptions, about the design that is quietly trying to emerge.&lt;/p&gt;</description></item><item><title>Software Engineering: The Art of Thinking Out Loud (with AI)</title><link>https://calyntro.com/blog/posts/software-engineering-thinking-out-loud-with-ai/</link><pubDate>Tue, 14 Apr 2026 09:00:00 +0200</pubDate><guid>https://calyntro.com/blog/posts/software-engineering-thinking-out-loud-with-ai/</guid><description>&lt;p&gt;A colleague said something to me recently that I keep coming back to:&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&amp;ldquo;Often, by the time you&amp;rsquo;ve finished articulating a complex problem for the AI, you&amp;rsquo;ve already solved it yourself.&amp;rdquo;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;It sounds almost like a joke. You open a chat window, start typing out your problem in careful detail — and somewhere in the middle of the second paragraph, the answer appears. Not from the AI. From you.&lt;/p&gt;
&lt;p&gt;If you&amp;rsquo;ve worked with LLMs seriously, you&amp;rsquo;ve probably experienced this. And I think it points to something important about what is actually changing in our craft — something that goes beyond the usual conversation about automation and job displacement.&lt;/p&gt;</description></item><item><title>AI in Software Engineering: Between Vision and Craftsmanship</title><link>https://calyntro.com/blog/posts/ai-in-software-engineering-vision-and-craftsmanship/</link><pubDate>Mon, 07 Apr 2025 00:00:00 +0000</pubDate><guid>https://calyntro.com/blog/posts/ai-in-software-engineering-vision-and-craftsmanship/</guid><description>&lt;p&gt;A question recently surfaced in my LinkedIn feed that I haven&amp;rsquo;t been able to shake:
&lt;em&gt;How will the next generation of software developers gain experience when AI takes over the writing?&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;The analogy offered was that of a conductor — someone who doesn&amp;rsquo;t need to play the violin to judge whether the orchestra is in harmony. It&amp;rsquo;s a compelling metaphor. But I think it lets us off the hook too easily.&lt;/p&gt;</description></item></channel></rss>