Real Code Ltd - Using AI to enhance your businesses

Finance deploys one AI agent. Manufacturing picks a different one. Engineering builds their own. Suddenly you've got three islands of AI, each optimised locally, none talking to each other. I call this fractured AI, and it's costing organisations more than the original pilots combined. Why? Because you're building governance three times, running three separate security reviews, training teams on three different interfaces, and losing visibility across the business. The decision to deploy AI used to be about the technology. In 2026, it's about the architecture. You need shared governance, shared standards, and shared ownership across departments. That sounds bureaucratic. It's not. It's the difference between an agent that pays back in 5 months and one that becomes technical debt. I've built on everything from SQL Server to Supabase to .NET. The pattern is always the same: centralised architecture wins at scale. Distributed experimentation loses, expensively. The teams treating AI as an enterprise platform, not a set of isolated tools, are the ones actually operationalising it. Are you orchestrating AI across departments, or letting each team run their own show?

I just watched a client spend 18 months on an AI agent pilot. Prototype worked beautifully. Moved to production and... nothing. Sat idle for six months. Turns out 88% of agent pilots never make it to production. That's not a tech problem. That's a governance problem. Here's what separates the 12% that actually ship: 1. They name an agent owner with real budget authority and measurable targets. Not a committee. One person accountable. 2. They run automated evaluations on every change before deployment. Not after. The moment you deploy an agent that outputs non, deterministic results, you've already lost. 3. They measure evaluation gaps upfront. 64% of pilot failures come from teams unable to tell when the agent is about to fail. You can't govern what you can't see. Most organisations treat agents like software features. Deploy, monitor, iterate. But agents are systems. They need operational infrastructure, not just infrastructure code. I've seen this pattern repeatedly with legacy system migrations. Teams build the thing, nobody owns the outcome, and it quietly rots in production. What's your production agent status? Actually running, or still in the "it works in testing" phase? https://lnkd.in/e3Ty6x6h

A junior dev asked me yesterday why we care so much about documentation in database design. "The code is self documenting, " he said. Then I showed him a migration that failed silently because nobody knew what a status_code column actually meant. Someone added value 4 to what was supposed to be a 1 to 3 range. The billing report broke. Nobody caught it until customers complained. Database documentation isn't bureaucracy. It's the difference between understanding your schema in six months and spending two days reverse engineering it. I've been through full rebuilds that cost six figures because teams skipped schema planning and documentation. It sounds expensive when you're moving fast. It's catastrophic when you're not. Three things that actually matter: comment your columns with intent, write tests for migrations, keep your ER diagrams current. Light documentation makes massive difference when onboarding someone or debugging at 2am. What documentation do you actually maintain on your database? Or are you relying on tribal knowledge?

I spent this morning digging through a client's schema and found they're storing structured data in JSON columns across half their tables. Then wondering why queries are slow. JSON's useful when you genuinely don't know your data shape upfront. But excessive JSON storage weakens relational database strengths, reduces indexing efficiency, and complicates queries. You end up paying for that flexibility on every single read. I see this constantly with teams chasing flexibility. They think schema rigidity is the enemy. Usually it's the opposite. A proper relational structure with clear constraints catches bugs at write time instead of letting bad data corrupt your system months later. Here's the pragmatic approach: if you're storing structured data that you query regularly, it should live in proper tables with relationships. If you're storing truly unknown data shapes, JSON has a place. But not both at once. What's your JSON usage looking like? Are you solving a real problem or just avoiding schema design? https://lnkd.in/ekVkwPYh

Just read through a massive chatbot guide and kept thinking: most businesses are picking the wrong platform before they even know what problem they're trying to solve. The article breaks down free tiers, open source options, managed platforms, the whole lot. Fair enough. But here's what jumped out at me after 15+ years building solutions for SMBs. Everyone wants the "best" chatbot. What they actually need is the cheapest one that doesn't embarrass them in six months. I've watched clients spin up a fancy AI customer support bot on Dialogflow because it looked clever. Six months later, it's hallucinating answers, customers are furious, and they're manually handling 80% of queries anyway. The ROI? Negative. Meanwhile, a mate of mine built a hybrid approach for his ecommerce business. Rule based flows for the obvious stuff (order status, returns, FAQs), human handoff for anything remotely complex. Cost him about £200 a month. CSAT went up 34%. No magic. Just boring, predictable logic. The guide mentions this balance between automation and control, which is spot on. But most people skip that chapter because it doesn't sound as exciting as "LLM powered conversational AI." If you're evaluating a chatbot platform right now, start with this question: what's the one thing your customers ask that actually costs you money to answer manually? Build for that. Everything else is nice to have. What's your chatbot actually doing? Is it saving you time or just making you feel like you're keeping up with the trend? https://lnkd.in/e9VdQNJi Messenger Bot

