DEV Community: Marc Newstead

Why Your Image Upload Pipeline Should Check for Physically Impossible Lighting

Marc Newstead — Mon, 18 May 2026 11:10:19 +0000

Why Your Image Upload Pipeline Should Check for Physically Impossible Lighting

If you're building user-generated content platforms, marketplace verification systems, or anything that ingests images from untrusted sources, you've probably noticed the synthetic media problem getting worse. Gen-AI tools have become good enough that casual users can't spot the fakes anymore.

But here's the thing: the physics still breaks. And if you know what to look for, you can build surprisingly effective validation layers using simple computer vision techniques.

The Shadow Problem: Your First Line of Defence

In any real photograph, shadows share a common light source geometry. This is basic physics—light travels in straight lines. When AI image generators compose scenes from learned patterns rather than simulated physics, they consistently mess this up.

Here's what you can check programmatically:

1. Shadow Direction Consistency

Extract shadow vectors across different objects in the scene. In a genuine photo, these should converge toward a common vanishing point (the light source).

# Pseudocode for shadow vector analysis
def analyse_shadow_consistency(image):
    objects = segment_objects(image)
    shadow_vectors = []

    for obj in objects:
        if obj.has_shadow():
            vector = calculate_shadow_angle(obj, obj.shadow)
            shadow_vectors.append(vector)

    # Check if vectors converge within tolerance
    convergence_score = calculate_convergence(shadow_vectors)
    return convergence_score > THRESHOLD

This won't catch everything, but it'll flag a surprising number of AI-generated images, especially from earlier-generation models or rushed prompts.

2. Shadow Intensity Relative to Distance

Shadows should soften and lighten with distance from the object casting them. AI generators often produce shadows with uniform intensity throughout, or inconsistent softness between objects at similar distances.

You can measure this with edge detection and gradient analysis across shadow boundaries.

Reflection Geometry: The Silent Tell

Reflections are even harder for generators to get right. Water reflections, glass surfaces, and metallic objects all follow strict geometric rules.

What to check:

Reflections should be vertically symmetrical (for horizontal surfaces)
Reflection angles must match viewing angles
Environmental lighting in reflections should match the scene lighting

A simple geometric validation:

def validate_reflection(surface_region, reflected_region):
    # Extract key points from both regions
    surface_features = extract_keypoints(surface_region)
    reflection_features = extract_keypoints(reflected_region)

    # Check if reflection obeys mirror symmetry
    symmetry_score = calculate_mirror_symmetry(
        surface_features, 
        reflection_features
    )

    return symmetry_score > MIN_SYMMETRY_THRESHOLD

Where This Actually Matters in Production

If you're building:

Marketplace verification systems — Preventing fake product photos that don't represent real inventory. One e-commerce platform I know ran into this when sellers started using AI to generate "lifestyle" product shots that looked professional but didn't match the actual items.

Content moderation pipelines — Flagging synthetic profile pictures in identity verification flows, or detecting manipulated images in insurance claims.

Media asset management — Automatically tagging AI-generated images in your DAM system so teams know what they're working with.

You don't need perfect detection. You need a confidence score that feeds into your review queue prioritisation.

The Detection Tool Ecosystem

Before you roll your own, know what exists:

Hive Moderation and Illuminarty offer API-based detection with probabilistic scoring
Google's SynthID watermarks AI-generated content at generation time (only useful if the generator cooperates)
Open-source models like the ones from Hugging Face give you full control but require more infrastructure

These tools are useful as part of a layered approach, but they're not silver bullets. False positive rates are still high enough that you'll need human review for edge cases.

For a deeper look at the specific physical tells and how they manifest across different generators, spotting AI-generated imagery has become a critical organisational competency.

Building a Practical Validation Layer

Here's a sensible architecture:

