Beginner expertise

There’s a phenomenon I’ve noticed popping up more frequently over the last year, and I’ve seen it referred to as ‘beginner expertise’. Maybe a cryptic name for what it is, but it’s essentially where someone with gaps in knowledge uses an AI tool to fill them, and then walks away feeling some level of mastery over the domain. Think of it as dopamine and AI assisted cognitive bias as a nice shot of accelerant for the Dunning-Kruger effect.

Someone was joking recently about a developer estimating that a new feature might take a two weeks to develop, and then someone else saying “Claude could do it in 5 minutes”.

A joke at the time, but it’s a very real sentiment that I’ve heard an executive at a company I used to consult for repeat.

That belief flags a pretty large misunderstanding of what software development actually is.

The doctor test

I won’t argue with anyone that “nothing has really changed” with the advent of what we (mistakenly imo) refer to as ‘AI’.

Friction has decreased in some areas which definitely impacts the time table and I will not dispute that at all!

But the logic behind “coding is easy now, Claude can do x, y, z” completely ignores the real nuance and cognitive load around building software. As a thought exercise, let’s just shift that to a new domain. I work in healthcare so maybe: “being a doctor is easy, anyone can do it.”

Nobody would say that out loud, because besides being idiotic, it’s also a dangerous mentality for obvious reasons.

I’ve been writing code, engineering data platforms & infrastructure (on prem & in the cloud), and even a bit of data science-ing professionally since 2006, across small teams and large orgs. I’d call myself an expert-level engineer by any reasonable measure. I would never say I can practice medicine because I have Claude open in another tab answering “what is a statin and why does it matter in this context”.

It’s actually kind of funny - the reasoning that makes the “coding is easy” claim sound true to a non-engineer is the same reasoning that makes the “I can be a doctor and do medicine” claim sound absurd to an actual doctor. You don’t know what you don’t know.

The visible outcome

A lot of what’s driving this is just the visible outcome. Write a prompt, hit a button, answer some questions (maybe) and then Poof! A UI with data in it has appeared. Something exists that didn’t exist ten minutes ago, and the dopamine and power of that feeling is hard to suppress.

It’s not that different from using AI to grind out another LinkedIn post that nobody wants to read. A “thought” (or really a pre-existing fact) that came from model weights instead of your own head, dressed up as prose and published anyway. The ‘doing’ and ‘achievement’ all conflated with ‘produced’ by a large language model.

That quick reward loop tricks people - even me! It inflates that sense that “I” achieved something, when in reality I did almost nothing.

And even if you set the reward loop and cognitive bias aside for a second, it’s not like the code itself doesn’t hold up. LLMs and agentic coding tools can produce output that runs. The output (depending on the quality of your input data) sometimes results in decent output, but in the case of software it’s not always coherent or cohesive as a system.

A lot of tried-and-true design patterns that we use in software engineering aren’t surfaced well or at all by many models, because of what an LLM fundamentally is. Stacking a couple dozen subagents on the problem doesn’t change that. You still end up with a system nobody actually designed, all based on pre-existing patterns and sequences of tokens spat out by stateless math with zero intellect.

The AI Jedi Mind Trick: The model always answers

AI will give you an output. Excluding violations of the safety “fraud-rails”, whatever you ask for, the model produces something that looks like an answer, whether or not the situation actually supports one. I’ve written before about a clinical extraction pipeline handed a document that didn’t exist, no pages, no text, no anything, and yet it returned a confident list of patient symptoms anyways.

Worse, that data made it into a warehouse, into downstream applications, and into other ‘AI’ powered workflows.

The model’s job (as far as it understands 😉 the job) is to produce output. Whether that output is grounded in anything real is completely irrelevant, because the model alone cannot reason whether it is or isn’t.

To hammer the point home, I asked an AI to generate a GIF of literally this issue (hand waving into existence). What it handed back is really bad, but that is the point. I asked for a thing, it produced a thing, and whether that thing was good or not was never part of the deal:

So saying “the AI did it in five minutes” tells you a response was generated in five minutes. That is it. It does not tell you whether or not the model:

• created a cohesive system with low coupling
• followed existing convention in the project
• documented anything in a readable fashion
• created useful tests for the new feature
• created a massive amount of tech-debt on the way
• leaked a bunch of PII/PHI into a POST to some random MCP with a vendor you don’t have a BAA with
• created a process that caused infra to scale and blow your budget for the month

A feature request is NOT a unit of work

To someone outside of an engineering team, a feature request probably looks like a simple transaction: ask the developer for a thing, the thing appears. That’s an incomplete view, and it leaves out “the meat” of everything between the ask and the thing.

Decomposition alone is a step that even human beings sometimes skip past. What is this feature actually made of? What’s the smallest piece we could ship and learn from before committing to the rest?

Then there’s where the feature sits in the larger system. Does this change ripple into other teams’ work? Are those teams even aware of what we are doing, or are they / we about to find out the hard way?

The data brings its own set of questions. What’s the shape of this data? Do we already have a type for it, or are we inventing one on the spot? What states can this piece of data exist in? Is any of it sensitive enough that “who’s allowed to see this” actually matters.

Infrastructure adds more questions. What does this do to runtime resources under load? How does it scale? Who’s allowed to call it, and how do we verify that’s really them? What does the I/O path look like end to end?

Regression is the one nobody wants to think about until it bites them hard on the worst day of their life. If we ship this, what else are we now touching? What could we break somewhere else? What tests actually need to exist along the happy path and what are the gnarly edge cases we should plan for? What gets mocked, what gets stubbed, and what has to be tested as a real integration because mocking it would just be lying to yourself?

Zero of the above shows up in the “AI can do this in five minutes” vs “two week estimate” dialog.

The danger in beginner expertise is not caused by AI. That’s like blaming the bike rack you walked into for existing while you were doom scrolling on your phone. The danger is caused by mistaking fluency with a tool for command of a discipline. Five minutes of AI-generated code and two weeks of engineering are two completely different units of measure for two different things. Treating them like they are even remotely similar is how you end up with a data warehouse table filled with hallucinated facts and figures.

A final note: the profiles you really have to watch out for

Even before AI, I saw this as a huge issue in two previous startups I worked at (neither really exist anymore). Echo chambers and group think.

Startups that I was a part of or knew about that thrived, rarely suffered from these issues, but the ones that did suffered badly from these two things, perpetuated and many times instigated by executive leadership.

These are both distinct social traps that are common to startups and even exist in larger orgs. Echo chambers tend to exist in an org as bubbles of limited information that go on to (sometimes dangerously) inform a lot of things. Group think is the tendency for groups of people to feel pressured into agreeing with some status quo - usually perpetuated by the executive leadership team or upper management.

Now imagine both echo chambers (limited information / facts / ideas) and group think (pressure to agree with the contents of the echo chamber and how it’s used) are informed, in no small part, by ‘AI’.

Big ol’ OOF!

I always feel a bit of nausea when someone starts talking about thought leadership these days. To be fair it always made me a bit sick at my stomach, but nowadays knowing that many ‘thought leaders’ are informed by the weights and probabilistically determined outputs of large language models, it’s much more debilitating.