DEV Community: Brendan Graetz

Use Prototypes to Plan Production Software with AI

Brendan Graetz — Thu, 27 Aug 2026 02:03:15 +0000

Eight hours of planning, or fifteen minutes? Depends what you're building: Production-grade or prototype-grade.

In June, I gave a talk
at Agentic Builders Collective Singapore
about a planning workflow for building software with generative AI.
In a nutshell, it combines the grill-with-docs agent skill by Matt Pocock
with the shaping agent skills from Ryan Singer,
and runs them in a highly customised way.
The result is a PRD plus an implementation plan.
Feed those into an AI harness (OpenCode, Pi, Codex, Claude Code, …) and you get production-grade software.

The Hard Parts: Building with Gen AI

The people who tried it came back with the same verdict:
The planning took too long.

Three hours at best.
One person reported over eight.

My first fix was wrong

The obvious response was to optimise.
Fewer questions.
Tighter interviews.
Same rigour.

I attempted to tune the planning skill, while still aiming for production-grade specs.
It didn't yield much improvement.
After several iterations of failing to bring the time down, I finally understood why.

The hours spent planning were not a waste after all.

If you are genuinely planning production-grade software
(the kind a team will maintain for months or years),
then an intense interrogation of the requirements is the correct amount of work.
When humans build over months, mistakes in the plan get discovered and fixed along the way.
When an AI harness builds the entire thing in mere minutes, those opportunities simply don't surface.
The plan is the only place that errors get caught.
Of course it takes a while… it needs to!

My aha moment was the realisation that the problem was never about efficiency.
The problem was a mismatch of grades.

Match the plan to the grade

Here is the distinction I was missing:

Production-grade software deserves production-grade planning.
Three to eight hours of it, if that's what it takes.

Prototype-grade software deserves prototype-grade planning.
Fifteen minutes of it is more than enough.

Most of us don't actually need production-grade software right off the bat.
What we need, at that point, is to know what to build.
That is a different problem, which needs a completely different tool.

The right tool is an old one: Prototyping.

An old idea with new economics

Prototyping fell out of fashion because it used to be expensive:
Even throwaway software took days or weeks.
If you were going to spend that much, you may as well plan carefully and build it properly once.

Generative AI changed the economics. Radically.
A prototype now takes under an hour to plan and build, for a single developer paired with an AI harness.
When the experiment is that close to free, it makes much less sense to skip the prototype.
It is now a more valuable use of your time to build a prototype,
and use that to make a more informed plan for the software that you intend to ship to users.

If you are familiar with agile methodologies, think of it this way:
A prototype is a spike.
Except instead of spiking one risky feature, you spike the entire system.
You learn the true shape and specs of the thing you wanted to build,
not what you assumed it would be when you wrote the plan.

Order of operations:

Write five bullet points about what you want to build in a REQS.md file (requirements).
Run the prototype-plan agent skill.
Spend around fifteen minutes answering interview questions.
It produces PRD.md (product requirements document) and IMPL.md (implementation plan).
Build the prototype.

The key point here is that you intentionally spend very little time planning up front.
The idea is to build a working prototype ASAP.
This is not something you will ship to your users.
The prototype reveals to you what should go into the plan for the production-grade version of your software.
Using a prototype, you do this hands-on with a real, working application.
Without a prototype you would have had to imagine the intended application, which is a lot harder.

Skills to run in an AI harness

This entire process is now made easy and repeatable, using a few agent skills.

First, use the prototype-plan agent skill
to plan a prototype-grade version of your software.

(Next, build a working prototype using PRD.md and IMPL.md, and learn from it.)

Finally, use the build-plan-product agent skill,
then the build-plan-specs agent skill
to plan the production-grade version of your software.

What prototypes cannot tell you

An honest caveat, before you take this too far:
A prototype will not surface your scaling limits, your security model, your compliance obligations,
or the migration path from the system it replaces.
Those problems don't show up in prototypes, and no fifteen-minute interview will find them.

That is why the two grades are distinct.
The prototype tells you what to build.
Now planning can start from evidence instead of imagination or guesswork.
As you've already cut yourself on them, you know where the sharp edges are.

Prototype to learn.
Then plan and build for production.
In that order.

This post was originally published at:
blog.bguiz.com/2026/prototypes-plans-production-software-ai

DevRel now that generative AI is here

Brendan Graetz — Fri, 29 May 2026 07:48:49 +0000

Being a DevRel engineer is like being a jack of all trades, covering at least seven distinct areas.
Developer Education, Developer Success, and Developer Marketing ¹
Combined, make up 80-90% of a DevRel team’s time/ output.
Each of these areas is going to be massively disrupted by gen AI. ²
These areas will probably also be boosted by gen AI.

Developer education disruption

How is developer education going to be disrupted?
Traditional modes (tutorial docs, video demos, workshops) will become less relevant,
because gen AI can explain concepts on demand, plus do the work of coding for you.

How must developer education change because of gen AI?
Expose developer education in new channels
(agent skills, MCP servers, etc)
in addition to traditional channels like documentation websites,
and teach more relevant skills
(higher level concepts, reviewing gen AI output, etc).

The formats and approaches need to change,
because even though gen AI can “do the work” for you,
humans still need to understand what the gen AI is doing to direct it properly,
otherwise developers end up with too much “code slop” proliferating.
Instead of teaching syntax and patterns,
focus on higher level concepts,
such as judgment and architecture.
Those were always important, but there is a new skill that must be taught too:
How to review and evaluate code written by gen AI.
The way developer education material is delivered also changes:
Rather than a documentation website,
expose the same materials in different AI-native formats. ³
Examples:

Documentation search MCP tool where every result contains a citation
Full-blown guided tutorial via agent skills
Agent skills as docs as code, evolved from docs as code

Despite this disruption, developer education becomes more, not less, important.
Focus on how to reason and make decisions about code, rather than how to write it.
Developers will move up the chain, and thus developer education must follow.

Developer success disruption

How is developer success going to be disrupted?
Seeing that the “developers” writing code are now largely gen AI agents, not humans,
we scale back on the in-person events such as tech meetups, hackathons, and workshops;
and double down on virtual formats.
Especially so, when there is pressure to slash budgets in the parts of the tech industry that are experiencing a “bear market”. ⁴
It is like the COVID-era playbook is being repeated, but for entirely different reasons.

How must developer success change because of gen AI?
Do the opposite and double down on in-person events and communities,
but shift focus to doing more developer experience research on AI-native engineers.
During uncertain times, trust matters more,
and meeting in-person builds trust in a way that remote interactions do not.
Tactically, your competition is likely pulling back,
creating a vacuum for you to fill.

Remember that humans are still the ones operating gen AI tools,
and it is important for you, as DevRel,
to map out their developer journey, identify their friction points,
and resolve/ work around those.
AI-native engineers will have radically different journeys, frictions, and experiences.
DevRel faces a steep learning curve here.

Baseline developer success activities are still relevant,
so apply the same methodologies to the emerging class of AI-native developers.

Developer marketing disruption

How is developer marketing going to be disrupted?
Content marketing, social media, swag at events lose effectiveness,
as developers are using these touchpoints less in their decision making.
Their “top of funnel” (ToFu) discovery is increasingly becoming whatever their gen AI tools and agents recommend.

How must developer marketing change because of gen AI?
When a developer asks a gen AI tool for technology choice recommendations, your docs should be cited.
When a developer asks how to create feature X or fix bug Y, your docs should also be cited.
That is the winning play.

Just as SEO shaped what developers found on Google,
GEO will shape what developers' AI tools recommend. ⁵
GEO is only the tip of the iceberg though, and it is useful for getting your foot in the door.
It is the new critical path for the awareness and evaluation stages of a developer journey.
For the learn, build, and scale stages of the developer journey,
there are other means to surface your technology in gen AI tools and workflows.

Developer marketing catered exclusively to human developers.
Now it needs to cater to non-human developers too.
The latter is literally growing exponentially!
Treat them as additional developer personas.

Internal DevRel

Most DevRel teams are focused on external developers.
Rightly so, when team sizes are small.
However, the gen AI disruption is huge internally too.
The engineering team may have wildly variable levels of gen AI adoption and fluency. ⁶
DevRel teams are well placed to run the R&D,
and roll out upskilling programmes and internal tooling improvements.

Things that do not change

Which parts of developer education do not change because of gen AI?
There is something that gen AI and humans have in common when they learn:
Pattern matching.
Watching and replicating other humans is a central to how humans learn and execute.
This is very different from learning by reading text alone.

Which parts of developer success do not change because of gen AI?
The processes remain the same:
Create segments and personas, map journeys, identify friction points, and improve developer experience.
The difference is that they are now applied to non-human personas.
(As covered in the "Developer success disruption" section.)

Which parts of developer marketing do not change because of gen AI?
Do not replace the information valve approach with a marketing funnel ⁷
just because of gen AI and a fresh focus on GEO.
GEO is ToFu in marketing funnel speak.
GEO is novel and important, yet only one piece of the puzzle.
Do not neglect the basics.
Ensure that your information valve remains bidirectional.

Patterns of change

Will gen AI disrupt DevRel?
Yes, all three main functional areas are deeply affected.

Will gen AI therefore make DevRel irrelevant?
No.
A subset of current DevRel work will be minimised or sunset;
and new approaches and techniques will take their place.
Overall, there is more work to be done,
and DevRel becomes more important.

Thanks

This was largely based on a hallway conversation that I had with Mike Swift,
at AI Engineer Singapore 2026.
He put “swyx”,
instead of “swift” on his name badge,
and that was the reason we got talking, crazy huh?
Glad we did!

Thanks also to Owanate Amachree and Fabian Hug for your reviews and comments!

This post was originally published at blog.bguiz.com/2026/devrel-now-that-gen-ai-is-here

Developer documentation, developer tools, developer community, and strategy.
Read Developer Relations, by Caroline Lewko and James Parton
for detailed descriptions.

GEO is to ChatGPT as SEO is to Google.
Note that GEO is also known as AEO, which is Answer Engine Optimisation.
Reference: GEO - Wikipedia.
Note that in-person activities are still relevant;
see the "Developer success disruption" section.

The Marketing Funnel Applied to Developer Audiences

However, DevRel’s ability to impact these teams is more limited.

Apart from developer education, developer success, and developer marketing, the other areas within developer relations are: ↩
As are all white collar jobs, eventually. ↩
Pioneering examples: Mintlify for with-citations documentation search MCP tool. Mastra for guided tutorial via agent skills. PaperMoon for agent skills as docs as code. ↩
This includes almost every part of the tech industry other than AI, in 2026. ↩
GEO is Generative Engine Optimisation, and is distinct from SEO (Search Engine Optimisation). ↩
This also applies to other teams within the company too, of course. ↩
Read about the relationship between marketing funnels, information valves, and developer journey maps: ↩