Over 90% of enterprises will face critical skills shortages by 2026. That's not a statistic. That's a business emergency happening right now. I've watched this play out in real time with my clients. They've got the budget for new tech stacks, new tools, new infrastructure. What they haven't got is people who can actually use any of it. Here's what I'm seeing repeatedly: companies treat the skills gap like a hiring problem. "We need senior developers." "We need AI specialists." So they post a job, wait three months, then panic when nobody applies. That's backwards. The real problem isn't that the talent doesn't exist. It's that organisations have stopped investing in the people they've already got. A solid mid, level developer with proper mentorship and actual time to learn becomes your AI specialist in six months. A junior who gets paired with someone who actually cares becomes your next technical lead. But that requires something most companies have forgotten how to do: patience. Consistency. Showing people that their growth actually matters to the business. I've built teams that way. It works. It's cheaper than panic hiring. It's more reliable than hoping you'll find a unicorn developer who magically knows everything. The companies winning in 2026 aren't the ones with the flashiest tech. They're the ones who decided that their people were worth investing in before the skills crisis forced their hand. Is your organisation actually developing capability, or just buying it?

Query latency spikes without warning. Simple schema changes suddenly trigger cascading failures. Nobody thinks they have a database problem until they do. Most early, stage teams I work with assume scale is the culprit. It never is. The real issue is usually a design decision made in month two that felt pragmatic at the time but constrained everything that came after. I've watched startups spend months rewriting systems because they skipped foreign keys early on. Or because they let the application layer handle all the business logic while the database became a dumb persistence layer. Or because they normalised everything to death without understanding their actual access patterns. The pattern repeats: these aren't obvious mistakes. They pass code review. They ship. Six quarters later, you're paying the bill. Where's your database pain point right now? DM me, I've been through this enough times to know where to look first.

I read an article today about what humans do better than AI, and it's missing the actual problem. Everyone's arguing about whether AI can think critically or be creative. Fair points. But the real issue I see with clients isn't what AI can't do. It's that we're treating it like a replacement instead of a tool that needs a driver. I worked with a fintech company last year who threw an AI reporting system at their team and expected magic. The system processed data faster than anything they'd ever built. But faster data with no direction is just... faster noise. What changed everything: one person whose job was literally to ask "why are we looking at this metric" and "what should we actually do about it." Suddenly the AI output went from impressive to useful. The article mentions a 46% reduction in manual processing for one SaaS company. Notice it didn't say 100%. That's not a failure. That's the actual design. Humans asking questions. AI answering them. Humans deciding what matters. The skill gap isn't about developers learning to code with copilot. It's about understanding that every AI tool in your business needs someone who can think without a blueprint. Someone who can say "this looks right on paper but it's wrong for what we actually need." That's the job now. Not building the AI. Knowing how to use it like you actually understand the business. https://lnkd.in/eY5XvHDX Growth Hackers

Discover Tech Energy Usage, a privacy-first, open-source desktop widget that tracks your computer's energy consumption and AI carbon footprint in real-time.

I watched a team spend three hours debugging a 'slow query' last week. Turned out the real problem wasn't the code at all. They were running a full table scan on a 50 million row table because nobody had ever looked at the execution plan. This is how I see it play out repeatedly: a junior dev writes a query that works. It's fine on test data. Then production gets hit and suddenly it's taking 40 seconds instead of 2. Everyone panics. Everyone points fingers. The truth is simpler. Most teams never check their execution plans until something breaks. And by then you're firefighting instead of designing. Here's what actually works: 1. Logical reads tell you everything. If your query is doing 10, 000 page reads when it should do 50, you've got an indexing problem. Full stop. 2. Missing indexes are invisible until you look. You can't tune what you can't see. 3. One poorly optimised query at scale will bring a whole application down. I've seen it tank a £2M system. I'm not saying you need to obsess over every query. But if you're running production databases and you're not regularly checking execution plans, you're just waiting for something expensive to break. How often does your team actually review execution plans? Or is it something you only touch when there's a crisis? Drop me a DM if you're dealing with performance issues now. I've been there enough times to recognise the pattern.