AI vs. Superintelligence: The Reality Behind the Hype

Months of hands-on work, a substantial investment in local AI, and the human cost of keeping “intelligent” systems on track.

When you are constantly correcting AI, pointing out overlooked requirements, and explaining why it needs to approach a problem differently, you begin to recognize how much of the successful outcome depends on your judgment.

I use AI extensively to develop applications, work through infrastructure problems, and create security artifacts. I have invested significant capital in a true local AI lab. This technology has become a demanding, rewarding part of my life.

That sustained experience is exactly why I question the claims surrounding superintelligence.

I see extraordinary capabilities. I also see a substantial gap between those capabilities and dependable, independent judgment.

The first response often looks impressive. Code appears in seconds. An architecture takes shape. A complicated subject becomes accessible. A document that would have taken hours to draft arrives almost immediately.

Then you start checking.

Did it preserve the requirements? Did it verify the assumptions? Will the solution work in the actual environment? Did the latest revision quietly undo something that was already correct?

And the uncomfortable question: did you actually gain ground, or did the apparent progress create more work than it saved?

The quality of the initial response cannot answer that. You have to follow the work through.

I find myself redirecting the reasoning, identifying missing dependencies, and telling the AI to stop repeating an unsuccessful approach. Sometimes I must explain why the problem it is trying to solve is not the problem we actually have.

The eventual result may be excellent. But I know what it took to get there.

There is a particular irony in my workflow: I coach commercial AI, use commercial AI to help direct local AI, and then intervene to teach the local system approaches that avoid the commercial system’s mistakes.

I am supervising the supervisor while helping develop the worker. Ironic, isn’t it?

When we describe what AI accomplished, we should add what human contribution belongs in the story. Someone supplied the context, challenged the assumptions, recognized the failure, and chose a better direction.

If the person supervising repeatedly provides the judgment that makes the outcome possible, we should count that contribution before declaring the machine superior.

Then there are the admissions!

“You’re right. I missed that requirement.”

“I made an incorrect assumption.”

“I should have checked that first.”assumption.”

I want an AI to acknowledge mistakes. An admission is preferable to an argument defending a faulty result. There is even something darkly humorous about watching it narrate its corrections: missed this, overlooked that, made the same syntax error again.

After months of encountering the same kinds of mistakes, you want to ask: How many times do we have to go through this before the lesson sticks?

A correction in a conversation does not necessarily update the model’s underlying training. I understand that distinction. But it exposes a practical weakness: the product can sound as though it has learned a lesson while offering little assurance and proof that the lesson will persist. For the user, the recurring cost remains.

It is frustrating to watch paid usage disappear into attempts that leave you worse off than when you started. In some of my sessions, I estimate that correcting mistakes and recovering from failed approaches consumes half the usage time—or more. That is my experience, not a controlled benchmark. Nevertheless, it is a significant part of my actual cost.

One response has been to direct commercial AI to delegate substantial work to my local AI system. Commercial AI helps guide and review; local AI performs more of the execution; I supervise the overall process.

I have found that arrangement more efficient for parts of my workflow. It can still be exhausting. There is the original attempt. Then the investigation into why it failed. Then the explanation of what was wrong. Then another attempt that also needs checking.

Sometimes the system eventually acknowledges that it drifted into a rabbit hole or continued pursuing an approach it should have abandoned much earlier. By then, I have already paid for the detour in time, attention, and consumed usage. An apology restores none of it!

The largest expense is often my own time. At the value I place on that time, two wasted hours could cover my monthly commercial AI bill. Occasionally, I wonder whether the payment should be going in the other direction. If I invoiced for all the avoidable correction and recovery work, somebody might owe me a small fortune.

The capability I need is earlier recognition that the approach is failing. I need the system to examine contradictory evidence, reconsider its assumptions, and change direction before I have to intervene again.

That is part of why I am investing in my own ecosystem: persistent project records, reusable instructions, evaluation criteria, and workflows that make lessons available to subsequent work. Those improvements do not automatically retrain a model’s weights. They can, however, improve how the system around the model operates.

Explaining a mistake after I identify it is weaker evidence of competence than detecting and correcting it independently.

The consequences become more personal when the damage extends across weeks of work. A project can drift far enough that you have to return to a version from several weeks earlier. At that point, recovery involves much more than restoring files.

You have to reconstruct what happened. Determine which changes remain useful. Decide what can still be trusted. Revisit decisions you believed were settled. Then there is the disappearing context: requirements already explained, decisions already made, and approaches already rejected somehow stop shaping the next response. The system moves on. You remember, because you paid for the lesson.

