DEV Community: Ahmad Khokhar

AI Doesn't Write Buggy Code — Your Workflow Does

Ahmad Khokhar — Mon, 08 Jun 2026 16:22:43 +0000

There's a complaint I see constantly from developers:

"AI wrote the code but I spent hours debugging it."

I've been using AI heavily in my own projects. And honestly — I don't relate to this experience. Not because the AI I use is magical, but because I've noticed the bugs almost always trace back to one of two things. Neither of them is the AI.

Problem 1 — The Implementation Plan

When I give an AI agent a vague instruction, I get vague code back. That's not a bug. That's math.

If I say:

"Build me an authentication system"

I'm going to get generic code that makes assumptions about my database structure, my session handling, my token strategy, and my error responses. Some of those assumptions will be wrong. I'll spend an hour figuring out which ones.

If I say:

"Build a token-based auth system using Laravel Sanctum. Users table already exists with these columns. Tokens stored in personal_access_tokens. Login returns a Bearer token. Failed login returns 401 with this JSON structure. No session-based auth needed."

The output is precise. The edge cases are handled. There's almost nothing to debug.

The AI didn't get smarter. I gave it a better plan.

This is the part most developers skip. They open a chat, type a rough idea, and then blame the tool when the output doesn't match the thing they had in their head but never wrote down.

An AI agent is not a mind reader. It's a very fast executor of whatever context you give it. The quality of the output is almost entirely a function of the quality of the input.

Problem 2 — Session Length

This one is less talked about but equally important.

AI models have a context window. As a conversation gets longer, earlier parts of it get compressed or effectively lost. The model starts making decisions without full access to what was established at the start of the session.

In practice this looks like:

A function that contradicts a constraint you defined 40 messages ago
A variable name that doesn't match the naming convention from earlier in the project
Logic that reimplements something already handled elsewhere in the codebase

The code isn't wrong because the AI is bad. It's wrong because you asked it to hold more context than it reliably can.

The fix is simple: start a new session when the context gets heavy.

Before a new session, summarize what's been built, what conventions are in use, what's already handled, and what the next task is. Paste that as the first message. You're not losing work — you're giving the AI a clean working memory instead of a cluttered one.

Developers who don't do this and then hit inconsistencies blame the AI. Developers who manage their sessions rarely hit those inconsistencies.

Where AI Actually Deserves the Blame

I want to be honest here — there are cases where the AI genuinely introduces bugs regardless of how good your plan is.

Complex interdependent business logic is one. If you have five systems that affect each other in non-obvious ways, AI will occasionally make a confident assumption that's subtly wrong. It won't tell you it's guessing. It'll just be wrong.

Large existing codebases are another. Asking an AI to extend code it hasn't seen in full leads to inconsistencies. It's working with a partial picture.

These cases exist. They're real. But in my experience they're maybe 10-20% of the debugging complaints I see developers make. The other 80% is a planning problem or a session management problem — both of which are entirely within the developer's control.

"But Real Development IS Complex Tasks"

Fair pushback — and I've heard it.

The argument is: simple tasks are easy to plan, but real-world development involves complex interdependent systems. That's where AI falls apart, and no amount of planning fixes that.

I partially agree. But the response is not "therefore AI can't handle complex work." The response is: complex tasks are just multiple small well-defined tasks stacked together.

The mistake is treating complexity as one big instruction:

"Build me a multi-tenant payroll engine with attendance, leave, deductions, and statutory compliance"

That's not a task. That's a project. Throwing that at an AI in one session and expecting clean output is not a workflow problem — it's an expectation problem.

Break it down:

Session 1 — Tenant database switching on auth
Session 2 — Employee model and relationships
Session 3 — Attendance calculation logic
Session 4 — Payroll computation engine
Session 5 — Statutory deductions

Each session gets a fresh context. Each task is specific. The AI's output per session is clean because the scope is clear.

