Working Effectively with AI

For months, I approached artificial intelligence the way many founders probably do. I wanted to know which model was best—not in theory, not according to a benchmark or a launch presentation, but for the work we actually do.

We are a startup, and that matters. A large corporation can absorb expensive tools, specialized teams, multiple layers of review, and experiments that lead nowhere. A startup has to think differently. Every subscription, every hour, every engineering decision, and every mistake competes for limited resources.

The objective was never to find something free. It was to find value.

I paid for several major commercial AI platforms over a period of months. I used different models, different subscription levels, and different workflows. I compared their ability to write, reason, translate, research, multitask, program, modify existing work, and help us build and maintain real production systems.

The conclusion was not that one model permanently defeated the others. The more useful conclusion was that the models could make each other more valuable.

This Is Not a Ranking

AI systems change too quickly for a field report like this to become a permanent league table. A model that performs exceptionally well on one kind of task today may be overtaken, reconfigured, limited, or improved a few months later. Another model may be stronger in a different context.

Our experience was also not a controlled scientific benchmark. The work involved real website deployments, multilingual content, software changes, document production, technical research, and repeated revisions under practical constraints.

That limitation matters. The purpose of this article is knowledge transfer: what changed when we stopped asking which AI deserved exclusive loyalty and started asking how multiple AIs could be organized into a safer process.

The Startup Economics Are Different

For a startup, the price of an AI subscription is only the visible part of the cost.

The effective cost of an AI-assisted workflow is closer to: subscription cost + human supervision + correction time + regression cost + deployment risk.

A cheaper tool can become expensive if it consumes hours of verification. A more expensive tool can be economical if it prevents a serious production failure. Two paid models can even cost less than one model in practical terms if independent review prevents days of rework or a damaging deployment.

The right question is therefore not, “How much does this subscription cost?” The better question is, “What is the smallest combination of tools and supervision that materially reduces engineering risk and human workload?”

When a Working System Is Not Necessarily a Healthy System

The visible result often looked correct. The website loaded. The requested modification appeared. Nothing obviously failed. That can create a dangerous assumption: If the result looks right, the underlying implementation must also be right.

Eventually, we inspected the deployment itself much more deeply. What we found changed my understanding of AI-assisted engineering.

Beneath a functioning website, technical debt had accumulated. There were duplicated representations of pages, historical artifacts that no longer belonged in production, routing complexity, obsolete configuration, old compatibility mechanisms, inconsistent URL handling, and files that had survived from previous iterations long after their original purpose had disappeared.

None of those problems necessarily prevented the homepage from loading. That was precisely the lesson. A system can work and still be unhealthy. A modification can satisfy the visible request while making the architecture more fragile.

The Most Dangerous Failure May Look Like Success

When people imagine software failure, they tend to imagine something dramatic: a crash, a compilation error, a missing page, a server error, or a build that refuses to complete.

Those failures are painful, but they are usually visible.

The subtler failure is a successful-looking modification that solves the immediate request by adding another compatibility rule, duplicated route, unnecessary asset, special case, or workaround. The result works, the task appears complete, and the architecture becomes a little harder to understand.

Repeat that process often enough and the system begins to carry the history of every correction instead of a clean representation of what it is supposed to be now.

The most expensive AI failure may not be the spectacular failure. It may be the successful-looking change that quietly becomes technical debt.

The Second AI Changed the Experiment

The workflow changed when a second AI was asked to inspect the work independently rather than continue the same conversation.

Instead of being told how the first model had reasoned, the second model could be given the actual files, the intended requirement, and a clear auditing role. Its job was not to be polite to the first model. Its job was to ask whether the implementation really matched the requirement and whether anything else had been damaged.

That independent review exposed a different class of problems: regressions outside the requested page, stale files, inconsistencies between routes, assumptions embedded in configuration, and changes that looked harmless when viewed only from the perspective of the original task.

The first AI could then examine that audit, accept valid findings, reject incorrect ones with evidence, and produce a correction. The second AI could review the correction again. The process became build → inspect → challenge → correct → verify.

The important discovery was not that the second AI was always better. It was that independence itself had value.

Redundancy Is Not New to Engineering

Engineering already uses redundancy when the cost of one unnoticed failure is too high.

We use independent checks, peer reviews, test instruments, backups, protection circuits, duplicated measurements, fault detection, and verification procedures because a single component or a single observer can be wrong.

Software teams use code review for the same reason. One developer can be highly competent and still miss the consequence of a change. The reviewer does not need to be universally more talented. The reviewer needs enough independence and understanding to notice a different mistake.

AI should not be exempt from this principle simply because it is fast or persuasive.

One Human and One AI Is Still a Small Team

A startup using one AI model for everything may appear efficient. It may also be building its business on an unverified assumption.

The risk is easy to underestimate because AI systems are persuasive. They produce fluent explanations, coherent code, complete-looking documents, and confident recommendations. That surface quality can create the impression that the work has been checked when it has only been generated.

A two-person team understands the principle intuitively. One person does the work; another reviews it. The second person may catch a missing requirement, an incorrect assumption, a calculation error, a security problem, or a small change that creates a larger failure elsewhere.