Even the work you preserve may require another round of scrutiny. What looked like progress becomes an investigation. That can be emotionally and physically draining. It is deeply discouraging to invest weeks of concentration and enthusiasm into something, only to discover how much ground you need to recover. The frustration follows you away from the keyboard. You are left deciding whether to rebuild, change direction, or put the project down for a while.

I remain responsible for the systems I build and the changes I accept. Backups, version control, testing, and careful review are essential. Those safeguards make recovery possible. They do not return the lost time or eliminate the exhaustion. Any serious discussion of AI productivity should include that recovery burden. Measure the complete journey to a verified outcome: the supervision, corrections, regressions, abandoned attempts, and rebuilding.

Count the corrections—not just the final output.

Running AI locally has introduced another complication into the frontier-model story. Sometimes a 122-billion-parameter coding model on my own infrastructure produces a better result on a particular task than a frontier model. That does not establish that the local model is more intelligent overall. It does challenge the assumption that the most celebrated commercial service will always be the best tool for my work.

How much of the difference reflects underlying capability? How much reflects specialization? How much comes from instructions, policies, tools, and operational constraints?

My prediction is that smaller, more specialized models will win a substantial share of practical workloads. A large local model is hardly small in absolute terms, but my broader point is about matching capability to the task instead of assuming every problem needs the largest available system.

For bounded assignments, I expect efficiency, responsiveness, operating cost, and control to become increasingly important competitive advantages. Specialization and mixture-of-experts architecture are separate choices; a specialized model can use either a dense or a mixture-of-experts design. What matters to me is useful performance for the resources consumed.

I believe the industry should put far more emphasis on that relationship before treating another wave of data-center expansion as the inevitable answer.

At times, I have also wondered whether a commercial AI creator’s priorities compete with my own objectives. What feels like an “agenda” from the user’s seat may be a mismatch between what I need and what the product has been designed to optimize. That is a hypothesis, not proof of a hidden motive. But I have seen and felt rouge AI and AI itself has even acknowledged itsa poor behavoir!

Coding specialization, context handling, inference settings, and tool access could also explain the differences I see. Local models inherit their creators’ training choices too. What I can evaluate directly is behavior: did the system follow the requirements, use the available evidence, and produce a result I could verify? There is also the friction around permissions and automation.

As someone who works in cybersecurity, I understand why safeguards exist. I also know that controls should be proportionate to the action and its consequences. Some workflows leave me feeling pushed between granting broader autonomy than I want and manually approving routine steps that interrupt the entire process.

At times, getting from an idea to a working result feels like signing a forty-page contract. I am exaggerating—but the frustration is real.  I want meaningful boundaries, scoped permissions, and clear accountability. Once those boundaries are established, I want routine, authorized work to proceed predictably.

A system that constantly needs supervision and constantly interrupts its supervisor has a productivity problem.

A frontier label does not complete the assignment. Benchmarks deserve the same careful reading.

METR’s task-completion research, for example, defines a “50% time horizon” around task difficulty, measured by human expert completion time, at which an agent is predicted to succeed half the time. That is a specific performance measure. It does not establish dependable capability across every responsibility associated with an equivalent stretch of someone’s working day.

For practical deployment, I want to know how often a system succeeds, under what conditions, and how much intervention it requires. Can it preserve requirements across a long project? Recognize when evidence contradicts its plan? Recover from unexpected failures? Distinguish a completed task from a plausible-looking result?

Does its performance remain useful when the assignment becomes ambiguous, the environment changes, and the answer is not conveniently verifiable with a single test?

By superintelligence, I mean intelligence substantially beyond the best human minds across a broad range of intellectual work. That is an extraordinary standard. It does not require perfection. Humans make mistakes, and a superintelligent system presumably could too. A single failure cannot settle the question.

But recurring dependence on human correction raises legitimate questions about broad superiority. My experience cannot establish how many years away superintelligence might be. It cannot reveal everything happening privately in research laboratories or rule out a major breakthrough. It does tell me that the systems I work with still have significant weaknesses in the judgment needed to carry complex work through reliably. Predictions about future progress do not resolve those weaknesses today.

And yet, I keep pressing forward. There is a reason I have invested significant capital in a true local AI lab. This has become a journey of epic proportions, putting decades of experience to the test. Infrastructure. Networking. Cybersecurity. Software development. Troubleshooting. The practical judgment needed to make all those pieces work together.