Fast rejection filters — Basic checks for impossible lighting/shadows using CV libraries (OpenCV, scikit-image)
API-based scoring — Send suspicious images to a detection service
Human review queue — Images above a certain suspicion threshold get reviewed
Feedback loop — Feed confirmed cases back into your filters

async def validate_uploaded_image(image_file):
    # Layer 1: Fast physics checks
    physics_score = await check_lighting_consistency(image_file)

    if physics_score < 0.3:  # Clearly fake
        return {"status": "rejected", "reason": "lighting_anomaly"}

    if physics_score > 0.8:  # Probably real
        return {"status": "approved", "confidence": physics_score}

    # Layer 2: API-based detection for ambiguous cases
    api_score = await detection_service.analyse(image_file)

    if api_score < 0.5:
        return {"status": "review_queue", "scores": {"physics": physics_score, "api": api_score}}

    return {"status": "approved", "confidence": min(physics_score, api_score)}

The Bottom Line

You can't stop AI-generated images from being uploaded. But you can build systems that flag the physically impossible ones before they cause problems downstream. If you're working on platforms where image authenticity matters—or you're helping clients navigate this space through AI automation and software development—basic physics checks should be in your validation pipeline.

The generators will get better. But until they're simulating actual light physics rather than pattern-matching, the tells will remain.

Stop Optimising for One Search Algorithm — You Need Three in 2025

Marc Newstead — Mon, 18 May 2026 11:04:07 +0000

The search layer cake nobody warned you about

If you've built anything user-facing in the last 18 months, you've probably noticed something weird: classic Google search still exists, but so do AI Overviews. And ChatGPT. And Perplexity. And whatever Bing is calling their AI feature this week.

Here's the bit that matters for us as developers: you're now optimising for three distinct layers of search, not one. Classic SEO still matters. Answer Engine Optimisation (AEO) is a thing. And Generative Engine Optimisation (GEO) — making your content LLM-friendly — is rapidly becoming table stakes.

Ignore any one of these and you're leaving traffic (and revenue) on the table. The good news? A lot of this is automatable. The bad news? Most teams are still pretending it's 2019.

Why classic SEO isn't dead (and won't be)

Let's get the obvious out of the way: traditional SEO fundamentals still matter.

Core Web Vitals haven't gone anywhere
Structured data still helps crawlers parse your pages
Backlink authority is alive and well
Mobile responsiveness is non-negotiable

If your Lighthouse scores are in the red or your robots.txt is blocking half your site, no amount of AI magic will save you. Google's crawlers need to index your content before any algorithm — classic or generative — can surface it.

The mistake teams make is treating SEO as only this. It's necessary, but no longer sufficient.

AEO: structured answers for featured snippets and voice

Answer Engine Optimisation is about formatting content so it can be extracted cleanly as a standalone answer. Think:

FAQ schema that actually answers the question in the markup
Concise <h2> headings that mirror user queries
Tables and lists that are trivial to parse

Example: instead of burying your API rate limits in prose, do this:

## What are the API rate limits?

- Free tier: 100 requests/hour
- Pro tier: 10,000 requests/hour
- Enterprise: Custom limits

This works for featured snippets, voice assistants, and — crucially — gets picked up cleanly by LLM crawlers. Which brings us to layer three.

GEO: making your content LLM-legible

Generative Engine Optimisation means writing and structuring content so LLMs can cite it accurately. A few practical tactics:

Use explicit attributions. "According to [Your Company], the median API latency is 120ms." LLMs love citations they can quote.
Front-load key facts. Don't bury your lede six paragraphs down. Put the answer in the first 100 words.
Avoid jargon overload. LLMs are trained on the web; niche terminology without context confuses them.
Link internally with descriptive anchor text. "See our authentication guide" beats "click here."

If you want to go deeper on the strategic layer, there's a solid overview of AI-driven SEO that covers the business case.

What this looks like in practice

Let's say you're documenting a new SDK. Here's the old way:

"Our SDK provides a robust interface for interacting with the platform, offering flexibility and performance."

Here's the new way:

How do I install the Python SDK?

Install via pip:
pip install your-sdk
Supports Python 3.8+. Typical installation takes under 30 seconds.

The second version works for classic SEO (keyword-rich headings), AEO (structured Q&A), and GEO (clear, quotable answer). One piece of content, three optimisation layers satisfied.

Tooling that actually helps

You don't need a seven-figure MarTech stack to do this. A few categories worth exploring:

Schema validators (Google's Rich Results Test, Schema.org validator)
Content analysis tools that flag vague language or poor structure
AI-powered SEO platforms that surface keyword gaps and suggest schema improvements

If you're working with a team that spans AI automation and software development, ask them to audit your content pipeline. Most of this is scriptable.

The metrics trap

One last thing: rankings are now a lagging indicator. A page can rank #1 and still see click-through rates collapse because an AI Overview answered the query above the fold.

Track:

Impressions vs. clicks (CTR decay is your canary)
LLM citation frequency (some tools now track this)
Conversion rates, not just rankings

If your content is good enough to be cited by ChatGPT but your site never gets the click, you've got a GEO problem — or a business model problem.

TL;DR

Classic SEO fundamentals (Core Web Vitals, schema, backlinks) are still essential
AEO means structuring content as extractable answers (FAQ schema, lists, tables)
GEO means writing so LLMs can cite you accurately (front-load facts, use attributions)
One piece of content can satisfy all three layers if you write it right
Track CTR and conversions, not just rankings

The search landscape fragmented. Your optimisation strategy should reflect that — or you'll spend 2025 wondering where your traffic went.

Your Website's Content Now Has Two Jobs: Feeding Crawlers and Training LLMs

Marc Newstead — Mon, 18 May 2026 10:47:21 +0000

Your Website's Content Now Has Two Jobs: Feeding Crawlers and Training LLMs

If you've built a documentation site, marketing platform, or content-heavy application recently, you've probably optimised for Google's crawlers—structured data, semantic HTML, decent page speed, sensible meta tags. Job done, right?

Not anymore.

Google's AI Overviews (and similar LLM-powered search features from Bing, Perplexity, and others) are now extracting, synthesising, and presenting your content without sending users to your site. Your carefully crafted landing pages might be cited in an AI-generated summary, but the click? Gone.

This isn't theoretical. Organic click-through rates are dropping. The real battle for UK search visibility isn't just about ranking #1 anymore—it's about being the source LLMs choose to cite.

What Changed: From PageRank to Prompt Context

Traditional SEO was a game of signals: backlinks, domain authority, keyword density, Core Web Vitals. You knew the rules. You played by them.

Generative Engine Optimisation (GEO) is different. LLMs don't "crawl" in the same way. They're trained on massive corpora, then retrieve and synthesise information at inference time. The question isn't "Does this page rank?" but "Does this content get selected as context for the LLM's response?"

Think of it like this:

# Traditional SEO
def get_search_results(query):
    pages = index.find(query)  # crawled, indexed, ranked
    return sorted(pages, key=lambda p: p.pagerank)

# GEO / LLM-powered search
def get_ai_overview(query):
    context = retrieval_model.fetch_relevant_docs(query)
    response = llm.generate(query, context=context)
    return response  # user never clicks through

Your content needs to be selected during retrieval, not just indexed. That's a different optimisation problem.

What LLMs Actually Reward

Based on research into how generative engines select sources, here's what seems to matter:

1. Authoritative, Structured Answers

LLMs favour content that directly answers questions in a clear, hierarchical format. Think:

Concise definitions at the top
Bullet lists for steps or options
Tables for comparisons
Headings that map to user intent ("How to...", "What is...", "Best practices for...")

2. Semantic Richness

Keyword stuffing is dead. LLMs look for semantic coverage—related concepts, synonyms, contextual depth. If you're documenting an API, don't just list endpoints. Explain use cases, common errors, and edge cases.

3. Freshness and Specificity

Generic evergreen content is losing ground to timely, specific answers. If you're writing a guide, reference current versions, real-world examples, and actual data.

4. Citation-Friendly Formatting

LLMs are more likely to cite content that's easy to extract and attribute. This means:

Clear authorship and publication dates
Structured data (JSON-LD, Open Graph)
Blockquotes, code snippets, and other semantically marked-up elements

Practical Steps: Optimise for Both

The good news? You don't have to choose. Most GEO best practices also improve traditional SEO. Here's a starter playbook:

Audit Your Content for "Extract-ability"

Can someone (or an LLM) quickly pull a useful answer from your page? If your intro is 300 words of marketing fluff before the actual information, you're in trouble.

Use Structured Data Everywhere

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Building Resilient APIs",
  "author": {"@type": "Person", "name": "Jane Dev"},
  "datePublished": "2024-01-15"
}
</script>

