Technology Radar

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.

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.

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.

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.