Sign Up | JetBrains goes live with Junie AI agent, updates AI assistant, adds free tier: The multi-step AI coding agent now has an updated AI Assistant with new models and multi-file edit support, and a free tier for 2025.1 IDEs.
JRuby 10 brings faster startup times: The version improves startup times using modern JVM features like AppCDS and Project CRaC, adds support for Java 21, and aligns with Ruby 3.4.
💡Optimizing memory usage with modern .NET features: Shows how the author reduced memory allocations after migrating to .NET 8/9 by replacing inefficient patterns with modern .NET features.
💡When Nanoseconds Matter: Ultrafast Trading Systems in C++ - David Gross - CppCon 2024: Explains how to engineer low-latency trading systems in C++ by focusing on data structure design, CPU profiling, and performance-aware memory use.
💡When Inheritance is a Good Thing: Argues that while inheritance is often misused for code reuse—it remains valuable particularly in implementing design patterns like Decorator and Visitor.
💡Some features that every JavaScript developer should know in 2025: Covers iterator helpers for memory-efficient data transformation,
Promise.withResolvers(),structuredClone(), tagged templates, and more.💡Unit testing using mocks in Go: Covers AWS S3 bucket creation, by refactoring functions to accept interfaces, implementing mock types to simulate success and failure scenarios, and using table-driven tests to streamline cases.
🎓A 2025 Survey of Rust GUI Libraries: Assesses 23 libraries including Azul, Cacao, Core Foundation, Crux, and Floem, based on ease of setup, accessibility support, internationalization capabilities, and overall user experience.
Swift🎓SQL Plan Baseline, SQL Patch, SQL Profile: Differences and Use Cases: Explains the differences between the three Oracle mechanisms, detailing how each influences SQL execution plans and when to apply them for optimal plan stability and performance tuning.
💡Migrating Sidekiq Background Jobs to Temporal in Ruby on Rails: Explains how Temporal enables reliable, stateful workflows with built-in retries, fault tolerance, and orchestration suited for long-running or complex processes.
KotlinWhy most technical documentation fails (and how to fix it with inclusive, accessible design): Outlines a science-based framework for creating inclusive, modular, and accessible documentation through clear language, visual support, progressive disclosure, and user-friendly navigation.
Q: What inspired you to write Software Architecture with C# 12 and .NET 8?
Francesco:
The main point was that this book brings together various subjects that are hard to find in one place. I wanted to collect my experience and put it into something solid—a book that could be useful in my advisory work, in courses, and also for my customers. It’s a practical tool for all of that.
Gabriel:
For me, it marked a really important point in my career. I’ve worked both in the college environment and in industry for a long time. This opportunity allowed me to give back to the community a complete material, a full pipeline on how to create an enterprise solution.
It was a great chance to work with Francesco too—we found a lot of common ground. I think readers will notice that the book reads as though it was written by a single person. We worked closely and it was a really enjoyable collaboration.
Q: Could you give us a few examples of how AI-driven tools are currently being used in architectural design and what new paradigms you see emerging?
Gabriel:
AI is definitely the topic on everyone’s mind right now. But a good AI still depends on a good software architecture—because AI needs good data. Without good data, you can't have good AI.
As architects, we’re going to be impacted by AI, positively or negatively, depending on how we work with it. For example, today it’s possible to upload an architectural design into a tool like ChatGPT and have a conversation about whether it’s good or bad. I’ve done this—it can suggest changes or provide feedback. But you still need to analyse that feedback and judge if it's correct, especially in enterprise environments where things are more complex.
So AI will change the world, but we need to use our intelligence to evaluate its output. Architects need to design systems that can produce good AI—because poor architecture means poor data, and that leads to poor AI.
Francesco:
AI is a valuable tool, but it can’t fully replace a professional’s experience—at least not yet. It helps save time and can suggest options, but sometimes those suggestions are wrong. Other times they’re a useful starting point for further investigation.
AI can write some code, create diagrams or designs that serve as a base to work from. It might remind you of something you’d forgotten to analyse. But that doesn’t mean it’s giving you the best solution—it’s just helping you avoid overlooking things.
Right now, it’s still far from the kind of general intelligence that could fully take over an architect’s job.
Q: What remains irreplaceable about human architects—and how they can use AI to enhance, rather than replace, their role?
Francesco:
Architects should use AI to save time—for instance, to generate some starting designs or initial code. In my company, we developed an AI tool that can generate a complete Visual Studio solution, with all the needed projects and some basic starting code. It doesn’t always work perfectly, but it’s a useful starting point and it saves time, especially with complex architectures like those based on microservices or onion architecture.
In those cases, setting everything up manually would take a long time. With this tool, we can automate 50–60% of that groundwork. But even then, the hard part is modelling the real world—and AI doesn’t have enough understanding of the world to do that on its own. It still needs a human to interpret the requirements and guide the process.
Gabriel:
Our book focuses a lot on the architect’s role in a team. Architects design the solution pipeline and are responsible for the technical direction of enterprise projects.
Today, AI can be used to accelerate things for the whole team—not just the architect. But it’s still just a starting point. You need someone with experience to evaluate whether the output fits the requirements. This is especially true for enterprise systems, where quality and correctness matter a lot.
Even tools like GitHub Copilot don’t just help you write code—they also help analyse if you’re following best practices. But it’s still the architect’s responsibility to decide which tools are appropriate and whether they’re improving the team’s performance.
Q: What skills do you see becoming essential for software architects as technology continues to evolve?
Gabriel:
If you look at everything we’ve talked about so far—distributed systems, AI, security—they all point to one thing: the future is distributed. So, understanding how to build distributed applications is going to be essential. Architects also need a solid grounding in information security.
And beyond the technical, I’d say soft skills are critical too. When you introduce changes like DevOps or observability, you’re impacting the entire team. The ability to bring people along with you—to communicate, to influence—is just as important as technical skill.
Francesco:
I agree with Gabriel. Many developers and architects still think of security as something you add at the end—firewalls, updates, patches. That mindset has to change. Security needs to be part of how we design and write code from the beginning.
Architects preparing for the future should update how they design, how they build, and how they think about development. That means learning about DevOps, distributed systems, and modern development methodologies—and making them second nature.
About the Authors
🎓SQL Plan Baseline, SQL Patch, SQL Profile: Differences and Use Cases: Explains the differences between the three Oracle mechanisms, detailing how each influences SQL execution plans and when to apply them for optimal plan stability and performance tuning.
💡Migrating Sidekiq Background Jobs to Temporal in Ruby on Rails: Explains how Temporal enables reliable, stateful workflows with built-in retries, fault tolerance, and orchestration suited for long-running or complex processes.
KotlinWhy most technical documentation fails (and how to fix it with inclusive, accessible design): Outlines a science-based framework for creating inclusive, modular, and accessible documentation through clear language, visual support, progressive disclosure, and user-friendly navigation.
Why most technical documentation fails (and how to fix it with inclusive, accessible design): Outlines a science-based framework for creating inclusive, modular, and accessible documentation through clear language, visual support, progressive disclosure, and user-friendly navigation.
Q: What inspired you to write Software Architecture with C# 12 and .NET 8?
Francesco:
The main point was that this book brings together various subjects that are hard to find in one place. I wanted to collect my experience and put it into something solid—a book that could be useful in my advisory work, in courses, and also for my customers. It’s a practical tool for all of that.
Gabriel:
For me, it marked a really important point in my career. I’ve worked both in the college environment and in industry for a long time. This opportunity allowed me to give back to the community a complete material, a full pipeline on how to create an enterprise solution.
It was a great chance to work with Francesco too—we found a lot of common ground. I think readers will notice that the book reads as though it was written by a single person. We worked closely and it was a really enjoyable collaboration.
Q: Could you give us a few examples of how AI-driven tools are currently being used in architectural design and what new paradigms you see emerging?
Gabriel:
AI is definitely the topic on everyone’s mind right now. But a good AI still depends on a good software architecture—because AI needs good data. Without good data, you can't have good AI.
As architects, we’re going to be impacted by AI, positively or negatively, depending on how we work with it. For example, today it’s possible to upload an architectural design into a tool like ChatGPT and have a conversation about whether it’s good or bad. I’ve done this—it can suggest changes or provide feedback. But you still need to analyse that feedback and judge if it's correct, especially in enterprise environments where things are more complex.
So AI will change the world, but we need to use our intelligence to evaluate its output. Architects need to design systems that can produce good AI—because poor architecture means poor data, and that leads to poor AI.
Francesco:
AI is a valuable tool, but it can’t fully replace a professional’s experience—at least not yet. It helps save time and can suggest options, but sometimes those suggestions are wrong. Other times they’re a useful starting point for further investigation.
AI can write some code, create diagrams or designs that serve as a base to work from. It might remind you of something you’d forgotten to analyse. But that doesn’t mean it’s giving you the best solution—it’s just helping you avoid overlooking things.
Right now, it’s still far from the kind of general intelligence that could fully take over an architect’s job.
Q: What remains irreplaceable about human architects—and how they can use AI to enhance, rather than replace, their role?
Francesco:
Architects should use AI to save time—for instance, to generate some starting designs or initial code. In my company, we developed an AI tool that can generate a complete Visual Studio solution, with all the needed projects and some basic starting code. It doesn’t always work perfectly, but it’s a useful starting point and it saves time, especially with complex architectures like those based on microservices or onion architecture.
In those cases, setting everything up manually would take a long time. With this tool, we can automate 50–60% of that groundwork. But even then, the hard part is modelling the real world—and AI doesn’t have enough understanding of the world to do that on its own. It still needs a human to interpret the requirements and guide the process.
Gabriel:
Our book focuses a lot on the architect’s role in a team. Architects design the solution pipeline and are responsible for the technical direction of enterprise projects.
Today, AI can be used to accelerate things for the whole team—not just the architect. But it’s still just a starting point. You need someone with experience to evaluate whether the output fits the requirements. This is especially true for enterprise systems, where quality and correctness matter a lot.
Even tools like GitHub Copilot don’t just help you write code—they also help analyse if you’re following best practices. But it’s still the architect’s responsibility to decide which tools are appropriate and whether they’re improving the team’s performance.
Q: What skills do you see becoming essential for software architects as technology continues to evolve?
Gabriel:
If you look at everything we’ve talked about so far—distributed systems, AI, security—they all point to one thing: the future is distributed. So, understanding how to build distributed applications is going to be essential. Architects also need a solid grounding in information security.
And beyond the technical, I’d say soft skills are critical too. When you introduce changes like DevOps or observability, you’re impacting the entire team. The ability to bring people along with you—to communicate, to influence—is just as important as technical skill.
Francesco:
I agree with Gabriel. Many developers and architects still think of security as something you add at the end—firewalls, updates, patches. That mindset has to change. Security needs to be part of how we design and write code from the beginning.
Architects preparing for the future should update how they design, how they build, and how they think about development. That means learning about DevOps, distributed systems, and modern development methodologies—and making them second nature.