Artificial Intelligence has fundamentally changed the way software can be developed. Tasks that once took days can now be completed in hours, repetitive boilerplate can be generated almost instantly, documentation can be drafted automatically, and developers have an ever-present assistant capable of accelerating almost every aspect of software engineering.
For startups and established businesses alike, this is transformative.
However, one lesson has become increasingly clear as AI-assisted development matures:
AI accelerates development: it does not replace software engineering discipline.
If anything, the faster code can be written, the more important it becomes to maintain a structured, iterative development process.
AI as an Accelerator, Not a replacement
Speed Can Create Technical Debt
The Cost of Technical Debt
One of AI’s greatest strengths is its ability to generate working code quickly.
Given a well-defined prompt, modern AI tools can produce complete components, APIs, database migrations, unit tests and documentation in minutes.
The challenge is that these outputs are often created in isolation.
Without regular architectural oversight, an application can begin to accumulate:
duplicated business logic
inconsistent coding styles
multiple approaches solving the same problem
diverging architectural patterns
unnecessary abstractions
hidden technical debt
Each individual piece of code may be perfectly valid, yet collectively the application becomes increasingly difficult to understand and maintain.
This isn’t a failure of AI.
It’s a consequence of accelerating development without equally accelerating governance.
The Importance of Product-Led Development
AI performs best when solving clearly defined problems.
That places greater importance on maintaining a living product roadmap.
Rather than asking AI to “build features”, successful teams define:
the business problem
user journeys
acceptance criteria
architectural constraints
non-functional requirements
future extensibility
Clear product requirements allow both developers and AI tools to evolve the platform intentionally instead of reactively.
As a product matures, every new capability should strengthen the core platform rather than simply add another layer on top.
The goal is not simply to ship features, it is to build a platform that remains maintainable after hundreds of features have been delivered.
Agile Is More Relevant Than Ever
Agile vs Waterfall
Traditional Agile methodologies were designed to embrace change through short feedback cycles.
That philosophy becomes even more valuable when AI dramatically increases development velocity.
Short development sprints allow teams to regularly ask:
Does this still align with the roadmap?
Is there duplication emerging?
Are architectural principles being followed?
Can existing functionality be reused?
Has complexity increased unnecessarily?
The objective is no longer simply to deliver functionality every sprint.
Each sprint should also improve the quality of the underlying platform.
Code Reviews Become Architectural Reviews
Code Review Focus Areas
Historically, code reviews focused on correctness.
Today they must also focus on consistency.
Regular reviews should consider questions such as:
Does this follow existing design patterns?
Has similar functionality already been implemented elsewhere?
Can common logic be extracted into reusable services?
Are naming conventions still consistent?
Is this introducing unnecessary coupling?
Does it remain easy for future developers, and future AI assistants, to understand?
The best code review is often less about finding bugs and more about protecting the long-term health of the application.
Refactoring Should Be Planned
One misconception about modern software development is that refactoring is something that happens “when time allows.”
In reality, refactoring should be planned work.
Every few sprints it is healthy to pause feature development and focus on improving the foundation.
Typical activities include:
consolidating duplicate services
simplifying APIs
improving database design
extracting reusable components
reorganising project structure
improving documentation
increasing automated test coverage
Ironically, AI makes this work significantly easier than it was just a few years ago.
Large-scale refactoring tasks that once carried considerable risk can now be completed much more confidently with AI assistance, provided they are reviewed by experienced engineers.
Rather than treating the codebase as something that simply grows larger, successful teams periodically reshape it to reflect the current direction of the product.
This continuous evolution keeps complexity under control and ensures the platform remains flexible enough to support future growth.
Why Waterfall Falls Short
Traditional waterfall development assumes that requirements can be fully defined up front before implementation begins.
Modern AI-assisted development exposes the limitations of this approach even more clearly.
When development becomes dramatically faster, the ability to respond to changing requirements becomes the competitive advantage.
Large upfront designs often become outdated before implementation is complete.
By contrast, an iterative approach allows teams to continuously refine both the product and the architecture as new information emerges.
Rather than following a linear path:
Design → Build → Test → Release
AI-supported development is better viewed as a continuous cycle:
Each cycle strengthens not only the functionality but also the quality of the platform itself.
AI Is a Multiplier, Not a Replacement
AI has become an exceptional engineering assistant.
It can generate code, identify bugs, explain unfamiliar frameworks, write documentation, produce tests and accelerate delivery at a pace that would have seemed impossible only a few years ago.
What it cannot replace is thoughtful software architecture.
It cannot independently decide the long-term direction of a product.
It cannot own engineering standards.
It cannot determine when simplicity is preferable to cleverness.
Those remain human responsibilities.
The most successful development teams are therefore not replacing software engineering with AI, they are combining AI with disciplined engineering practices.
Final Thoughts
The future of software development is not AI versus Agile.
It is AI powered by Agile.
Rapid iteration, clearly defined product requirements, continuous architectural review and regular refactoring are no longer optional engineering practices, they are essential disciplines for maintaining high-quality software in an era where code can be generated faster than ever before.
The lesson many teams are discovering is simple: the speed of development should never outpace the quality of the architecture.
AI allows us to build faster.
Agile ensures we build the right thing.
Regular reviews ensure we build it well.
Together, they create software that is not only delivered quickly but is also robust, maintainable and ready to evolve as the product grows.
The modern home is no longer just a collection of appliances, it’s a connected, intelligent ecosystem designed to save energy, reduce costs, and shrink your carbon footprint. With smart meters, LED lighting, and IoT platforms like Samsung SmartThings and Philips Hue, amongst others, homeowners can now fine-tune their energy use like never before.
But there’s a catch: What happens when the cloud service powering your smart home shuts down? Companies like Google, Philips, and even Samsung have discontinued or scaled back cloud support for older devices, leaving users with bricked hardware or forced upgrades. Neato smart vacuum cleaners is a prime example of this. The solution? Local control.
This post explores how LED lighting, smart heating, and IoT can make your home more sustainable, while keeping you in charge of your devices, no matter what the future holds.
1. The LED Revolution: Efficient, Long-Lasting, and Locally Controlled
Why LEDs Are a No-Brainer LED bulbs use up to 90% less energy than incandescent bulbs and last 25,000+ hours, that’s over 20 years of use at 3 hours a day. For a typical UK household, switching to LEDs could save £200+ annually on electricity bills.
But efficiency isn’t just about energy, it’s also about longevity and independence. Unlike some smart bulbs that require a cloud connection to function, many LED smart bulbs (like those from LIFX or Zigbee-compatible brands) can be controlled locally via a hub or home automation system.
💡 Pro Tip: Opt for Zigbee or Z-Wave bulbs (e.g., Philips Hue with a local bridge or for your best bet, Home Assistant) to ensure they work even if the cloud goes dark. But make sure it has matter support.
The Carbon and Cost Impact Replacing just one halogen bulb with an LED saves ~50 kg of CO₂ per year. If every UK household did this, the annual CO₂ reduction would equal taking 70,000 cars off the road.
2. Smart Homes: Efficiency Meets Independence
The Problem with Cloud Dependency Many smart home devices rely on cloud servers for functionality. But what happens when a company discontinues support? In 2024, Google Nest dropped support for the Works with Nest programme, leaving some users with non-functional integrations. Similarly, Philips Hue’s early bulbs lost features when the company shifted its cloud infrastructure.
The Solution: Local Control To future-proof your smart home, prioritise devices that: ✅ Work with local hubs (e.g., Home Assistant, Hubitat, or SmartThings with local processing). ✅ Use open protocols like Matter, Zigbee, Z-Wave, or Thread (instead of proprietary cloud-only systems). ✅ Support offline modes (e.g., Philips Hue with a bridge, LIFX LAN mode, or Shelly devices).
🏡 Build a Cloud-Resistant Smart Home:
Hubs: Home Assistant (open-source, local-first) or Hubitat (local processing).
Lighting: Zigbee bulbs (IKEA, Innr) + a local hub (e.g., Sonoff Zigbee 3.0).
Heating: Tado or Heatmiser (local API access) over cloud-dependent options.
Plugs/Switches: Shelly or TP-Link Tapo (LAN control).
Smart Meters: Local Data for Local Decisions Smart meters provide real-time energy data, but some models require cloud syncing to access full features. To retain control:
Choose smart meters with local APIs (e.g., Octopus Energy’s API for self-hosted dashboards).
Use Home Assistant’s energy dashboard to store and analyse data locally.
Smart Heating: Keep the Warmth, Ditch the Cloud Smart thermostats like Hive or Nest are great for efficiency, but Hive’s 2025 cloud outage left some users without heating controls for days. To avoid this:
Drayon Wiser (fully local control with cloud support).
Tado (supports local API via Home Assistant).
Heatmiser (fully local control).
OpenTherm gateways (for boiler integration without cloud).
You can even link these into weather stations so that your home can predict the outside temperature and adjust the house automatically. They also have TRVs so that individual rooms can call for temperature individually.
3. The Bigger Picture: Sustainability Meets Self-Reliance
Why Local Control Matters for Sustainability
Longevity: Devices last longer when they’re not tied to a company’s cloud lifespan.
Reduced E-Waste: No forced upgrades = fewer discarded gadgets.
Energy Savings: Local processing reduces latency and eliminates cloud server energy use.
The UK’s Push for Energy Independence With rising energy costs and net-zero targets, the UK government is incentivising self-sufficient homes. Local control aligns with this vision, your data, your rules.
Myth: “Local Control is Too Technical” While some setups require a bit of tinkering, user-friendly options exist:
Home Assistant (now offers easier installations via Home Assistant Green or Raspberry Pi kits).
Hubitat (plug-and-play local automation).
Pre-configured systems (e.g., Athom’s Homey Pro).
Myth: “I’ll Lose Features Without the Cloud” Most local-first platforms (Home Assistant, Hubitat) replicate or improve cloud features:
Automations (e.g., “Turn off lights when no motion is detected”).
Voice control (via Home Assistant’s local Alexa/Google integration).
Remote access (using Tailscale or Cloudflare Tunnel, no reliance on manufacturer clouds).
5. Your Future-Proof Smart Home Checklist
Action
Cloud Risk
Local Alternative
Switch to LED bulbs
Low
Zigbee/Z-Wave bulbs + local hub
Install a smart thermostat
High
Tado, Heatmiser, or OpenTherm
Use smart plugs
Medium
Shelly, TP-Link Tapo (LAN mode)
Set up a smart home hub
High
Home Assistant, Hubitat
Monitor energy usage
Medium
Local smart meter + Home Assistant
Sustainability Starts with Self-Reliance
The smart home revolution isn’t just about convenience or cost savings, it’s about taking control of your energy use and your devices. By prioritising local control, open protocols, and cloud-independent hardware, you can: ✅ Future-proof your home against discontinued services. ✅ Reduce e-waste by extending the life of your devices. ✅ Save energy and money without sacrificing functionality.
The future of smart homes isn’t just connected, it’s independent.
Call to Action: Build a Smart Home That Lasts
Ready to create a smart home that’s efficient, sustainable, and—most importantly—under your control? Here’s your step-by-step roadmap to a cloud-independent, future-proof setup:
📌 Step 1: Audit Your Current Setup
Before buying anything, assess what you already own:
List your devices: Are they cloud-dependent (e.g., Nest, Hive) or locally controllable (e.g., Zigbee, Z-Wave, or LAN-based)?
Check for obsolescence risks: Have any of your devices lost support in the past? (e.g., Philips Hue v1, Google Nest Works with Nest).
Identify gaps: Do you need lighting, heating, security, or energy monitoring?
🛠️ Step 2: Choose Your Local Hub
A local hub is the brain of your smart home, ensuring everything works even if the internet goes down. Here are your best options:
Hub
Best For
Ease of Use
Local Control
Cost
Home Assistant
Advanced users, full customisation
⭐⭐⭐ (Moderate)
✅ 100% Local
Free (DIY) or £100+ (pre-built)
Hubitat
Plug-and-play local automation
⭐⭐⭐⭐ (Easy)
✅ 100% Local
~£200
Athom Homey Pro
User-friendly, multi-protocol
⭐⭐⭐⭐ (Easy)
✅ 100% Local
~£300
SmartThings (Local)
Samsung ecosystem, partial local mode
⭐⭐⭐ (Moderate)
⚠️ Hybrid
~£100
🔄 Step 3: Swap Cloud-Dependent Devices for Local Alternatives
Replace cloud-reliant gadgets with locally controlled or open-protocol alternatives:
Category
Avoid (Cloud-Dependent)
Choose (Local-First)
Why?
Lighting
Philips Hue (cloud for some features)
Zigbee bulbs (IKEA, Innr) + Hub
Works offline, no subscriptions.
Heating
Hive, Nest (cloud-dependent)
Heatmiser Neo, Tado (local API)
No reliance on external servers.
Plugs/Switches
TP-Link Kasa (cloud-only)
Shelly, Sonoff Zigbee
LAN control, no cloud needed.
Security Cameras
Ring, Nest Cam (cloud storage)
Reolink, Eufy (local storage)
No monthly fees, full privacy.
Vacuum Cleaners
Ecovacs (cloud-heavy)
Roborock (local maps, LAN mode)
Offline mapping and control.
📋 Step 4: Design Your Automations
Now for the fun part, making your home work for you! Start with these essential automations (all run locally):
Lighting:
“Turn on hallway lights when motion is detected after sunset.”
“Gradually dim living room lights in the evening for a cosy mood.”
Heating:
“Lower the thermostat when no one is home (using presence sensors).”
“Increase the thermostat when someone one is approaching home (using geofencing).”
“Boost heating in the bathroom 30 mins before my morning alarm.”
Energy Savings:
“Turn off all non-essential plugs at night.”
“Notify me if energy usage spikes abnormally.”
🚀 Step 5: Test, Refine, and Expand
Test offline functionality: Unplug your router and ensure critical devices (lights, heating) still work.
Refine automations: Adjust triggers and conditions based on real-world use.
Expand gradually: Add one new device or automation at a time to avoid overwhelm.
🎯 Your Smart Home Journey Starts Now
Don’t let cloud dependency hold your home hostage. With the right hub, devices, and automations, you can build a sustainable, efficient, and future-proof smart home that works for you, not for Big Tech.
A few weeks ago, I shared how I built a RESTful API layer over Oracle’s OCNCC billing engine using decoded Escher protocol flows. The response from operators, MVNEs, and BSS/OSS teams was overwhelming—and it led to a simple but powerful question:
Could this API layer be exposed to AI agents?
The answer is yes, and the implications for Online Charging Systems (OCS) are far bigger than I initially anticipated.
The Problem: OCS Platforms Are Still Black Boxes
Most OCS platforms, whether Oracle OCNCC, Matrixx, or legacy IN stacks, remain hidden behind proprietary protocols (like Escher) and limited integration surfaces. Even basic operational queries often require:
Deep platform-specific knowledge.
Custom-built tooling or SDKs.
Manual intervention for troubleshooting or automation.
This creates a barrier to innovation. While modern telecom networks (especially 5G) demand agility, real-time intelligence, and automation, the charging layer often lags behind, locked in a specialist-driven model.
The Solution: MCP as a Bridge to AI-Native OCS
To solve this, I’ve been experimenting with Model Context Protocol (MCP), an open standard for exposing tools, data, and capabilities to AI agents in a structured, machine-readable way. Here’s how it works:
Architecture Overview
Integrating AI Agents Into A Real-time OCS
Key Design Principles:
Non-Invasive: The MCP layer sits in front of your existing API and Oracle query layers, leaving the underlying OCNCC stack untouched. No re-architecture required.
Tool-Centric: Instead of exposing raw endpoints, the system presents meaningful, self-descriptive tools that AI agents can reason about, not just execute.
Standardised: MCP provides a common language for AI to interact with OCS capabilities, regardless of the underlying platform (OCNCC, Matrixx, etc.).
What Does an AI-Native OCS Look Like?
By exposing OCS capabilities via MCP, AI agents gain the ability to:
Understand what operations are possible (e.g., subscriber lookups, balance adjustments, policy controls).
Reason about when and why to use them (e.g., “This subscriber’s session failed, check their balance and profile”).
Execute actions with structured, auditable precision.
Example Tools Exposed via MCP
Here’s a snapshot of the OCS capabilities currently exposed in the prototype:
Tool
Description
Underlying Action
lookup_subscriber
Retrieve subscriber details (balance, profile, status) by MSISDN or IMSI.
API call to OCNCC’s subscriber database.
query_network_topology
Fetch the current network topology (nodes, connections, status).
SQL query to OCNCC’s topology tables.
inspect_profile
Return a subscriber’s active profile blocks (e.g., barring, roaming restrictions).
Escher protocol message (decoded via API).
adjust_balance
Deduct or add balance for a subscriber (with validation).
OCNCC charging API call.
reset_bundle
Trigger a monthly/weekly bundle reset for a subscriber or group.
Batch API call to OCNCC.
check_service_eligibility
Verify if a subscriber is eligible for a service (e.g., 5G slicing, roaming).
Policy control API call.
correlate_alarms
Cross-reference active alarms with subscriber sessions or network events.
Joins OCNCC logs with alarm databases.
Why This Matters:
No More Silos: AI agents can query and act across charging, policy, and network layers without jumping between systems.
Natural Language Interfaces: Tasks like bundle resets or subscriber diagnostics, which previously required SDKs or APIs, can now be triggered via conversational queries (e.g., “Why did MSISDN 447123456789’s session fail?”).
Automation-Ready: Routine operations (e.g., balance adjustments, profile updates) can be automated via AI workflows.
Use Cases: How AI-Native OCS Changes Operations
1. Support Workflows: Diagnose Issues in Seconds
Before:
A support agent receives a complaint: “My data isn’t working.”
They manually check OCNCC logs, subscriber profiles, and network alarms, often requiring multiple tools and logins.
After (with MCP):
The agent (or a customer-facing chatbot) asks the AI:“Diagnose why MSISDN 447123456789 can’t access data.”
The AI:
Calls lookup_subscriber → Finds the subscriber has insufficient balance.
Calls inspect_profile → Confirms no barring is active.
Calls query_network_topology → Verifies the subscriber’s serving node is operational.
Conclusion: “Subscriber has £0 balance. Top up required.”
Result: Faster resolution, fewer escalations, and happier customers.
2. Network Operations: Correlate Alarms and Charging Events
Before:
A network alarm fires for a billing engine node.
NOC teams manually cross-reference alarms with subscriber sessions and charging logs to identify impact.
After (with MCP):
The AI automatically:
Calls correlate_alarms → Links the alarm to 1,200 failed charging sessions on that node.
Calls query_network_topology → Identifies the node is overloaded.
Action: Triggers a load-balancing adjustment or node restart (if automated).
Result: Proactive issue resolution before subscribers are impacted.
3. 5G Policy Control: Dynamic, AI-Driven Charging
Before:
5G Policy Control Function (PCF) makes static charging decisions (e.g., “Allow this slice if balance > £10”).
No real-time intelligence: Can’t adapt to network congestion, subscriber behaviour, or business priorities.
After (with MCP):
The PCF queries the AI:“Should I allow a new 5G slice for MSISDN 447123456789? They’re roaming in Spain with £5 balance.”
The AI:
Calls lookup_subscriber → Confirms £5 balance.
Calls check_service_eligibility → Checks roaming agreements for Spain.
Calls query_network_topology → Sees high congestion in Spain.
Decision: “Deny slice. Suggest downgrading to 4G to avoid overage charges.”
MVNOs rely on manual requests to the host operator for bundle resets, balance adjustments, or reporting.
After (with MCP):
MVNOs interact with the OCS via AI:“Reset monthly bundles for all subscribers on the ‘Premium’ plan.”
The AI:
Calls reset_bundle for all ‘Premium’ subscribers.
Logs the action for audit and billing reconciliation.
Result: Faster operations, reduced errors, and lower OPEX.
The Bigger Picture: Why This Matters for Telecom
1. Democratising OCS Access
Today: OCS platforms are specialist-driven. Only engineers with deep platform knowledge can extract insights or automate workflows.
Tomorrow: With MCP, anyone (support agents, NOC teams, even subscribers via chatbots) can query and act on charging data—without writing code.
2. Enabling AI-Driven Automation
Predictive Charging: AI can anticipate balance depletion and proactively notify subscribers or trigger auto-top-ups.
Anomaly Detection: AI can flag unusual patterns (e.g., fraud, misconfigurations) in real time.
Dynamic Pricing: AI can adjust pricing based on network demand, subscriber loyalty, or competitor offers.
3. Future-Proofing for 6G and Beyond
As networks evolve toward 6G, AI-native architectures will become the norm.
MCP provides a standardised way to expose any OCS or IN platform (OCNCC, Matrixx, legacy IN) to AI, without vendor lock-in.
What’s Next? The Roadmap for AI-Native OCS
This started as a personal R&D exercise, but the architectural pattern is universal. Any OCS or IN platform with a queryable data layer and a billing interface can be exposed via MCP. Here’s what’s left to do:
1. Expand the Tool Surface
Add more OCS capabilities as MCP tools (e.g., refunds, shared balance groups, QOS adjustments).
Support bulk operations (e.g., “Apply a discount to all subscribers in region X”).
2. Tighten Security Boundaries
Role-Based Access Control (RBAC): Restrict which AI agents can call which tools (e.g., a support chatbot can’t adjust balances).
Audit Logging: Track every AI-driven action for compliance and debugging.
Rate Limiting: Prevent abuse (e.g., an AI agent spamming lookup_subscriber).
3. Ensure Full Observability
Logging: Capture all MCP requests/responses (e.g., via Prometheus).
Tracing: Correlate AI actions with OCNCC logs and network events.
Alerting: Notify operators of failed AI-driven operations (e.g., “Balance adjustment failed for MSISDN 447123456789”).
4. Integrate with AI Orchestration Layers
Connect MCP to AI orchestration platforms (e.g., LangGraph, Microsoft Autogen) for multi-step workflows.
Example: “If a subscriber’s balance is low AND they’re roaming, send them a top-up reminder via SMS.”
The Future: From API-Enabled to AI-Native OCS
We’re at an inflection point. APIs made OCS platforms programmable. MCP makes them AI-native.
Phase 1 (Now): APIs expose OCS capabilities to developers.
Phase 2 (Emerging): MCP exposes them to AI agents.
Phase 3 (Future): Fully autonomous OCS, where AI manages charging in real time, optimising revenue, reducing churn, and enabling self-healing networks.
This isn’t just about efficiency. It’s about unlocking the full potential of your OCS platform, whether it’s Oracle OCNCC, Matrixx, or a legacy IN stack.
Let’s Collaborate
This is still early days, but the direction is clear: AI-native OCS is coming, and MCP is the key to getting there without replacing your existing infrastructure.
If you’re working with OCNCC, Matrixx, or similar platforms and exploring how AI fits into your operational model, I’d love to compare notes. Here are some questions to kick off the discussion:
Have you experimented with AI-driven telecom operations?
What OCS capabilities would you prioritise exposing to AI?
How do you see MCP (or similar protocols) fitting into your roadmap?
