DEV Community: ArthurJ

AI‑Assisted Writing as Search (Not Draft Generation)

ArthurJ — Sun, 14 Dec 2025 06:41:17 +0000

I have a steady stream of ideas I genuinely want to explore.

And yet most of them die in the same place: a few bullet points in a notebook, or an outline in a repo.

In my case it literally looks like files named things like:

projects/personal/ideas/2025-12-10-blog-post-second-brain-experience.md
projects/personal/ideas/2025-12-13-ai-writing-process.md

They weren’t nothing. They were real attempts.

But they rarely turned into something I could publish.

Not because I had nothing to say but writing (for me) had become a fragile, synchronous activity:

I need long, uninterrupted time to polish.
I need peers to push back in real time.
I need enough confidence in English (and honestly, even in French) to feel the result was “worth reading.”

Those conditions don’t reliably exist in my life.

I’m a founder with a family. Time comes in fragments. I also don’t live in a dense tech ecosystem where you get daily, high‑signal pushback by osmosis. So ideas would keep looping in my head… and I’d keep not shipping.

This post is the workflow I built to fix that.

It’s opinionated, but not performatively confident. And it has a simple thesis:

One useful way to think about writing is as a search problem.

AI is useful when it helps you explore the search space (multiple framings, objections, structures) before you commit.

Promise (under my constraints): when time is fragmented and I don’t have editorial peers on tap, this workflow reliably turns “looping idea noise” into a draft I’d actually be willing to share. It does this by expanding options first, then forcing precision before polishing.

Who this is for: people with ideas, limited uninterrupted time, and limited high‑signal pushback.

Who this is not for:

If you already have strong editorial peers and deep uninterrupted time.
If your main goal is “prettier prose” or a polished AI voice.
If your goal is SEO/marketing outcomes.

A quick epistemic note

I try to label important statements as experience, opinion, assumption, or verified.

In this post, most claims are experience or opinion. When I say “this works,” I mean “this works for me under my constraints,” not “this is a universal method.” (Full taxonomy in Appendix A.)

The real failure mode: committing too early

If you’re busy and you have ideas, the default “one‑draft” AI workflow is tempting:

Prompt a model.
Get a passable draft.
Edit a bit.
Publish (or don’t).

My opinion: this fails in a subtle way.

It collapses the space too early.

If you accept the first coherent framing you see, you miss the alternative theses you didn’t think to ask for. You also miss the objections you would have discovered in a real debate. The result may be fluent, but it’s often shallow or generic.

When I say “writing as search,” I mean:

There are many plausible ways to frame an idea.
Your first framing is rarely the best one.
The work is not producing text; it’s choosing what you actually believe.

Why “search,” specifically?

Other metaphors are available: writing as sculpting (remove excess), writing as iteration (revise until good), writing as dialogue (respond to an imagined reader).

I still use “search” because it emphasizes a trade‑off that matters under my constraints: backtracking is cheap before commitment.

If I haven’t spent three hours polishing Draft A, it’s easier to abandon it when Draft B reveals a better thesis.

Caveat: this isn’t “free.” It shifts the cost from writing to reading (and attention). You pay a reading tax to avoid paying a polishing‑the‑wrong‑draft tax.

That’s the workflow: separate two modes.

Exploration: expand the space of possible essays.
Commitment: pick a framing and make it honest.

The 5‑step loop (plus an optional 4.5)

Here’s the pipeline I run (the folder structure in this repo mirrors it):

Raw dump (fuel)
Perspective expansion (parallel drafts)
Synthesis (selection + compression)
Human clarification (where truth enters)
Integration (write the draft)

Optional:

4.5. “What would X say?” critique (objection generation, treated cautiously)

The steps sound straightforward; the point is where you put the effort.

My experience is that Step 4 (human clarification) is the highest‑leverage part. It’s where I stop hand‑waving. Steps 2 and 3 are what make Step 4 possible.

Pipeline in one line:

Raw dump → Parallel drafts → Synthesis → Human Q&A → Draft

Step 1: Raw dump (give the system real fuel)

A raw dump is not an outline. It’s not a prompt. It’s closer to a messy interview with yourself.

Experience: I often start as a voice note (because typing feels like “writing,” and writing triggers perfectionism).

What goes into the raw dump:

What happened (the event) and why it matters to you.
What you currently believe.
What you’re unsure about.
What you’re optimizing for (clarity? novelty? persuasion?).
Constraints (time, audience, sensitivity).

Example from this post (grounded): my “raw dump” literally began as a process spec:

“A technical blog post about a systematic approach to writing better technical blog posts…”
“Step 1: Raw Information Dump”
“Step 2: Multi‑Model Perspective Expansion”