This helps both crawlers and LLMs understand your content's context.

Write for Humans, Optimise for Machines

Your content should read naturally, but also be scannable. Use:

Bold text for key terms
Short paragraphs (2-3 sentences max)
Code blocks for examples (not screenshots)
Tables and lists for structured info

Track Non-Click Visibility

If your content is cited in an AI Overview but doesn't generate clicks, that's still brand exposure. Tools are emerging to track "impression share" in AI-generated results, but even anecdotal monitoring (searching your own key topics and noting citations) is useful.

The Workflow Shift

If you're building content pipelines or CMS tooling, consider:

AI-assisted content audits: Use LLMs to identify gaps in semantic coverage or question-answer alignment
Automated structured data generation: Parse your markdown/HTML and inject schema.org markup programmatically
Prompt testing: Literally query LLMs (ChatGPT, Claude, Perplexity) with your target keywords and see if your content surfaces

Agencies focused on AI automation and software development are building these workflows into content ops—treating GEO as a CI/CD problem, not just an editorial one.

The Takeaway

If you're maintaining documentation, a developer blog, or any content-heavy platform, your success metrics are shifting. Rankings matter less than retrieval. Clicks matter less than citation.

Optimise for both crawlers and LLMs. Structure your content like an API response: clear, hierarchical, and easy to parse. And remember—your content isn't just being read anymore. It's being used as training data.

Make sure it's worth learning from.

You Built the AI Feature. Now Sell It to the C-Suite Without Getting Stonewalled

Marc Newstead — Fri, 15 May 2026 09:37:34 +0000

You Built the AI Feature. Now Sell It to the C-Suite Without Getting Stonewalled

You've shipped a brilliant ML feature. The accuracy metrics are solid, the API is clean, and your team is buzzing. Then you present it to the exec team and hit a wall of "let's revisit this next quarter."

Sound familiar?

The problem isn't your code. It's that you're speaking a different language about risk, accountability, and control. Here's how to bridge that gap without dumbing down your work.

The Real Objection Isn't Technical

When a senior exec pushes back on AI features, they rarely say what they're actually worried about. They'll talk about "data quality concerns" or "needing more validation," but the underlying fear is simpler: who gets blamed when the AI screws up?

This is especially true for executives who built their careers in the 80s and 90s, when accountability meant your signature on a decision. The idea of delegating judgement to a statistical model feels like abdicating responsibility. Why boomer executives fear AI isn't just about technological conservatism — it's about personal liability.

As developers, we think in terms of accuracy, precision, and error rates. They think in terms of "whose neck is on the line if this goes sideways?"

Stop Pitching Automation, Start Pitching Augmentation

Here's where most technical presentations go wrong:

❌ "This model automates credit decisions with 94% accuracy"
✅ "This model flags high-risk applications for manual review, 
    processing the easy cases automatically"

The first framing sounds like you're replacing human judgement. The second sounds like you're giving humans superpowers. Same feature, entirely different reception.

