Random rant and thoughts on AI LLM, AI Statistical Modls



Big Claims, Real Limits

There’s a lot of hype about AI right now. Some CEOs say AI has already surpassed human intelligence. Others claim it can replace all office work. Take this quote from OpenAI’s Sam Altman:

“We are past the event horizon… The takeoff has started.”
– Sam Altman, MarketWatch Interview (2025)

He also wrote:

“Robots are not yet walking the streets… we still can’t easily go to space, and there is a lot about the universe we don’t understand.”
– Sam Altman’s Blog: The Gentle Singularity

Bold stuff. But here’s my everyday, boots-on-the-ground experience.


I’ve experimented with GitHub Copilot, DuckDuckGo AI, Agentic AI, Google’s AI tools, and I'm also building my own local LLM setup. I’d consider myself a layman when it comes to the deep internals of LLMs, but I use them regularly in a hands-on way.

Good Uses of AI (So Far)

AI tools work great for quick, well-scoped questions:

  • “What’s 45 million divided by 100,000?”

  • “How do I fix an SSL error in a Java HTTP call?”

You’d get the same answers from a Google search. AI just shortens the loop.

But Then… It Falls Apart

Try to scale up a little:

  • Update a 100,000-line Java or Node.js codebase?

  • Convert Java APIs to Node?

  • Understand how 1000 microservices and libraries interconnect?

GitHub Copilot and similar tools can’t handle it. They’re not “seeing” the entire codebase. Maybe that's my fault—maybe I’m not using them the right way. But if the tool needs me to be the glue, then is it really helping?

Honestly, Copilot is probably better than a junior dev at some tasks, maybe even great at Leetcode-type questions. 

Office Work Isn’t Just Typing

There’s still a physical and social aspect to office work that AI doesn’t touch:

  • Sometimes I have to call someone.

  • Sometimes I read undocumented manuals or fix things after conversations in hallway meetings.

  • Sometimes a bug gets reported as: “There’s an error on that screen.” Which screen? Who knows.

I use human intuition, body language, tone, and context. An AI can’t read the room. It doesn’t grasp subtle cues. It doesn’t know which undocumented page you’re talking about unless you tell it everything—at which point you might as well fix it yourself.

Agentic AI and Real-World Debugging

Let’s say there’s a 401 Unauthorized error on an external web API. I might:

  1. Open the frontend.

  2. Click through 10 screens.

  3. Realize a dropped token caused the problem.

  4. Trace it to a bug in the JavaScript.

Will an AI trace those 5+ steps? Not really. Monitoring tools may say, “Hey, you’ve had 20 401s today”—but they don’t explain why. I once spotted a missing space in an HTTP header after hours of scanning. That’s not something current AIs do well.

What I Want AI To Do (But It Doesn’t)

  • Build an operating system.

  • Write an entire project, introduce bugs, test it, deploy it on Docker or AWS, then fix and redeploy.

  • Convert Chrome source code to Rust.

  • Fix traffic in my area.

  • Cure cancer.

Okay, some of these are jokes—but the point is: AI still can’t do a full pipeline end-to-end without constant correction and context.


LLMs like ChatGPT are powerful, but they’re not like brains. They don’t live 80 years, adapt across environments, or discard unimportant memories. They run from a centralized, expensive server. I think a more promising path might be:

  • Distributed, decentralized AI agents

  • Independent learners (like humans)

  • Biological inspiration, like Jeff Hawkins’ Thousand Brains theory via the Numenta project

Humans are long-lived, cheap, energy-efficient, and work independently or collaboratively. We’re still way ahead in that regard.

What About Replacing Jobs?

Would you trust an AI to:

  • Be your doctor, even when you’re hiding a symptom?

  • Be your lawyer, navigating a courtroom, winning over a judge or jury?

  • Be your CEO, saving a company on the brink?

  • Be your teacher, when all the kids are asleep in class?

  • Be your IVR support line? (Press 0 to talk to a real human.)

Yeah. I still hit “zero” too.

TL;DR

  • AI is exciting—but overhyped.

  • It's not replacing high-context, messy human jobs anytime soon.

  • It doesn’t understand humans the way humans do.

  • It’s expensive, centralized, and doesn’t scale like human cognition.

  • We need more distributed, brain-like approaches.

Some of these prompts are admittedly silly. I didn’t put a ton of thought into all of them—they’re more like thought experiments. Most wouldn’t work with current AI capabilities, and I know that. But they highlight something interesting: there are still things humans can do that AI can't.

