A person sitting at a desk with multiple code-filled monitors, head in hands, looking toward a bright forest path glowing through a window.

AI fatigue is real

In my previous startup, I jumped on the AI coding train and fully immersed myself in running agents instead of writing code. πŸ€– At first it felt incredible. I was 10x more productive, doing in a fraction of the time all the things I’d wanted to do. Hard changes became easy, and I was producing more code in days than I used to produce in months. πŸš€

But at some point, I broke. I’d sometimes spend one or two days just lying in bed, mentally exhausted, needing to do anything except work. I’d take days off mid-week because I simply couldn’t keep going. This went on for weeks, until I needed an entire week to recover. Eventually I couldn’t even look at the code anymore - I’d start my computer, open my IDE, look at the tasks in front of me, and still couldn’t get my brain to focus. I needed a longer break, 4 to 6 weeks, before I was ready to work again.

AI fatigue is real. More people are starting to talk about it. 🧠

What I took away from it:

  • I can spend about 3 to 4 hours a day prompting agents. The rest of the day is needed for recovery and for my brain to catch up.
  • I have to force myself not to work in between. My brain keeps processing everything anyway, so that time isn’t wasted.
  • Taking care of myself matters more now than ever: regular exercise, walks in the park, healthy food, limiting caffeine β˜•, finding ways to relax, and spending time with people - real conversations, with people who are physically there.
  • I can push past these limits for a while, but there’s no free lunch. Doing more today eventually means doing less tomorrow, or worse.

Have you experienced AI fatigue yet? πŸ‘‡


Originally posted on LinkedIn.

Four panels showing an evolution from a terminal window, to a file browser, to a web page, to a glowing AI robot connected to chat, database, analytics, and integration icons.

GUI is dead, long live agents

GUI is dead. Long live agents. πŸ€–

Computer interfaces keep evolving: command line β†’ thick clients β†’ the web β†’ and now, agents. Most people move through the same stages with agentic engineering:

Level 1: “I’m getting so much more done.” ⚑ AI speeds up how you write code.

Level 2: “I can build all these features myself, ship to every platform.” πŸš€ AI removes the limits on what you can scope and build.

Level 3: “Why build a UI at all? I can expose the data via MCP and let users’ own agents pull data, generate reports, take action directly.” πŸ”Œ The interface itself becomes optional.

The front end is dissolving into the protocol layer. The product isn’t the screen anymore, it’s the API your users’ agents can talk to. πŸ‘€


Originally posted on LinkedIn.

A crumbling wall labelled legacy code, outdated stack, and slow delivery on one side, with a small robot carrying a code icon flying through into a bright modern laptop dashboard on the other side.

AI can rewrite your legacy app in hours

The application needs to be rewritten. Better tech, better architecture, better code. Management says no. πŸ™…

The reason is always the same: big-bang migrations rarely work, and engineers spend weeks or months with nothing visible to show the business. So you don’t rewrite it, you improve it step by step. That’s been best practice for decades.

Until AI agents showed up. πŸ€–

Now an agent can review tens of thousands of lines in seconds, absorb the docs for any technology, and rewrite an app in hours instead of months. Zero risk, 100% gain. Not everyone has realised this yet.

  • Your project would benefit from an iOS app you’ve never had time to build? πŸ’₯ Done.
  • Your backend is PHP 8 or Java 7, and a consultancy quoted $200k to move it to TypeScript? πŸ’₯ Done.
  • Your app is still jQuery and static HTML? Pick your stack. πŸ’₯ Done.

It’s time to modernise your tech stack and reap the benefits. πŸš€


Originally posted on LinkedIn.

A person at a desk holding their head, with a cloud of thoughts above showing security warnings, a glowing brain, a legal scale, a dollar sign, and a document.

The unexpected side effect of LLMs: the burden of knowledge

AI is supposed to make us more productive. But is it, really? πŸ€”

Once you know something, there’s no going back. The burden it puts on you has to be handled, and that’s energy on its own. Sometimes blissful ignorance helps you in ways you don’t realize.

Two examples:

1️⃣ I asked my coding agent to review the security of my app. I just wanted to make sure there was no easy way to get hacked, maybe even automatically by a bot. Now all I can think about are the 10 security holes it found. Four are “low severity,” sure, but now I know. And if we get hacked, I can’t tell my business partner I had no idea. A harmless question created a dilemma I can’t escape.

2️⃣ I asked ChatGPT a legal question out of pure curiosity. That night I couldn’t sleep, convinced I was going to get sued. I ended up paying a lawyer to review my case and tell me, out loud, that there was nothing to worry about. I normally love that it’s thorough and precise - this time it cost me money, time, and a lot of energy solving a problem I’d created for myself. πŸ˜…

Just because AI can hand you all the knowledge in the world in seconds doesn’t mean you should burden yourself with unlimited information. βš–οΈ

Where do you draw the line? πŸ‘‡


Originally posted on LinkedIn.

I vibe-coded a Sudoku app and learned that product taste doesn't come free

AI writes code now, so technically almost anything can be built quickly and efficiently. Engineers will all be laid off soon πŸ˜„

So I tried vibe coding a little Sudoku app myself. How hard can it be? A 9x9 grid and 3 rules, sounds easy, right? And honestly, I was right about the vibe coding part - I shipped a fully functioning app without ever looking at the code. πŸ‘€

What surprised me was all the tiny details and hard decisions that showed up along the way:

  • Scoring system: it has to feel fair, reward both speed and precision, scale well, and still stay motivating. 🎯
  • Visual helpers: finding the balance between helping the player and solving the puzzle for them. Too few and the app feels clunky, too many and you remove the joy of solving it. 🧩
  • Difficulty levels: there are 10+ Sudoku solving techniques. Difficulty isn’t just how many numbers are missing, it’s how the puzzle has to be solved. One step too hard and the puzzle feels impossible; too easy everywhere and it gets repetitive. 🧠
  • Winning conditions, error highlighting, hints, drafts, undo, save and resume, statistics, settings, animations, etc.

