The Age of Artificial Confidence

AI has made it easier than ever to do things we don't fully understand. The question is whether we're becoming equally good at recognising what we don't know.

I built my own website with AI.

Not just a few pages with some nice animations, but a reasonably complex platform with an admin interface, analytics, interactive functionality and quite a bit of logic behind it. I use Codex to develop it, maintain it, introduce new capabilities and improve existing ones. And I am quite comfortable doing so.

I'm a product designer, not a software engineer.

A few years ago, building something like this independently would have been considerably more difficult for me. Today, AI makes it possible to take my ideas much further into implementation, often without needing someone else to translate them into working code.

That's a remarkable change, and one I genuinely enjoy.

But here's something else I've learned along the way.

I wouldn't consider myself qualified to independently architect and deliver a complex enterprise SaaS platform.

Not even close.

And the more I learn about development, the more comfortable I become acknowledging that distinction.

When capability grows faster than understanding

One of the most exciting things about AI is that it allows us to work beyond the traditional boundaries of our disciplines.

Designers can write functioning code. Engineers can create sophisticated interfaces. People with little formal training in either discipline can build products that would previously have required entire teams.

And I think that's wonderful.

I don't believe these capabilities should be reserved for experienced professionals. A junior designer should absolutely be encouraged to experiment with code. Someone who has never designed an interface should be able to explore that discipline. A person with a good idea shouldn't need years of specialist training before being allowed to test it.

But there's a difference between being able to produce something and understanding everything required to make that something reliable.

My website is production-ready for the environment in which it operates. I understand its requirements, I can make decisions about its architecture, and I can accept responsibility for the consequences of those decisions.

An enterprise platform is an entirely different kind of beast.

There are architectural dependencies, APIs, permissions, user accounts, compliance requirements, security considerations and years of accumulated decisions that may not be immediately visible.

An apparently isolated change can have consequences in a completely unrelated part of the product.

An experienced engineer may recognise those relationships because they've spent years encountering them. I might not, because my professional experience has developed in a different direction.

AI can help me write the code. It can explain architectural concepts, identify potential problems and suggest solutions.

But generating an implementation doesn't automatically give me the judgement required to recognise everything that implementation might affect.

And I think this is where AI introduces a particularly interesting danger.

It can make us capable enough to stop recognising how much we still don't understand.

The appearance of expertise

We've always had people who were more confident than their knowledge justified. AI didn't invent overconfidence.

What it has changed is how convincing that overconfidence can become.

Someone can now produce a sophisticated application, a detailed architectural proposal or an impressive piece of design work with relatively little understanding of the discipline behind it.

The result might be genuinely good. It might even be better than something produced by an experienced professional.

But it might also contain fundamental problems that aren't visible to the person who created it.

And when the output looks convincing, it's tempting to assume that the reasoning behind it must be equally sound.

A successful prompt becomes evidence of competence. A few successful implementations become evidence of expertise. Eventually, the person may begin advising others on how to do work they haven't yet learned to evaluate properly.

And AI can make that progression even easier by supplying the vocabulary needed to sound knowledgeable.

I learned a great deal of engineering terminology while building my website with Codex. Some of it has since become genuinely useful in my conversations with engineers, and I've even helped other designers adopt some of that terminology to communicate their intentions more clearly.

But I make a point of understanding what those terms mean before using them to explain or justify my decisions.

The goal isn't to sound like an engineer. It's to reduce the translation gap between what I intend and what someone else needs to implement.

There's a difference between knowing the words, understanding the concepts behind them and having the judgement to apply those concepts appropriately.

AI can help us develop all three, but it doesn't guarantee that they develop at the same pace.

And there's a danger when we confuse them.

Technical fluency can make someone sound credible. Confidence can make their conclusions sound certain. Experience can make other people less inclined to question either.

That's a dangerous combination, but not because beginners are inherently dangerous.

The problem isn't being inexperienced.

It's becoming unwilling to recognise that inexperience still matters.

Professionalism isn't a measure of experience

I've come to believe that we frequently confuse professionalism with seniority.

We hear that someone is a professional and immediately associate that with years of experience, qualifications or an established reputation.

I don't think that's what professionalism means.

A designer with six months of experience can be thoroughly professional. They can question their assumptions, seek criticism, recognise when something exceeds their understanding and act responsibly on what they learn.

Someone with twenty years of experience can behave in precisely the opposite way.

Experience matters enormously. It builds pattern recognition, develops judgement and exposes us to consequences we might never have anticipated.

But experience doesn't guarantee professionalism.

Expertise is what we've learned. Professionalism is how we behave when we discover we haven't learned enough yet.

For me, one of the clearest signs of professionalism is the willingness to discover that I'm wrong.

Not just slightly wrong, either.

Spectacularly wrong.

If I bring an idea to someone with considerably more expertise than I have, I'm not necessarily asking them to confirm that my idea is better. I'm asking whether it's viable, whether it's feasible and whether I've missed something fundamental.

And if they show me that the entire premise is flawed, that's a valuable outcome.

