Why AI works for everyone except certain developers

Non-technical people are outperforming developers with AI. This isn’t luck. It’s a very old principle showing up in a new context.

Why AI works for everyone except certain developers

Something counterintuitive has been happening over the past year. The people most likely to complain that AI is "useless" are software developers. The people actually getting results? Course sellers, project managers, humanities graduates, and business analysts.

The pattern has a name.

What experienced engineers see in AI

If you've spent years working with unstructured data, you remember the pain. Real, specific, engineering pain that came from text processing tasks with no good tools.

SOUNDEX in PostgreSQL — a phonetic matching function that's been around since the 1990s. The fuzzystringmatch extension with Levenshtein distance, metaphone, and double metaphone. When you needed to match "John Smith" with "Smith, J." across two databases, you wrote a custom pipeline or you suffered. Classifying incoming support tickets by category meant labeled training data and a naive Bayes classifier. Deduplication at scale meant hours. Fuzzy ranking by something like "relevance" meant training a model.

And then AI arrived.

What does an experienced engineer see? A text processor of enormous power.

Input: text at any level of structure. Output: text in whatever format you specify. No rules, no training data, no labeled examples. Describe what you want — get it.

"Finally."

The transformation pipeline

If you think in texts and structures, you now have a tool for converting anything into anything else:

  • Vague stakeholder requests → structured requirements
  • Requirements → code and tests
  • Test output → requirements correction
  • Error messages from logs → actionable bug tasks
  • Market intelligence → product direction adjustments

If you also think in processes, you connect these transformations into pipelines. Each step consumes the output of the previous one. What used to require human coordination at every step becomes an automated chain.

A conveyor belt that removes 99% of the routine and produces predictable output.

At Askona — a $680M+ retail enterprise with 20+ distributed engineering teams — we built exactly this: a conversational interface to the data lake. A business user asks a question in plain language. The system generates SQL automatically and returns the result in both human-readable and machine-readable format. Text in, structured query, answer out. A text processor running in production.

Garbage in, garbage out

GIGO is as old as computing.

Someone who has never worked on information structuring tasks picks up AI and gives it what's in their head: an unstructured request, no context, no goal, no format. They get an unstructured answer. They conclude: "AI doesn't work."

That the output is bad precisely because the input was bad — they don't see it. They've never had to think about it. Their entire career, the tools structured things for them: CRM forms, ERP fields, Excel templates. The system compensated for the absence of structured thinking. AI is the first tool that doesn't do this. It amplifies what you bring.

Bring structure — get structure.

Why everyone else is getting results

The people getting results with AI are the ones developers least expected to win: LinkedIn course sellers, project managers, humanities graduates, business analysts.

What do they have in common?

They think in texts and structures. Not because they're smarter — it's their professional muscle. The course seller lives by crafting clear persuasive text. The project manager translates vague requests into structured deliverables for a living. The humanities grad works with language as a primary tool. The analyst's entire job is converting reality into structured descriptions that other people can act on.

AI amplifies exactly this. The people who had it — won. Developers who spent careers behind IDEs with autocomplete, with compilers that explained every error in plain English — they found the first tool that doesn't.

Knowing how to code turned out much less useful than knowing how to describe what you want.

August 2026

People still arrive in my comments insisting that AI "can't work" because it doesn't know their business logic and project architecture.

This argument was weak in late 2025. In August 2026, it's embarrassing.

Speckit shipped in September 2025. Superpowers in October. BMAD Method in April. All three solve exactly the context problem: give AI structured knowledge about your project — architecture, decisions, domain conventions, standards. All open source. Available now.

And the baseline pattern — CLAUDE.md plus a couple of memory files — requires no additional tooling at all.

"AI doesn't know our codebase" is a configuration problem, not a technology limitation. The distinction matters.

What AI actually revealed

AI didn't change the rules. It made the rules visible.

Structured thinking — the ability to formalize a problem, express it as a series of transformations, chain steps into a reproducible process — has always been the dividing line between people who build systems and people who follow patterns without understanding them.

The difference used to be hidden by tooling. The IDE held your hand. The framework made decisions. The compiler explained your mistakes. Now the scaffolding is gone, and what's left is whether you can think through a problem clearly enough to describe it.

If you're seeing that gap in your organization — you know where to find me.

Leave a Reply

Your email address will not be published. Required fields are marked *