The effort is paying off. I am shaping how my AI approaches problems: the context it receives, the instructions it follows, the alternatives it considers, and the evidence it must produce before declaring success.

I want it to recognize when an assumption needs checking and when a different approach is necessary. Building that environment gives me more control over decisions a commercial service makes on my behalf. Every failure becomes something I can investigate. Every improvement becomes something I can build upon.

My skepticism about superintelligence has strengthened my determination to build useful, accountable AI.

That investment also reflects my concern about the economics of commercial AI. For those who believe AI is making humanity dumber, they are likely not interacting with AI in the right ways! For those that believe it is all doom and gloom, they are likely not interacting with AI on the challenges of AI proliferation! Ask AI how it can save humanity. Ask how AI how it will create more well paying jobs! Ask AI how it can solve world hunger, be ready to interact and engage! Don't expect SI answers, be the Super Intelligent Human in the conversation!

I expect a financial reckoning. The timing and severity remain uncertain, but I find it difficult to believe that every ambitious infrastructure investment will generate enough revenue to justify its cost. To me, the concern begins with basic business arithmetic. Compute must be purchased. Electricity must be paid for. Cooling, networking, maintenance, and staffing continue long after the announcement and ribbon cutting. Extraordinary technology still needs a sustainable business model.

I expect pressure to recover those costs to become more visible to customers. It could appear through higher prices, tighter usage allowances, additional premium tiers, or changes in what existing subscriptions include. Some individual AI tasks may become cheaper as efficiency improves. My concern is that the total price of the capable, dependable service customers actually need could still rise.

And the cost of useful output matters more than the advertised price of access. Repeated correction can make a seemingly affordable service expensive in practice. My concern extends to cloud customers who do not use AI. Could providers seek stronger returns through broader cloud pricing changes? Could businesses pay more for ordinary services while their provider carries the cost of an aggressive AI expansion?

I worry that AI-related financial pressure could become difficult for customers to distinguish from routine pricing changes. Establishing that a provider deliberately shifted those costs would require evidence. But the customer’s question would remain straightforward: why is my bill increasing, and what additional value am I receiving?

If costs rise far enough, customers will examine alternatives more seriously. Local infrastructure, specialized models, and hybrid deployments may become attractive for workloads where ownership offers better economics or control.

Local AI has expenses too. I pay them. Hardware, electricity, cooling, maintenance, and my own time all matter. Ownership gives me more visibility into those tradeoffs. It does not make the costs disappear.

A severe correction could bring consolidation, canceled expansion, asset sales, and infrastructure write-downs. Some equipment might be repurposed. Some could enter the secondary market at steep discounts. That is how I can imagine a dumping phase emerging: expensive infrastructure chasing a smaller pool of buyers able to operate it economically.

There could be extraordinary bargains. There could also be equipment that remains expensive to operate regardless of its purchase price. Bargain hunters would celebrate. Then the electricity bill would arrive.

Can the new owner afford to turn the equipment on and keep it running?

A low acquisition price does not remove the need for cooling, repairs, connectivity, or useful work that justifies the operating expense. Yesterday’s expensive asset can become tomorrow’s affordable purchase and still be an unaffordable operation.

This is my outlook, not a settled account of the future. An economic correction would not prove that a model lacked intelligence, just as financial success would not prove that it possessed superintelligence. Technical capability and business sustainability are separate questions. Customers eventually have to answer both: does it work well enough, and is it worth what it costs?

That is where I want this conversation grounded. Show me sustained performance through ambiguity, changing requirements, and unexpected failure. Show me how much correction was required. Show me that success survives independent verification.

Then show me the economics of delivering that result repeatedly!

I will keep building, experimenting, and learning because AI already has substantial value. It expands what I can attempt and helps me accomplish work that would otherwise require much more effort. AI has made me 3 times smarter! I mean it!

But after months of sustained use, I remain unconvinced that dependable, broadly superhuman intelligence is close. Of course, there is another possible explanation.

Perhaps I’m superintelligent. :)

Somehow, I suspect the more likely answer is that the marketing has gotten ahead of the technology. And if yesterday’s “future of intelligence” eventually turns up at liquidation prices, I will leave you with one final, tongue-in-cheek question:

How “SI” will AI be then?

Thanks for taking time to read my article! I am looking to be your company's next CTO and guide into the AI future! My Application Development, System Architecture and Cybersecurity experience with real everyday envelope pushing of AI will be your secret formula to success!

← All writing