It means I've discovered a limitation in my reasoning before allowing it to become a much more expensive mistake.

That doesn't mean an expert is automatically right, or that their opinion should end the discussion. Expertise deserves consideration, not unquestioning obedience.

A professional should be willing to challenge an expert when the evidence justifies it.

But there's an enormous difference between challenging someone's reasoning because you want to understand it and challenging them because you've already decided you know better.

The objective should be to find out whether the idea is right, not to prove that you are.

Experience can make overconfidence more dangerous

There's another uncomfortable aspect to this.

I believe unprofessional behaviour can be considerably more damaging when it comes from someone with substantial experience.

Not simply because they should know better, although I think that's a reasonable expectation.

It's because their decisions generally carry more weight.

A junior's overconfidence might result in a poorly considered solution that gets caught during review.

A senior's overconfidence can influence product strategy, establish flawed standards, redirect teams or convince an organisation to invest substantial resources in the wrong direction.

And seniority creates another complication.

The more experienced someone becomes, the more likely others are to interpret their confidence as evidence of sound judgement.

Sometimes that confidence is entirely justified.

Sometimes it isn't.

An experienced professional has the vocabulary, the credibility and the accumulated reputation to make an argument sound convincing, even when they're operating outside their actual expertise.

AI can make that illusion considerably easier to sustain.

AI makes it easier to produce the appearance of expertise. Experience makes it easier for that appearance to be believed.

And the problem can compound.

A junior's questionable idea is relatively easy for others to challenge. A senior's questionable idea may go unchallenged, or may only be reconsidered when someone with comparable authority raises the concern.

The evidence might be identical. Only the perceived credibility of the person presenting it has changed.

I find that particularly troubling because the consequences of a senior person's mistakes are often greater, while the opportunities for those mistakes to be challenged can become fewer.

If anything, accumulating experience and authority should make us more deliberate about inviting scrutiny.

Not less.

The table has become smaller

I've been experiencing another side of this change through my work on design systems.

AI now allows me to build functional React components, document their behaviour, implement responsive rules and explore complex configurations directly in Storybook.

Some relatively contained components can get remarkably close to production-ready before engineering needs to make substantial changes.

Others are considerably more complex.

I'm currently working on a complex component with nine purpose-defined slots and more than seventy configuration controls. It can support combinations beyond those currently used in the product, while allowing existing configurations to be represented through reusable patterns.

When I shared it with the engineers, one of them made an observation I particularly appreciated:

"It is beautiful from a design perspective, but as a developer it makes it very hard to maintain."

And that was exactly the kind of feedback I wanted.

From a design perspective, the component did what I needed it to do. It allowed me to explore a wide range of configurations, test behaviours and establish the rules governing how its different parts worked together.

From an engineering perspective, however, exposing all that flexibility directly would introduce unnecessary complexity into implementation and maintenance.

Neither perspective invalidated the other.

The solution wasn't to sacrifice the flexibility I'd designed, but to find a way of making that flexibility easier to consume. The comprehensive configuration environment could remain available for exploration, while reusable patterns provided engineers with a simpler interface for implementation.

And that's exactly the kind of collaboration I want AI to enable.

I can take my design intent much further into working implementation than I could before. Engineers can review something functional, challenge the architecture and apply their expertise much earlier.

My objective is to make the component as close to production-ready as I reasonably can.

But I don't assume that because I can build it, I'm the most qualified person to determine whether it belongs in an enterprise production environment.

That's not an artificial limitation I'm placing on design. It's recognition that engineering brings expertise I don't possess, just as design brings expertise that isn't automatically acquired by learning to generate an interface.

For years, designers and engineers have often worked across an unnecessarily large table.

Designers produced specifications. Engineers interpreted them. Questions travelled back and forth, misunderstandings accumulated, and decisions sometimes got lost in translation.

AI is making that table much smaller.

Designers can reach further into implementation. Engineers can reach further into design. We can understand each other's work more directly, explore ideas together and eliminate enormous amounts of unnecessary translation.

The table is finally small enough for us to hold hands.

It would be a shame if we used that opportunity to fight over each other's chairs.

Confidence should come with curiosity

I don't want AI to make people less ambitious.

I want juniors to experiment with things they couldn't previously build. I want designers to explore engineering. I want engineers to challenge design decisions. I want people from completely different backgrounds to bring ideas that established experts might never have considered.

And I want experienced professionals to be just as willing to learn from those people.

But I also want us to recognise that a convincing result isn't proof of complete understanding.

The more capable our tools become, the easier it is to overlook the difference.

Professionalism, to me, is not about knowing everything or having the right title. It's about approaching our work with enough curiosity to question our assumptions, enough confidence to put our ideas forward, and enough responsibility to recognise when we need someone else's expertise.

AI is giving us extraordinary new capabilities.

Perhaps one of the most important skills we can develop alongside them is the willingness to discover where our confidence has outrun our understanding.

When was the last time someone showed you that you were spectacularly wrong about something you were convinced you understood?

And did it change how you approached the next problem?