Tech Radar: What Actually Changed for Teams Building Software
A periodic briefing on the tools and shifts that affect how you build - filtered for what changes a decision, not what made headlines this week.
In short
A recurring briefing filtered by one test: does this change a decision someone is about to make? This edition covers the maturing AI coding agent market, the shifting build-versus-buy line for internal tools, and why generation speed has not translated into proportional delivery speed.
Key takeaways
- AI coding agents have split into two design philosophies - autonomy versus dialogue - rather than converging.
- The build-vs-buy line moved genuinely for internal tooling and barely moved for regulated systems.
- Faster code generation has relocated bottlenecks to review and QA rather than removing them.
- Elevated vulnerability rates in generated code make security review a default rather than an option.
This is a recurring briefing. The filter for inclusion is a single question: does this change a decision someone is about to make? Product launches, funding rounds and benchmark leapfrogging generally do not. Shifts in what is worth building, buying or trusting generally do.
AI coding agents: the market split rather than converged
The expectation a year ago was that AI coding tools would converge on a common shape. They have done the opposite - settling into two distinct philosophies about how much autonomy the tool should take.
One approach optimises for delegation: describe an objective, and the agent completes it with minimal intervention. The other optimises for collaboration: the agent stays in dialogue, explains its reasoning and keeps the developer in the decision loop.
The interesting data point is that these produce diverging signals. In one widely cited comparison, a majority of surveyed developers preferred the more autonomous tool for daily work, while blind reviews rated the more collaborative tool’s output as cleaner and better structured.
What it changes: if your team merges AI-assisted code with light review, default output quality matters more than how the tool feels to use. If review is rigorous, pick for throughput. We went through this in more depth in choosing between coding agents.
Verdict: adopt. Both are cheap relative to salaries and the trial cost is a week.
The build-vs-buy line moved - in one direction only
Enough analyses now report the same thing that it is worth treating as established: internal tooling that used to take a quarter can ship in days with agentic coding tools. Admin dashboards, CRUD interfaces, integration glue.
The important qualifier is that this has not generalised. For systems needing security review, compliance evidence or multi-year maintenance, the reduction is far smaller, because code generation was never the dominant cost there.
What it changes: re-run build-vs-buy on internal tools you previously ruled out on cost. Do not re-run it on anything customer-facing or regulated - the answer has not moved, and maintenance cost is entirely unchanged. The full framework is here.
Verdict: trial, selectively. Genuine for simple internal tools. Overstated everywhere else.
Generation got faster; delivery mostly did not
The most consistent report from teams a year into AI tooling adoption is that velocity improved less than expected.
The mechanism is unglamorous queueing. If your pipeline is write → review → QA → deploy, and review was already the slowest stage, making writing five times faster lengthens the review queue rather than shortening the cycle.
What it changes: if you are adopting AI tooling expecting throughput gains, budget for review capacity and test automation at the same time. Teams reporting real compounding gains invested in both. This also applies when evaluating vendors - a supplier who generates faster but reviews the same is delivering at the same rate with more code to check. More on where the bottleneck went.
Verdict: watch your own metrics, not the benchmarks.
Security review moved from optional to default
Reported vulnerability rates in AI-generated code run materially higher than in human-written code. The methodology behind specific figures deserves scrutiny, but the direction is consistent across sources, and the mechanism is intuitive - these models produce plausible code, and insecure code is often plausible.
What it changes: dependency scanning and security review should be defaults in any pipeline accepting AI-assisted contributions, concentrated on authentication, payments and personal data. This is a process change, not a tooling change, and it costs almost nothing to implement compared to what it prevents.
Verdict: adopt now.
Cost benchmarks worth having in your head
Published estimates across the market have converged enough to be useful as sanity checks when reviewing quotes:
| Category | Typical range |
|---|---|
| Focused web app / MVP | $15K-60K |
| Mid-sized SaaS or portal | $50K-150K |
| Enterprise platform | $200K+ |
| Annual maintenance | 15-25% of build cost |
What it changes: if a quote sits far outside these, that is not automatically wrong - but it is a question worth asking. Quotes well below usually indicate a narrower scope interpretation rather than better value. Why the spread is so wide.
How to read this format
Items are marked adopt (worth acting on now), trial (worth testing on something low-risk), or watch (real but not yet decision-changing).
The bias throughout is toward reversibility. Tools that are cheap to stop using - editors, assistants, local utilities - are worth adopting early because being wrong costs a week. Anything that embeds itself in your architecture, data model or deployment pipeline deserves considerably more scepticism, because being wrong costs a migration.
Most technology regret comes from the second category being evaluated with the enthusiasm appropriate to the first.
FAQ
Frequently asked questions
What is a tech radar?
A tech radar is a periodic assessment of tools, platforms and techniques, categorising them by whether a team should adopt, trial, watch or avoid them. The format originated as an internal engineering practice and works well as a briefing because it forces a recommendation rather than just describing what happened.
How often should engineering teams review their tooling?
Quarterly is a reasonable cadence for most teams. More frequently than that and you spend more time evaluating than building, while annually is too slow in categories moving as quickly as AI tooling. The trigger for an off-cycle review should be a specific decision, such as a new project or a contract renewal.
Has AI tooling actually made development teams faster?
Less than headline claims suggest, because generation was rarely the binding constraint. Teams that also expanded review capacity, test automation and deployment confidence have seen real gains. Teams that only added generation tools typically report that work moved from writing code to reviewing it.
Should we adopt new developer tools quickly or wait?
It depends on reversibility. Tools that are easy to stop using - editors, coding assistants, local utilities - are cheap to trial and worth adopting early. Tools that embed themselves in your architecture, data model or deployment pipeline deserve much more caution, because the cost of being wrong is a migration rather than a preference change.
Written by
FlowLaunch Editorial
Research & Editorial Team
The FlowLaunch editorial team researches, fact-checks and reviews every article published here. Each piece is verified by an operator who has run the play described before it goes live.
- Operator-reviewed
- Primary sources only