That’s a common trap: the “workflow post about workflows.” If your raw dump is thin, everything downstream becomes generic. It is purely procedural.

Step 2: Perspective expansion (generate full drafts, not bullets)

This is the step I used to avoid.

I would ask one model for an outline, accept the first structure, then start writing. The result was always thin. It was coherent enough to publish, but it missed the alternative framings I didn’t know to ask for.

Now I generate parallel drafts: multiple full essays from different models (or different prompts/lenses).

Why full essays?

Because a complete draft forces:

a thesis
definitions
transitions
a conclusion
an implicit set of assumptions

A bullet list can hide all of that.

Experience: I typically run 3–4 models. Not because it’s magic, but because it’s where I personally hit diminishing returns: fewer often converge too quickly; more rarely adds genuinely new structure for the extra reading time.

What I look for when comparing drafts (practical checklist):

Which draft makes the strongest claim (and what does it assume)?
Which draft surfaces the best objections?
Which draft has the cleanest structure (even if the content is wrong)?
Which draft feels most “alive” (specific constraints, real stakes)?

Important: I don’t treat these drafts as “the answer.” I treat them as:

alternative framings I didn’t think of
objections I didn’t anticipate
better structure than my default
phrasing I might reuse only if it matches what I mean

If you only have one model

If you only have access to one model, you can still do perspective expansion by forcing lenses across three passes:

Skeptic: strongest objections + missing caveats
Teacher: simplest explanation + concrete examples
Editor: structure + cuts + “what should be removed?”

Step 3: Synthesis (curation, not averaging)

After the parallel drafts, I do a collapse step.

Most people hear “synthesis” and imagine “merge paragraphs.”

A safer claim (and my real experience): the temptation is to average everything into one polite post. That usually produces blandness.

My opinion: synthesis should be opinionated.

It’s selection + compression:

Extract the strongest claims.
Surface disagreements.
Identify what needs evidence.
Propose a narrative shape that could actually carry the post.

Example from this post (grounded): my synthesis flagged the core risk:

“The missing ingredient: a concrete event… Without a real event/case study, it reads as generic advice.”

That forced a decision: the post couldn’t just be “here is a pipeline.” It needed to be grounded in the repeated event of ideas dying as outlines under my constraints.

Step 4: Human clarification (answer questions like an interview)

This is the step that turns “sounds right” into “is right.”

After synthesis, I have the model ask me targeted questions.

Not “what else should I add?”

But questions that force precision:

What was the triggering event?
What exactly failed in the old process?
What are you not claiming?
What would falsify this?
What are the hallucination risks?

Then I answer like I’m being interviewed.

Experience: this feels like an async podcast episode. It gives me the pushback I don’t get locally.

What changed for this post (a concrete transformation)

Here’s a literal before → question → after chain from this post.

Before (raw/spec voice): “A technical blog post about a systematic approach to writing better technical blog posts using AI models…”
Clarification question: “What was the triggering event?”
After (draft voice): “I have a steady stream of ideas… And yet most of them die… I’m a founder with a family. Time comes in fragments… I don’t live in a dense tech ecosystem…”
What changed: the post stops being a workflow diagram and becomes an explanation of why I need this workflow: it substitutes for missing pushback and makes exploration possible in fragmented time.

This is why I call Step 4 “where truth enters.” The model can generate structures and objections, but it can’t supply my constraints. If I don’t answer precisely, the post becomes confidently generic.

Step 5: Integration (write the draft you actually want to read)

After Step 4, you have something most writing processes don’t reliably produce: a clear set of constraints and editorial decisions.

Now you write.

This is where you:

choose one framing (and discard others)
insert real examples where they do argumentative work
add caveats and “unknowns” instead of smoothing them away

Experience: I stop when I read the draft and genuinely enjoy it.

What does “enjoy it” mean concretely (for me)? Three signals:

I can read the draft without wincing at any sentence.
There’s at least one idea that surprised me. It’s something I didn’t know I thought until I wrote it.
I’d send it to someone whose judgment I respect without prefacing it with “sorry this is rough.”

If I don’t hit that bar after one loop, I often choose not to publish rather than turning it into a multi‑week project.

Caveat (non‑negotiable): the evidence for this workflow is entirely self‑reported. I haven’t run controlled comparisons, I haven’t measured reader outcomes, and I don’t have reliable external feedback. The claim is “this feels better to me under my constraints,” not “this is objectively better.”

What this is optimizing for (and what it isn’t)

Let me make the trade‑offs explicit.

Optimizing for

