Lian Lim | Dashboard & AI Automation Expert

Building 8-9 figure AI Operating Systems

[Lian Lim | Dashboard & AI Automation Expert @dashboardlim]

Claude built your SaaS login?

cool. now try breaking it with 2 browser windows.

this is one of the simplest tests i'd recommend to anyone vibe coding an app with real users

1. create user A and user B
2. log in as A and open a private record
3. copy the record URL
4. log in as B in another browser
5. paste A's URL

B should NOT be able to read or modify A's record

now repeat the test against the actual API endpoint

because hiding a button in the frontend is not authorization

and just because your app has login doesn't mean your users' data is isolated

this catches a class of bugs that a beautiful UI will never reveal

before you add another AI feature, make sure customer B can't see customer A.

[Lian Lim | Dashboard & AI Automation Expert @dashboardlim]

Claude Fable 5.2 just helped build a working operating system in 8 days.

with over 1,000 AI agents

that's a pretty insane demonstration

but before switching your entire Claude Code workflow to Fable, i'd run one test

give Fable and your current coding model the exact same bug

1. start from the same Git commit
2. give both the same task + instructions
3. use the same tools and time budget
4. let each investigate, fix and test
5. compare the final results

don't just measure which agent finished first

check:

→ did it actually fix the bug?
→ did it break anything else?
→ how many unrelated files changed?
→ how many times did you intervene?
→ what did the task cost?

a model that finishes in 3 minutes but introduces 2 regressions isn't necessarily better than one that takes 10

and a benchmark score won't tell you how well a model handles YOUR codebase

before paying for the smartest coding model, find out if it actually makes your engineering better.

[Lian Lim | Dashboard & AI Automation Expert @dashboardlim]

here's a 2-minute test for anyone who built a dashboard with AI.

put 101 records in your test database.

make sure the API returns 100 per page.

now open your dashboard.

what does the total say?

100 or 101?

i've seen how easy it is for dashboards to calculate totals from whatever the frontend happened to load.

the chart looks correct.

the API returns 200.

there's no error.

but the dashboard is missing page 2.

to check yours:

1. compare the dashboard total with a database COUNT
2. add a filter that matches records on multiple pages
3. check that charts include all matching records

the fix is often to calculate aggregates server-side instead of summing the currently loaded table rows.

pagination should change what you display.

not what the business thinks it has.

[Lian Lim | Dashboard & AI Automation Expert @dashboardlim]

if Claude wants to rename a database column

and the app is already live

please don't let it happen in one deploy

imagine changing:

customer_name → full_name

the new backend expects full_name

but your old backend workers are still running

your scheduled jobs still use customer_name

and users have requests in flight

suddenly a tiny schema change becomes an outage

the safer pattern is expand → migrate → contract

→ add the new column without removing the old one
→ make the application compatible with both
→ backfill existing data
→ move reads + writes to the new field
→ verify the old field is no longer being used
→ remove it in a later deployment

you need to plan for mixed application versions and concurrent writes during the transition

AI can generate the migration in seconds

it can't make your existing production traffic disappear while you deploy it

never see your database migration as just a code change

because it's more of an actual rollout.

[Lian Lim | Dashboard & AI Automation Expert @dashboardlim]

before Claude Code touches an unfamiliar repo, i want it to answer 5 questions

not tell me it understands everything

just this:

1. which file actually owns the behavior we're changing?
2. where does the data come from?
3. what else depends on this?
4. what's the smallest possible fix?
5. how will you prove it worked?

you can literally paste:

“investigate first. answer these 5 questions with file references. propose the smallest change. don't modify anything during this investigation.”

it's amazing how much bad code you avoid by making the agent understand the problem before it tries to solve it

the first useful output isn't always code

I feel sometimes it's a map of what shouldn't be touched

[Lian Lim | Dashboard & AI Automation Expert @dashboardlim]

here's something i'd make Claude Code do before fixing a bug that involves both frontend + backend

trace the entire request.

not just the file where the error appeared

paste this:

"Investigate this bug without changing code.

Trace the full path:

1. user action in the UI
2. frontend handler
3. API request + payload
4. backend route
5. database read/write
6. API response
7. UI state update

For every step, show the exact file + function.

Mark anything you couldn't verify as UNKNOWN.

Identify the earliest point where expected and actual behavior diverge.

Do not propose a fix until the trace is complete."

this forces the agent to distinguish code it actually inspected from code it assumes exists

especially useful when the frontend says one thing and the database says another

sometimes the fastest way to fix a bug is to stop the agent from fixing it for five minutes.

[Lian Lim | Dashboard & AI Automation Expert @dashboardlim]

we spent time building an automation

tested it

watched it run

then switched it off a few days later

not because it broke

it did exactly what we'd built it to do

the problem was what it replaced

a monthly reporting process that forced us to sit down, look at the numbers and actually think about what was happening

we'd automated the report

but we'd also removed the moment where we made decisions

so we killed the automation

there's something funny about running an AI automation company and realizing that sometimes the manual step is the valuable part

what's one task in your business you'd deliberately keep human?

[Lian Lim | Dashboard & AI Automation Expert @dashboardlim]

this is more interesting than another AI model getting smarter

Claude can now hand a plugin a long-running job and keep working

the plugin can also stop mid-task and ask a human for something it needs

sounds small until you've built a real automation

exports take time
APIs fail
humans disappear halfway through approvals

quite sure the problem isn't just making agents autonomous

it's deciding what happens when a task is halfway done and nobody answers

for everyone building MCP tools...

do you make the task wait, fail, or continue with a fallback?

[Lian Lim | Dashboard & AI Automation Expert @dashboardlim]

we built 255 rules so our AI could ignore 5,536 emails.

yes, ignore them.