The complexity doesn't disappear — you're managing it. That's the actual skill. Decomposing a complex system into well-scoped pieces and feeding them to an AI with proper context is harder than typing one big prompt. It's also the reason some developers get great results and others don't.

Complex tasks don't break the argument. They prove it.

What I Actually Do

Before any non-trivial task I write out:

What already exists and what it does
What I'm building and why
The data structures involved
Edge cases I already know about
What the output should look like

Then I start a fresh session with that as context.

When a session gets long — past maybe 20-30 exchanges on a complex task — I start a new one with a summary.

This workflow basically eliminated the "AI wrote broken code" problem for me. Not because I'm using it better than everyone else — just because I stopped treating it like a shortcut and started treating it like a junior developer who needs a proper brief.

A junior developer given a vague task will produce vague work. The same junior developer given a clear spec, existing context, and defined constraints will produce something usable.

The AI is the junior developer. The brief is your job.

I write about practical decisions behind real projects. Follow if that's useful.

What We Learned Building a Multi-Tenant Payroll Engine in Laravel

Ahmad Khokhar — Sat, 06 Jun 2026 16:21:58 +0000

Payroll software looks simple from the outside. You multiply hours by rate, subtract taxes, and send a number to a bank. That's it.

Then you actually build one.

We've been building an HR and payroll platform for a while now — 14 integrated modules, multi-tenant, modular, built entirely on Laravel. These are the decisions that turned out to be harder than expected, and what we'd do differently.

The Multi-Tenancy Decision

The first real decision was how to handle multi-tenancy. There are three common approaches in Laravel:

Separate databases per tenant — cleanest isolation, more overhead to manage
Separate schemas (PostgreSQL) — good middle ground
Shared database with tenant ID column — most common, most dangerous if you get it wrong

We started with option 3. Global query scopes, tenant_id on every table, seemed manageable. Then we hit exactly the problem everyone warns you about.

A missing scope bypass in one admin operation returned records across tenants. In a todo app that's embarrassing. In payroll software — where the data is salary figures and bank account numbers — that's a hard stop.

We moved to separate databases per tenant. Each tenant gets their own database. The connection is resolved at authentication — not on every request. Once a user logs in, their tenant's database name is stored in the session, and every subsequent request in that session uses it:

class AuthenticatedSessionController extends Controller
{
    public function store(LoginRequest $request): RedirectResponse
    {
        $request->authenticate();

        $user   = $request->user();
        $tenant = $user->tenant;

        // Store in session at login — resolved once, not per request
        session(['tenant_db' => $tenant->database_name]);

        config(['database.connections.tenant.database' => $tenant->database_name]);
        DB::purge('tenant');

        $request->session()->regenerate();

        return redirect()->intended(RouteServiceProvider::HOME);
    }
}

No per-request resolution overhead. The connection is set when the session is established and stays for its lifetime.

Cross-tenant leakage is now architecturally impossible — not a discipline problem, a structural one. The tradeoff is real: migrations run per tenant, not once. We handled that with a queued migration runner using Artisan::call() across all tenant databases.

The overhead was worth it. When you're handling payroll data, isolation has to be guaranteed, not assumed.

Modular Architecture — The Part We Got Right

HR software has modules nobody uses. If a 30-person team enables the recruitment pipeline, performance review engine, and training catalog from day one, they're paying for complexity they don't need.

We made each module a Laravel service provider that registers its own routes, policies, and bindings:

class PayrollServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        if (!Module::isEnabled('payroll')) {
            return; // Routes, policies, and resources never load
        }

        $this->app->bind(PayrollEngine::class, StandardPayrollEngine::class);
    }

    public function boot(): void
    {
        if (!Module::isEnabled('payroll')) {
            return;
        }

        $this->loadRoutesFrom(__DIR__.'/../routes/payroll.php');
        $this->loadPoliciesFrom(__DIR__.'/../policies');
    }
}