Novelty (opinion): compressing an idea until there’s at least a small “new” thing inside.
Conversation (experience): getting pushback and alternate framings without needing synchronous peers.
Momentum (experience/opinion): turning “idea noise” into “idea clarity” in short, fragmented sessions.
Cost Opportunity efficiency: The whole loop, with 3 revisions, using frontier models costed me 3US$ and about an hour focused on the idea (The CLI and workflows were already built prior). I never wrote anything that fast (of reasonable quality).

Not optimizing for

Perfect prose (opinion): the writing may still feel rough or “AI‑ish.”
Automatic truth (non‑negotiable): this does not replace research, benchmarking, or fact‑checking.
Guaranteed speed/quality (non‑negotiable): sometimes exploration expands the problem space and you still decide not to publish.
Marketing outcomes (non‑negotiable): this isn’t about attention or becoming famous.

Guardrails and failure modes

This workflow can help you think. It can also help you be confidently wrong.

Minimum safety protocol (use even for casual posts)

Label important claims (experience/opinion/assumption/verified).
Keep a “things to verify” list as a first‑class artifact.
No attribution (“X said…”) without a source.
For technical claims: do separate validation work (experiments/citations/peer review).

Failure mode 1: hallucinated authority

The biggest risk is that fluent text smuggles in fake certainty.

Common offenders:

performance claims (“X is fastest”) without benchmarks
invented timelines
misattributed quotes without sources

Mitigations I use (experience/opinion):

Keep epistemic labels.
Maintain a “things to verify” list.
Prefer narrow, attributable statements.

Failure mode 2: genericness via weak grounding

If you skip the event and constraints, everything becomes “AI transforms writing.”

My opinion: a process‑only post is almost always less compelling than a story‑backed one.

Mitigation: include an artifact trail (even a tiny one):

raw dump excerpt
contrasting draft theses
synthesis bullets (tensions, missing evidence)
what changed after clarification

Failure mode 3: process tax

This pipeline adds steps.

And yes: the timeboxed loop below is often ~60–80 minutes.

My experience/opinion is that it’s still worth it when the alternative is spending three scattered evenings polishing the wrong idea, or never shipping at all. The efficiency gain is often in discarding bad paths early, not in “typing faster.”

Mitigations (experience):

Timebox sessions to your real life (kid asleep, late night).
Stop after one loop if it’s “good enough.”
Save artifacts so future posts get easier.

Failure mode 4: deep technical claims without verification

For highly technical writing (benchmarks, correctness proofs, security claims), this workflow can produce plausible nonsense.

Opinion: treat it as idea refinement, not validation.

If you need rigor, add separate work:

experiments
citations
reproduction steps
peer review

A minimal “do this tonight” recipe

If you want to try this tomorrow, don’t copy my whole setup. Do the smallest viable loop.

Timeboxed loop

10 minutes: voice‑note raw dump
- what you believe
- what you’re unsure about
- what you’re optimizing for
10–20 minutes: generate 3 full drafts (different models, or the same model with different forced lenses)
10 minutes: synthesize
- best claims
- disagreements
- “needs evidence” list
30–45 minutes: answer clarification questions like an interview (voice works well)
Stop: when you hit your “enjoy it” bar; publish or save as an internal memo

Even if you don’t publish, you’ve converted a looping idea into a clearer artifact.

Closing: ship artifacts, not perfection

I built this workflow because I wanted a repeatable way to turn “ideas I can’t stop thinking about” into “ideas I can actually examine.” I needed it under real constraints: language, isolation, and fragmented time.

My strongest claim here is simple (opinion): use AI to explore the space before you commit.

Use AI for expansion (parallel drafts), not for authority.
Use synthesis to curate, not average.
Use human clarification to keep yourself honest.

If you’re someone with too many ideas and too little uninterrupted time, try one loop.

You don’t have to become a better prose stylist overnight.

You just have to build a process that makes thinking possible again.

Appendix A: Epistemic status taxonomy

I try to label important statements with one of these tags:

Experience: something I personally observed/did.
Opinion: a value judgment or preference.
Assumption: plausible but not verified.
Verified: backed by a link, benchmark, or citation.

Appendix B: Optional Step 4.5 (“What would X say?” creator critique, experimental)

I’ve experimented with an extra loop: simulate critique using a corpus of a creator’s past takes.

I’m not sure I love it yet.

So I treat it as optional. I treat it as objection generation, not truth.

Non‑negotiable safety rules (opinion):

No attribution without a link/source.
Explicitly call out context mismatch and possible staleness.
Human must approve/reject anything incorporated.

Also: if this ever became more than a private tool, I’d want creator buy‑in; otherwise it can drift into “abuse” territory.