one of our clients had 7 mailboxes full of newsletters, notifications, customer enquiries and random noise

the obvious solution was to let AI read everything and decide what mattered

we did the opposite

we put a boring filter in front of the model

blocklists
allowlists
pattern matching
rules the client could edit themselves

over one 30-day period:

→ 5,536 messages filtered before AI
→ 2,256 processed downstream
→ 1,052 replies drafted

and every filtered message still had a recorded reason

the funny part is that we spent so much time building an intelligent inbox...

only to discover that one of its best features was knowing when not to use intelligence at all

sometimes the best AI optimization is a simple rule.

[Lian Lim | Dashboard & AI Automation Expert @dashboardlim]

just last week, GitHub gave Copilot Automations a way to learn from humans correcting its work

this is actually pretty interesting

imagine an AI that triages GitHub issues

it labels 100 issues

your team keeps changing the labels

instead of repeating the same mistakes forever, the automation can use those corrections to propose a better prompt

same idea for code reviews

developers keep ignoring its suggestions?

that's feedback too

the proposed changes still need human approval

but we're getting closer to AI workflows that improve from actual outcomes instead of someone constantly rewriting the instructions

there's one thing i'm curious about though

would you trust an agent to suggest changes to its own instructions?

or would you rather keep those rules completely human-written?

[Lian Lim | Dashboard & AI Automation Expert @dashboardlim]

@RohanBhanotAI oh well 😤

[Lian Lim | Dashboard & AI Automation Expert @dashboardlim]

this is why i don't trust a permission rule until i've tested the denial path

Cursor just fixed a bug where a Claude Code hook could say:

deny this tool call

and the local agent could still run it

that's such a perfect agent engineering lesson

config says “denied” system proved “denied”

when we connect agents to real systems, the tests that matter are boring:

allowed action actually works

denied action actually fails

secret stays unreadable

production action actually stops

audit log actually records it

guardrails aren't the JSON you wrote

see it as the behavior you can prove

[Lian Lim | Dashboard & AI Automation Expert @dashboardlim]

@shlokbuilds you'd think so. but most teams test what the agent can do, not what it must never be able to do.

[Lian Lim | Dashboard & AI Automation Expert @dashboardlim]

@VZ4EE lol a permission system where the agent gets the final vote.

[Lian Lim | Dashboard & AI Automation Expert @dashboardlim]

i think we're entering a weird phase of software

building things is getting ridiculously fast

trusting what got built isn't

an agent can:

write the migration
change the API
update the frontend
rewrite the tests
open the PR

before a human has properly understood the first decision it made

so the valuable engineering skills are shifting

less:

“can you type this implementation?”

more:

“do you understand the system?”
“what assumption is this making?”
“what could this break?”
“what evidence proves it works?”
“what should the agent NOT touch?”

AI is making execution abundant

judgment is becoming the scarce part

we need to do better

[Lian Lim | Dashboard & AI Automation Expert @dashboardlim]

one phrase causes more bugs in business software than people realize:

“the customer status”

okay

which one?

CRM says active

billing says cancelled

database says trial

automation has them in onboarding

spreadsheet says something completely different

this is where AI makes bad architecture look even worse

because the agent will happily find all 5 answers

the hard part isn't giving AI access to more company data

it's deciding which system is allowed to be right

before we connect an agent now, one of the first questions should be:

what is the source of truth for this decision?

[Lian Lim | Dashboard & AI Automation Expert @dashboardlim]

one of the best uses i've found for coding agents has nothing to do with building features

it's finding what we can delete

dead helpers
old flags
stale experiments
duplicate logic
unused dependencies
code supporting something that stopped existing 8 months ago

we humans are very good at adding “temporary” things

much worse at coming back for them

AI changes the economics of maintenance because you can finally ask:

“trace this properly and prove whether we still need it”

instead of:

“nobody touch that file, we don’t know what depends on it”

everyone talks about how much more code agents can produce

i'm increasingly interested in how much code they can safely make disappear

[Lian Lim | Dashboard & AI Automation Expert @dashboardlim]

coding agents are slowly getting access to more than the repo

machines
environments
deployments
other agents

and i think this is where agent UX gets interesting

the best permission system probably isn’t:

“allow everything”

or

“approve every tool call”

it’s teaching the system where the boundaries are once

repo A: yes
production: ask
secrets: never
new environment: ask
tests: yes
merge: human

the better agents get

the more important boring permission design becomes

[Lian Lim | Dashboard & AI Automation Expert @dashboardlim]

we changed one small thing in our cost monitoring that made the alerts 10x more useful

before:

“cost spike detected”

cool.

which client?
which account?
which service?
which key?
is it expected?

an alert that creates 5 more questions isn’t really an alert

so now the notification carries the context required to act:

→ account
→ client
→ source
→ amount
→ time window

monitoring shouldn’t tell you something happened

it should get you as close as possible to knowing what to do next

[Lian Lim | Dashboard & AI Automation Expert @dashboardlim]

@xpanncai that's the problem. we’ve made connecting agents to infrastructure easier than defining what they’re actually allowed to do with it.

[Lian Lim | Dashboard & AI Automation Expert @dashboardlim]

connecting an MCP server is the easy part

the question that takes us way longer is:

what should the agent actually be allowed to do once it’s connected?

we've been wiring AI into things like:

AWS
databases
automation workflows
internal tools

and “connection successful” is basically step 1

after that you need to decide:

→ read or write?
→ which resources?
→ which environments?
→ can it delete?
→ can it deploy?
→ can it see secrets?
→ which actions still need a human?

MCP makes giving an agent tools incredibly easy

which also makes giving it too much incredibly easy

the interesting part of MCP isn’t connectivity anymore

i think it’s permission design