When a module is disabled, its routes don't exist. Its policies never register. Its queries never run. There's no conditional logic scattered through controllers — the module simply isn't there.

This also made testing significantly cleaner. Each module's test suite runs in isolation with only its dependencies loaded.

The Payroll Computation Problem

This is where payroll software actually gets hard.

A payroll run for 500 employees isn't one calculation — it's 500 independent calculations, each involving:

Base salary for the period (handling mid-month joiners and leavers)
Attendance data and approved overtime
Leave taken (paid, unpaid, partially paid)
Active deductions (loan EMIs, advances)
Statutory amounts (National Insurance, Health Insurance, income tax withholding)
Custom earning and deduction components configured per salary structure

Running this synchronously in a web request is not an option. On a slow connection, a 500-employee run would timeout in under two minutes.

We moved the entire payroll computation to Laravel queues with Horizon managing the workers:

class ProcessPayrollRun implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    public int $timeout = 3600; // 1 hour max for large tenants

    public function handle(PayrollEngine $engine): void
    {
        $this->run->employees->each(function (Employee $employee) use ($engine) {
            ProcessEmployeePayslip::dispatch($employee, $this->run);
        });
    }
}

Each employee's payslip is computed as a separate job. If one fails (bad data, edge case in overtime calculation), the rest of the run continues. Failed jobs retry automatically and surface in a review queue for the payroll officer.

The UI shows a live progress bar. The payroll officer can review anomalies — overtime spikes, partial-month joiners, mid-cycle resignations — before approving disbursement.

Statutory Compliance Is Not a Report

The mistake we almost made: treating statutory compliance as a reporting feature you add at the end.

National Insurance contributions, Health Insurance employee and employer shares, income tax withholding — these are not numbers you calculate at year-end and hope they match payroll. They have to be embedded in every computation cycle, against the rates and wage ceilings in effect for that period.

We modeled statutory rates as versioned configuration:

// config/statutory/national_insurance.php
return [
    '2025-04-01' => [
        'employee_rate'     => 0.12,
        'employer_rate'     => 0.138,
        'upper_earnings_limit' => 967, // weekly
        'lower_earnings_limit' => 123,
    ],
    // next rate change will be added here
];

When rates change, we add a new entry. Historical payroll runs use the rates that were in effect at the time — the computation is reproducible years later without the database knowing what today's rates are.

The Audit Trail Problem

HR data mutations need to be permanent and unalterable. An employee's salary change, a leave approval, a payroll disbursement — if any of these are later questioned, you need a record that cannot be edited.

Standard Laravel model events write to a log table, but that table can be edited by anyone with database access.

We solved this with append-only writes and a hash chain:

class AuditEntry extends Model
{
    public $timestamps = false;

    // No update() or delete() methods
    protected static function booted(): void
    {
        static::updating(fn() => throw new \Exception('Audit entries are immutable'));
        static::deleting(fn() => throw new \Exception('Audit entries are immutable'));
    }
}

Each entry contains a hash of the previous entry. Tampering with any record breaks the chain — detectable without needing a separate integrity service.

What We'd Do Differently

Start with the permission model. We designed features first and added access control later. Retrofitting field-level permissions (hiding salary from managers while showing headcount) onto an existing codebase is painful. Define your access control matrix before your first migration.

Don't build a notification system from scratch. We spent weeks building an in-app notification system that was essentially a simplified version of Laravel Notifications with a custom UI. Laravel Notifications with a database channel and a thin frontend is enough for most things.

Version your API from day one. We added versioning to the REST API after two external integrations were already in production. The migration was manageable but unnecessary.

The product is live. If you're working on something similar or have questions about any of these decisions, the comments are open.

We build Laravel-based products at Syftnex. The HR & Payroll platform is available for demos if you want to see the architecture in action.

Stop Building Native Apps for Small Businesses — You're Wasting Their Money