Concrete example: If you've built a recommendation engine, don't present it as "AI that knows what customers want." Frame it as "a system that surfaces patterns across 10 million transactions that a human analyst would miss, then presents them for strategic decisions."

You're not replacing the executive's judgement. You're giving them better data to judge with.

Build Explainability Into Your Demo

When you demo AI features to technical peers, you might gloss over the model internals. When you demo to execs who are worried about accountability, lead with explainability.

Show them:

What inputs drive decisions — not just feature importance scores, but actual examples
How they can override the system — make the human-in-the-loop obvious
What the audit trail looks like — who reviewed what, when, and why

If your system doesn't have these features yet, build them before you present. They're not nice-to-haves; they're the price of admission for risk-averse organisations.

# Instead of just returning predictions
def predict(input_data):
    return model.predict(input_data)

# Return predictions with context
def predict_with_context(input_data, user_id):
    prediction = model.predict(input_data)
    return {
        'prediction': prediction,
        'confidence': model.predict_proba(input_data),
        'key_factors': get_feature_importance(input_data),
        'similar_cases': find_similar_historical_cases(input_data),
        'reviewed_by': user_id,
        'timestamp': now()
    }

Address Governance Before They Ask

Don't wait for the "but what about compliance?" question. Bring it up first.

Talk about:

Model versioning and rollback procedures
How you'll monitor for drift
Who has override authority and how it's logged
What the approval workflow looks like for edge cases

Yes, this feels like boring process stuff. But for execs who worry about accountability, this is the product. The ML model is just a component.

If you're working with partners who specialise in AI automation and software development, make sure they understand your organisation's governance requirements upfront. Retrofitting compliance is expensive.

Reframe Failure as Improvement

One subtle but powerful shift: stop talking about model accuracy as a fixed number.

Instead of: "The model is 92% accurate."

Try: "The model is currently 92% accurate, and we have a feedback loop that improves it every week based on human corrections."

This does two things:

It positions human oversight as valuable (not a sign of failure)
It frames errors as learning opportunities, not disasters

Execs who fear AI often imagine catastrophic, unfixable failures. Show them a system that learns from mistakes, with humans in the loop, and you've addressed the fear directly.

The Bottom Line

You don't need to compromise your technical standards to get exec buy-in. You need to frame your work in terms of amplified human judgement rather than automated replacement.

Build explainability, audit trails, and override mechanisms into your systems from day one. Present them prominently. Address governance before anyone asks.

Your AI feature isn't just code — it's a proposal for how decisions will be made. Speak to that directly, and you'll find the conversation shifts from "should we do this?" to "how fast can we roll this out?"

Why Your Web App Should Think Like Desktop Software (and How to Build for It)

Marc Newstead — Thu, 14 May 2026 15:01:43 +0000

The browser isn't a document viewer anymore

If you're still architecting web apps like they're fancy HTML documents with some JavaScript sprinkled on top, you might be building for a platform that's already evolved past you.

The browser has quietly become a full-blown application runtime. WebAssembly is now mature enough to run Figma's entire rendering engine, Photoshop, and even x86 emulators. AI-powered browsers are intercepting your carefully crafted UIs and summarising them into chat responses. The "page" as we knew it is being abstracted away.

So what does this mean for how we actually build things?

WebAssembly isn't experimental anymore

Wasm crossed the chasm from "interesting tech demo" to "production-ready platform" a while ago. If you haven't touched it yet, here's what you need to know:

It's polyglot by design. You can compile Rust, C++, Go, even Python to Wasm and run it in the browser at near-native speed. This isn't about replacing JavaScript — it's about escaping its performance ceiling when you need to.

Real-world use cases:

