Ask Good Questions: Do not let AI build the elephant in the room

21

Fair enough. :slight_smile:

At this point, Iā€™ve been working with AI 10 to 12 hours a day, pretty much every day, for almost two years. So if some of the phrasing has started to sound AI-adjacent, thatā€™s probably not too hard to imagine.

But thatā€™s also part of what Iā€™m trying to sort out in public.

The useful question is not really whether AI was involved. The useful question is whether the final result says what I meant, whether I understood it before posting it, whether I agree with it, and whether Iā€™m still the one making the judgment calls.

Thatā€™s where I think developers have to draw the line.

Using AI to help think, draft, test, summarize, compare, or write code is one thing. Letting it replace your own understanding is something else entirely.

22

Iā€™ve seen it suggested that your claude.md file should be tiny and it should always have the instruction to ā€¦

Donā€™t make assumptions, if you are not sure ask questions

ā€¦I donā€™t know if that would help with Clarion.

Recently I have been getting Claude to write the prompts it needs to perform tasks (in svelte, not Clarion) and together with the claude.md instruction I mentioned above, this gets it to ask questions while it is planning. Then I get it to implement the prompts. I think that has made it more efficient?

23

That makes sense to me, and I do think ā€œdonā€™t make assumptions; ask questions if you are not sureā€ is one of the most useful general-purpose instructions you can give an AI coding tool.

For Clarion, though, I donā€™t think that is enough by itself.

The problem Iā€™ve seen is that the AI often does not realize it is unsure. It will confidently borrow ideas from C#, JavaScript, Python, or some generic pseudo-code pattern and then present it as if it were valid Clarion. So the ā€œask questionsā€ rule helps, but only after you also teach it what kinds of things it must not guess about.

For Clarion, I think the stronger version is something like:

  • Do not invent Clarion functions, methods, attributes, or template symbols.
  • Do not borrow syntax from other languages.
  • Do not use Clarion reserved words as variable names.
  • If a method or function is not visible in the supplied INC/CLW/EQU files, ask before using it.
  • If the task depends on project-specific coding style, ask or follow the examples already provided.
  • If unsure whether something is valid Clarion syntax, say so and ask.

I also like the idea of getting Claude or ChatGPT to write the prompt it thinks it needs before implementing. That is very close to how Iā€™ve been working. It forces the model to plan the job, surface assumptions, and expose gaps before it starts spraying code.

In my experience, the best results come from a combination of both approaches: a small set of permanent rules, plus a task-specific prompt that tells the AI exactly what files, conventions, and constraints apply to this particular change.

For Clarion especially, Iā€™d rather have it pause and ask one extra question than confidently generate beautiful-looking code that cannot compile.

24

Thats where you get the prompt knowledge back.

25

I think that is a good approach.

One thing Iā€™ve found useful is to treat the prompt itself as part of the work. Instead of jumping straight to ā€œwrite the code,ā€ ask the AI something like:

ā€œHere is the task I want to do. What information, files, rules, and constraints do you need from me to do this correctly?ā€

That turns it into a ā€œhelp me help youā€ situation.

With Clarion especially, that can be valuable because the AI may need more context than it realizes at first. It may need the INC file, the CLW file, the EQU file, the existing method names, the style rules, or an example of how similar code is already written in the project.

So having the AI help improve the prompt is not just busywork. It can expose missing assumptions before the code gets written.

I think the workflow becomes:

  1. Describe the task.
  2. Ask the AI what it needs to know before implementing it.
  3. Let it help refine the prompt.
  4. Then have it do the work from that improved prompt.

Thatā€™s where a lot of the efficiency comes from.

26

Nardus posted a link on Discord.
I havenā€™t seen it reposted here, so herewith.
Worth a read.

27

yes great read but reminds me of getting around in winter.. used to be on two planks of wood with some poles in each hand.. now snow mobile.. some people going holidaying now go to norway on a motorbike!!!

28

Thatā€™s a good article, and I think it makes an important point.

The danger isnā€™t that AI can help write code. The danger is when the developer starts getting farther and farther away from the code that is being produced.

That is especially true in Clarion.

It is very easy for an AI model to produce something that looks like plausible code, but it may be borrowing ideas from C#, JavaScript, Python, or some imaginary Clarion function that does not actually exist. Add to that if the developer doesnā€™t know Clarion well enough to spot that, then the AI has not made them more productive. It has just made the mistakes faster.

But I wouldnā€™t take the article as an argument against using AI for development. I use AI heavily, and I think it is one of the most powerful tools I have ever had.

The key is that I am still the developer.

I am still the one setting the architecture, checking the code, testing the results, and deciding what belongs in the application.

To me, the useful workflow is not ā€œturn the agent loose and hope it knows what it is doingā€. It is more like:

Use AI to help plan.

Use AI to help explain.

Use AI to help find problems.

Use AI to generate small, reviewable pieces.

Use AI to help improve the prompt.

Use AI to handle boring repetitive work.

Rinse, wash, repeat.

But donā€™t let it run so far ahead that you are no longer sure what changed or why.

That also goes back to the elephant in the room.

A developer using AI well still has to be a developer. Maybe even more so. You need enough judgment to know when the answer is wrong, when the code is too complicated, when it violated your standards, when it hallucinated something, and when it solved the wrong problem.

So yes, agentic coding can absolutely be a trap. But AI-assisted development doesnā€™t have to be.

The difference is whether the human stays actively engaged or becomes a passenger.