How I Like to Keep AI Honest

I want to hear from the doers, not the talkers.

That is the litmus test I keep coming back to.

When somebody tells me about a new AI tool, a new workflow, a new expert, or a new thing I am supposed to trust, I try to make myself ask a boring question first:

What have they done?

I want to hear from the doers, not the talkers. I want to hear: what have they built that people want? What traction? Can I see outside of the nice examples they show me?

That will miss some tools that end up being important. It absolutely will. But right now it is the test I like to use for getting a sense of whether something should be paid attention to.

AI makes it very easy to generate confidence. It makes it easy to generate screenshots, plans, docs, demos, and a nice-looking explanation of why the thing works. That is not the same as the thing working.

So I try to keep the question close: what has actually been built, used, tested, shipped, repaired, and trusted by someone besides the person pitching it?

The old solutions still matter

The funny thing is that the good solutions to all these new AI problems are old solutions.

The best app, the best technology that I’m relying on right now is just plain text files.

That sounds almost too small for the moment we are in, but that is the point. Plain text lasts. Markdown lasts. Reference links last. A directory of research that another person, another tool, or a newer smarter AI can inspect later is more valuable than a long chat thread that only makes sense inside one app.

The workflow I keep falling back to is simple:

I start by just generating. I don’t go to ChatGPT or Claude at the start. But as soon as I can, I pull all that into just a research directory.

And then:

Saving everything, dumping everything to Markdown with reference links, so that way a newer smarter AI can come in through with it and just re-verify all the research.

That is not glamorous. It is not a magic prompt. It is closer to bookkeeping. But it gives the work a shape that can survive the tool changing.

If the research is in files, I can audit it. If the sources are linked, I can check them. If the assumptions are written down, I can rerun them. If the system changes next month, I have not lost the work to a black box.

Those two questions go together for me:

What are the doers saying? And then what is the old solution?

Research needs an immune system

The other thing I do not want is a research process that just eats the first page of search results.

When a chatbot goes out and searches the web, it can bring back the same SEO-shaped content everybody else sees. It can confidently summarize a page that was written to win a keyword battle instead of a person trying to solve the problem.

So I like cynical sources early.

Search Hacker News, search research papers, search Reddit.

Not because any of those are perfect. They are not. But some communities have an immune system.

Somebody posts a product and the first comment is, “isn’t this just X but you’re charging money for it?” Somebody creates an account today and only posts about one company and someone notices. People push. People complain. People catch weird incentives.

That does not make the crowd right. It just means the junk has to fight a little harder.

If AI is going to help me research, I want it exposed to that kind of friction. I want it to find the polished claim, and then I want it to find the person saying, “hold on, that does not match my experience.”

Do not give AI every risky role at once

There is a security version of the same idea. One of the cleanest rules I have seen is basically a rule of two:

You shouldn’t give it like three roles at the same time where it can see sensitive info and it can also do dangerous things and it can also be accessed by the world.

Do not do three. Never do three of those things at the same time.

Only do two of those things.

That is the kind of rule I like because you can build a system from it. It is not “be careful with AI.” It is not “AI is risky.” It is a practical constraint you can hold in your head when you are designing a workflow.

Can it see sensitive information? Can it take dangerous actions? Can the world access it?

If the answer is yes to all three, the design is wrong. Take one away. Put a human review step in. Move it local. Remove the dangerous action. Narrow the access. Split the system.

The point is not to avoid AI. The point is to stop pretending a powerful tool is trustworthy just because it is useful.

Make it reproduce the problem first

I use AI heavily in engineering. A lot of what I build now is accelerated by agents. But I do not want to ever trust AI that it works for a human just because it says it works.

One of the loops I keep forcing is reproduction before implementation.

If I am seeing a bug, I do not want the agent to jump straight into “fixed it.” I want it to prove it can see what I see.

Before you write any implementation code, I want you to reproduce what I’m getting and confirm to me that you have also reproduced that.

That matters because otherwise you get the cycle where the tool says it is fixed, it is not fixed, then it says it is fixed now, and it is still not fixed. You waste cycles because the system is solving the wrong problem with total confidence.

Reproduction is a trust-building step. It tells me the agent is working on the actual failure, not an imagined version of it.

For anything UI-heavy or agent-coded, I want real checks around it.

Anything vibe-agent-coded, I want to have heavy Playwright testing with it.

The test does not have to prove everything. It has to lock down the thing that matters enough that I am not just reading a cheerful report from a machine that wants to be done.

Keep control over the judgment layer

I am fine letting AI move fast on boilerplate. I am fine letting it sketch structure, write first passes, generate options, and help me get to a working prototype faster.

But the judgment layer is different.

When I was talking through a product with a ranking mechanism, I said the quiet part out loud:

When it comes to things like the ranking mechanisms, I want to have a lot of control over those.

That means tests. It means scenarios. It means making sure the implementation lines up with the behavior I actually want.

I want to make sure we’re building out a test suite where we have our scenarios and then making sure all of the implementation lines up with that.

The ranking is where values sneak into the product. Who gets shown first? What signal matters? What incentives are we creating? What happens when someone tries to game it?

That is not a place where I want to shrug and say the model probably made a reasonable choice.

The same thing applies to code style. I have opinions about how I want the code to read, because readability is part of control.

I want you to write in a certain way. I just know that’s readable code and so then I can dig into it and understand what’s going on.

Readable code is not just taste. It is the difference between being able to take responsibility for a system and just hoping the generated parts keep behaving.

Be clear about what was hand-built

There is also a social version of keeping AI honest: be clear about what was hand-built and what was accelerated.

In one technical interview, I showed work that had moved very fast with AI. The feedback was fair. They wanted to see deeper evidence of traditional engineering judgment: file structures, hand-coded capabilities, the parts under the hood.

My own read afterwards was:

I did have like hand coded stuff prepared but I should have been a little more upfront.

And:

I’d be totally up for a second session where it’s just, this is all I’ve written, this is more from hand.

That is not an anti-AI point. It is the opposite. If AI is part of the work, say where. If the deeper organization is yours, show it. If the generated layer is useful but shallow, say that too.

People are trying to answer a reasonable question:

You crafted this, you understand the code organization in the deeper levels of it.

That matters. Not because every line has to be typed manually, but because somebody has to understand the system deeply enough to own it when the prototype becomes real.

The brick walls are the work

The reason I still like this whole space is that AI gets people moving.

Somebody can build the screen. Somebody can get a prototype that feels real. Somebody can get far enough to believe the idea might exist.

Then they hit the wall.

Nobody knows where the brick walls are but there are so many brick walls with AI.

The login screen does not work. The database has to exist. Authentication has rules. The cloud is not just a button. The workflow was easy until it had to be secure, reliable, observable, and maintainable.

You hit that brick wall and you’re just like, what now?

That is where I think the work gets interesting.

I can be a prompt guide. I can help somebody use Claude or ChatGPT better. But at a certain point, if all I am doing is helping people do something they can figure out on their own, that is not the highest-value part.

The better moment is when someone has played with the tool enough to see what is possible, exhausted the easy parts, and now they are hitting hard engineering problems.

That is where keeping AI honest stops being a slogan. It becomes the work: source the claims, preserve the research, test the behavior, control the judgment layer, separate risky roles, and own the system deeply enough to know what is actually happening.

Use AI heavily. Just do not confuse generated output with a trustworthy system.