Foremy Software Insider Report — a weekly look inside the tools, deals, and decisions shaping the software industry.
The workflow nobody predicted five years ago
Walk into almost any engineering org today and you’ll see the same quiet ritual: a developer opens an editor, starts typing a comment describing what they want, and waits half a second for a suggestion to appear. That half-second pause has become one of the most consequential UX moments in modern software development. It’s the moment where a human decision — write it myself, or accept the machine’s guess — happens dozens, sometimes hundreds, of times a day.
What began as autocomplete-on-steroids has evolved into something structurally different. AI coding assistants are no longer just suggesting the next line; they are proposing entire functions, refactoring modules, writing tests, and in some configurations, opening pull requests with minimal human intervention. The industry has quietly shifted from “AI-assisted coding” to something closer to “AI-delegated coding,” and most organizations have not yet updated their processes, review standards, or even their vocabulary to match.
“The interesting shift isn’t that the tools got smarter. It’s that teams stopped treating suggestions as suggestions and started treating them as first drafts of record.” — engineering lead at a mid-size fintech company, speaking on background
Three competing philosophies
Broadly, the current generation of AI coding tools splits into three design philosophies, and the differences matter more than most buyers realize when evaluating a platform.
1. The inline-completion model
This is the original paradigm: the assistant lives inside the editor and predicts what you’re about to type, line by line or block by block. It’s fast, low-friction, and easy to trust because the developer stays firmly in the driver’s seat. The downside is scope — inline completion is excellent at local reasoning (finishing a function, matching a pattern already in the file) but weaker at reasoning across an entire codebase or making architectural judgment calls.
2. The agentic model
Agentic tools take a task description — “add pagination to the users endpoint and update the corresponding tests” — and work semi-autonomously: reading relevant files, editing multiple locations, running the test suite, and iterating on failures before presenting a diff for review. This model compresses hours of work into minutes, but it also compresses hours of *context-building* into minutes, which is exactly the part that historically taught junior engineers how a codebase actually works.
3. The conversational-pairing model
Here the assistant behaves more like a senior colleague in a chat window: explaining tradeoffs, asking clarifying questions, and leaving the actual typing to the human. It’s the slowest of the three in raw throughput, but insiders increasingly argue it’s the model best suited to preserving engineering judgment over the long run.
The productivity numbers are real — and also misleading
Every vendor in this space publishes some version of the same statistic: developers using their tool complete tasks 30–55% faster. These numbers are not fabricated, but they are measuring the wrong unit. Task completion speed on a well-scoped, well-understood ticket is not the same as organizational throughput, and it is definitely not the same as long-term code quality.
Several engineering leaders we spoke with this month described a similar pattern playing out on their teams:
- Week one to four: Visible, celebrated speedups on routine work — boilerplate, CRUD endpoints, test scaffolding.
- Month two to four: A subtle rise in “plausible but wrong” pull requests — code that compiles, passes shallow tests, and looks correct at a glance, but embeds a misunderstanding of business logic.
- Month five onward: Review burden shifts from “did you write this correctly” to “did you understand what you approved,” which is a harder, slower, more senior-loaded form of scrutiny.
None of this means the tools are bad. It means the bottleneck in software delivery is migrating from typing speed to judgment and verification — and most teams haven’t restructured their review culture to reflect that migration.
What’s actually changing inside engineering orgs
The most forward-looking teams aren’t asking “how do we adopt AI coding tools.” They’re asking a more uncomfortable question: “what does code review mean when the author might be a model?” A few emerging practices are worth tracking:
Provenance tagging
Some teams now tag pull requests by origin — human-authored, AI-assisted, AI-generated-then-edited, AI-generated-unreviewed-by-author. This sounds bureaucratic, but it gives engineering managers a real signal about where defects are clustering, rather than treating “the codebase” as a single undifferentiated mass.
Test-first mandates
Because generated code is fluent but not always correct, teams are pushing test creation earlier and treating it as non-negotiable, sometimes requiring tests to be written or approved by a human before an agent is allowed to implement against them.
Junior-engineer redesign
Perhaps the most structurally significant change: some engineering leaders are deliberately restricting AI tool access for engineers in their first year, not out of distrust of the tools, but because they believe the struggle of writing code manually is where foundational intuition is built. Others argue this is nostalgia dressed up as pedagogy, and that the skill being built now is *review and specification*, not typing.
The vendor landscape: consolidation pressure building
The market for AI coding assistants has gone from a handful of players to a crowded field of IDE-native tools, standalone agents, and features bolted onto existing developer platforms. That crowding is unsustainable, and insiders expect the next 12–18 months to bring meaningful consolidation, for a few structural reasons:
- Model cost compression. As the underlying models these tools are built on become commoditized and cheaper to run, the differentiator shifts away from “who has the smartest model” toward workflow integration, enterprise trust features, and codebase-specific context handling — areas where scale and distribution matter more than raw research talent.
- Enterprise procurement fatigue. Large organizations are increasingly unwilling to run security review, SOC 2 audits, and procurement cycles for five different point solutions doing overlapping jobs. Expect platform bundling to accelerate.
- Data and context moats. Tools that have accumulated deep integration with a company’s internal repositories, ticketing systems, and design docs have a durable advantage that’s hard for a new entrant to replicate quickly, even with a better model underneath.
The quiet risk nobody wants to put in a slide deck
There’s a version of this story that’s purely optimistic — faster shipping, lower costs, happier developers. There’s also a less comfortable version that insiders discuss privately more than publicly: a growing dependency on tools whose failure modes are still poorly understood at scale. Generated code doesn’t fail the way human-written code fails. It doesn’t get tired, but it also doesn’t have a survival instinct about the specific thing that will embarrass the company if it breaks in production. A human engineer who’s shipped a payments bug once tends to be paranoid about payments code forever. A model has no equivalent scar tissue unless the organization builds guardrails to simulate one.
What to watch next
- Whether enterprise contracts start including explicit liability and audit language for AI-generated code, the way they already do for third-party libraries.
- Whether “agentic” tools that touch production infrastructure directly (not just source code) see adoption slow due to risk aversion, even as code-only agents keep growing.
- Whether a second wave of tooling emerges specifically to *review* AI-generated code — essentially, AI checking AI, with humans arbitrating disagreements.
- Whether compensation structures for engineers begin to explicitly reward review quality and specification-writing rather than raw commit volume.
A quick insider Q&A
Q: Should a growing engineering team standardize on one AI coding tool, or let individual developers choose their own?
A: Most platform leads we talked to landed on a middle path — a small, vetted shortlist rather than a single mandated tool or a total free-for-all. A single mandated tool simplifies security review and licensing, but developer workflows and language ecosystems vary enough that forcing everyone onto one assistant tends to produce quiet, unofficial workarounds anyway.
Q: Is it true that junior engineer hiring is slowing down because of these tools?
A: The picture is mixed and highly team-dependent. Some engineering leaders report hiring fewer entry-level engineers because senior-plus-AI now covers work that used to require a larger junior bench. Others argue this is short-sighted, since today’s junior engineers become tomorrow’s senior engineers with the judgment these tools still can’t replace, and organizations skipping that pipeline may face a painful talent gap in five to seven years.
Q: What’s the single most common mistake teams make when adopting these tools?
A: Treating adoption as a tooling decision instead of a process decision. Buying licenses is the easy part. The teams that struggle are almost always the ones that never updated code review standards, testing requirements, or onboarding materials to reflect the fact that a meaningful share of new code no longer originates from a human’s first draft.
A note on measuring this correctly
One structural problem insiders flag repeatedly: most organizations still measure engineering productivity using metrics built for a pre-AI world — commits per week, lines of code, tickets closed. All three metrics become actively misleading once a meaningful share of code is machine-generated, because they reward volume in a period where volume is no longer the constrained resource. A handful of more sophisticated engineering organizations are experimenting with alternative measures — defect rates traced back to origin, time from merge to production incident, and reviewer confidence scores — but there’s no broadly agreed-upon replacement yet, and vendors selling “developer productivity” dashboards are, unsurprisingly, still mostly built around the old metrics because they’re easier to compute and easier to sell against.
The bottom line
The AI coding wars are not really a story about which vendor wins. They’re a story about an entire profession renegotiating what its core skill actually is. For twenty years, being a good software engineer meant being good at writing code. The organizations that figure out — ahead of their competitors — that the new core skill is judgment, specification, and verification will end up with a durable advantage that has nothing to do with which assistant logo appears in their editor.
Foremy’s Software Insider Report publishes weekly analysis on the tools, deals, and decisions shaping enterprise and developer software. Have a tip or an inside perspective to share? Reach the team at team@foremy.com.