Software engineering, architecture and design stuff, mainly on .Net, F#, and Azure.
Co-Host of .Net user group Central-Switzerland.
#fsharp
#dotnet
#SoftwareArchitecture
| Blog | www.planetgeek.ch |
| www.linkedin.com/in/ursenzler/ |
Lately, I see a lot of posts saying we need a robust suite of automated tests to ensure AI agents produce quality results.
Keep in mind that one cannot test quality into software. Automated tests are a necessity, but they are not sufficient as a sole approach.
I wouldn't ship a feature without first running an exploratory testing session. So many things can go wrong that we can't specify explicitly; only exploratory testing finds these.
And I want a dry run on difficult data migrations, too.
We started using event sourcing over ten years ago. One of the hardest lessons was that there is a kind of events that is not obvious at first but have a big impact on your system design. I call this kind secondary domain events.
https://www.planetgeek.ch/2026/04/01/the-problem-with-secondary-domain-events-in-event-sourcing/
We started using event sourcing over ten years ago. One of the hardest lessons was that there is a kind of events that is not obvious at first but have a big impact on your system design. I call this kind secondary domain events. In this post, I'll explain what secondary domain events are, and...
I would favour more efficient solutions, but none are in sight to me. Maybe once, when we have to pay for the real costs of training and running these agent farms, a correction will happen.
The picture Gen-AI created is, however, quite funny. 😄
2/2
I'm not a fan of "let's throw more resources at the problem" solutions. What currently happens in the AI-assisted software development community is, however, exactly this:
From single LLM via single agent (repeat until succeeded) to multi-agent setups (giving themselves feedback to iterate on) - burning tokens like there is no tomorrow (or no token limit, if you care more about your money than the planet 😅 ).
1/2
The 5th and final part of my post series about "to test, or not to test" takes a look at why the shown concepts help with LLMs and concludes the series.
https://www.planetgeek.ch/2026/03/24/to-test-or-not-to-test-part-5-final-words/
Do you like these longer topics, or do you prefer short single posts?
I wrote code without tests that ran in production without defects, and I wrote buggy code with TDD (Test Driven Development). Time to look back at 35 years of coding and when tests help, and when there is something better. And especially, what these better things are. In the final part, we examine how LLMs...
Part 4 of my blog post series about "to test, or not to test" is about making manual testing easy, and why it matters: https://www.planetgeek.ch/2026/03/19/to-test-or-not-to-test-part-4-make-it-easy-to-test-locally/.
Can you run your system locally and/ or test things quickly, or do you have to wait for a test environment?
I wrote code without tests that ran in production without defects, and I wrote buggy code with TDD (Test Driven Development). Time to look back at 35 years of coding and when tests help, and when there is something better. And especially, what these better things are. In this part, we look at how to...
In part 3 of my blog post series on "to test or not to test", I take a look at how to recover from a defect if it finds its way into production anyway: https://www.planetgeek.ch/2026/03/17/to-test-or-not-to-test-part-3-make-it-easier-to-recover-from-a-defect/
What are your approaches to recovering easily from a defect?
I wrote code without tests that ran in production without defects, and I wrote buggy code with TDD (Test Driven Development). Time to look back at 35 years of coding and when tests help, and when there is something better. And especially, what these better things are. In this post, we look at what we...
Second part of my series on "To test or not to test": What if we weren't allowed to write automated tests? What concepts, approaches, and tools would help us?
https://www.planetgeek.ch/2026/03/12/to-test-or-not-to-test-part-2-make-it-hard-to-make-mistakes/
I wrote code without tests that ran in production without defects, and I wrote buggy code with TDD (Test Driven Development). Time to look back at 35 years of coding and when tests help, and when there is something better. And especially, what these better things are. In this part: What would you do if...
I use the great AZD plugin to make working with Azure DevOps PRs simpler for JetBrains IDEs (https://plugins.jetbrains.com/plugin/22319-azd ). One of its many features is an AI-driven PR review. It gave me many good pointers, but it should sharpen its F# knowledge 😀
I don't have to search and check all instances of pattern matching on `Codes` as it suggests (as shown in the image). The compiler does that for me.
btw: we use the PR tooling for releasing, not as a quality gate.
Jan Schaumann