Six Things (and counting) That Break When Engineering Teams Adopt AI
So you thought you could get AI to write all your code for you, huh? You poor, unfortunate soul.
The Little Mermaid: Ursula and Ariel
AI coding tools don't remove work from software engineering. They move it. The bottleneck shifts from writing code to reviewing, integrating, and maintaining it. Not noticing this shift fast enough will cause your team all sorts of pain. Here are the six failure modes that show up most consistently, and what actually helps.
1. Everyone is suddenly an engineer
Your PM has an opinion on your caching layer. Your CEO forwarded you a message about switching to event sourcing. Your uncle dms you “Gemini sent me this link about denormalising tables. Thoughts?”.
They all mean well and the output sounds right. The output consists of words, words that you are familiar with, that form sentences. But the sentences… The sentences sound like when you teach a kid a new word and they try to use it in a sentence. I mean it is completely idempotent, you know?
Fluent, structured, plausible garbàge.
The chatbot has no clue about your legacy contracts that can’t change until Q3, about the compliance requirement or the downstream consumers or about your strategic direction and why refactoring this whole application to fix a bug is not ideal, when this application is getting decommissioned next month.
But most importantly the person relaying the chatbot’s output to you has no way to tell good from bad. That's discernment - that little skill you’ve spent a decade sharpening and that people pay you very good money for? Yes, that one. So now you're not just doing the work. You're doing the work and explaining, patiently, why applying anti-fungal cream to your eyes is not a good idea just because it said "apply directly" somewhere in the instructions.
What helps:
Redirect to outcomes, not implementation. "What problem are you trying to solve?" is a better conversation than debating their proposed solution. Usually there's a real problem underneath worth hearing.
Write your constraints down once. A living doc of hard limits means you point at it instead of re-litigating from scratch every time. Collate regulatory, contractual, performance and dependency constraints in one place.
Give them a sandbox. Non-engineers with AI curiosity will build something regardless. Better it lands in a sanctioned playground than in a Slack thread aimed at your roadmap. (See point 2 for potential issues with this approach.)
Sometimes they're right. Test the suggestion cheaply rather than dismissing it on principle. Reflexive dismissal costs you credibility on the one occasion the idea would have worked.
Build your own heuristics for when to engage versus when to nod and move on: is this idea horrible out of the box? is this person generally sharp? Have they been right before? Can they fire me? Do I care if they do? Etc, etc
2. "Everyone can build their own tools now"
Another “democratisation” wave is upon us, people. As a Greek, I feel compelled to weigh in. Here are my thoughts as someone coming from the birthplace of democracy:
The pitch is genuinely appealing: text-to-SQL, natural language dashboards, internal app builders. Marketing asks a question in English and gets a number. Ops builds the tool it's been waiting six months for. Engineering stops being a ticket queue and everyone is high-fiving each other during Thursday drinks at The Nag’s Head.
Then it meets the data. The hard part of analytics was never SQL syntax. It's knowing that orders still contains test rows from the 2019 migration, that revenue is pre-refund in one table and post-refund in another, that EMEA changed its fiscal calendar in 2022, that deleted_at IS NULL is load-bearing, and that the customer table has three definitions of "active" depending on which team wrote the column. A model handed your schema has all of the syntax and none of that. And the failure mode is silent. Nobody debugs a number that looks reasonable.
The precedents are not encouraging
None of the below cases involved AI. They are the same mechanism running at a fraction of the volume.
Barclays and Lehman Brothers, 2008. During the fire-sale acquisition of Lehman's North American business, a junior associate at Barclays' law firm compiled the list of trading contracts for the deal in Excel. Roughly 1,000 rows, of which 179 were meant to stay out and had been hidden rather than deleted. Reformatting the file and converting it to PDF for court filing brought those hidden rows back as visible, active line items. The spreadsheet hadn't malfunctioned; it had done precisely what it was built to do. Barclays ended up legally bound to contracts nobody intended to include.
Reinhart–Rogoff, 2010–2013. A widely cited economics paper linking high public debt to negative growth was used to justify austerity policy internationally. When a graduate student finally obtained the underlying spreadsheet in 2013, part of the headline result traced to an averaging formula that omitted five countries from the selected range (paper here). Correct data, wrong methodology.
The citizen-developer waves before this one. Access databases, FileMaker Pro, SharePoint, then low-code platforms. Each promised the same democratisation. Each produced a decade of shadow IT that engineering eventually inherited: undocumented, unowned, and business-critical by the time anyone looked at it.
The common thread isn't a lack of expertise. Reinhart and Rogoff were serious economists. It's that a tool that produced a confident, plausible result, and nobody checked the mechanics behind it before the result got used. Expertise in the subject doesn't substitute for scrutiny of the tool. AI doesn't change that gap. It changes the volume by orders of magnitude.This problem shows up in engineering too, and sections 5 and 6 cover that version directly. This section works through the analytics case in depth, because it's the clearest illustration and because the fixes below are genuinely specific to data work.
What helps:
Start with a data dictionary. Column-level docs (e.g. this field is UTC, this is pre-refund, status=3 means cancelled) are descriptive: they say what a raw thing is. This is the foundation everything below depends on, and it's the layer most teams skip because it's unglamorous. It can live in dbt's own column descriptions, a wiki and if you're already running a platform like DataHub, dbt's column descriptions land there automatically on ingestion, sitting alongside DataHub's business glossary for the org-wide vocabulary ("revenue" means the same thing to Sales and Finance) layered on top of the raw field docs. This is your foundation. Not the whole house. For instance, for text-to-sql tools a 2026 paper (“Arming Agents with Tribal Knowledge”) on grounding text-to-SQL agents found that simply restating database contents doesn't actually correct an agent's misconceptions about how to use the data. A dictionary tells the model what a column is, not how to reason with it, which is exactly why the next layer exists.
Put a semantic layer on top of it. Avoid pointing text-to-SQL (and non technical users in your org) at raw tables. Point it at a governed metrics layer, such as dbt's Semantic Layer or LookML, where "revenue" and "active customer" are defined once, by someone who knows, using the dictionary above as ground truth. You are explicitly defining how to calculate something, not what the field contains.
This matters more than it sounds like it should: research on enterprise-scale text-to-SQL consistently finds that the failure mode isn't bad SQL syntax but the model selecting the wrong context in the first place — such as picking the wrong table out of a large catalog, or missing the right column inside a large, redundant schema. A governed metric layer sidesteps this by giving the model a small, curated surface to query instead of the raw catalog. It's also why a bare dictionary isn't a substitute: even good documentation on every column doesn't help if the model still has to search a thousand of them to find the right five.
Worth noting that the semantic layer accumulates draft, half-finished, and abandoned metric definitions just as easily as governed ones. To mitigate this,certify a small set explicitly: everything else stays labelled exploratory, and numbers that reach a board deck come from certified definitions only, with everyone clear on which is which.Put a metadata platform under all of it. The semantic layer is only as good as what feeds it. It's a calculation engine sitting on inputs it can't independently verify. If the underlying table goes stale, gets silently redefined, or drifts from its documentation, the semantic layer computes a wrong answer with exactly the same confidence as a right one. A platform like DataHub tracks where data actually comes from, who owns it, and whether the definition feeding your metric is still current, so drift gets caught before it reaches the calculation rather than after it reaches the board deck.
Always show the SQL. Make it copyable and easy to hand to an analyst. Reviewability matters more than accuracy here, because accuracy you can't inspect is indistinguishable from luck.
Sunset citizen-built apps by default. Every one gets a named owner and a review date. Unowned tools get switched off rather than silently inherited. The alternative is engineering maintaining forty apps it didn't write in five years' time.
Route the use case honestly. Anything a decision, a customer, or a regulator depends on, route to your analysts. Any exploratory work and hypothesis generation, route to these tools.
Upgrade your analysts to your org's stewards. Their role shifts from writing queries to defining semantics and auditing output. Same expertise, 10x output. They now watch over the whole organisation’s judgement instead of just their own queries.
Have the tough conversation. All the above rest on the premise “If they’re gonna do it, I’ll make sure they are safe.”. However, if someone is trying to put a live wire into a bucket of water, it is preferable to just ask “What on earth are you doing, mate???”.
3. The prototype that ate the roadmap
Someone builds a working demo in an afternoon. It gets shown to leadership. Leadership assumes launch next Monday. There are two separate ways this goes wrong, and they compound each other.
Error Mode 1: You will underestimate how far the demo is from production
The prototype skipped auth, error handling, migrations, observability, rate limiting, retries, and roughly 40% of the edge cases, which is where most of the actual engineering time lives. AI is exceptionally good at producing the happy path, which is exactly the part that was never the hard part.
Photo by David Muska on Unsplash
Error Mode 2: You will build the wrong thing
Underestimating hardening costs you a quarter. Shipping something nobody wanted costs you the year.
Product risk has always had four parts: can we build it, will they use it, can they figure it out, does it make business sense.
Feasibility (can we build it) used to be the slow one, and that slowness accidentally did a job nobody assigned it. Three months of engineering effort forced someone to justify the idea, gave the market time to change your mind, and killed a lot of bad concepts through sheer attrition.
When you can build a pigeon water deterrent in an afternoon, you don’t stop to think “Should I even be doing this, eh?”. AI collapses feasibility to an afternoon. The filter is gone, and nothing replaced it. The other three risks are unchanged and now completely unguarded.
The failure pattern is old and well documented:
RIP Google Wave (2009). A technically spectacular demo at I/O that got a standing ovation from a room full of engineers — listen nerds, we do get excited about the most random stuff; it's embarrassing sometimes. Almost nobody outside that room could articulate what it was for. Google shut it down roughly fifteen months after launch.
RIP Juicero (2016–2017). Have you ever wanted a glass of juice but all the supermarkets were closed so the only thing that made sense was to purchase a proprietary machine that required proprietary pouches of pre-chopped fruit which it would then squeeze and produce a fresh glass of proprietary juice? Look no further! A beautifully engineered connected press is here and can be yours for $699. Reporters discovered the packets could be squeezed by hand about as fast but that’s neither here, nor there. The machine worked and was backed by well over $100m before the project was unfortunately shut down 16 months after launch.
RIP Amazon Fire Phone (2014). Four front facing cameras and novel head-tracking 3D? Sign me up! Sadly no-one else signed up and the product was written down by roughly $170m within months.
RIP Segway (2001). Picture this: wheel on your right, wheel on your left, you in the middle, leaning back and forth on this prehistoric hoverboard with -100 aura points. It was predicted internally to reshape how cities were built but sadly sold a small fraction of projections. Bummer. The engineering was real; the demand model was real bad.
None of these failed on execution. They failed on a premise nobody tested, and every one of them had a demo good enough to sustain belief for years.
Now imagine that dynamic with the build cost dropped by 95% (for now). You don't get fewer of these. You get more, faster, and with less justification required to start each one. "We already have a working version" is the most persuasive and least meaningful argument in the room.
What helps:
Label it loudly and structurally. Prototype in the repo name, a banner in the UI, a slide in the demo. Make it impossible to forget.
Show the gap concretely. A checklist of what's missing lands better than "it needs hardening." People can't estimate an abstraction.
Give two numbers. Throwaway-and-rebuild vs. harden-what-exists. Rebuilding is frequently faster, and the side-by-side makes that visible instead of arguable.
Make prototypes deliberately unshippable. Different stack, hardcoded data, ugly UI. If it could ship as-is, someone will eventually ask why it doesn't.
Demand the problem statement before the demo. Who has this problem, how do they solve it today, what does that cost them, why is that unacceptable. If those can't be answered without hedging, the prototype is a mirage.
Separate demo risk from product risk explicitly. "It works" answers feasibility only. Make someone state, in writing, which of the other three risks has been tested and how.
Test the riskiest assumption first, and make it the value assumption. A handful of cheap techniques exist for this, listed below. All of them are now slower than building the thing, which feels absurd and is exactly why they get skipped. Do them anyway.
Fake-door test: a button or menu item for a feature that doesn't exist yet. Click it, get "coming soon" instead. Measures real intent, not opinion.
Landing page test: a page describing the product as if it's real, with a signup button, pointed at actual traffic. Cheaper and faster than building anything.
Concierge / Wizard of Oz test: a human quietly does the work behind what looks like an automated product. Concierge is upfront about the human; Wizard of Oz hides them. Tests whether the outcome is valuable before automating it.
Pre-sales: asking people to pay before the product exists. Money on the table beats a survey answer every time.
Letter of intent: a non-binding written commitment from a company saying they'd buy it if built. The B2B version of a pre-sale.
Talk to users continuously, not as a gate. A steady cadence of customer conversations is the only thing that reliably catches a premise problem before launch. Small and weekly check-ins, beat a big research phase.
Use AI for discovery, not just delivery. Building three throwaway variants and putting them in front of real users in a week is a legitimately new capability. That's the version of cheap prototyping that reduces risk instead of manufacturing it.
Keep a kill criterion. Written down before you start, with a date. Prototypes are enormously good at generating sunk-cost commitment, and the only defense is deciding what failure looks like while you still don't care about the answer.
TLDR: your product people are becoming your unicorns. - Listen. I said the nice thing about product. I broke the engineering decree. Tell no one. This. Stays. Here.
4. The token bill nobody (?) forecasted
Actually, somebody did forecast it and it was the people selling you the tokens and also every engineer, everywhere.
Have you people learned nothing from Deliveroo? From Uber eats ???
Now, your agents? Re-reading the whole repo every turn. Your context? Grows unbounded across sessions and you pay for the entire history. Your costs? Ballooned. Your eye-brows? Plucked from the stress of looking at your token bill.
Most of this spend is the agent doing archaeology. It is grepping and reading files to answer questions like "where is this defined" and "what calls this." Those are structural questions, and there are far cheaper ways to answer them than loading thirty files into context.
What helps:
Set budget alerts before you need them. Per team, per project. The first surprise bill should be an alert, not an invoice.
Right-size the model. Renames, test scaffolding, formatting, and codemods don't need your most expensive model. Reserve that for work that actually requires reasoning.
Cache aggressively.Prompt caching on stable context is usually the single largest cost reduction available, and it's mostly configuration. Cache the stable stuff (system prompts, conventions file, tool definitions, reference docs, the code graph); don't bother with the variable stuff (the live question, freshly edited files). Put stable first in the prompt and variable last, since caching matches on exact prefixes. One caveat worth internalizing before you build your own tooling: caching in the product and caching at the SDK level are not the same thing. Tools like Claude Code and Copilot place the breakpoints for you; build directly on the SDK and the cache won't happen until your code marks them itself. Check your specific SDK's docs before assuming it's automatic. And know the shared failure modes: starting a fresh session, switching models mid-session, editing your instructions file mid-session, or resuming after a long idle gap all invalidate or double-charge the cache. All these overcomplicate the next point which is…
Start fresh sessions. Long-running threads pay for their entire accumulated history on every turn. Resetting is cheaper than continuing.What we mentioned at the end of the previous section makes this point a bit more complicated. A new session reprocesses the whole system prompt on turn one at full price, so two ten turn sessions can cost nearly twice what one continuous twenty turn session would for the same work. Reset while the cache is still warm and you also throw away a hit you already paid to build. So reset as a tool, not a reflex. One question to help you decide: Did the last few turns actually need the early context?
Reset when:
The conversation has moved on, and you're paying every turn to re-send an old task the model no longer needs.
The thread has grown long enough that reprocessing a fresh prefix once beats dragging the whole transcript through many more turns.
The model has anchored on something wrong and keeps drifting back to it. Here you reset for quality, not cost.
You're about to step away for a while anyway. The cache may expire on its own, so the reset is roughly free.
Keep going when:
You're in active back and forth on the same task. The cache is warm and the history is still load bearing.
The thread is still short. History is cheap and the prefix is the expensive part.
The last few turns clearly relied on the early context.
Scope the context. Point tools at directories, not the repo root. A good ignore file is worth more than it looks.
Give the model a map, not the territory. The structural fix is indexing your codebase so the agent can query it instead of reading it.
Generate a code graph. Tools like graphify (or any AST/dependency-graph indexer, tree-sitter-based tooling, ctags, or a language-server-backed map) produce a queryable model of symbols, definitions, call edges, and imports. The agent finds the three files that matter instead of loading thirty to figure that out.
Update it in a pre-commit hook. A graph that goes stale is worse than no graph, because the model will confidently act on it. Regenerate incrementally on changed files only; a full rebuild in a commit hook gets disabled within a week. Commit the artifact, or build it on checkout if it's too large to version.
Keep semantic information in separate docs. The graph tells the model what connects to what. It cannot tell it why. Business rules, domain vocabulary, the reason a particular workaround exists, which module owns which concern — that lives in markdown written by humans and read directly by the model.
The split matters because staleness behaves differently on each side. Structure changes constantly and must be automated. Intent changes slowly and is worth maintaining by hand.
5. Pull requests nobody can actually review
Are your Pull Requests turning into CVS receipts? It is now trivial to touch sixty files but my poor brain just can’t scale. A PR that is TLDR gets approved because approving it is easier than reading it, and the bugs that survive are precisely the subtle, plausible-looking ones AI is best at churning out.
Modelling your PRs after 'Shree Haricharitramrut Sagar'?
What helps:
Enforce size limits in CI. Warn around 400 lines, block at a hard ceiling with an explicit, logged override. Friction is the point.
Plan first, implement in slices. Ask the model for an approach, agree on it, then build one piece at a time. Stacked PRs work well here.
Split mechanical from semantic. Renames, formatting, and codemods go in their own PR so the logic diff stays small enough to actually read.
Pair programming, anyone? Tale as old as time, the pair-programming-vs-PR-review wars long predate AI, and this might be the moment to reopen them. The mechanic is simple: two people on one task, reviewing as the code is written rather than after. One drives (types) while the other navigates (watches, questions, catches problems in real time), and they trade off. The point for this list is that review moves upstream, i.e. there's no 3,000-line diff to rubber-stamp later, because a second brain already saw every line in context, as it happened. It isn't free (two people, one task), so spend it on the gnarly, high-risk, or design-heavy work rather than everything. But if unreviewable PRs are the disease, catching issues at the keyboard beats catching them never.
Unit, regression, end-to-end tests are your friends. When your PR is 7000 lines and you don’t know what to do, who you gonna call? Ghostb- Yes, that’s right your good old CI/CD staples.
Now, if you are really smart, you might be thinking, “But Lia, can’t I use AI to help me fix the problem AI is creating?”. My dear friend, why, of course you can! You can do anything you put your mind to. Orchestrate agents to split planning, implementation, review, QA. Check QA results and a report of which tests were modified and Bob’s your uncle (Uncle Bob is also experimenting with this very thing).
Have I tried this? Yes! Have I tried this at work? Absolutely not. Unless you get buy-in from leadership to build this as a tigh product and spend time, energy and resources reading papers, experimenting with what works and what doesn’t, the liability is all yours.Authorship means ownership. "The AI wrote it" is not a review defense. Whoever opens the PR is responsible for every line in it. (Unless you can get management to approve they aren’t that is - see also the previous point.)
6. The same function, written five times
I am getting tired of the pop cult references so below you will mostly get hard, cold facts. It’s late at night and I want to finish this article, ok? Just imagine I wrote something witty here to keep you engaged. Now back to writing the same function five times…
So, each code pass invents its own helper, because the model doesn't know your utils exist. You end up with five date formatters, four HTTP wrappers, and three retry implementations. Nobody notices until a bug needs fixing in all of them.
The old friction protected you here. Writing a date formatter by hand was annoying enough that you'd go find the existing one first. That friction is gone.
What helps:
Prevent
Maintain a conventions file. A CLAUDE.md or equivalent listing shared utilities, patterns, and where things live. Highest-leverage single fix available.
Ask before generating. "What in this repo already does something similar?" costs one prompt and prevents the sixth wrapper.
Keep shared code discoverable. A flat, well-named lib/ beats deep nesting the model will never explore.
Query the graph. The index from section four is one of the cheapest ways to make the model find your existing formatDate instead of writing a new one.
Fix
Detect duplication in CI. Clones come in four flavors, easy to hard:
Type 1: identical. Straight copy-paste, maybe reindented. Trivial. You don't need AI; a token scanner (jscpd, PMD CPD, Simian) catches these in seconds and blocks the build. Just turn it on.
Type 2: renamed. Same code, total became sum. Still trivial for the same deterministic tools. No AI required.
Type 3: near-miss. A line added, removed, or reordered. AST-based detectors (SonarQube, DeepSource) handle these by comparing structure instead of text. Still not really "AI," and still cheap enough to gate on.
Type 4: semantic. Two functions that do the same thing written completely differently. For instance, a for loop versus recursion. Nothing looks alike; only the behavior matches. This is the only tier where AI is doing real work, and it's exactly the tier where AI is least trustworthy. Recent research testing state-of-the-art semantic detectors on realistically-rewritten code found they collapse. They'd quietly been keying off surface tokens and structure ("shortcut learning") rather than understanding behavior, so they ace the benchmark and miss the real clone. Great for the demo, not so great for your actual codebase.
Gate on Types 1–3 with deterministic tools; make Type 4 advisory. Block the build on the duplication you can detect reliably. Let the AI/semantic layer comment, not block but treat its findings like a tip, not a verdict, because its false-positive rate on real code is high.
Detecting isn't deduplicating. None of these tools remove the duplication. They only flag it. The actual refactor is a code change, and for that you need to…
Schedule deduplication passes. Once you've identified the duplicates (see previous step), AI is good at the mechanical merge, i.e. collapsing five formatters into one, updating every call site. That's the division of labor that works: you supply the judgment about what's actually a duplicate (the part the semantic tools can't be trusted with), the agent does the tedious rewrite. But the rewrite is still a code change like any other. Which brings us back to… PR Reviews.
Ouroboros
Thoughts
1. The mentorship layer underneath #5 and #6
Both of those problems mostly originate with junior engineers, not through carelessness, but because they don't yet know what the codebase contains, and AI has removed the friction that used to force them to look.
This is worth addressing at the source rather than catching at the gate.
Pair on the prompt, not just the review. Watching a junior assemble context is far more instructive than reviewing what came out. You catch "you never told it about our repository pattern" in real time, instead of eight hundred lines later.
Teach repo cartography explicitly. Most juniors have never been shown how to survey a codebase for existing patterns. Make "search before you generate" a taught skill with actual commands attached, not a slogan on a wiki.
Require them to explain the diff unaided. If they can't walk through why each change exists, it doesn't merge. This one rule shrinks PR size on its own, because people stop submitting code they'd have to defend line by line.
Assign ownership early. A junior who owns lib/http starts noticing when someone generates a fifth HTTP client. Ownership manufactures the reviewer you need.
Give them the consolidation passes. Merging duplicates is the fastest possible way to learn what the shared code actually is — and it's a task where AI assistance is entirely appropriate.
Seniors are drifting toward being reviewers and architects. Juniors need to arrive there faster than the old apprenticeship allowed. A junior whose only skill is prompting will generate problems #5 and #6 indefinitely. A junior who can read a codebase and defend a diff is made genuinely fast by these tools.
2. The senior/junior chasm
Seniors and juniors are not using the same tool. They think they are, and that's why the advice flowing between them keeps failing.
A senior reads a suggestion and knows within two seconds that it's wrong because the pattern doesn't fit or the abstraction is off - they've been burned by that exact approach before. AI is a fast typist attached to their existing judgment. It's a genuine accelerator.
A junior reads the same suggestion and sees something better than they'd have written themselves. That's often true, and it's exactly the trap. They have no model to evaluate against, so they accept, and every acceptance skips the struggle that would have built the model. The tool that makes seniors faster can quietly prevent juniors from becoming seniors.
Then the senior says "just review the output critically", which is not advice, it's a description of a skill the junior is trying to acquire. It sounds actionable and isn't.
An exercise for seniors
Pick a domain you're genuinely not confident in. Kubernetes networking if you're a frontend engineer. Rust if you've only written Python, a GPU kernel, an embedded toolchain, the tax logic in your billing system. Something where you can't bluff.
Now build something real with AI. Not a toy, something you'd have to defend.
Pay attention to what happens:
You accept suggestions because they look plausible, not because you evaluated them.
You can't distinguish a subtle bug from a convention you simply don't know.
When it breaks, you have no instinct for where to look, so you paste the error back in and hope.
You feel productive and fast, and you have genuinely no idea whether what you built is any good.
Someone senior in that domain could glance at it and see problems you'd never find.
This is your junior's entire working day, in your codebase, every day.
The point isn't humility for its own sake. It's that the exercise changes what you say afterwards. "Be critical of the output" becomes "check whether it used our repository pattern, verify the transaction boundary, and ask why it chose that index". These are the specific, teachable checks that a person without your model can actually run. That's the difference between advice and mentorship.
It's also worth saying plainly to your organisation: the productivity gap between seniors and juniors is widening, and it will show up in performance reviews as a talent problem when it's actually a tooling-and-training problem. If that goes unexamined for a few years, you won't have a junior problem. You'll have a senior shortage.
3. What doesn’t kill you makes you stronger
Above, I've outlined six failure modes and how to mitigate them. Essentially, every one of them is the same problem wearing different clothes: producing an artifact got cheap, and everything downstream of producing it did not. That's true of code, and it's equally true of queries, dashboards, and internal apps.
Teams that hold review standards constant while output accelerates come out ahead. Teams that let review quality drop with volume end up with a codebase nobody understands and a set of numbers nobody can defend and they'll get there faster than anyone.
But every one of those failure modes has a flip side. The same shift that breaks those six things makes six others stronger, provided you meet it deliberately.
So here are Six Things (and counting) That Thrive When Engineering Teams Adopt AI:
Judgment becomes the premium skill. When anyone can generate a plausible answer, the person who can tell good from bad is worth more, not less. Discernment stops being invisible and starts being the whole job.
Your analysts level up into stewards. Freed from writing the same query for the hundredth time, they define the semantics and audit the output instead. They have the same expertise with 10x reach, watching over the whole org's numbers rather than just their own.
Product discovery gets cheap. Three throwaway variants in front of real users in a week is a genuinely new capability. Pointed at discovery instead of just delivery, cheap prototyping reduces risk instead of manufacturing it.
Your codebase gets legible. The pressure to index it (code graph, conventions file, semantic docs) leaves you with a queryable, documented system you never found time to build before. The agent benefits; so does every human who joins next year.
Review standards become even more important. Pair programming, plan-first, sliced PRs, i.e. the practices AI forces back onto you are the ones good teams always wished they had the discipline for. The disease ships with its own cure.
Your juniors arrive faster. A junior who learns to read a codebase and defend a diff is made genuinely fast by these tools. If you mentor deliberately instead of outsourcing it to the model, the apprenticeship compresses.
Ok. I am done for now. I hope you have enjoyed reading my very first thoughts ever.
Toodaloo φίλη/φίλε μου,
Αποστο(Lia)