Then I showed it to five people and immediately got ten pieces of feedback, many of them directly contradicting each other. πŸ˜‚

At that point it became obvious: AI can write all the code, but it still can’t magically create a great product. Anyway, the app finally made it to the App Store, so I can cross this one off my bucket list. βœ…


Originally posted on LinkedIn.

Diagram titled 'Safe. Powerful. Direct.' showing an AI agent routed through guardrails (dedicated role, read-only transactions, connection pool, query timeouts) into a read-only schema and read replica, separate from the primary production database.

Seven strategies for safe AI agent database access

Should your AI agent have direct access to the production database? Unrestricted access is dangerous. Locking it down so hard the agent can’t do anything useful defeats the purpose. The answer is architectural guardrails, not a binary yes or no.

Seven strategies that work:

  1. Dedicated database user or role with read-only permissions on selected tables only.
  2. Read-only transactions - native in Postgres, and a cheap safety net.
  3. Separate connection pools, so agent traffic can never starve or block application traffic.
  4. Query timeouts, so a bad query from an agent can’t take down performance for everyone else.
  5. Staging tables for writes - the agent writes there, a review step promotes changes to production.
  6. A dedicated read-only schema, scoped down to exactly what the agent needs to see.
  7. Read replica access instead of the primary, so exploration never touches the system of record.

Most teams are treating AI agents like untrusted interns. The teams getting the best results are treating them like highly capable analysts, operating inside carefully designed guardrails.

The goal isn’t maximum restriction, it’s the right restriction. πŸ”’


Originally posted on LinkedIn.

Being a software engineer is weird when it comes to family

Being a software engineer is weird when it comes to family. Many of us feel misunderstood, and honestly, it makes sense - what we do is rarely easy to grasp for a general audience.

Have you had this at a family dinner? Everyone talks about their life, your turn comes, someone asks what you’ve been working on. You explain, short or long. The reaction is always the same: dead silence, then that subtle shift to change the topic. “Let’s open presents!” 🎁

Then I ask my agent to “write me a Sudoku app,” show it around the table, and people lose their minds. 🀯 “Oh wow, you can do that?” I have never received this much attention, compliments, and validation for my skills as I did after three days of vibe coding a Sudoku app.

For comparison:

  • My team and I spent years automating the invoicing of Β£50 million in promotional income from 20 million sales events a week. β†’ silence
  • My team and I built a system handling tax reporting for 60 million people. β†’ silence
  • Here’s a Sudoku app I asked my agent to write. β†’ admiration, excitement, basically a star on the Hollywood Walk of Fame ⭐

If you want to take advantage of this moment too, the window might not stay open long. Agents are getting more powerful, and more expensive, fast. ⏳


Originally posted on LinkedIn.

Pressure reveals patterns

This is a lesson I recently learned in business: pressure doesn’t create character, it reveals it.

Under stress, people tend to fall into one of two patterns:

  • They communicate openly, reach out to others, and invite collaboration in solving the problem.
  • They get defensive, deflect blame, or quietly shift responsibility elsewhere.

The same split shows up in how people handle failure. Some take ownership and focus on what to improve next. Others externalise it, and the story becomes about anything except their part in it.

These aren’t fixed personality types, more like defaults people fall back on when things get hard. But the patterns are consistent enough that pressure becomes a genuinely fast way to learn who you’re working with.

Worth being intentional about it: work with people who communicate, take ownership, and treat others with respect, especially when things aren’t going well. That last part matters most exactly when it’s hardest to do.


Originally posted on LinkedIn.

A pendulum swinging back from 'AI writes the code' toward 'Humans write the code', under the headline 'The AI honeymoon is over - the pendulum is swinging back'.

The AI honeymoon is over

The real cost of AI writing code is starting to show πŸ‘€

For the past 6 months, we’ve been coding like there’s no tomorrow: endless tokens, multiple agents running in parallel, shipping features in stacks and technologies we barely touched before πŸš€

But the golden phase is fading. The signs are already here:

  • Anthropic dropped their $20 subscription
  • Token usage is getting tighter
  • Companies are reporting hundreds of thousands to millions in monthly AI spend πŸ’Έ

The pendulum might be swinging back. Smaller companies are starting to hire juniors again to write code. Larger companies are seeing senior engineers spend most of their time reviewing AI-generated output instead of building.

We’re not at equilibrium yet. That balance between humans and AI is still ahead of us βš–οΈ


Originally posted on LinkedIn.

How can an LLM write code?

How can an LLM write code? πŸ€” How can it come up with ideas? πŸ’‘ How can it summarize long documents? πŸ“„

It can feel like AI is “thinking”. But what is actually happening is closer to pattern recognition.

An LLM is like someone who has read millions of crime stories. When you start telling a new one, they can quickly guess what usually happens next. Not because they know the truth, but because they have seen similar patterns many times. πŸ•΅οΈβ€β™‚οΈ

The same idea applies to everything else:

πŸ’» Writing code - It has seen millions of code examples and learns common patterns

πŸ’‘ Coming up with ideas - It has seen brainstorming sessions, strategy docs, and idea lists

πŸ“„ Summarizing text - It has seen many examples of long texts paired with shorter summaries

So instead of thinking from scratch, an LLM predicts what a good next response usually looks like, based on patterns learned from a huge amount of text.

In a way, LLMs are extremely powerful pattern recognition engines that learned from human knowledge at scale. 🌍


What analogy do you use to explain AI to non technical people?


Originally posted on LinkedIn.