Most “AI is changing software development” articles fall into one of two camps: utopian (AI will replace engineers) or apocalyptic (AI will destroy software quality). After fourteen years of shipping production software, we’ve found the honest answer is neither. AI is a force multiplier — and the multiplier only pays off if you point the freed-up hours at the parts of the craft that actually move the needle.
This post explains how we use AI in software development across Advisory Apps in 2026: what we delegate, what we never delegate, and where the time we save actually goes (spoiler: security, UX, and the unglamorous detail work that separates “it works” from “it’s good”).
In short: AI as a force multiplier means delegating the predictable 60–70% of engineering work — boilerplate, scaffolding, first-pass refactors, repetitive tests, documentation — to AI tools like Claude, GitHub Copilot, and Cursor. The 30% it cannot touch reliably — security threat modelling, UX micro-interactions, edge cases, architecture, and judgment calls — is exactly where senior engineers should be spending more time anyway. The win is reallocation, not replacement.
What “Force Multiplier” Actually Means in Software Engineering
A force multiplier is a tool or technique that lets a small team produce the output of a larger one — without the team itself getting larger. In software engineering, that means the same five engineers ship the workload of eight or ten, but the quality bar stays the same or goes up. The output increases because the input mix changes, not because the people work longer hours.
This matters because the alternative framing — “AI replaces engineers” — gets the economics backwards. The work doesn’t disappear when AI writes the first draft. Someone still has to review it, secure it, integrate it, test it under load, and live with it for the next five years. What changes is which work gets done by whom.
“AI is best understood as a junior teammate with senior-engineer typing speed and zero context on your codebase. It’s fast, opinionated, and dangerous unsupervised — exactly like a senior contractor on day one.”
Three things happen when a team adopts AI well:
- Throughput rises on the predictable, pattern-matched work — CRUD endpoints, form validation, test scaffolding, type definitions
- Cycle time drops on chores most engineers dislike — Stack Overflow archaeology, regex authoring, SQL translation, boilerplate refactors
- Senior attention is freed for the work AI does poorly — architecture, security, UX, debugging novel failures, judgment calls
The third bullet is the actual value. The first two just make the third one possible.
What We Hand to AI (and Why)
Our internal rule is simple: if a task is well-defined, pattern-rich, and reviewable in under five minutes, it’s a candidate for AI. If any of those three conditions fail, a human writes it.
The work we routinely delegate to AI assistants:
| Task | Why it fits AI |
|---|---|
| Boilerplate scaffolding (REST routes, DTOs, repository stubs) | Highly patterned, low judgment, fast to verify |
| First-pass unit tests | AI is good at enumerating obvious cases; humans still write the non-obvious ones |
| Type definitions and schema migrations from existing code | Mechanical translation work, easy to diff-review |
| Documentation drafts (JSDoc, README sections, API param descriptions) | Tedious for humans, well-suited to language models |
Regex, SQL one-liners, complex awk/jq expressions | Compresses an hour of trial-and-error into seconds |
| Translating between languages (Python script → TypeScript, etc.) | Mechanical, easy to validate by running both versions |
| Commit message and PR description drafts | Reduces friction, freeing energy for the actual review |
| Refactor proposals (rename, extract function, reshape data) | AI suggests; engineer accepts or rejects |
In a typical sprint, this category is roughly 60–70% of raw lines of code touched. It’s also the work that produces the least leverage when humans do it — the kind of work where talent doesn’t show through, only time. Handing it to AI is the easy call.
What We Never Hand to AI — and Where the Saved Hours Go
This is the part most posts skip. The work we don’t delegate, in 2026, is also the work where great teams pull ahead of average ones. Three categories matter.
Security and Threat Modelling
AI can spot textbook vulnerabilities (SQL injection, missing CSRF tokens, leaked secrets in commits). It is materially worse at threat modelling — reasoning about a specific system’s attack surface, what an adversary would actually target, where trust boundaries should sit, and how a feature could be abused in ways the spec didn’t anticipate. AI also routinely confabulates secure-looking patterns that aren’t (suggesting bcrypt with a hard-coded salt, or token storage in localStorage, or auth checks on the client).
Every Advisory Apps project ships with a human-written threat model before any code lands, and every PR touching auth, payments, or PII goes through senior review regardless of who (or what) wrote the diff. The time we save on boilerplate goes directly here. Our engineers now spend roughly 2–3 hours per sprint per project on threat modelling — up from “we tried to” before AI freed the capacity.
User Experience and the Details That Don’t Show Up in Tickets
AI can implement a “modal that closes when you click outside it.” It cannot tell you that the modal shouldn’t close on outside click if the user has typed anything into the form inside it, because losing typed data is the kind of frustration that loses a user permanently. That judgment lives in the heads of engineers and designers who have watched real users fumble with their software.
The taste, the micro-interactions, the loading states, the empty states, the “what happens when the connection drops mid-checkout” — these are where products win. We use the AI-freed time to widen the UX review on every feature: more usability tests, more design-engineering pairing, more time spent on the 10% of edges that nobody asked for but everyone notices. This is where the custom software work we do for Perodua, MyJPJ, and MedicalMet actually differentiates itself.
Architecture, Edge Cases, and Novel Debugging
AI is a strong pattern-matcher on problems it has seen many times before. It is a weak problem-solver on the genuinely novel: a race condition specific to your event queue, a memory leak that only manifests under a specific tenant load, a state-machine bug at the intersection of three services. The harder a bug, the less AI helps — and the more a senior engineer’s hours matter.
We’ve come to see “time spent debugging” as a healthier metric than “lines of code shipped.” A team that ships 4,000 AI-generated lines but cannot debug its own production issues at 2 AM is in a worse position than a team that ships 1,500 lines and owns every one of them.
How We Keep AI From Breaking What Matters: Review Discipline
A force multiplier multiplies whatever signal it gets. Sloppy inputs, sloppy review, no spec — and AI multiplies the chaos. Discipline isn’t optional; it’s the entire reason the multiplier works.
Our internal rules:
- Every AI-generated diff goes through the same code review as a human one. No “AI wrote it, looks fine” shortcuts. The reviewer carries the same responsibility.
- AI never gets write access to production systems or secrets. Tools like Claude and Copilot can read and propose, but the human merges, deploys, and rotates keys.
- No AI output ships without tests. If the AI also wrote the tests, a human writes at least one more — typically the failure case the AI didn’t think of.
- Specs come from humans. AI is allowed to draft user stories, but acceptance criteria and edge-case lists are always reviewed by an engineer who’s read the actual product context.
- We log what AI touched. Internally we tag AI-assisted PRs so that when a bug surfaces six months later, we know whether to suspect a pattern in AI output or a gap in human review.
This last rule has been the most useful. After tagging eighteen months of AI-assisted work, we know exactly where AI is reliable for us (test scaffolding, type definitions, internal admin UIs) and where it’s costly (authentication flows, payment integrations, anything touching multi-tenant data isolation). That knowledge isn’t transferable from a blog post — every team has to build it for themselves.
The Tools We Use — As Examples, Not Endorsements
We name specific tools below because we think tool-agnostic posts are vague to the point of useless. But the tools change every six months. The discipline doesn’t.
| Tool category | Tools we use (May 2026) | What it’s good for |
|---|---|---|
| Agentic coding assistants | Claude Code, Cursor, Codex | Multi-file refactors, scaffolding, test generation, codebase Q&A |
| In-editor autocomplete | GitHub Copilot | Line-by-line completion, ergonomic for boilerplate-heavy work |
| Chat-style LLMs | Claude, ChatGPT, Gemini | Architecture discussions, debugging-as-rubber-duck, doc drafts |
| Code review assist | Internal tools + Copilot Review | First-pass review for style and obvious bugs (humans still review after) |
Three things to note:
- No single tool dominates. Different jobs suit different tools. Forcing a team onto one tool because of a license deal usually leaves productivity on the table.
- We rotate as the landscape shifts. A tool that was best six months ago may have slipped. Treat “the toolchain” as a living thing.
- We pay for the tools. Free tiers are fine for evaluation, but production engineering teams need the higher rate limits and the data-handling guarantees that come with paid plans.
If you’re a Malaysian SME wondering where to start: pick one of the agentic coding assistants, give two senior engineers a month to integrate it into one project, and measure the difference in code-review-to-merge time. Don’t try to roll it out company-wide on day one.
What This Means for Clients: Faster Shipping, Same Craft
If you’re a founder or operations lead engaging Advisory Apps in 2026, you’ll feel the multiplier in three places.
Faster scoping conversations. We can spin up working prototypes inside a discovery call — not “polished mockups” but actual running code on a real stack. This compresses the back-and-forth that used to take two weeks into two meetings.
Tighter sprint cycles on well-scoped work. Modules from our pre-built module catalog — payment gateways, role-based access, document recognition, AI chatbot integration, AI voice agent — ship faster than ever because the boilerplate around them is no longer the time sink.
More senior attention per ringgit spent. Because AI absorbs the predictable work, a higher fraction of the engineering hours you pay for go toward the judgment calls only humans can make. That’s the real ROI of working with a team that has both the tooling discipline and the fourteen-year-old engineering culture to make AI safe.
This is also why we are deliberate about how we offer custom software development and AI-powered software as paired services rather than competing line items. The system is custom. The AI inside it is custom. The way both are built reflects the same engineering discipline.
What We’re Watching for the Rest of 2026
A few honest predictions, in case they age usefully:
- Multi-agent systems will be overhyped before they’re useful. Industry reports project that 80% of enterprise apps will embed AI agents by 2026, but in practice “agentic” still means “one model called in a loop.” Real multi-agent orchestration is two to three years from boring-and-reliable.
- Governance will become the differentiator. Teams that can prove their AI use is auditable, secure, and reversible will win the regulated-industry work (financial services, healthcare, government). Teams that can’t will lose it.
- The “AI replaced our engineers” headlines will quiet down. McKinsey’s $2.6–$4.4 trillion agentic-AI value projection assumes humans are still in the loop; the same report makes clear that organisations capturing that value invest more in skilled people, not fewer.
- Tooling consolidation is coming, then fragmenting again. Big platforms (GitHub, Atlassian, the hyperscalers) will absorb point tools. Then a wave of new startups will rebuild the same point tools, better. Don’t lock in long.
Frequently Asked Questions
Does Advisory Apps still hire human engineers?
Yes — actively. AI changes which work humans do, not whether we need them. Our 2026 hiring is weighted toward senior engineers, security specialists, and design-engineers, exactly because AI raised the floor on junior-level output and made senior judgment more valuable per hour. See our careers page.
How do you protect client code when using AI tools?
Three controls. (1) We use enterprise plans with no-training-on-customer-data clauses. (2) Secrets and credentials never enter prompts — our tooling redacts them before they leave the editor. (3) AI tooling has no production-system access; all writes go through human-merged, human-deployed pipelines.
Will this make our project cheaper?
In our experience, projects ship faster but the unit economics are similar. The hours we save on boilerplate get reinvested in the security, UX, and edge-case work that used to get cut for time. Clients usually report higher quality at similar cost rather than the same quality at lower cost. We think that’s the better trade.
Is AI suitable for regulated industries like healthcare or finance?
Yes — with discipline. Our healthcare product MedicalMet and our financial-services engagements both use AI in the engineering process, but never in places that would create audit, PDPA, or BNM RMiT compliance issues. The rule is: AI accelerates the building; humans own the security, compliance, and clinical/financial logic.
Talk to Us About Your Project
If you’re scoping a custom software project for 2026 and want a team that uses AI as a multiplier — not a shortcut — we’d like to hear from you. We’ll spend the first conversation understanding what you need, mapping the parts of the build that AI accelerates safely, and being honest about the parts that still need senior human attention.
Or browse our portfolio of 200+ delivered projects and our pre-built module catalog to see what we’ve shipped before.
Sources referenced: SBE Council 2026 Small Business Tech Use Survey; QuickBooks Small Business Insights 2026; BizBuySell Small Business AI Adoption Report, 2026; McKinsey Global Institute, “The economic potential of generative AI” (updated 2025); UiPath Automation Trends Report 2026; Gartner Strategic Predictions 2026.