Appendix C: Prompt shapes (rough, but runnable)

Use whatever tool you like. The important part is the shape of the prompts.

Perspective expansion (run 3 times):

Read raw.md. Write a full essay draft.

Pick a thesis and make it explicit in the first 10 lines.

Define 3 key terms you’re using.

Include at least 3 objections (steelman them).

Flag any claim that needs evidence.

If you’re about to generalize (“most people…”), rewrite as the author’s experience or delete.

Keep epistemic honesty: don’t invent facts.

Synthesis:

Given the 3 drafts, produce:

the best 3 thesis options

the strongest claims (with which draft they came from)

disagreements/tensions

“needs evidence” list

10 clarification questions for the human

one recommended narrative spine (and why)

Clarification questions:

Ask me at least 15 targeted questions.
Prefer questions that turn vague sentences into concrete, falsifiable statements.

Integration:

Write draft.md using raw.md, synthesis.md, and answers.md.

Choose one framing.

Add explicit caveats.

Keep what is true; remove what is only plausible.

Do not add quotes or attributions without sources.

Implicit CSS Grid, 301 & 305

ArthurJ — Sun, 01 Mar 2020 13:28:04 +0000

Skipped last week's post because I changed job, and adaptation is still in full force. You might have seen it in the videos, which are now one take without prep, and are about 50% longer. Sometimes, shipped is better than perfect!

Here we are, at the end of this series on CSS grid, exploring the concept of implicit grids.
So far, all of our layouts have been strictly defined using grid-template and grid-area, which is great for static layouts, but it's only half of the equation. Dynamic ones needs a little bit more flexibility, guiding the browser to place items rather than placing them ourselves.

The first 5 videos are about constructing a dummy login/register modal, with the columns defined and rows handled implicitly by the browser.

The last 5 are about building a gallery, with 3/2 horizontal images, 2/3 vertical ones, 2/2 squares and 1/1 fillers, without having to calculate optimum layouts' placement. Oh! and did I mention it's fully responsive, without media queries?

In the next few weeks, I'll be answering questions that I received during this series about CSS Grid, you can expect maybe 1 or 2 videos per week at this point, depending on schedule. Feel free to ask more here or tweeter, I'll try to answer as many as possible!

After that It will be time to move on to another subject, if you have any suggestion, I would like to know from you if there's a subject you feel should have a bit more exposure! So far, I'm planning a series on State machines, images handling, HTML node performance costs & HTML performance in general.

As per usual, you can check the code on GitHub, one branch for every video

link to the full playlist here

-1 track line trick

Centering with Grids, place-content, place-items & place-self

Introduction to the implicit Grid

Filling out the login form

Set default height of the Implicitly created rows

Creating our Gallery

Using auto-fit & auto-fill for responsiveness

Ordering items

creating our vertical/horizontal/square items

Densely pack our gallery in one property

CSS Grid 201, let's get technical

ArthurJ — Sat, 15 Feb 2020 14:22:36 +0000

So last week, I presented my way of talking about CSS Grid, focused on being simple to understand and visual. This week, we are going to go a bit deeper under the hood!

As much as I think that using track numbers is unfriendly, it's still super useful to know how they work, especially before entering the "dynamic" part of the series next week.

You will find below a walk through of how to place items using the track lines, area lines, all the shorthands you will need and as a bonus, how to overlap items!

link to the full playlist here

Under the hood

Spanning multiple rows/columns

Using our named areas as tracks

Hooking to multiple areas and span across them

Overlapping items

Reduce code verbosity with shorthands

Learning CSS Grid the easy way

ArthurJ — Mon, 10 Feb 2020 14:26:39 +0000

For those who know me a little, I've always been that weird friend/colleague excited about CSS Grids and trying to push them for layout. But usually the answer is: "I don't know, CSS grids seem kind of complicated".

I always was conflicted about that answer, because I always felt Grids were really easy to get into, and they would be the clear way of doing things if we hadn't been going around breaking the flow of the pages for the past many years.
But recently I wanted to find tutorials to share and spread the Grid love all around. And to my surprise, every tutorial begins with the same description of the spec, and how to set a grid and place items in it by number. You end up having something like that as a "hello world":

.container{
  display:grid;
  grid-template-rows:repeat(4,1fr);
  grid-template-columns:repeat(3,1fr);
}
.header{
  grid-area: 1 / 1 / 2 / 4;
}
.footer{
  grid-area: 4 / 1 / 5 / 4;
}
.content{
  grid-area: 2 / 2 / 3 / 3;
}