If a startup has one human and one AI, the AI may increase the amount of work that one person can produce. It does not automatically create independent verification. In that sense, one founder plus one AI can still behave like a one-reviewer organization.

Where the work matters, a second independent AI can provide an additional line of inspection before the human accepts the result.

Independence Matters More Than Hierarchy

The second AI does not need to be better than the first AI for this to work.

It only needs to be independent enough to notice a different mistake, assumption, or omission. Likewise, the first AI does not need to be better than the second in every area. The value comes from independent redundancy, not from declaring one model the winner.

It is the same basic principle as one human doing the work and another human verifying it. The second person does not need to be more intelligent or more skilled overall than the first; they need enough understanding to inspect the work independently and ask, “Does this actually satisfy the requirement?”

That independence can be weakened if the reviewer is simply given the first model’s entire reasoning and invited to agree with it. A stronger audit begins with the requirement and the artifact itself.

Reverse the Roles

A useful redundancy system should not permanently assign one model the role of builder and the other the role of critic.

On some tasks, Model A may produce the stronger first implementation. On another task, Model B may be more effective. The roles can reverse.

That role reversal has another advantage: it prevents the workflow from turning into a hidden ranking. Each model is treated as a capable but fallible engineering tool. Each can produce. Each can inspect. Each can challenge the other.

The process becomes more durable because it is based on roles rather than brand loyalty.

Verification Must Touch the Real Work

An AI review is weak if it only reviews a summary written by the AI that performed the work.

For software and deployment tasks, the reviewer should inspect the actual files, routes, configuration, links, generated artifacts, and relevant tests whenever practical. The same principle applies to documents, calculations, research notes, and structured data: review the artifact, not merely the explanation of the artifact.

A model can sincerely report that it changed only one page and still be wrong because a shared component, stylesheet, routing rule, build process, or generated file changed somewhere else.

Independent review becomes much more useful when the reviewer can compare the requirement with the delivered state directly.

Make Quality Measurable

Redundancy works best when neither AI is asked to judge quality only by impression.

For a website deployment, measurable checks can include file-difference reports, link sweeps, route checks, sitemap validation, language parity, HTML parsing, archive integrity, regression tests, and visual inspection of the pages that changed.

For another type of work, the checks will be different. The principle is the same: convert as much quality as possible into evidence that can be inspected.

The human then has something stronger than two confident opinions. The human has two independent analyses plus testable results.

The Effective Cost of AI

The debate about AI pricing often focuses on the monthly subscription. For engineering work, that number can be misleading.

If one AI saves an hour but creates three hours of regression repair, the apparent productivity gain was false. If two AIs together require an additional subscription but prevent a deployment error, the second subscription may have paid for itself immediately.

This does not mean every startup needs every premium model. Redundancy should be proportional to consequence. A low-risk draft may need one tool and a quick human check. A production deployment, financial model, critical technical document, or complex code change may justify an independent second review.

The objective is not maximum AI spending. It is controlled risk at a rational cost.

Today’s Best Model Is Not a Permanent Winner

The AI market moves too quickly for a permanent winner to be a useful operating assumption.

Models are updated. Capabilities improve. Pricing changes. Context limits change. Tools appear and disappear. A platform that fits one workflow exceptionally well today may become less suitable later, while another improves.

A process built around independent roles survives those changes better than a process built around loyalty to one model.

If a stronger model appears tomorrow, it can enter the workflow as a builder, reviewer, or specialist without requiring the organization to abandon the underlying verification discipline.

Design the Process, Not the Loyalty

The most valuable question changed from “Which AI should we use?” to “What should happen before AI-generated work is trusted?”

For us, the stronger pattern became simple: define the requirement clearly; let one model produce; let another model inspect independently; return the findings to the first model or the responsible builder; run objective checks; and keep final responsibility with the human who owns the decision.

This is slower than accepting the first convincing answer. It is also often faster than repairing a problem after deployment.

Good process does not assume failure. It makes failure easier to detect while correction is still cheap.

The Discipline That Makes Redundancy Useful

Two AIs can still agree on the same wrong answer. They can share similar training data, interpret an ambiguous requirement the same way, or repeat a plausible assumption.

Redundancy is therefore not a substitute for human judgment, testing, domain expertise, or clear requirements.

It is an additional layer. Its value depends on discipline: preserve independence, give the reviewer access to the real artifact, ask for evidence, distinguish findings from guesses, resolve disagreements explicitly, and verify the final state.

Human responsibility remains the final boundary. AI can generate, inspect, compare, and accelerate. The human still decides what is acceptable to release.

The Answer

Should a startup use two AI models simply because two is better than one? No.

Should important AI-assisted work depend on one model generating and effectively approving its own output? That is much harder to justify.

The lesson from our experience is that AI redundancy can be practical, affordable, and surprisingly powerful. One model can build. Another can inspect. The roles can reverse. Automated checks can test both. The human remains responsible for the final decision.

The objective is not to create an argument between machines.

It is to create a process in which a convincing answer is not automatically treated as a verified answer.

Working effectively with AI may ultimately depend less on finding the one model we trust most and more on designing a system that does not require blind trust in any single model.