Ahmad Khokhar — Sat, 30 May 2026 15:46:57 +0000

I'm going to say something that will probably annoy a few mobile developers.

Most small and mid-sized businesses do not need a native app. And the people convincing them they do are either uninformed or have a billing incentive to keep them confused.

I've seen this play out too many times. A business owner gets excited about "having an app." They spend $30–80k on iOS and Android development. Six months later, their app has 200 downloads, a 2.1 star rating because nobody wanted to install it in the first place, and a maintenance bill they didn't budget for.

This isn't a failure of execution. It's a failure of the right question not being asked upfront.

The Question Nobody Asks

Before any mobile discussion, someone should ask:

Why does this need to be native?

Not "what features do you need" — that comes later. First: why native specifically?

The honest answers that justify native are actually pretty narrow:

You need Bluetooth, NFC, or deep hardware access
You're building a game with complex rendering
You need background processing that runs independently of the browser
Your users are offline 80% of the time with zero connectivity (not just spotty)

For most SME use cases — field service tools, customer portals, internal dashboards, loyalty programs, booking systems — none of these apply.

What SMEs Actually Need From "An App"

When you dig into what a business owner means when they say "I want an app", it usually comes down to:

Works on mobile, looks good, feels fast
Users can access it without opening a browser every time
Sends notifications when something happens
Works even when internet is slow or drops

That's it. That's the whole list.

Every single one of those is solvable without the App Store.

The Hidden Costs Nobody Mentions

Native development has costs that don't show up in the initial quote.

Two codebases. iOS and Android are different languages, different paradigms, different release cycles. You're either paying for two teams or accepting that one platform will always lag behind.

App Store dependency. Apple can reject your update. A policy change can affect your app overnight. Your release schedule is now partially controlled by a third party.

Update friction. Every time you fix a bug or ship a feature, users have to update. Some won't. Now you're supporting multiple versions in production.

Ongoing maintenance. OS updates break things. Each new iOS or Android version requires testing and often code changes — whether you shipped new features or not.

A web-based solution has none of these constraints. You deploy once. Everyone gets the update instantly. No review process. No two codebases.

"But PWAs Aren't Real Apps"

This one comes up every time.

In 2019, that was a fair criticism. In 2026, it's just not accurate anymore.

PWAs can be installed on the home screen on both iOS and Android. They send push notifications. They work offline with proper caching. They load fast on slow connections. They pass through app stores if you actually need that distribution channel.

The gap between a well-built PWA and a native app — for the majority of business use cases — is negligible to the end user.

What is not negligible is the cost difference and the time to ship.

The Actual Cases Where Native Makes Sense

I want to be clear — I'm not saying native is always wrong. There are legitimate use cases:

Consumer apps where offline hardware access is central to the product (fitness trackers, AR tools, music production)
Apps targeting platforms where PWA support is still limited
High-frequency trading or real-time systems where milliseconds matter
Products where App Store discoverability is a core acquisition channel

If your use case is genuinely in this list, build native. It's the right call.

But if you're a logistics company that needs field workers to log deliveries, or a clinic that needs patients to book appointments, or a retailer that wants a loyalty card on their customer's phone — you do not need to spend six figures on a native app.

Why This Keeps Happening

Developers like building native apps. The work is interesting, the billing is higher, and clients don't know enough to question it.

That's not malicious — it's just the natural result of an information gap. When someone doesn't know the alternative exists and performs comparably, they default to what they've heard of.

The problem is that nobody in the room has an incentive to close that gap.

What I'd Tell Any SME Owner

Before you sign anything for app development, ask the agency or developer one question:

"Could this be built as a Progressive Web App, and if not, why not?"

If they can't answer that clearly, or if they dismiss it without explanation, get a second opinion.

You might end up saving half your budget and shipping three months earlier.

If this was useful, I write about practical web development and the decisions behind real projects. Follow along if that's your thing.