Not very welcoming and intuitive if you ask me. I believe this is the reason people assume Grids are hard! I mean, even I always mix up the row/column order in the grid-area shorthand property, and I'm supposed to be the Grid guru.
The good thing is you really don't have to use it this way at all. There is a cleaner way, instantaneously understandable way to do it and it look like this:

.container{
  display:grid;
  grid-template:
    "header header  header" 1fr
    "...... content ......" 1fr
    "...... ....... ......" 1fr
    "footer footer  footer" 1fr
    / 1fr   1fr     1fr;
}
.header{
  grid-area:header;
}
.footer{
  grid-area:footer;
}
.content{
  grid-area:content;
}

It looks in the .CSS file just like it will looks in your layout. If you want to refactor it, you just have to change one property and everything falls into place. This is an absolute win for the web and us, web developers.

This being said, there's still way more to grid than just the templates and visually see your layout in the .CSS file. So I started to record a series of video, each in the 2 minutes range, around CSS Grids that I call "Noob 2 pro". My goal is to explore Grids potential from an usage-based perspective, where we use new properties for specific needs rather than just go down the list of properties like a cheat sheet.

The first part of the series is done, and being my first tutorial, it might still be a bit shaky at times, but I'm working to get it out there, I'm sure it will help some people!
Those 10 videos will make you self sufficient in static/responsive layouts using CSS grids. Then, as I add more videos, one every 2 or 3 days hopefully, push on and make you a Grid master. Soon your life will be easier!

Here is a link to the playlist on youtube

And here are the the videos:

No code here => 1. Announcement

No code here => 2. Pros/cons of CSS Grid

Code starts here => 3. Your first grid

Add your first item/cell
Add more items and gaps
Place one element by name
Place all the items by name
Shorthand grid-template
media queries refresh
Responsive Grids
Add empty cells
Refactor your UI in seconds

(kind of) Getting the memory address of a JavaScript object

ArthurJ — Thu, 28 Nov 2019 22:35:36 +0000

Hey everyone,

I am building a library for Graph Object Notation, at the moment in super early stage, and I came across a really nice "loophole" to what I imagined being the biggest obstacle of the project : Getting the memory address of the objects in JavaScript. Here is a nice post if you need a quick reminder on how memory works in JavaScript!

As you may know, you can't access them for security reasons, end of the post, thank you for reading...
...but turns out, you can cheat a little bit there. The actual address isn't really that important in my case, what's important is the consistency of the "fake address" that we will generate and make sure the same object always spits out the same address!

First though is to go on and brute force things, building an array of known Object, another of fake address and comparing every object against that array. Turns out it works, but here comes the slow library judgement.
Second though, building hashes of the object based on properties and values, then only comparing with "same hash" object, works as well, but not really efficient either.

Then came an idea.

The Map object isn't really used in the JavaScript front-end world, but it's really effective at finding if it has a key defined, and it can hold any type of data as a key. This is contrary to the Object object, where keys can only be strings.

1 + 1 = success, let's use the objects themselves as key, and the fake address as value.

Here is a short video on how it works : https://youtu.be/-ZenKpRfJdo

And the next one in a more functional programming style, with a nice triple arrow function : https://youtu.be/r7y8roTIPig

And for those not wanting to watch a video, here's the code :
(the live version is here)[https://gon.arthurj.now.sh/references]

https://codesandbox.io/s/vibrant-northcutt-wkh2e

const user1 = { name: "arthur" };
const users = [user1, { name: "arthur" }, { name: "Joe" }, user1];

//This generator doesn't garantee uniqueness, but looks way more memoryish than a incremental counter
//if you use this code for real, do incremental or something else unique!
function* generator() {
  while (true) {
    const random = Math.random()
      .toString(16)
      .slice(2, 10);
    yield `0x${random}`;
  }
}

const preload = (knowObjects, refs, generate) => (reference = false) => {
  if (reference) {
    return refs;
  } else {
    return object => {
      let address;
      if (knowObjects.has(object)) {
        address = knowObjects.get(object);
      } else {
        address = generate.next().value;
        knowObjects.set(object, address);
        refs[address] = object;
      }
      return address;
    };
  }
};

const setup = preload(new Map(), {}, generator());
const findRef = setup(false);

const array = users.map(u => findRef(u));
/*
console.log something like that, and builds up the knowObjects map / refs object
[
 "0xf094c649",
 "0x7de35306",
 "0x6a99aa2f",
 "0xf094c649"
]
*/

const refs = setup(true);
/*
console.log something like this
{
 "0xf094c649": {
  "name": "arthur"
 },
 "0x7de35306": {
  "name": "arthur"
 },
 "0x6a99aa2f": {
  "name": "Joe"
 }
}
*/