DEV Community: Robert Love

Ask AI to Stop Being Nice

Robert Love — Wed, 01 Apr 2026 03:33:00 +0000

A Better Way to Review Your Design Docs

In a prior post, I wrote about using AI before code—shaping the system in words, building Markdown documents, and reducing drift before implementation starts.

You can read that here: I Don’t Start With Code Anymore

This post is about the next step:

Once you have the documents, ask AI to stop helping and start judging.

If you stripped away all prior context, would your design docs still make sense?

That sounds harsher than it is. But it matters.

By default, AI often tries to be agreeable. It smooths rough edges. It validates your thinking. It finds what is good before it tells you what is weak. That can be useful early on, when you are trying to explore an idea. It is much less useful when you need to know whether your documents actually stand on their own.

At some point, you need the model to stop acting like a collaborator and start acting like a reviewer.

The real test is not whether AI understands you

The real test is whether AI understands your documents without you.

That is a very different standard.

A lot of design work feels coherent inside an ongoing chat because the model is benefiting from your previous explanations, corrections, and intent. It may be using surrounding context to fill in missing assumptions. That can hide weaknesses in the actual documents.

So one of the most useful things I can do is isolate the material.

I start a clean project or fresh conversation with as little extra context as possible. Then I upload only the files that are supposed to define the system: the vocabulary, goals, architecture notes, interfaces, process model, whatever should be sufficient on its own.

Then I ask the model to judge the material based only on that.

That is where things get honest.

Why this works

When the extra context is gone, the documents either carry the meaning or they do not.

If they do, the model can summarize the system, explain the boundaries, identify the phases, and reason about implementation from the files alone.

If they do not, the cracks show quickly:

terms are undefined
boundaries are fuzzy
assumptions are implicit
phases are inconsistent
interfaces are under-specified
important decisions exist only in prior chat history

That is exactly what I want to find.

I would rather discover that weakness while refining the documents than discover it later when a coding agent starts implementing the wrong thing.

Tell the AI to be ruthless

This is the part many people skip.

If you ask AI, “What do you think of these docs?” you will often get a polite answer. It may be thoughtful. It may even be useful. But it will usually soften the critique.

Sometimes that is the wrong mode.

Sometimes you need to tell it, explicitly:

do not be polite
do not optimize for encouragement
do not assume missing details are intentional
do not fill gaps unless the text supports them
treat ambiguity as a defect
treat undefined terms as a defect
treat hidden assumptions as a defect
be harsh, direct, and specific

That changes the quality of the feedback.

The goal is not abuse. The goal is objectivity.

You want the model to stop saying, “This is a strong start,” and start saying, “This section fails because it depends on context not present in the document.”

That is far more useful.

What I ask it to evaluate

When I do this, I usually want the model to answer questions like:

Can you explain this system from these files alone?
What assumptions are missing?
Which terms are overloaded, vague, or undefined?
Where do the documents contradict each other?
What would an implementation agent still not know?
Which sections sound precise but are actually ambiguous?
What depends on prior chat context rather than written material?

That is the audit.

If the model can only understand the system because I already taught it the system in conversation, then the documents are not done yet.

The shift in mindset

This is the big change:

Stop using AI only as a builder. Use it as a hostile reader.

That does not mean every interaction has to be adversarial. Early on, collaboration is useful. Exploration is useful. Drafting is useful.

But once the docs are supposed to be real, you need a different posture.

You need something closer to:

Read this as if you were a new engineer, a coding agent, or a future version of me with no extra context. Then tell me what breaks.

That is where the quality bar rises.

What good feedback looks like

The best feedback is not vague negativity. It is precise pressure.

Good critical feedback sounds like this:

“This term is used three different ways.”
“This section implies authority, but never defines the source of truth.”
“The phase boundary is unclear.”
“This interface description is incomplete because input shape is missing.”
“This workflow only makes sense if the reader already knows the unstated constraint.”

That kind of criticism is gold.

It tells you exactly where your design is still living in your head instead of in the docs.

Why this matters before implementation

Once code generation starts, ambiguity gets expensive.

A coding model will happily turn vague documents into concrete code. That is the danger. It has to choose something. If your design artifacts are unclear, the model will still produce output, but that output may reflect assumptions you never intended.

That is why I want brutal feedback first.

I want the documents attacked before I ask for implementation.

If the docs survive that, then they are much more likely to guide coding tools well.

The takeaway

Here is the workflow:

Build the design documents
Move them into a clean context with minimal extra history
Upload only the files that should define the system
Tell the AI to stop being nice
Ask it to identify ambiguity, contradiction, and hidden assumptions
Fix the documents
Only then move toward implementation

AI is useful when it helps you draft.

It becomes far more useful when it helps you detect where your draft is lying to you.

Not just using AI to help me think.

Using AI to tell me, bluntly, where my thinking is still not good enough.

What’s your approach to getting brutally honest feedback from AI?

I Don’t Start With Code Anymore

Robert Love — Tue, 31 Mar 2026 03:14:31 +0000

How I Use AI to Design Software First

Many developers want AI to jump straight into the code.

I don’t.

Before I ask any tool to implement something, I work the problem out in words first. I use AI as a design partner before I use it as a coding assistant. That shift has had a bigger impact on my results than any specific model or tool.

My toolset

My setup varies between home and work, but the pattern stays the same:

Home	Work
ChatGPT Plus	Gemini Pro
GitHub Copilot	GitHub Copilot
Codex	N/A
Claude Code	Claude Code

These tools are not interchangeable. I use them differently depending on the stage of work: discussion first, implementation second.

The real leverage comes before code

Most AI-assisted development starts too late.

People bring AI in once they are already in the code and expect it to figure everything out. But the hard part is usually earlier, when the idea is still unclear and the boundaries are not defined.

Before I ask for code, I want clarity on:

the problem I am solving
system boundaries
consistent terminology
what belongs in scope vs later
assumptions that will cause drift if left implicit

If I solve that first, everything downstream improves.

My workflow

1. Start in chat

I begin in ChatGPT, usually using voice.

That lets me move quickly through ideas, constraints, edge cases, naming, and structure. At this stage I am not asking for code. I am shaping the system.

2. Turn it into documents

Once the idea stabilizes, I convert it into Markdown:

vision
vocabulary
goals and non-goals
system overview
interfaces
roadmap

The goal is not code generation. The goal is clarity.

3. Design before implementation

I do not rush into the repo.

I want the architecture, terminology, and constraints clear enough that implementation becomes execution, not invention. Better design leads to better prompts, which leads to better code.

Existing code still matters

This is not just for greenfield work.

If I have an existing codebase, I will often zip up the relevant parts and bring them into ChatGPT early. That gives me a baseline for discussion:

what stays the same
what changes
where the boundaries are weak

It is not perfect for code navigation, but it is extremely effective for shaping changes before implementation.

Why this works

The main benefit is reduced drift.

Because the design is already defined, I do not have to re-explain everything in every prompt. I can give focused instructions:

Implement feature X using these constraints. Do not expand scope. Preserve terminology.

That is far more reliable than asking a model to infer everything from scratch.

How I think about the tools

I group tools into two categories:

Discussion tools (ChatGPT, Gemini): explore ideas, refine design, produce artifacts
Implementation tools (Copilot, Codex, Claude Code): execute against a defined design

Most frustration comes from using the wrong tool at the wrong stage.

What changes when I move to code

By the time I start implementation, the system is already defined.

That usually means:

less drift
fewer corrections
better consistency

The model is no longer guessing what I want. It is executing against a plan.

The takeaway

My workflow is simple:

Talk through the idea
Turn it into design documents
Bring in existing code when needed
Use those artifacts as the source of truth
Then implement

AI is not just a code generator.

Used well, it is a design amplifier.

And the clearer the design is up front, the better the code tends to be.

Hello, I’m ForgeMechanic

Robert Love — Sat, 28 Mar 2026 20:03:19 +0000

I’m Robert Love, a software architect and builder working in public under ForgeMechanic.

I already have a handful of open source projects on GitHub, and behind them I have thousands of lines of code and a number of programs that I expect to open source over time. Some of that is ready now. Some of it I’m still hesitant to put out before I better understand how people respond and where the right collaborators might be.

A big part of why I build is personal. I want to significantly improve how we interact with our systems, especially through disability-aware design that can also unlock better, faster, and more powerful ways for able-bodied developers to work.

I live with Parkinson’s, which makes typing difficult, and I’m blind in my right eye. Because of that, I do about 90% of my work through voice and AI. That has pushed me to think differently about input, control, accessibility, and what better human-system interaction could look like.

This space is where I’ll be sharing architecture notes, experiments, prototypes, and lessons learned as I build in the open. I’m also hoping to connect with people who care about similar problems and may want to collaborate long-term on open source tools, systems, and ideas.