A developer relations engineer builds examples and tools that help other developers understand a system and make their own implementation choices. My projects include academic-paper retrieval, generative-video evaluation, spatial video experiments, and AI agent demonstrations. The most useful output is an example whose behavior another developer can inspect.
A research tool makes retrieval concrete
I built an academic-paper analysis and generation system around a collection of 5,634 IEEE Access papers from 2025. In the project write-up, I reported extracting 225,855 references. Those figures describe that corpus and extraction run. The engineering lesson is how the information travels through the system.
The pipeline prepares documents, preserves their structure and metadata, creates searchable representations, retrieves relevant passages, and uses those passages to support an answer. The source information matters throughout. If a chunk loses the identity of its paper, the final answer becomes harder to inspect even when it sounds coherent.
I also included a paper explorer and draft-generation workflow. For teaching RAG, I would begin with the retrieval path before adding those features. Ask one narrow question, inspect the retrieved passages, and then compare the generated response with them. That gives a developer a way to evaluate each stage independently.
Explain what belongs to the application
The project repository is the next place to look after the demonstration. In a RAG application, retrieval settings, document preparation, and citation presentation are application choices. A language model receives the context that the system gives it. Explaining those responsibilities makes an example easier to adapt.
My recommended review starts with a small set of questions whose supporting passages are known. Record which passages the system retrieves, whether the response uses them appropriately, and whether the displayed citations lead back to those passages. Keep retrieval quality and answer quality separate so each change has a clear purpose.
This is a proposed evaluation method for extending the project. It gives a developer something more useful than a single attractive answer to compare between versions.
Build experiments that make evaluation visible
In my generative-video cost study, I compared five models using 63 generated videos and 32 human evaluators. The accompanying code and data repository gives readers another kind of engineering artifact: a record of how an evaluation was conducted.
For DevRel, the useful teaching opportunity is the relationship between a measurement and a decision. A team choosing a video workflow may care about visual quality, generation time, cost, or ease of use. Those criteria should remain visible rather than disappear into one score. Results from a particular study describe its models, settings, and sample.
When extending an experiment, I want the comparison to preserve the input task and document any changed conditions. That makes the next result interpretable. It also gives an audience a concrete way to ask whether the experiment resembles its workload.
Use personal builds to explore a different technical question
At a spatial-intelligence hackathon in San Francisco, I built a scene using a generated reference image, World Labs’ Marble, my own footage, and a Tripo AI double. The project explored how a persistent environment changes the process of making multiple shots.
That is a different question from document retrieval. Here, the teaching artifact should show camera movement and what stays consistent between shots. A diagram can explain the sequence, while the build video shows the visual result. The reader gets a concrete reason to choose each format.
Package the engineering for the next developer
For a reusable example, I want a clear task, setup instructions, sample input, observable output, and a short explanation of the choices. I also want a small extension exercise. Change one retrieval setting, use a different input, or adjust a camera path. Tell the reader what to observe.
My test is whether another developer can explain the system after trying it. If they can point to the part responsible for the behavior they want to change, the example has become useful engineering education.
Questions readers ask
What should a DevRel engineer portfolio include?
A working technical example, a readable explanation, and a clear account of the author’s contribution. Include the environment and intended result so another developer can assess the project.
Are demos and documentation engineering work?
They can be. Building and validating an integration requires technical judgment, while documenting its behavior requires understanding what the system does. The balance depends on the project.
How much production detail belongs in a demo?
Include the details required to understand and evaluate the demonstrated task. Explain the example’s scope so readers can identify the additional work their application needs.