Heavy compute (image/video processing, CAD tools, scientific simulations)
Porting existing codebases without a full rewrite
Client-side data processing where latency matters
Running untrusted code safely (Wasm's sandboxed by default)

Here's a trivial Rust → Wasm example:

#[no_mangle]
pub extern "C" fn process_image(ptr: *mut u8, len: usize) -> usize {
    // Your heavy image processing logic
    // Runs at ~80-90% native speed in-browser
    len
}

Compile with wasm-pack, import into JS, and you've got near-native performance without a server round-trip.

The shift in thinking: Stop assuming expensive operations need a backend. If your web strategy is ready for this, you're designing client-first architectures where the server becomes optional infrastructure, not the default.

AI browsers are breaking your UI assumptions

Arc Browser, Opera with built-in AI, and browser extensions powered by LLMs are already changing how users consume the web. They're not just reading your DOM — they're parsing it, summarising it, and presenting it differently.

What this means practically:

Semantic HTML matters again (but differently). AI agents parse structure better when your markup is meaningful. That <article>, <nav>, and proper heading hierarchy? Not just for accessibility anymore.
Your API is your product. If an AI can bypass your UI entirely and interact with your backend, your business logic needs to be exposed thoughtfully. Think API-first, with rate limiting, auth, and proper error responses.
Progressive enhancement, redux. Build for the scenario where your carefully designed UI might be summarised into three bullet points. Does your app still work? Is the core functionality accessible via keyboard, API, or structured data?

Architecture for an OS-like browser

Here's how to think about building for this shift:

1. Design for stateful, long-lived sessions

Traditional web: stateless, page-based, server-authoritative.

Browser-as-OS: persistent local state, offline-capable, sync when needed.

Use IndexedDB or SQLite (via Wasm) for real client-side data
Design sync strategies that assume conflict (CRDTs, last-write-wins, operational transforms)
Service Workers aren't optional — they're your process manager

2. Treat JavaScript as the orchestration layer

Your heavy lifting should increasingly happen in Wasm, Web Workers, or streamed from a backend. JS coordinates, it doesn't compute.

3. Expose structured data and APIs

If your app is only usable through your React SPA, it's fragile. Provide:

A documented REST or GraphQL API
JSON-LD or structured metadata for AI parsing
Web Components or iframes for embedding

4. Performance ≠ bundle size anymore

Wasm modules, streamed data, and lazy-loaded workers shift the performance equation. A 2MB Wasm binary that runs in 50ms can beat a 200KB JS bundle that blocks the main thread.

Stop building documents, start building environments

The mental shift is this: you're not publishing content that gets requested and rendered. You're shipping an environment that runs on someone else's machine.

That means thinking about:

Resource management (memory, CPU, battery)
Security boundaries (sandboxing, CSP, subresource integrity)
Interoperability (can other tools, agents, or apps consume what you build?)

If you're working with clients or stakeholders who still think "website = pages + forms", this is the conversation to have. Agencies focused on AI automation and software development are already building this way — browser-native apps that behave like desktop software, API-first platforms that work with or without a UI.

What to do Monday morning

Audit one feature in your app that's slow or server-dependent. Could Wasm or local-first architecture solve it?
Check how your app behaves when an AI tries to parse it. Run it through ChatGPT's browser mode or Arc's AI features.
Expose one core workflow as a documented API, even if it's just for internal use.

The browser is already an OS. The question isn't whether to build for it — it's whether you'll do it intentionally or get dragged along by the shift.

Using AI to Map Legacy Code Without Rewriting Everything

Marc Newstead — Wed, 13 May 2026 16:46:44 +0000

Using AI to Map Legacy Code Without Rewriting Everything

If you've ever inherited a fifteen-year-old Java monolith or been asked to "modernise" a COBOL system that's been running since before you were born, you know the real problem isn't the code itself — it's understanding what the hell it actually does.

The business logic is tribal knowledge. The original developers have long since moved on. The documentation, if it exists at all, is either outdated or actively misleading. And yet, this code is mission-critical.

This is where AI tooling is starting to show genuine value — not by magically rewriting everything (please don't), but by making legacy systems legible enough to modernise incrementally.

The Documentation Gap Is What Actually Kills You

Let's be honest: the blocker on most legacy migrations isn't technical complexity. It's the fact that nobody knows what the code is supposed to do.

You've got thousands of lines of procedural COBOL or deeply nested Java that's been patched and extended for decades. Business rules are embedded in the code itself. There are no tests. The person who understood the invoice calculation logic retired in 2012.

Traditionally, you'd need to:

Reverse-engineer the business logic by reading code
Interview subject matter experts (if they still exist)
Run the system with test data and observe outputs
Document everything manually

This takes months. And it's boring, error-prone work that nobody wants to do.

Enter AI-Assisted Mapping

Modern LLMs (GPT-4, Claude, even specialised models) can:

Parse legacy code and generate plain-English summaries of what functions do
Trace data flows across modules
Identify dependencies and side effects
Suggest which components are safe to decouple

Here's a simple example. You've got a 500-line stored procedure that calculates something financial. You feed it to an LLM:

-- Legacy stored procedure from 2005
CREATE PROCEDURE calculate_customer_discount
  @customer_id INT,
  @order_total DECIMAL(10,2)
AS
BEGIN
  -- 500 lines of nested IF statements
  -- and undocumented business rules
END

You prompt:

"Summarise what this procedure does, list all business rules, and identify external dependencies."

The output won't be perfect, but it gives you a starting point that would've taken hours of manual analysis. You can then:

Validate the summary with a domain expert
Use it as documentation for the replacement service
Identify edge cases that need testing

This approach is already being used across UK enterprises — financial services and public sector teams are documenting legacy systems at a pace that simply wasn't feasible before. For a broader view on how organisations are tackling this, see this pragmatic guide for UK enterprises.

Strangler-Fig with AI: Incremental Wins

The strangler-fig pattern is still the safest way to modernise: you build new services alongside the old system, gradually routing traffic over, until the legacy code can be retired.

AI tools can act as a co-pilot here:

Identify bounded contexts — which chunks of the monolith can be safely extracted?
Generate interface contracts — what inputs and outputs does this component expect?
Scaffold replacement services — create boilerplate for new microservices based on analysed legacy behaviour
Compare outputs — run both old and new implementations in parallel and flag discrepancies

You're not trusting the AI to do the work unsupervised. You're using it to speed up the tedious parts so you can focus on the hard decisions: architecture, trade-offs, risk.

Where AI Breaks Down (and You Still Need Humans)

Let's be clear: LLMs don't understand your business logic. They pattern-match. They hallucinate. They'll confidently give you plausible-sounding nonsense.

Don't use AI for:

Final architectural decisions — a human needs to own that
Validating business-critical logic — always verify with domain experts
Security-sensitive code — treat AI output as untrusted input
Anything without code review — hallucinations are real and dangerous

AI is a documentation accelerator and a mapping tool. It's not a replacement for engineering judgement.

Practical Takeaways

If you're staring down a legacy modernisation project:

Start with documentation, not code replacement — use AI to map what exists before you change anything
Validate everything — treat AI output as a first draft, not gospel
Focus on knowledge capture — the real value is making implicit knowledge explicit
Use AI for boring, repetitive analysis — free up your team to solve actual problems

Legacy systems aren't going away. But with the right tooling and a pragmatic approach, you can make them understandable — and that's half the battle.

If your team is exploring how AI fits into modernisation work, agencies specialising in AI automation and software development can help structure these programmes without the hype.

What's your experience with legacy code and AI tooling? Have you used LLMs to document or analyse old systems? Let's hear it in the comments.

Your AI Copilot Is Steering Your Tech Stack (And You Might Not Have Noticed)

Marc Newstead — Wed, 13 May 2026 16:31:29 +0000

Your AI Copilot Is Steering Your Tech Stack (And You Might Not Have Noticed)

Let's talk about something that's been happening on development teams everywhere, but hardly anyone's discussing openly: AI coding assistants are influencing which languages and frameworks we choose. Not through recommendations or warnings, but through something far more subtle — better autocomplete suggestions.

If you've noticed your team gravitating toward TypeScript over JavaScript, or reaching for well-documented frameworks more often, there's a good chance your AI assistant is quietly pushing you in that direction. Here's what's actually happening and why you should care.

The Autocomplete Bias

AI coding assistants aren't neutral tools. They're trained on massive datasets of public code, and they perform measurably better with some languages than others. TypeScript over JavaScript. Go over Ruby. Frameworks with extensive documentation over newer alternatives.

This isn't about one language being objectively "better" — it's about which languages AI can parse and predict more reliably.

Think about your own experience. When you're working in TypeScript, your AI assistant probably feels almost telepathic — completing entire functions, suggesting the exact pattern you were about to write. Switch to a dynamically-typed language or a less-documented framework, and suddenly it feels… duller. More generic. Less helpful.

That difference in experience creates a feedback loop:

Better suggestions → faster development → positive reinforcement
Weaker suggestions → more manual typing → subtle frustration
Over time, the path of least resistance shifts toward AI-friendly choices

When AI Preferences Become Architectural Decisions

This influence doesn't stop at language choice. It cascades:

Language → Framework → Architecture

When your AI assistant excels at TypeScript, you'll naturally get better suggestions for TypeScript-first frameworks like Next.js or NestJS. The autocomplete for configuration, routing patterns, and common operations will be sharper. You'll ship faster.

Meanwhile, that interesting new framework with sparse documentation? Your AI assistant will be nearly useless. You'll feel like you're coding with one hand tied behind your back.

The result: teams drift toward a narrower range of technologies, not because of deliberate technical evaluation, but because of tooling friction.

The Real Risk Isn't Technical

Here's the uncomfortable bit: for many projects, TypeScript probably is the right choice. The static typing, improved tooling, and reduced runtime errors are genuine benefits.

The risk isn't that AI is quietly deciding your tech stack poorly — it's that you're not deciding at all.

When was the last time your team had a proper discussion about language choice? Can you honestly say you evaluated the trade-offs, or did TypeScript just become the default because "everyone's using it" and it felt better with Copilot?

What You Can Actually Do About It

This isn't a call to abandon AI assistants or reject TypeScript. It's a nudge to make technology decisions deliberately.

Here's what that looks like in practice:

1. Name the Influence

In your next tech stack discussion, explicitly ask: "How much of this preference is driven by better AI assistant support?" Just acknowledging it changes the conversation.

2. Separate Evaluation from Implementation

When assessing a new library or framework, spend time with the documentation and community before diving into code. Don't let autocomplete quality be the primary signal.

3. Track Your Technology Radar

Keep a lightweight register of your tech choices and why you made them. Review it quarterly. Are you actually evaluating alternatives, or has your stack ossified around what your AI assistant knows best?

4. Test Drive Without Assistance

Occasionally try prototyping in a new language or framework with AI assistance disabled. It's uncomfortable, but it recalibrates your sense of what's genuinely difficult versus what just has weak AI support.

The Bigger Picture

For teams working on AI automation and software development, this is doubly important. If you're building AI-assisted tools, you're both influenced by and influencing these patterns.

The future probably involves AI assistants becoming even more capable and more opinionated. That's not inherently bad — but it makes intentional technical decision-making more valuable, not less.

Your Move

Next time you're starting a new project or choosing a framework, pause before reaching for the obvious choice. Ask yourself:

Are we choosing this because it's the best fit for our problem?
Or because our AI assistant makes it feel effortless?

Both can be valid reasons. But you should know which one you're acting on.

The tools are meant to serve your decisions, not make them for you. Keep it that way.