Technology Radar Vol.30
Thoughtworks Technology Radar is a twice-yearly snapshot of tools, techniques, platforms, languages and frameworks. This knowledge-sharing tool is based on our global teams’ experience and highlights things you may want to explore on your projects.
Each insight we share is represented by a blip. Blips may be new to the latest Radar volume, or they can move rings as our recommendation has changed.
The rings are:
Adopt. Blips that we think you should seriously consider using.
Trial. Things we think are ready for use, but not as completely proven as those in the Adopt ring.
Assess. Things to look at closely, but not necessarily trial yet — unless you think they would be a particularly good fit for you.
Hold. Proceed with caution.
Explore the interactive version by quadrant, or download the PDF to read the Radar in full. If you want to learn more about the Radar, how to use it or how it’s built, check out the FAQ.
![Thoughtworkers at Radar discussion Thoughtworkers at Radar discussion](/content/dam/thoughtworks/images/photography/side-by-side/insights/radar/tr_side_by_side_tr30.jpg)
Inside the Technology Radar is a short documentary that provides a fresh insight into all things Technology Radar.
![](/content/dam/thoughtworks/images/photography/collection-of-media/insights/radar/tr_com_download_subscribe.jpg)
Themes for this volume
For each volume of the Technology Radar, we look for patterns emerging in the blips that we discuss. Those patterns form the basis of our themes.
![](/content/dam/thoughtworks/images/photography/side-by-side/insights/radar/tr_side_by_side_2023_29_theme_01.png)
Open-ish source licenses
Two types of discussions about licenses arose during our meeting. First, for many years, the open-source software development ecosystem relied on a set of licenses, cataloged by the Open Source Initiative (OSI), with a small number of popular licenses used in most cases. Recently, however, we’ve seen churn in this previously serene landscape. Several prominent tools have recently garnered bad press, when their maintainers switched — in several cases abruptly — from an open-source license to a commercial model. We have no problem paying for software and are fine with the common model of commercial licenses for additional functionality. However, we find it problematic when core functionality of a widely used tool is suddenly put behind a paywall, especially when an ecosystem has developed around the tool. Second, the other interesting development concerns software that proclaims to be open source yet fundamental capabilities only appear after consumers pay subscriptions or other charges. Even though this business model has existed before, it seems to be exploited more with many of the shiny new AI tools — offering amazing capabilities a little too hidden under the fine print. We advise particular diligence around license issues. Pay attention to caveats and make sure that all files in a repository are covered by the license at the top level.
![](/content/dam/thoughtworks/images/photography/side-by-side/insights/radar/tr_side_by_side_2023_29_theme_02.png)
AI-assisted software development teams
The topic of AI obviously dominated our conversations; one-third of our blips concerned some aspect of it. While we discussed several developer-focused AI tools like GitHub Copilot, Codium AI, aider and Continue, we also had numerous conversations about how the holistic use of AI across an entire team changes aspects of software development. We talked about a variety of tools that didn’t make the final cut, including AI-assisted terminals like Warp, the ability to convert screenshots to code, ChatOps backed by LLMs and a host of other topics. Although the developer tools tend toward a higher degree of maturity, we suspect that all aspects of software development can gradually benefit from the pragmatic use of AI and derived tools, and we're actively following innovations across the development landscape. Of course, with the almost magical new capabilities offered by AI come new risks to software quality and security. This calls for teams to remain vigilant, including keeping non-developers in the loop about potential hazards.
![](/content/dam/thoughtworks/images/photography/side-by-side/insights/radar/tr_side_by_side_2023_29_theme_03.png)
Emerging architecture patterns for LLMs
Patterns are popular in the technology world because they provide a succinct name for a solution to a particular problem. With the growing use of large language models (LLMs), we’re starting to see the emergence of specific architecture patterns to support common contexts. For example, we discussed NeMo Guardrails, which allows developers to build governance policies around LLM usage. We also talked about tools such as Langfuse that allow greater observability into the steps leading to an LLM’s output and how to deal with (and validate) bloated code bases full of generated code. We discussed how retrieval-augmented generation (RAG) is our preferred pattern to enhance the quality of LLM outputs, especially in the enterprise ecosystem. Additionally, we discussed techniques like using a lower-powered (and cost-efficient) LLM to produce material which is selectively vetted by a more powerful (and expensive) LLM. Patterns form an important vocabulary for technologies, and we expect to see an explosion of patterns (and the inevitable anti-patterns) as generative AI continues to suffuse software development.
![](/content/dam/thoughtworks/images/photography/side-by-side/insights/radar/tr_side_by_side_2023_29_theme_04.png)
Dragging PRs closer to proper CI
Thoughtworks has always been a strong proponent of fast feedback loops during software development and thus a big supporter of continuous integration (CI). To assist with adoption, we built the first-ever CI server — CruiseControl — that was open-sourced in the late 1990s. Recently, our chief scientist Martin Fowler updated the canonical definition of continuous integration on his bliki to renew attention on this practice. However, many of our teams are compelled to ignore the CI part of CI/CD because they find themselves in situations where pull requests (PRs) are mandated. Although the practice of PRs was originally developed to manage massively distributed open-source teams and unreliable contributors, they’ve become a synonym for peer review commonplace even on small, close-knit delivery teams. In these circumstances, many developers yearn for the same sense of flow that they get from practicing actual CI. We surveyed several tools that are trying to alleviate the pains of PR review processes, including gitStream and Github merge queue. We also discussed techniques such as stacked diffs that hold promise for aligning with the core principles of CI by enabling more granular control over the integration process and discussed methods for deriving metrics from PRs to identify inefficiencies and bottlenecks during software delivery. Tooling helps tremendously in this space because of the trend toward generative AI for coding. With AI coding assistants, coding throughput increases, which leads to a tendency to create larger PRs. This puts even more pressure on asynchronous code review processes. Even though we still prefer the original practice of CI, we encourage teams who cannot use it because of external constraints to find ways to improve the accuracy of integration and the speed of their feedback cycle.
Contributors
The Technology Radar is prepared by the Thoughtworks Technology Advisory Board, comprised of:
Rebecca Parsons (CTO Emerita) • Rachel Laycock (CTO) • Martin Fowler (Chief Scientist) • Bharani Subramaniam • Birgitta Böckeler • Brandon Byars • Camilla Falconi Crispim • Erik Doernenburg • Fausto de la Torre • Hao Xu • James Lewis • Marisa Hoenig • Maya Ormaza • Mike Mason • Neal Ford • Pawan Shah • Scott Shaw • Selvakumar Natesan • Shangqi Liu • Sofia Tania • Vanya Seth • Will Amaral
Subscribe. Stay informed.
Sign up to receive emails about future Technology Radar releases and bi-monthly tech insights from Thoughtworks.