Agentic coding tools (like Claude Code, OpenAI’s Codex agents) are making it ridiculously easy to turn an idea into working software. That’s exciting. It’s also where people can get into trouble – especially when non-developers or non-solution designers use these tools to build systems they can’t confidently secure, test, operate, or maintain.
Below is a pragmatic way to think about agentic tools: when they’re a superpower, when they’re a liability, and how to get value without accidentally creating a future incident (or an unmaintainable mess).
What is it?
Agentic coding is when an AI model doesn’t just suggest code it acts like a developer with initiative:
- It plans changes across multiple files.
- It writes code, runs commands, installs packages, and refactors.
- It debugs by iterating through errors and logs.
- It can integrate services, wire up databases, deploy infrastructure, and connect APIs.
- In some setups, it can use tools and credentials to interact with real environments.
In other words: it can move fast, make lots of changes, and produce a “working” system quickly – often faster than a human can track line-by-line.
What does it mean from a business perspective?
From a business perspective, agentic coding shifts the constraint from “can we build it?” (the answer is almost always yes) to “can we govern, secure, and support it?” The upside is real – speed, experimentation, and faster delivery – but the risks show up later as security gaps, operational overhead, and fragile solutions that no one can confidently maintain (I have seen the repercussions of this first hand – it takes lot of time and money to repatriate all the while dealing with risk).
- Throughput skyrockets (for the right people). If you have developers and strong technical oversight, agentic tools can compress weeks of work into days – sometimes hours.
- Non-developers can accidentally ship production-grade risk. “It runs” is not the same as “it’s safe, compliant, and supportable.”
- Security debt is easy to create and hard to spot. Common failure modes including secrets in code, weak authentication, overly-permissive access, poor input validation, and insecure defaults.
- Hidden operational burden shows up later. Logging, monitoring, backups, patching, dependency updates, incident response, and cost control are rarely “done” just because the app works.
- Supportability becomes a single-point-of-failure problem. If the builder can’t explain the architecture, data flows, and failure modes, the organisation becomes dependent on tribal knowledge (or “ask the model again”).
- Compliance and privacy can be breached without intent. Data retention, PII handling, consent, residency, audit logs, and vendor terms can be violated by simple design choices made early.
- Quality risk shifts from “coding” to “verification.” The work becomes: requirements clarity, threat modelling, test strategy, and acceptance criteria – because the AI can produce code faster than you can validate it.
- Shadow IT gets a turbocharger. Teams can spin up “just a quick solution” that bypasses governance, procurement, and security review – until it becomes business-critical.
What do I do with it?
The goal isn’t to avoid agentic tools – it’s to use them in the right order and with the right guardrails. Start with the lowest-risk approach that solves the problem, and only move toward more powerful (and more complex) options when you’re clear on ownership, security, and support.
- Start with the simplest tool that can solve the problem. Ask: Is this actually a software build, or is it a workflow and content problem?
- Try prompt engineering first. If the goal is summarising, drafting, classification, extraction, or decision support – start with prompts, templates, and a repeatable process before building anything.
- Use a Custom GPT / Google Gem for lightweight solutions. If you can keep it inside a managed interface with controlled instructions and guardrails, you avoid a lot of unnecessary complexity.
- Use a “real” agent platform when you need tools + governance. If you need tool use, access controls, logging, connectors, and admin oversight, consider platforms like Copilot Studio rather than creating your own.
- If the above fails for you then:
- If you do build with agentic coding, add developer supervision. Pair a non-developer with a developer/architect for solution design, security review, and operational readiness.
- Define guardrails before the first line of code. Minimum: data classification, allowed tools, credential handling, approval steps, and where the system can/can’t deploy changes.
- Make “supportability” a deliverable. Require: architecture diagram, config documentation, runbook, dependency list, and a basic monitoring/logging plan.
- Adopt a “stop/go” checklist. Before anything touches real users or real data: threat model, test plan, access review, and a rollback plan.
Agentic coding tools are like giving everyone access to a high-powered workshop. Incredible things can be built quickly – but only if you also understand safety, structure, and maintenance. If you don’t have a development or solution design background, the best path usually isn’t “don’t use agentic tools” – it’s use them in the right order, with the right guardrails, and (when needed) with the right technical oversight.