For example, Linus Torvalds reportedly created an early version of Git in a day or so. That wasn’t random. He had likely been thinking through the problem for years—when the time came, he had a clear motivation and internal drive to solve it. AI, as it stands today, doesn't work that way. It doesn't have a problem it needs to solve. It has access to vast knowledge, but no purpose or self-generated motivation.

Take Super Mario Bros.—a classic created by a small team of just a few developers. Could an AI, with the right prompt, recreate something like that today? Maybe. But I doubt it could do so with the same sense of playfulness or intent.

Here are some prompts I’ve thought about. Some are just fun. Others are more serious:

My AI Prompts

  • Take the Minix operating system. Could you create an OS with an improved text interface (like Bash or Zsh), and add a windowed environment subsystem? Generate full source code that will run on a modern x86 machine.

  • Convert the entire Linux kernel to Rust. Preserve all functionality, but improve on safety where possible.

  • Take Git (source control). Could you design and implement a better SCM tool from scratch?

  • Could you build a Unix-like operating system in Java, inspired by Minix?

  • Create a new object-oriented programming language that runs on a VM. Improve on Java’s flaws while keeping what works.

  • Build a Doom-style retro shooter, but better. Full source code.

  • Create a full Super Mario–era platformer using Unity, with 30 levels and improved mechanics. Share all assets and source code.

  • Create an LLM system that crawls Wikipedia and extracts up to 10GB of text, encodes the data, and trains a LLaMA 3–style model that runs locally on a MacBook. Include a working web interface and provide all source code for download.

  • If I feed in a live camera stream, can you detect when I’m lying?

  • From that same camera, can you tell when I’m happy, sad, or angry?

  • Based on text conversations alone, can you tell if I’m lying to you?

  • Can you help me save money on my cable bill?

OK, sure—some of these could be refined or made more realistic. For example, with the Minix idea, we could dig into hardware specifics: write a graphics card driver for an NVIDIA GPU that supports OpenGL acceleration, based on official device documentation.

The point isn’t that these are immediately achievable. The point is that they explore where AI could go—and where humans still shine in motivation, context, and creativity.


Comments

Post a Comment

Popular posts from this blog

JVM Notebook: Basic Clojure, Java and JVM Language performance

Image
"Measure, don't guess. The primary goal of all performance tuning exercises should be maximize the end user experience given the resource constraints." [1] "It isn't so much a "farewell to the J" as an expansion of the platform opportunities Java provides. Sun's investment to power ongoing development of JRuby and Jython broadens the range and reach of Java, as a whole." -- Rick Ross Overview and JVM Languages    One of the exciting trends to recently emerge from the Java community is the concept of the JVM language. These technologies are all that you would expect them to be. They are implementations of languages that run on the Java Virtual Machine. Some are newly created and some are based on existing, more mature languages. JRuby, Jython are two JVM languages based on CRuby and CPython. Groovy, Scala, Clojure are three completely new JVM languages that were created to add new language features that weren't supported by the core Ja...
Read more

On Unit Testing, Java TDD for developers to write

It has been a while, let's kick off 2017 with a blog entry. I have read and I am reading about four or five posts a day about unit testing. It really has been a long time obsession for me. I have moved past the technical and practical considerations on unit testing frameworks and done with the debates with "should you use Junit or Mockito or Karma?" I am more interested in the psychology of unit testing, who does it, likes it, hates it? It really is one of those easy to learn, hard to master concepts. For example, many many may play chess when they are young and can end up being horribly chess players most of their life, I am part of that majority. Unfortunately, I have never played chess and sat down for hours and tried to master it. I never see the common patterns or have a developed end game. I mostly just play with a knowledge of the basic rules. Following good unit testing practices within your software development shop is a lot like playing chess. It is easy to le...
Read more

Is Java the new COBOL? Yes. What does that mean, exactly? (Part 1)

Image
"If you want to know the past, look at your present. If you want to know the future, look at your present." -- Gautama Buddha Java is the new COBOL, whaaaat?     If you are software developer that mainly writes applications for the web; even if you aren't a Java/J2EE developer, you have probably heard the new meme circulating the web and blogosphere. "Java is the new COBOL" . Most blogs and technical writers regurgitate that statement and follow-up by saying that EJBs suck, and some companies are considering Ruby on Rails. I didn't really think much of these posts. I get the impression that a lot of these "managers" don't write any Java or COBOL code. They are really not highlighting the seriousness of the problem. COBOL development has remained stagnant for decades. Java may see the same problem in the future. The Pentagon/DOD has a trillion dollar COBOL problem because it is so difficult to change their ancient infrastructure. Anyon...
Read more