Two quotes land on your desk for the same feature set. Both list similar features and both mention AI in their process. One includes architecture reviews, test suites, and hardening sprints. The other focuses on “AI-powered development, delivered in days.”
On paper they can look comparable. In practice they are often based on very different assumptions about how the software will be built, tested, and maintained.
At ZirconTech we have been building software for years for clients who handle real money, real compliance requirements, and real operational risk. We have been using AI coding tools since GPT-3 started producing useful code, and our estimates already reflect the productivity gains we see in day-to-day work.
In this article I want to explain how we think about AI in software delivery, what “vibecoding” looks like in practice, and how you can read software proposals in 2025 without needing a computer science degree.
What Vibecoding Actually Means
The term started as an inside joke among developers. Now it’s the best word we have for a specific phenomenon: code that matches the vibe of what you asked for, but collapses under any real scrutiny.
Picture this. You describe a feature: “I need users to upload documents, extract the key information, and store it in the database.” An AI coding assistant generates 300 lines of code in 45 seconds. You run it. It works on the demo document. You ship it.
Three weeks later: the system crashes when someone uploads a 50MB PDF. There’s no logging so you can’t tell what happened. There are no tests so you can’t verify the fix. The error handling assumes everything succeeds. The database schema doesn’t handle concurrent writes. The extraction logic fails silently on documents with tables or images.
That’s vibecoding. Heavy AI generation, light human design, zero thought about what happens after the demo.
When Trying It Is Fine
I’m not here to demonize fast prototyping. Vibecoding has legitimate uses:
Internal hackathons where you’re exploring ideas, not shipping products.
One-off scripts for your team where “good enough” actually is good enough.
Proof-of-concept demos where everyone understands the code is throwaway.
Research experiments where the code just needs to run once for a paper.
The pattern works when the stakes are low and the audience knows what they’re getting.
Where It Becomes Irresponsible
The problem starts when vibecoding gets sold as production engineering:
Systems that touch payments, personal data, or regulatory compliance.
Products that another team will maintain after the original developers leave.
Infrastructure that needs to handle scale, failures, and security threats.
Contracts with SLAs, uptime guarantees, or legal liability.
Vibecoding is fine for experiments. It becomes a serious problem when it is sold as production-grade software and you only discover the gaps months later.
How We Actually Use AI at ZirconTech
AI changed our workflow. It didn’t change our standards.
The best way I can describe modern AI tools: they’re like having a tireless junior developer who writes fast, never complains, and has zero judgment about what matters. You can get enormous value from that person. You can also ship catastrophically bad code if you treat their output as gospel.
Core Principles We Don’t Compromise
Architecture comes first. Before any AI writes a single line, we map out the system boundaries, data flows, and failure modes. AI is great at filling in implementations once you know what you’re implementing. It’s terrible at deciding whether you should build a monolith or microservices, or how to handle eventual consistency in distributed systems.
Everything goes through review. AI-generated code enters the codebase the same way human code does: pull request, automated tests, peer review, security scans. We’ve caught SQL injection vulnerabilities, race conditions, and memory leaks in AI-written code. The fact that a model wrote it doesn’t make it safe.
Someone is always accountable. When code breaks in production, “the AI did it” is not an acceptable answer. A human made the decision to ship that code. That human needs to understand what it does well enough to fix it at 2am when the alerts fire.
Quality gates stay consistent. We run the same test coverage requirements, the same static analysis tools, the same security scanners whether code came from a senior engineer or GPT-5. The source doesn’t change the standard.
A Real Feature, Start to Finish
Here’s how we’d build that document upload feature mentioned earlier:
Requirements phase: We talk through edge cases. What file types? What’s the max size? What happens if extraction fails? Who sees the data? What’s the privacy model? This takes maybe two hours. AI doesn’t help here because we’re figuring out what problem we’re actually solving.
Architecture design: We sketch the system. Object storage for files, queue for async processing, database schema with proper indexes, retry logic with exponential backoff, audit logs for compliance. This takes another hour. AI can suggest patterns but it can’t make the tradeoffs for us.
Implementation: Now AI earns its keep. We use Cursor to scaffold the API endpoints, storage helpers, and database migrations. GitHub Copilot writes the first draft of parsing logic and test cases. What used to take two days takes four hours. A senior developer reviews every suggestion, catches the missing error handling, adds the edge cases the AI missed.
Testing: AI generates the basic happy-path tests. We add the weird cases: corrupted files, network timeouts, concurrent uploads, malicious payloads. We run security scanners. We load test at 10x expected traffic. This still takes a full day because testing is where you find out if you actually built what you thought you built.
Review and deploy: Another developer reviews the entire PR. We check it against our security checklist. We deploy to staging, run through the test plan manually, then ship to production with feature flags so we can kill it instantly if something breaks.
Total time with AI: maybe three days for a feature that would have taken five or six days three years ago. That’s real acceleration. But notice what didn’t get faster: understanding the requirements, designing for failure modes, and verifying it actually works.
That’s why one quote includes time for all those steps, and another quote skips them entirely.
The AI Coding Tool Zoo
Clients ask me which AI tools we use. The honest answer: too many, and the list changes every quarter. But understanding the categories helps you know what’s possible and what’s still hype.
IDE Copilots and Coding Assistants
These tools sit inside your code editor and act like pair programmers. GitHub Copilot, Cursor, Cody, Amazon Q, Tabnine, Windsurf, JetBrains AI, and Cline autocomplete code, explain errors, suggest refactors, write tests. They’re the most mature category and we use them daily.
Concrete benefit: When you’re writing an API endpoint, they generate the boilerplate validation, error handling, and response formatting. Takes 30 seconds instead of 10 minutes. Over a project, this adds up to real time savings.
CLI and Terminal Agents
Warp, Fig, GitHub Copilot for CLI, Aider, Cline, and Gemini CLI help with git operations, shell scripts, and DevOps commands. Good for speeding up infrastructure work and debugging deployment issues.
Example: You paste an error message from a failed Kubernetes deployment, and the tool suggests the exact kubectl command to fix it. Saves you 15 minutes of documentation hunting.
Design-to-Code Tools
v0, Galileo AI, Vercel’s AI templates. You feed them a design file or description and they generate React components, Tailwind styles, basic routing. They’re getting better fast.
Reality check: They give you a starting point, not a finished product. You still need to hook up real APIs, handle loading states, add error boundaries, make it accessible, and test on actual devices.
AI web app builders. Tools like Lovable and Bolt.new go beyond components and generate full-stack apps from prompts: React frontends, backend, database, and hosting. v0.dev focuses more on frontends and components, while Lovable tries to take you from idea to running product.
Mobile and Native Development
FlutterFlow, Natively, Draftbit, and similar tools generate React Native or Flutter code from visual flows or natural-language prompts. Similar story: great scaffolding, still need someone who understands iOS performance quirks and Android permission models.
Backend and Database Tools
Amazon Q for databases, Supabase AI, tools that write SQL migrations, API controllers, and ORM queries. CodeRabbit reviews PRs with context about database performance.
These save time on CRUD operations and schema evolution. They don’t replace knowing how to index properly or design for data consistency.
Cloud and Infrastructure
AI features built into AWS, Azure, and GCP consoles. They explain error messages, write infrastructure-as-code, suggest cost optimizations. Some can execute commands directly in your cloud account.
Useful: cutting through cloud documentation to find the right configuration. Dangerous: giving an AI write access to production infrastructure without safeguards.
Security and Testing Tools
Snyk AI, GitHub Advanced Security, tools that scan for vulnerabilities and suggest fixes. Codium and TestGen generate test cases. Qodo reviews code for security issues.
These are genuinely helpful. They catch things humans miss. But they also generate false positives, so you need someone who can evaluate whether a finding is real.
Web3 and Blockchain
Solidity copilots, smart contract auditing tools, blockchain monitoring. Specialized domain where AI helps with the unique security patterns in crypto.
These are very relevant, as the stakes (and the exploits) are particularly high there.
We maintain a longer list of specific tools we’ve tested internally. It’s 50+ products and changes monthly. The point isn’t which tool has the best marketing. The point is that we benchmark them before they touch client code, and we keep the ones that actually make us faster without making us sloppier.
How These “Agents” Actually Work
When someone says “I’ll use AI agents to build your app,” what does that mean technically? Let me demystify this with a concrete example.
The Agent Loop
Most coding agents follow the same basic pattern:
- Read your request and scan the project files
- Build a plan (usually a TODO list of subtasks)
- Execute tools: read a file, edit code, run tests, execute shell commands
- Look at the result of each action
- Decide the next step based on what happened
- Repeat until the task is done or it gets stuck
- Return control to the human
It’s not magic. It’s a loop where a language model uses structured tools to manipulate code and infrastructure. The model never “understands” your code the way a human does. It’s doing sophisticated pattern matching and prediction at every step.
Claude Code as a Case Study
Anthropic has published best-practice guides for Claude Code, and independent researchers have reverse-engineered how it behaves in practice. One of the better write-ups is Jannes Klaas’s “Agent design lessons from Claude Code,” and it shows what responsible agent design looks like:
TODO lists for focus. The agent maintains an explicit task list and marks items complete as it works. This keeps it from wandering off or forgetting what it was doing mid-task. You can see its plan and veto directions that don’t make sense.
Controlled tool access. The agent can read files, edit files, run terminal commands, and search the codebase. Each tool has guardrails. For example, public analyses show that dangerous shell commands are routed through a smaller model first for safety checks before execution.
Iterative refinement. After running tests, the agent reads the output, sees what failed, and adjusts. It’s a feedback loop, not a one-shot generation. This is why agents can often fix their own bugs, unlike older code generation.
Parallel sub-agents. For complex tasks, Claude Code can spin up multiple smaller agents to work on independent parts simultaneously. One agent refactors a module while another writes tests for a different component.
Human checkpoints. The system asks for approval before certain operations, especially ones that modify infrastructure or install packages. You’re not just watching, you’re participating.
Why This Matters For Your Project
When you hire someone who’s “using AI agents,” you need to know:
Are they monitoring what the agent does? Or are they running it overnight and shipping whatever it produces?
Do they have safeguards around terminal access? An agent with unrestricted shell access can delete your database, expose secrets, or rack up $10,000 in cloud costs.
How do they handle mistakes? Agents make wrong turns. They generate code that doesn’t compile. They install incompatible dependencies. Someone needs to catch these errors before they hit production.
Is everything versioned? Every AI-generated change should go through Git like any other code. You need to be able to see what changed and roll back when something breaks.
You’re not just buying development time. You’re buying judgment about when to trust the AI, when to override it, and how to structure the workflow so mistakes get caught early.
Staying In Control When Agents Are Running
One of the biggest risks is losing track of what is happening in your own codebase. AI amplifies that risk because it moves fast and produces plausible-looking code that can hide serious issues if no one is watching.
Code Ownership and Traceability
Everything lives in version control. Full stop.
Every change an AI makes gets committed with a clear message explaining what happened. We tag AI-generated commits so you can filter them later. If we need to debug something six months from now, we can trace it back to the specific prompt and model version that created it.
We avoid tools that only give you a zip file at the end with no history. That is not a sustainable way to run a project, especially if you expect to maintain it over time.
Security and Backdoors
We treat AI code as untrusted until reviewed. Same way you’d treat code from a random GitHub project.
Security scanners run on every PR. Static analysis, dependency checks, secret detection. If the AI imported a package with known vulnerabilities, we catch it before merge.
Policy on secrets: never paste API keys, database credentials, or production data into external AI tools. The models are improving, but that data goes through someone else’s infrastructure. Use dummy values for development or run models locally when handling sensitive information.
Agents With Terminal and Cloud Access
This is where things get risky fast.
An agent that can run terminal commands can do anything you can do: deploy code, modify databases, change DNS records, delete resources. Some of these actions are reversible. Many are not.
We limit what agents can execute. Approved commands only. Sensitive operations require explicit human confirmation. Deployment and infrastructure changes go through CI/CD pipelines with logging and approvals, not through agent shell access.
When we use tools that can interact with cloud resources, we give them minimal IAM permissions. The agent can read CloudWatch logs, but it can’t terminate EC2 instances. Defense in depth.
Data and Privacy
Where do these models run? Are you sending client code to OpenAI, Anthropic, or Google? Are you using an enterprise plan with no-training guarantees? Are you running models on your own infrastructure?
For most projects, we use commercial APIs with enterprise agreements that prohibit training on customer data. For highly sensitive work, we evaluate self-hosted options like Code Llama or StarCoder running on our own hardware.
You should ask your vendor about this directly. How are they protecting your intellectual property and your users’ data when they run AI tools?
What AI Actually Accelerates (And What It Doesn’t)
A straightforward view of where the speed comes from and where it does not.
Where AI Genuinely Shines
Boilerplate and repetitive code. CRUD endpoints, form validation, DTO mappings, database migrations for straightforward schema changes. AI writes this faster than any human and often catches edge cases you’d forget.
Framework conversions. Migrating from REST to GraphQL, converting class components to hooks, translating Python to TypeScript. AI is absurdly good at these mechanical transformations.
Test generation. First-draft unit tests, integration test scaffolding, property-based test cases. You still need to add the weird edge cases, but the happy path tests appear almost instantly.
Documentation. README files, API documentation, inline comments explaining complex logic, architecture diagrams from code. AI turns “I should document this” from a four-hour chore into a 20-minute review task.
Data scripts and one-off tools. Need to clean up malformed records in the database? Parse a weird CSV format? Generate test fixtures? AI writes these throwaway scripts faster than you can Google the documentation.
What AI Doesn’t Replace
Understanding your business rules. The AI doesn’t know that refunds should be processed within 24 hours but not on weekends. It doesn’t know that premium users get different rate limits than free users. You have to encode that, and getting it wrong costs money or customers.
Domain modeling for maintainability. How do you structure the code so new developers can understand it? Where do you draw service boundaries? What belongs in the domain layer versus infrastructure? These decisions determine whether your system is still maintainable in two years.
Architecture for your specific constraints. Should this be synchronous or async? SQL or NoSQL? Monolith or services? Edge compute or regional? The AI can suggest patterns. It can’t make the tradeoff between cost, latency, consistency, and operational complexity that fits your exact situation.
Security and threat modeling. What attack vectors exist? Where’s the data most valuable to steal? What happens if this component gets compromised? How do you detect and respond to abuse? AI can check for known vulnerability patterns. It can’t think adversarially about your specific system.
The hard conversations about scope and priorities. What are we building in version one versus later? What’s a must-have versus a nice-to-have? What’s the real deadline versus the hoped-for deadline? These negotiations happen before any code gets written.
AI lets us spend less time on grunt work and more time where senior engineering judgment actually matters. That’s why our estimates changed over the last two years. The mix of work changed, not the level of care.
How to Read Software Quotes in 2025
You’re not an engineer. You shouldn’t have to become one just to evaluate vendors. But you need a way to distinguish real engineering from expensive theater and cheap vibecoding.
Questions to Ask Any Software Vendor
How do you actually use AI in your workflow? Listen for specifics. “We use Cursor for code completion and Copilot for test generation” is better than “We leverage cutting-edge AI agents.” If they can’t explain their process, that’s a yellow flag.
How do you ensure AI-generated code is tested and reviewed? You want to hear about test coverage requirements, code review processes, and security scanning. “We check everything the AI writes” is vague. “Every PR goes through two reviewers and automated security scans before merge” is concrete.
Who is accountable when something breaks in production? The answer should be a specific person or team, not “the AI” or “we’ll figure it out.” Ask about their on-call process, SLAs, and how they handle incidents.
What happens to my code and data when you use AI tools? Do they use enterprise agreements with no-training clauses? Do they run models locally for sensitive work? Do they have policies about what data never gets sent to external APIs?
Will I get full access to the repo and infrastructure? You should own everything: source code, infrastructure-as-code, documentation, deployment pipelines. Be suspicious of vendors who want to keep the code on their systems or deliver it as a black box.
Red Flags That Often Signal Vibecoding
Unrealistic timelines. “We’ll have your complete CRM system ready in two weeks” should make you suspicious, especially if it’s a complex system with custom workflows, integrations, and compliance requirements.
No time budget for testing or hardening. If the quote only shows development time and doesn’t mention QA, security review, performance testing, or bug fixing, ask what happens when those issues surface.
“One-click” or “no-code” platforms with no mention of customization limits. These tools are great for certain use cases. They’re terrible for others. If someone promises you can build anything with no code, it is usually an overstatement and you are likely to hit hard limits later.
Vague maintenance plans. “We’ll be available for support” is not the same as “We offer 24/7 on-call with 2-hour response times and monthly security updates.” Who fixes bugs? Who handles infrastructure updates? What happens if you want to change vendors in a year?
No one can explain how it actually works. If you ask “How does the payment processing work?” and get word salad about AI and microservices instead of a clear architecture explanation, that’s a problem. Good engineers can explain complex systems simply.
How We Handle This at ZirconTech
We benchmark every AI tool before it touches client work. When GPT-4 came out, we spent two weeks rebuilding an internal project to see where it helped and where it made things worse. We track which tasks got faster and adjust our estimates accordingly.
We’ve reduced our estimates for certain work by 30-40%. API development with well-defined specs is way faster now. Data pipeline work that’s mostly transformations and schema migrations got cheaper. Greenfield projects with clear requirements are quicker than they used to be.
But security reviews take the same time. Architecture design takes the same time. Requirements clarification takes the same time. Integration with complex legacy systems takes the same time, sometimes longer because the AI makes confident mistakes.
We keep the same quality gates regardless of who wrote the first draft. The code has to pass the same tests, the same reviews, the same security standards. If AI wrote it in 10 minutes but it takes us three hours to verify and fix, we’re honest about that.
We’re happy to walk you through how we’d build any feature. Not just what we’d build, but why we’d build it that way, what could go wrong, and how we’d detect and fix it. If you want to pair with our team during development to see the process firsthand, we can arrange that.
Where This Leaves You
AI changed how we estimate and build software. It didn’t change our responsibility for what runs in production.
The gap between quotes you’re seeing is real. Some of it is skill and experience. Some of it is honest disagreement about the right approach. And some of it is the difference between teams who are engineering with AI assistance and teams who are relying on AI without the supporting engineering practices.
At ZirconTech, we adopt new tools as soon as they prove they help us ship safer and faster. That’s already reflected in how we plan projects and the numbers you see in our proposals. But we don’t treat AI as a magic wand that makes hard problems easy. We treat it as leverage on the parts of software development that were always mechanical.
The hard parts are still hard. Understanding what you actually need. Designing systems that handle the weird cases. Building something another team can maintain. Making tradeoffs between speed, cost, and robustness. These problems require judgment that no model has.
If you are comparing quotes and want to understand what is behind them, or you want to talk through how AI can speed up your project without turning it into a fragile prototype, we are happy to walk you through our approach in plain language. Book time on our calendar or just send an email. No sales pitch, just a conversation about what is realistic given your specific constraints.
The future of software development is humans and AI working together, with humans staying in control of the decisions that matter. That’s not the sexiest narrative, but it’s the one that results in systems you can actually rely on.