Using AI to Build a Blazor App 2: Define the Requirement

Knowing roughly what you’re aiming for is one thing, but sooner or later you need to get clear on the specifics. What’s the feature you’re actually aiming for?

AI will build whatever you ask it to, so you’d better ask for the right thing.

Last time, we saw how to use AI to dig into a problem and define the rough shape of a viable solution. By the end of that session, we’d decided to keep things simple: a markdown editor that works directly with MDX files, a way to draft the corresponding newsletter emails and a publishing workflow to make the article live on the web.

We’d avoided heavy technical discussions, UI design or carving out specific features, and ended up with a number of decision records (markdown) which captured the decisions we made along the way. Now we needed to get more specific and figure out which feature to build first.

Here’s the prompt I tried this time (using GPT 5.5).

We previously worked through an ideation process for this new project and captured key decisions as ADRs on disk. Please now work with me to carve out the headline feature we want to build first, that we think has the best chance of delivering the value we carved out in phase 1. We know what we’re trying to build and why, now we want to make this concrete by figuring out what this core feature is. Do not get into specific implementation details here. The goal is to shape the feature (mapping to the decisions we’ve already made).

Ask me questions, one at a time, to flesh this out enough that we can later define our first behavioural tests, which will then drive implementation.

For each question, include your recommended answer.

By no means is this a perfect prompt, but the key thing I wanted was for GPT to focus on the headline feature—the thing we can build that will deliver the greatest value (to address the problem we identified in Part 1).

To avoid getting into the technical weeds at this stage, the instructions are to stay firmly in “what can the user do, and what does it achieve” territory. Just as with Part 1, this flushed out some crucial details.

For example, GPT asked how I wanted the flow between writing an article and then drafting its related newsletter to work.

I realized I didn’t want this to be a linear process (write article, prepare newsletter) but more of an editing surface where I could jump between the two.

I’d say the prepare newsletter can happen any time, I might potentially work on the article, then mid-writing realise I’ve got the hook for the newsletter and decide to jump over there to draft that (or at least capture it). So it’s not linear

To which GPT responded:

That’s a useful constraint: the headline feature is not a linear wizard. It’s an article workspace with a linked newsletter draft available at any time, plus a deliberate publish action when the blog post is ready.

Recommended shape: every article has a companion newsletter area that can be opened whenever inspiration hits. It can hold rough notes, hooks, or a near-final email. Publishing the blog post later gives that newsletter draft the final URL it needs.

We dug into details around how any AI assistance might work with the newsletter editor. I don’t like the idea of AI writing content for me, but would be happy to use AI for hook and subject line suggestions.

Next question: how should the app present those hook/subject suggestions so they help without taking over?

I answered:

I think maybe options for the user to generate hooks, generate subjects etc. then a way to take one and use it (or get new ones if they’re no good)

GPT:

That gives the assistance a clean role: explicitly requested idea generation for newsletter framing, with user-controlled insertion.

We covered a lot of ground in this chat, including:

• When you mark a finished article as ready to publish, should the feature generate the newsletter draft automatically?
• When you begin the publish article action, what guardrails should the app check before it lets you proceed?
• When the blog post is published, what should happen to the newsletter draft automatically?
• What is the main user-facing promise of this headline feature in one sentence?

AI Recommended Answers

In the prompt, I’d asked the LLM to include its recommended answer when asking questions.

This seems “off” at first (surely that’s your job, as the human!), but it turns out to be quite helpful.

There is a danger that you’ll just start accepting what the AI suggests because it’s the easiest option, so it’s worth thinking carefully about what you really think before blindly accepting its recommendations. But in many cases the AI gets it right, or close enough that you can tweak it and move on.

One of the biggest challenges with defining scope is being clear what not to build.

On this occasion, GPT caught this, finishing with this question:

Before we stop, one final shaping question: what would be explicitly out of scope for the first version of Article Workspace?

• Social posts.
• Newsletter sending/scheduling.
• Full AI article generation.
• Complex idea inbox or content pipeline states.
• Analytics beyond simple publishing visibility.
• Multi-user/productized workflows.
• Deep DevScribe/Bento integration.
• Rigid streak mechanics.
• Implementation-specific Git UI details beyond a deliberate publish action.

It’s tempting to think that, with AI, we could include some of these and let it go at them. But we still care about code quality and building features that work, and the best way to do that with LLMs is to be specific and reduce how many things we ask it to do at a time.

So I agreed with all of these being out of scope and we settled on this shape for the headline feature.

# Headline Feature: Article Workspace

Article Workspace lets you capture an idea, develop it into a Markdown article, prepare a companion newsletter draft, publish the blog post to Astro, and keep the email follow-up visible so the audience receives useful value and the weekly publishing rhythm builds trust over time.

## Core Happy Path

You open the app, capture a useful idea with why it matters, immediately get a draft article workspace, write the Markdown article, optionally draft newsletter hooks, subject, and body alongside it, confirm publish readiness, publish the blog post to Astro by marking it not draft and committing/pushing, then see the final URL available to finish the linked newsletter draft for separate sending.

## Key Boundaries

- Idea capture is the earliest form of a draft, not a separate workflow.
- Capture requires the idea plus why it matters / what is at stake / angle.
- The “why it matters” note stays visible near the editor, not inside the published article by default.
- Newsletter writing can happen at any time, not only after the article is finished.
- AI assistance is limited to optional hooks and subject-line suggestions.
- Blog publishing and newsletter sending remain separate deliberate actions.
- Blog success means the article is in Astro source, marked not draft, committed, and pushed.
- Newsletter success means subject/body are ready, reviewed, and have access to the final article URL unless sending the full article verbatim.

## Out of Scope For First Version

Social posts, newsletter sending/scheduling, full AI article generation, complex idea inbox or pipeline states, broad analytics, multi-user workflows, deep DevScribe/Bento integration, rigid streak mechanics, and implementation-specific Git UI detail beyond a deliberate publish action.

One last step, I asked GPT to capture this and it chose to record a new ADR.

It could be that ADRs aren’t the right tool here (using them for everything feels like we might be over-simplifying how we capture requirement details), but in the interest of pragmatism I chose to accept it and move on to the next stage.

Measure Twice, Cut Once?

Let’s address the elephant in the room. When you work through a process like this (with or without AI), it can feel like a lot of effort up front. The temptation is to bypass this stage. Wouldn’t it be quicker to simply throw a prompt at Codex and hope it sorts it out for us?!

In short, not really.

With the prompt-and-pray approach, you might feel like you’re going faster, but this thinking, scoping and being clear about what you’re building is going to happen somewhere.

The danger of jumping straight to prompt is you’ll end up with something that doesn’t solve the problem. Or you’ll spend much, much longer iterating to the solution because the thinking is happening as new code is written.

LLMs work best with smaller amounts of information in their context window (fewer tokens). If you can break the work down ahead of time, you can keep your context minimal for each small step.

If you start with wide-open scope, you’ll find yourself throwing more and more features at the problem (because building stuff is fun!). But the real goal here is to take the smallest step, in order to get feedback (from real users).

I’ve found this up-front thinking work pays dividends down the road.

But rather than take my word for it, give it a go for yourself. Get that impulsive part of your brain to take a back seat for an hour or so while you work with AI to get clear about what you’re building.

Then, when you’re ready, move on to the next step: figuring out what to build first and what that should actually look like. We’ll get into that in Part 3.

We’ll also discover how some old techniques, borrowed from a classic software development playbook, make AI work better too.