- Developers using AI at work report dramatic speed gains on greenfield projects but serious limitations in legacy enterprise systems.
- Developers using AI tools like Claude Code face unexpected cost surprises as token usage at scale proves far more expensive than anticipated.
- Context and tribal knowledge built over years still give human engineers a clear edge over AI agents in complex codebases.
- The gap between viral AI demos and everyday developer reality is wider than the tech industry’s loudest voices want to admit.
- Developers using AI at work report dramatic speed gains on greenfield projects but serious limitations in legacy enterprise systems.
- Developers using AI tools like Claude Code face unexpected cost surprises as token usage at scale proves far more expensive than anticipated.
- Context and tribal knowledge built over years still give human engineers a clear edge over AI agents in complex codebases.
- The gap between viral AI demos and everyday developer reality is wider than the tech industry’s loudest voices want to admit.
The Story the Internet Wants You to Believe
Developers using AI at work, according to the internet’s most vocal corners, are basically omnipotent now. Conference keynotes and LinkedIn feeds paint a picture of engineers casually directing fleets of autonomous agents, merging hundred-thousand-line pull requests before lunch, and rewriting entire applications over a weekend. Matteo Collina opens a 100k-line PR for Node.js and everyone panics. Someone migrates a full React codebase to Svelte in two weeks. The creator of Bun allegedly rewrites the runtime from Zig to Rust in a single evening — and still finds time for a date.
It’s a compelling narrative. It’s also, for the vast majority of working engineers, not especially close to their daily reality. The hype cycle around AI coding tools has reached a pitch where it’s genuinely hard to separate the signal from the noise — and that matters, because real engineering decisions, hiring plans, and budget allocations are being made based on these stories.
So what does the picture actually look like when you move past the demos and talk to developers using AI on real projects, inside real companies, dealing with real constraints?
The Big Tech Experiment: Fast Starts and Expensive Surprises
One pattern emerging from large tech organisations is a familiar arc: initial excitement, aggressive adoption, and then a quietly uncomfortable reckoning with costs and limitations.
Take a scenario that’s playing out at more than a few major corporations right now. A company — one of the recognisable names — embraces AI coding agents early and hard. GitHub Copilot comes first, then the more capable agentic tools, with Anthropic’s Claude Code among the most prominent. Management is enthusiastic to the point of cheerleading. Hit a token limit? Don’t worry, they’ll buy more. The energy is contagious.
For certain use cases, the results genuinely are extraordinary. Developers using AI to build new applications from scratch describe the experience as almost surreal — work that would have consumed a team for several months compressed into days, with large chunks of the system materialising at speed. When the developer is experienced enough to catch the exact moment the model starts drifting off course — which, perhaps unsurprisingly, seemed to happen with suspicious regularity around 5 PM — the pairing works well.
But the honeymoon has a shelf life. A few months in, two things become clear: AI doesn’t uniformly accelerate development the way the early wins suggested, and the cost of running these tools at scale is genuinely significant. Meta reportedly introduced what employees described internally as a “tokenmaxxing” culture — actively rewarding engineers for achieving results with fewer tokens, which tells you everything about where the economics of aggressive AI adoption eventually land. Unlimited AI agents, it turns out, are not cheap. For some organisations, the uncomfortable math is starting to make even bringing on interns look like a bargain by comparison.
Developers Using AI Inside Enterprise Legacy Systems
If greenfield development is where AI coding tools look their best, enterprise legacy systems are where they tend to look their worst. And here’s the uncomfortable truth the AI hype cycle rarely acknowledges: a staggering proportion of the software that actually runs the world is old, complicated, and deeply context-dependent in ways that current AI models fundamentally struggle with.
Consider a large international institution — the kind of organisation where privacy constraints are treated with near-religious seriousness, where a strategic pivot takes years to execute, and where the codebase has been accumulating history, workarounds, and architectural decisions made by developers who left years ago. These organisations were, understandably, among the last to adopt LLM-based tools. That they’ve now adopted them anyway speaks to how ubiquitous AI coding assistants have become across the industry.
But developers using AI agents inside these environments describe a consistent pattern: the tools perform reasonably well on discrete, well-defined tasks — squashing simple bugs, generating boilerplate, scaffolding small features. Push them into anything requiring genuine contextual understanding of the system, and they start to fall apart. An agent might read library code, crawl through the application structure, search across half the repository — and still completely misread what’s happening.
The knowledge gap is the core issue. Enterprise systems accumulate what engineers often call tribal knowledge: the understanding of why a specific architectural decision was made four years ago, why a UI library behaves in a specific undocumented way, why that one file written by a junior developer in 2018 is actually load-bearing. An engineer with two and a half years on a project often has a faster, more reliable debugging instinct than any current AI agent — not because they’re individually more capable in the abstract, but because they carry context the model doesn’t have access to and can’t easily infer.
This isn’t a criticism of the tools so much as an honest assessment of where they currently sit. Developers using AI agents are working with systems that pattern-match against what they’ve been trained on and what’s visible in the immediate context window. Enterprise codebases are full of decisions that made sense only in a specific organisational and historical context — and that context doesn’t live in the code itself.
What This Means for the Senior Engineer’s Role
There’s been a wave of commentary — some thoughtful, some breathless — about what AI means for the senior engineer specifically. The framing that keeps surfacing is whether the senior role is shifting from builder to reviewer, or from reviewer to orchestrator: someone who directs AI agents rather than writing code directly.
The reality emerging from practitioners is more textured than any of those clean categories. Developers using AI effectively right now tend to be doing something more like active collaboration than pure orchestration — they’re writing code, reviewing AI-generated code, catching hallucinations, adding context the agent is missing, and making architectural judgements the model isn’t equipped to make. It’s less “AI shepherd watching the robots” and more an experienced engineer using a powerful but frequently overconfident tool.
That skill — knowing when to trust the output, when to intervene, and crucially, where to look when the model goes off the rails — turns out to be something you build through deep domain experience. Which means, somewhat ironically, that the engineers best positioned to use AI coding tools effectively are often the most experienced ones. Not necessarily the ones most willing to outsource their judgement to a model.
The Real Productivity Story Is More Complicated
None of this means AI coding tools aren’t genuinely valuable — they clearly are, in the right contexts. Greenfield projects, boilerplate-heavy work, quickly prototyping an idea, generating test cases, summarising unfamiliar library documentation: these are areas where developers using AI report real, sustained productivity gains. The tools are getting better, the context windows are expanding, and the agents are becoming more capable at multi-step tasks.
But the narrative that AI is already transforming software development uniformly and dramatically across the industry doesn’t hold up against what engineers are actually experiencing day to day. The gains are real but uneven. The costs are higher than initial enthusiasm accounted for. And the assumption that deep human expertise becomes less relevant when AI enters the picture appears, at least for now, to have it backwards.
The more interesting question — and the one the industry will be working through over the next few years — is how these tools evolve to handle the kind of contextual, historically-laden complexity that makes up most of the software world. Better memory, smarter context management, and tighter integration with organisational knowledge bases are all directions the major AI labs are pursuing. When that gap closes meaningfully, developers using AI agents will find the conversation about what senior engineering looks like gets a lot more interesting. Until then, developers using AI day to day will be the first to tell you that the engineers who actually understand the systems they’re working on remain stubbornly difficult to replace.
Source: https://dev.to/sylwia-lask/how-are-developers-actually-using-ai-at-work-4g9c
