DEV Community: Monday Romelfanger

The Future of Working with AI — A Human-Centered Collaboration Model

Monday Romelfanger — Sun, 04 May 2025 00:00:00 +0000

The Friction of Current AI Tools

At the start of 2025, I worked as a software engineer at a tiny AI data analytics startup. I was fighting with AI on two fronts: how to provide valuable features for our customers and how to use AI tools for my work. Both somehow seemed intractable. Our customers weren't valuing the insights we were generating; I was introducing all kinds of defects I would have caught before relying on AI tools.

I left that company in February and spent the next few months deep-diving into understanding what was going wrong. For myself, I adopted a no-code-writing rule and worked on several projects. I talked with people across various disciplines, such as Devs, PM, marketing, and DevOps, about how they use AI tools and where they feel frustrated.

Along the way, I found some common themes: people feel less engaged and in control of their work when using standard LLM-based tools. Some people are learning how to work around this, others are either avoiding them altogether or using them minimally. That pattern is not the path to realizing the full potential of AI for work.

Pillars for AI-Human Interaction

Reflecting on the conversations, my own experience, and research around human collaboration, I've developed these five pillars:

Human‑First Purpose

Every feature starts with a concrete human need and ends with greater human agency. AI success is measured by how well it amplifies people, not how many tokens it generates or how long it works without human intervention.

Native to Human Communication

Humans think and collaborate through language, persistent artifacts, and iterative feedback. AI must operate in those same channels—clear text, editable docs, code diffs, sketches—and stay conversational rather than opaque.

Workflow Respect & Augmentation

Human workflow loops, like brainstorm → draft → review → ship, remain intact. AI plugs into each stage to accelerate or lighten the load; it never jumps or removes a step humans rely on for shared understanding. Even as these workflows evolve and AI takes on more work, they need to optimize for sharing intent.

Granular, Trust‑First Collaboration

Like a good teammate, AI delivers work in small, reviewable chunks, carries forward the shared project memory, and adapts quickly to human feedback. Total transparency isn't required—legible, context‑aware interaction is.

Feedback‑Ready by Design

Every interaction offers a low‑friction path for humans to correct, refine, or redirect the AI, turning each cycle into a learning moment for both sides and preventing silent drift from intent.

These pillars aren't speculative; they're already emerging in how thoughtful teams and builders work with AI today. These pillars hold regardless of how agentic AI becomes. The future of AI at work isn't purely agentic or autonomous; it's collaborative, contextual, and conversational. That's the path to real amplification, not just automation.

A Vision for the Future

Based on these pillars, I envision a collaborative AI future. Some ways this might look:

Artifacts as Memory

If it's not written down, it's forgotten. If it's not human-readable, it's not shared memory. LLMs must use artifacts rather than using opaque, internally generated memory structures. We write things down in documents, code, comments, and plans. Those are the artifacts that humans already trust because they convey information in a format and pace that's legible to humans. It also gives users the tools to communicate the source of the information.

Using documents and other artifacts as memory gives users a way to:

Inspect and adjust what the AI "remembers"
Trace why the agent took an action, or discover missing directives
Update or correct the AI's understanding without having to engineer a perfect prompt.

We see the start of this already with various types of RAG tools: ChatGPT doing web searches, Cursor doing searches within a codebase. Still, we lack tools that explicitly drive toward creating artifacts as a collaborative exercise in building shared context and assisting users in adjusting those artifacts to meet their needs.

Feedback-Driven Workflows

We don't need AI to replace our processes; we need it to participate in them. We design our processes to produce a series of artifacts that help specify and solve the target problem. Each artifact is a point where stakeholders and contributors can give feedback to ensure we maintain a path to the desired outcome.

Let's look at some example workflows across multiple domains:

Software Engineering

Workflow: Spec → Code → PR → Review → Merge → Changelog

Artifacts:

Feature specs (markdown, tickets)
Code diffs
Pull requests with review threads
CI logs, test results
Final changelog or release note

Each step produces reviewable, structured outputs. AI can draft, refine, test, and comment, but developers can also participate in the review process to maintain context and orient the work to meet their needs.

Hardware Product Manufacturing

Workflow: CAD Design → 3D-Printed Prototype → Tooling → Test Run → QA Feedback → Mass Production

Artifacts:

3D-printed prototype (early physical test of form/function)
Injection mold or custom jig (tooling as a reusable artifact)
Small batch from test run
QA reports (digital, but based on physical inspection)

Every phase produces something you can hold, test, or measure , and each artifact invites feedback before committing resources. A prototype might reveal ergonomic flaws. A test run might uncover material warping.

Technical Documentation

Workflow: Outline → Draft → Review → Publish → Update

Artifacts:

Doc outline
Drafts with comments
Final published documentation
Change tracking/reasoning

Feedback happens at multiple fidelity levels. AI can co-author, but clarity and accuracy come through human collaboration.

While these workflows are common, the way each person navigates them is deeply individual. Some people will want more iterations of feedback, and some will care about specific artifacts while disregarding others. Individuals and teams need to be able to express what they want from the process, have the AI help design that process, accept feedback from multiple human collaborators throughout, and adjust the process as needed.

Curated AI Personas and Multi-AI Collaboration

An AI that knows what I know can act as a stand-in for my experience and perspective. Individuals working alongside AI assistants build a knowledge base representing their collective experience and perspective—an expert diagnostician, developer, or civil rights activist. An AI agent can then participate in other workflows and act on their behalf to make expertise more accessible.

As each person develops and evolves their persona, they can contribute meaningfully to more conversations that they otherwise wouldn't have the bandwidth to participate in. AI personas can be especially helpful in ensuring diverse perspectives are available when garnering feedback. Multiple AI perspectives can converse and seek input from their human counterparts to develop the best solutions for the problems we're working to solve.

A Future Worth Collaborating On

Work aims to provide humans with what they need to survive and thrive. AI has the potential to unlock new types of creativity in problem solving, increase productivity, and scale perspectives, but AI can't replace lived human experience. People still experience the world through their bodies, with internal lives and needs that no model can fully replicate. This human-centered collaboration model strives to respect those needs and shape a future where AI boosts humanity instead of hindering it.

Refactor-First, Feature-Last: Conversing with Code

Monday Romelfanger — Fri, 02 May 2025 20:27:08 +0000

Two months into my no-code-writing development experiment, I've started to reflect on what I've gained and lost in the process.

There are clear wins: faster prototyping, more exploratory design conversations before touching code, and almost no actual coding (which is a huge relief, I'm more of an organize-ideas person, not a coder).

I followed the tools' lead intentionally, curious to see what they had to offer. But in doing so, I slipped back into early-career patterns, prioritizing feature work and not handling code smells up front. I lost my Monday-ness.

I'm a code whisperer. A wild west code wrangler. The one who could reshape entire systems by refactoring in their sleep.

In this post, I want to return to the process that made that kind of work possible. The one that helped me grow from an intrepid puzzle-solver into a slayer of ye olde tech debt. It's not flashy. But it's deliberate, repeatable, and it's how I've quietly transformed codebases, again and again.

The Core Philosophy

Building software is a cycle of failing and learning. You'll never build spotless code, and can't fully predict the future. Whatever you did yesterday is wrong for today.

That's why I treat building software as a conversation. All code talks back. It resists change, reveals design tensions, and asks for structure. A refactor-first, feature-last workflow gives me the space to listen before I act and lay the groundwork for successful feature building.

The Workflow

This diagram walks through all the stages I go through to develop a feature. You notice it has loops, sometimes I go through them a few times for any story I'm working on.

Identify Feature Scope

Usually, you do this before working on something, but it's a helpful starting point. Your feature might change scope or be broken into multiple features as you work.

Attempt Loop

I rarely do a feature in one shot. I take at least two passes through here, often 3 or 4. However, part of this process is that each subsequent iteration should be easier than the last. This loop has these stages:

Try implementing the feature: The first iteration should be messy. See what you can do: see what you need.
Evaluate friction and code smells: As you go, you'll get a sense of where the code isn't working and what you need to do for this feature. It might be missing test coverage, interface/abstraction, code duplication, or code smells. Keep a list of things you notice. You don't have to completely implement it before moving on; you just need to understand the space.
Decide: Can I add this feature cleanly while touching as little existing code as possible? This question is my primary evaluation criterion for whether or not I can move on to feature development. I typically prioritize reducing the risk of human error. Human errors are reduced when I can:
- Cleanly add feature flags to toggle new behaviors on/off
- Implement new code in focused isolation from the existing system

The SOLID principles are some of my primary benchmarks for evaluating this. These principles help me focus new work into smaller building blocks and help me find the missing ones.

Branches: If your answer to the Decide question is:
- Yes: Sweet, go to the feature phase
- No: Go to the refactor phase. Throw away this attempt. Hard reset, delete the branch, or do whatever feels useful.
- Too Big: The feature scope is too big if you're having difficulty keeping track of all the parts. Go back and re-evaluate the feature scope.

Refactor Phase

For the refactoring phase, you'll go through the top 2-3 friction points you identified earlier. For each friction point:

Create a new branch: do each refactoring in isolation. Isolating helps keep code reviews fast and simplifies identifying which introduced a defect in the worst-case scenario.
Add/update tests: ensure good test coverage before making changes. Tests help protect against errors even when refactoring. For some things, if you aren't changing behavior, you might consider a compiler as test coverage.
Refactor: make your changes
Open a Pull Request, Code Review, Run Validation: Like any other code change, do your typical quality checks. If you kept it small, these should be quick. It's much easier to get a little bit of someone's time to review a small PR than it is to get them to review a big one.

Once all the friction points you wanted to address are complete, return to the Feature Attempt Loop.

Feature Phase

By the time you get here, you've probably done most of the hard work. You should know how you want to build this feature, which should be relatively straightforward.

Create a new branch: create the branch from your main branch with your completed refactoring.
Implement your feature: write new code, add new tests
Open a Pull Request, Code Review, Run Validation: Get feedback, but remember, it doesn't have to be perfect – you'll fix it next time.
- Approved: Merge it; you're done!
- New Issues Found: go back to the refactor loop. You could keep this branch for rebasing or cherry picking from later.
- Too Big: Getting here and deciding your PR is too big is still possible. A big PR will be hard to review. Go back to the beginning and evaluate your feature scope.

Why This Works

This workflow helps adapt without fear. Because I know whatever I ship today, I've already built the space to improve it tomorrow. Learning, making mistakes, and improving are built into the workflow.

Each phase is relatively quick – I'll often do an attempt in the morning, do multiple refactorings in the afternoon, and then the feature the next day. Each PR reduces the cognitive load for you and your reviewers because you took the time to make small changes and set yourself up for success. Smaller PRs also increase your ability to be agile and react to new information as you go.

Paired with micro-commits, I have a safe and unstoppable workflow. I've used this flow to deep re-architect projects, migrations from old libraries to new, and for everyday feature work. It empowers me to continuously evaluate code change risk, build trust and design awareness with my teammates, and find strategies to ensure I'm providing a high-quality experience for customers.

Barriers to Adoption

I've seen a lot of developers struggle with adopting this pattern. Here are the top barriers:

Initial slowdown: As with any process change, you slow down when you implement it. You have to be disciplined in following it until it becomes second nature.
Pattern recognition: I've always relied on a gut feeling that not everyone has for detecting code smells. There is an art to writing good code that not everyone has. Code is communication, and not everyone is good at communicating. But it's a skill you can learn over time.
External pressure: Even if you develop the muscle to do this pattern, external pressure to 'get things done' can still override what you know needs to be done. In my experience, this workflow is more resilient to external pressures because I can't do the feature until I'm ready to, but in a very early startup environment, I've fallen back into old habits (feature first, too big PRs, not throwing away code when I should)

Final Thoughts

This workflow is key to my fearlessness when facing even the oldest tech debt, and is flexible enough to carry me through any tech stack. It's freeing to orient my work around learning from my mistakes and the mistakes of the previous authors.

I wanted to reflect on this workflow because I'm considering how it can apply when the 'conversation' includes AI tools. Can this flow be used to improve AI coding outcomes? Could it help reduce the context needed for any individual task? LLMs can do these tasks, but current tools require prompting each step individually, which is exceptionally tedious.

Some of my upcoming experiments will attempt to automate this workflow using LLMs.

What about you? Have you tried adopting a similar workflow? How do you talk to code? What barriers have you faced in trying to improve your workflows?

I thought you’d be more skeptical

Monday Romelfanger — Fri, 25 Apr 2025 21:23:21 +0000

A couple of weeks ago, at a weekly family dinner, I was discussing my thoughts on AI with someone when they turned and said, “I’m really interested to see where you go. If anyone was super skeptical of AI, I thought it would be you.” I’ve been thinking about this and wanted to share some framing about how I think about AI, because I am skeptical. As far as I can tell, the hype that artificial superintelligence is three years away is still hype. But I also want to view these tools practically in terms of what they can offer and do.

LLMs sound human because that’s what we asked for

LLMs are statistical machines. Many people oversimplify and say they’re “next word predictors," which is valid to an extent. You give a string of words going in, and it gives you a stream of words going out.

In 2012, I took classes for a certificate in Natural Language Processing from UW, and that’s essentially what we learned: the next word prediction model. We trained models on a big set of annotated text, which would make a giant matrix of weights for various words based on preceding ones, and it would guess one word at a time. You couldn’t ask it to make more than one sentence at a time without losing coherence. Here’s some papers from project work in one of those classes (1, 2. Side note: “For our classifier we chose to take a largely different path than a majority of the class,” of course I did 😂). Even if you wiggle through the technical jargon, you can see we weren’t doing overly complicated tasks: using keywords to indicate bias, single sentence generation. The models were so small that we could train them overnight on our laptops.

The most popular LLMs are based on these foundations, but hit a roadblock in defining what language features are essential. So, we gave machines a vast amount of data and resources (time, GPUs, energy, water) to decide how to define and create the data matrices to evaluate the input and generate output. We give them feedback, they iterate, and the process repeats until results meet some benchmark of success. They output by streaming text because that’s the interface we gave them. We wanted them to feel responsive, conversational. So they do.

Simulated Thought and Short-Term Memory

Last month, Anthropic released a post about recent research into how LLMs think. One of the downsides of training machines is that we lose insight into how they process the inputs and create outputs. My takeaway from that post is that LLMs “think” similarly to me. They take text, map it to concepts, fill in the next conceptual step, and then translate back to text. This process is how they simulate understanding. The problem with this is twofold: 1) language and images are inefficient for conveying conceptual meaning, and 2) context windows are limited, so an LLM can only remember a small number of concepts at a time.

Inefficiency of Language

Human language is low-bandwidth by our standards of technology. We’re not built for rapid communication, and our language reflects that. Even looking at the last sentence, wouldn’t it be more efficient to say, “Humans not optimal communicators?” Now I really sound like a robot, and your understanding of the idea is worse. We take time to chew on ideas; we insert less useful words to create space for comprehension between them. We also have limited vocabulary because we have limited memory. Not every word in every language is directly translatable. Vocabulary comes from the cultural context of the language and will be unique to each. So we do our best to find shared meaning, and the machines try to follow along.

The Magical Number Seven, Plus or Minus Two

I’ve referenced this idea before, but our brains can only hold onto a few ideas at a time. LLMs, currently, are worse. They’ve mapped language to concepts, but anecdotally, they only seem able to keep track of two things at a time, maybe three. They have no real long-term memory to pull from other than what’s baked into the model. Working memory is where AI still struggles the most. If it could hold on to more concepts at once, they’d feel more intuitive for people to work with (and maybe I’ll buy fewer keyboards?)

Working Within the Flaws

LLMs are great because of their flaws. They are a way for people to operate machines in a natural language, at speeds that make sense to us. That reduces the technical barriers to technology and will help reduce the need for human-machine translators (coders, programmers). They also push us to be clear about our needs and shift the focus to communication, while being a partner in creating that shared understanding. You don’t code with an LLM. You can explore ideas, generate specifications, and ask for feedback. When I think about the future of software engineering, I see more software engineering and less coding, which, if you know me, is one of my biggest complaints about the software industry.

LLMs are a translation tool. They can help translate your thoughts into natural language; they can translate natural language to code, and back again; they can translate one natural language into another. They aren’t perfect, and no translation ever is, but they are often good enough. And when they aren’t, you can give them feedback until they meet your bar for success.

I like LLMs because they reflect something human, flaws and all. However, they can never experience the world as we do, as fleshy bags of weird biology scurrying to keep ourselves alive. To say I’m skeptical isn’t far enough; I’m certain AI won’t solve everything and will create new problems too. But I hope it’ll help us see our own humanity and empower us to build a better future.

How LLMs 'Know' Stuff

Monday Romelfanger — Fri, 18 Apr 2025 19:05:43 +0000

One of the more quietly frustrating things about using large language models is realizing they don't actually know what you're talking about.

They sound like they do. They generate confident, fluent text that gives the impression of comprehension. But behind the curtain, it's a bunch of math trying to guess the following words based on patterns it's seen before.

But even if the model doesn't "know" anything in the human sense, it still produces helpful (sometimes even excellent) output. So, where does that output come from? What's shaping it?

1. Latent Knowledge

What the model learned before you showed up.

Every model is trained on a massive pile of text: books, websites, public forums, codebases, documentation, Wikipedia, and way too many Reddit arguments. I tend to think of it as 'the computers read the internet.' That training process creates what's called latent knowledge—the model's internal sense of how language works, and what tends to go with what.

It doesn't "remember" specific documents. It has no file system. What it has is a set of statistical associations baked into its weights. It knows that the phrase "how to boil an egg" is likely followed by steps. It knows that Python code looks a certain way. It knows that banana bread is a thing.

This baked-in knowledge is broad and surprisingly flexible. You can ask a well-formed question and often get a decent answer without giving it any context at all. But it's also static. It can't learn new things in real time. It doesn't know what happened yesterday unless yesterday happened in its training data, or it has a web search tool.

2. Initial Context

What you tell it upfront.

When you open a new chat with an llm, it waits for you to set the direction and tone of the conversation. When you send a prompt, you're shaping what the model sees; what statistical paths it chooses to generate a response. That prompt and any setup or documents you include or attach are the initial context. It's the only thing the model has to work with besides its training.

If your initial context is clear, well-structured, and includes relevant constraints, you give the model more to work with than its internal hunches. But if your prompt is vague or underspecified, the model will fill in the blanks using its latent knowledge. Might be good; might be based on a Spirk fanfic from 1976.

This is where people overestimate the model's awareness. You might assume that if you paste in a document or mention something once in paragraph four, the model "knows" it. Not always. Not unless it's recent, repeated, or phrased clearly enough to stick.

3. Conversational Context

What gets built over time.

If you're working in a chat interface, every message you send becomes part of the conversation history. That's conversational context—an evolving thread of instructions, clarifications, feedback, and bad follow-up questions. (We've all done it.)

This ongoing exchange feels collaborative. And it can be. But here's the thing people miss:

LLMs don't track conversation like a human. They reread the most recent portions of the thread every time and try to predict what comes next.

Unless you explicitly tell it, it doesn't "know" that it made a mistake two messages ago. Over the course of the conversation, the meaning of the words will get subtly reinforced or become more ambiguous. If the conversation gets long, the early stuff starts to fade—not because it's forgotten, but because it's buried.

Here's how all of this flows together:

Proximity Bias

Proximity bias plays a big role in the model's output. The model pays attention to everything in the context window, but the closer something is to the end of the conversation, the more influence it tends to have. In plain terms, the most recent messages often shape the output the most.

This is why:

A correction at the end of a long thread can override your original setup
A prompt tweak halfway through a conversation can shift tone or strategy
Important details buried early in the thread can get ignored entirely

The model isn't malicious. It's simple. It reacts to what's in front of it, but mainly to the most recent words.

Where This Leaves Us

When an LLM gives you a weird answer, it's tempting to blame the model. But more often, it's reacting to the context you gave it (or didn't).

Its "knowledge" comes from three sources:

What the model learned during training (latent knowledge)
What you gave up front (initial context)
What's accumulated in the chat (conversational context)

And those don't carry equal weight. As your conversation unfolds, recent messages tend to dominate. Earlier instructions fade. Meaning drifts.

So if you're aiming for clarity or consistency, don't tack a final question onto a long chat and hope for the best. Pause. Ask it to summarize what you need as a new prompt, and validate that it looks correct. Start fresh with a structured prompt that reflects what you need.

LLMs don't know what you mean—but they'll try to guess. The more clearly you understand and express your own intent, the more likely they'll get it right.

Monday’s Weekly Notes: April 14, 2025

Monday Romelfanger — Mon, 14 Apr 2025 07:00:00 +0000

Weekly Notes are here to inspire others experimenting right now, give me a framework for reflection, and open up discussion around these workflows.

Highlights

Made a lot of progress on Quilt: the modular actor system clicked, SQLite persistence landed, and the first full path through the cutting and swatching pipeline works.
Started writing as a companion to the dev work — two blog posts published, the reflection is helpful
The Cursor workflow is starting to prove itself, even if it’s still rough around the edges.
LLM-based workflows are fast but cognitively dense — I’m moving quickly, but it feels like carrying a lot at once.

In-Progress / Work Notes

Built and integrated Quilt’s actor system:
- The actor model was suggested by an LLM but made real when I connected it to how I already think — code as cooperating systems.
- Formalizing this helped break the work into intuitive, modular pieces.
Connected key components:
- Discovery actor ↔ scanner + material registry
- Cutting actor ↔ persistence backend
- SQLite integrated for early persistence
- Laid groundwork for swatching infrastructure
Cursor code review caught real issues:
- Missing error reporting if Cut persistence failed
- Architectural gaps in dealing with backpressure
Tooling insights:
- Plan → Act → Plan loop is effective at keeping the Cursor Agent from running away
- Memory bank too rigid for evolving work, not team-friendly yet
- Local review flow works but not yet integrated with GitHub
- Tried ai-code-review-action for GitHub PR reviews
  - It surfaced useful feedback, but added too many granular comments
  - I had to manually re-feed its notes into Cursor, which broke the flow
  - Still looking for a smoother way to bridge GitHub and Cursor-based reviews
- Considering GitHub MCP Server for bridging GitHub reviews with Cursor + LLM context

Thinking & Reflection

For Quilt, Contextual “spreads” are still a conceptual knot:
- The metaphor is solid, but implementation will need trial and error
Starting to see my work as cyclical: build → reflect → teach
Even with good velocity, I feel behind in documentation and reflection. Hopefully these weekly notes will help figure out what’s important to say.

Cursor Rules

These are my current Cursor rules. I can feed it commands to facilitate a largely automated workflow: what's next, do you have any questions, act, test, code review, then update memory bank, and it follows these rules to respond with consistent structure and behavior. As long at I have a clear implementation plan in place, this works fairly smoothly. If it fails, then we update the implementation plan with more detail / learnings from the attempt.

📄 implementation_planning.mdc

This powers commands like plan this feature or what's next. It guides Cursor to produce milestone-driven, end-user-focused implementation plans with learning goals and time estimates.

It reinforces incrementalism and discourages diving straight into code.

Pros: Keeps the LLM from jumping ahead. Forces it to model intent before execution. Helps me think too.

Cons: My implementation plan doc is a giant backlog. I really wish I had a nicer task tracking tool to use here. This is another thing I want to try the Github mcp for.
📄 modes_of_operation.mdc

This governs the Cursor event loop. It starts in PLAN mode and doesn’t switch to ACT until I explicitly tell it to ACT. Every response starts with # Mode: PLAN or # Mode: ACT so I know what state it’s in. Pros: Helps prevent the LLM from just going. Claude in Cursor is very eager to please with completed work. Helps the LLM frame the work before executing. Gemini is much better at planning and following the memory bank rules. Claude is better at acting because it’s fine-tuned to the tools. Cons: Claude is not very good at sticking to these rules anyway, and it’s less fluid and ‘natural’ feeling. Source: reddit post
📄 memory_bank.mdc

This defines how Cursor treats memory. It assumes total amnesia between sessions and reads the memory bank files on every task. The structure is layered — project briefs, system patterns, current focus — and acts as the persistent state for the project.

Cursor reads from this when initializing, and I can trigger updates with update memory bank.

Pros: Gives Cursor continuity. I don’t have to restate context every time. Especially powerful for long-form or paused work.

Cons: Not ideal for teams and it’s weird to maintain docs just for the LLM to use. Source: reddit post
📄 code_review.mdc

When I type code review, Cursor kicks off a structured review using this doc. It automatically diffs against main, scopes the changes, and walks through architecture, error handling, async, test coverage, performance, naming, and Rust-specific concerns.

It also checks that the memory bank and @implementation-plan.md are up to date.

Pros: Catches bugs and gaps with zero prompting. I can trust the review will be thorough without micromanaging it.

Cons: I wish I could do this on Github and transfer the feedback back to my local cursor session.

Overall Use Case:

These rules make Cursor act like a junior dev or co-pilot with strong instincts and a short memory. I drive the flow by giving high-level commands, and it uses the rule set to respond consistently — whether I’m asking for a review, a next step, or a rewrite.

Biggest Wins:

I don’t need to remember what to ask — I just say what I need (code review, plan, test, etc.) and Cursor knows what to do.
The structure helps me scale — I can pause work, come back, and pick up from where the memory left off.
It feels less like prompting, more like pairing with a teammate.

Biggest Gaps:

Missing integration with other tools
Not good for team environments. Maybe memory-bank could be git ignored and unique to the project/individual? Is it necessary with otherwise good documentation?

Overall Pros:

They reduce cognitive load and bring structure to async LLM dev work.
They’re a long-term bet on trustable rituals — I can feel the system getting sharper.

Overall Cons:

Still not integrated into GitHub or fully LLM-aware — lots of manual context syncing.
Too rigid in places (memory bank) and too reliant on me remembering to invoke them.
They need tooling, or at least automation hooks, to scale or share effectively.

Links & Publishing

📝 Blog posts:
- What the heck am I supposed to be doing?
- Transcript: Vibe Conding a Crystal Ball
🌐 Site migration:
- Moved blog to humans.build.software
- Redirect from GitHub Pages still pending
🎓 Teaching idea emerging:
- Thinking about running a class on LLM workflows — from philosophy to rituals
🔍 Exploring:
- Claude Task Master
- GitHub MCP Server

Life & Grounding

Playing Spiritfarer. It’s steady, gentle, and hitting the right rhythm.
Mid-day Monday is a lovely time for grocery shopping. It’s nice to feel free of the corporate schedule.

🐈 Cat Pic of the Week

Meta & Cadence

This review is more like a week and a half, but it’s all good stuff.
Working on a post about overall thoughts on an LLM-based workflow
First weekly notes!!
For non-cursor LLM chats if you’re having markdown rendering problems:

“Please produce a Markdown document that is entirely wrapped in a single code block with outer backticks (using four backticks for the outer fence) so that inner formatting is preserved.”

Join me on VibeColab Discord

💬 Open Threads

Curious how others are shaping their LLM workflows. Are you trying something similar with Cursor or memory-based systems?

This week I’m especially thinking about:

How to make memory banks more team-friendly
Integrating LLM review flows with GitHub
Finding a better bridge between GitHub and Cursor-based reviews
- I tried ai-code-review-action, but it overwhelmed me with low-priority comments that I had to manually feed back into Cursor. It broke the rhythm more than it helped.

If you’re experimenting in this space, I’d love to hear what’s working (or not).

Transcript: Vibe Coding a Crystal Ball

Monday Romelfanger — Tue, 08 Apr 2025 07:00:00 +0000

Transcripts are meant to be a reflection on a specific LLM interaction, exploring the context, learnings, and providing a concrete example of making something with AI

What I Made

Riding the high of my coming back post, I came across this reddit post, and I had the goofy idea to make a website to do this. I dunno why, just cause. So I did pure vibe coding in less than an hour. Introducing: Crystal Ball

Github Repo

A Tangent on Vibe Coding

If you’re new to the phrase vibe coding:

Vibe coding (also written as vibecoding) is a recently-coined term for the practice of writing code, making web pages, or creating apps, by just telling an AI program what you want, and letting it create the product for you. In vibe coding the coder does not need to understand how or why the code works, and often will have to accept that a certain number of bugs and glitches will be present. The verb form of the word is vibe code.

— Merriam-Webster Dictionary of Slang

We use ‘vibe coding’ in a derogatory/derisive way, but it’s specific to this discovery period. We’re all playing around with these tools, trying to reinvent how we work, and many of us are failing and making mistakes as we go. There have been leaks of OpenAI API keys from vibe coders who had probably never dealt with integrating a third-party tool (which is not that uncommon) or who failed to properly review the work done by the LLM (which is easy to do if you don’t have the effective workflows in place).

Just this week, one of my friends called me a vibe coder when I mentioned I hadn’t written any code in weeks. I felt defensive because I wanted to think I was working with more structure than other vibe coders. But everyone labeled a ‘vibe coder’ is a person failing, publicly, to use a tool that we collectively don’t know how to use yet, and that’s equally threatening to change the fabric of our work. Cheers to vibe coding in public 🥂

What I Learned

Whimsy

It’s much easier for me to follow my whimsy. I’ve always enjoyed the silly things people make just cause they want to, but building a simple website has always been challenging for me. There are a lot of details to create even something simple, and I tend to think more about the shapes, structures, and systems of things rather than the focused details. Even in college, I was the integrator. The one who got all the pieces to work together after everyone else wrote them. Using an LLM meant I could build something whimsical by just expressing the shape of what I wanted to make.

Letting go of control

Part of developing with an LLM is growing an internal sense of what you can/should try to control and shouldn’t. In this example, if I had built this thing alone, I might have used Nextjs even though it’s overkill because it’s what’s familiar to me and it’s easy to set up. But by letting go of the architecture details and seeing what it did, I realized we could do without and just set up a single Vercel function for the backend (Why Vercel? – I already have an account there for other projects). Then, I had to fight with it and not use Nextjs because most Vercel documentation is Nextjs-based. You win some, you lose some.

Letting go of control is a core part of my workflow with llms. You can experiment more quickly, so allowing the LLM agent to try without all the answers is okay. You’ll learn something in the process.

Crystal Ball Project Cursor Transcript (Generated by Claude 3.7)

The following transcript was generated by Cursor (v0.48.7), using Agent Mode, thinking Claude 3.7 by going through each chat window and requesting a transcript. I didn’t plan or prompt much—I just followed the vibes and let the assistant help me build something goofy, step by step.

Initial Request and Setup

User: I want to build a silly website that will ‘tell you your future’ like this reddit post @https://www.reddit.com/r/BenignExistence/comments/1jrw823/im\_a\_very\_really\_real\_and\_definitely\_not\_fake/

Assistant created initial website with:

HTML structure with a crystal ball interface
CSS styling with animations
JavaScript with hardcoded funny fortunes
Basic README file

User: Cool, but I want to use an LLM to generate the fortunes, and probably host it on Vercel

Assistant updated the project to:

Created API endpoint using OpenAI
Modified JavaScript to fetch from the API with fallbacks
Added Vercel configuration
Updated documentation for deployment
Added environment variables for API keys

User: I’m getting 404s from the API. The page could not be found. NOT_FOUND

Assistant restructured project to fix API routing:

Created Next.js compatible directory structure
Moved API file to pages/api directory
Moved static files to public directory
Updated Vercel configuration

User: According to Vercel docs https://vercel.com/docs/functions it was in the right place before

Assistant acknowledged the API file can work in multiple locations per Vercel docs:

Kept API in original location
Updated project structure to ensure proper routing
Cleaned up duplicate files
Restarted development server

Improvements Made During Development

During our conversation, we also:

Added responsive design for mobile devices
Implemented fallback fortunes if the API call fails
Added loading animations for better UX
Improved crystal ball visual effects

The project now features:

A visually pleasing crystal ball with animations
OpenAI integration for generating unique fortunes
Vercel deployment configuration
Proper fallbacks for error handling

New Chat w/ Rollover: Dependency and Package Updates

User: I’m still getting 404s and we have two copies of the backend code

Assistant fixed the duplicate backend code:

Identified two copies of API files in /api and /pages/api
Removed the duplicate API file
Updated Vercel configuration for proper routing

User: [Outside chat]: (I felt like the vercel config and next config it had created were making it confused, so I deleted them)

User: According to Vercel docs https://vercel.com/docs/functions /api was the correct location

Assistant restored the correct setup:

Put API in original location
Updated Vercel configuration for standalone functions
Removed Next.js from configuration

User: We don’t have Next.js in package.json

Assistant updated package.json:

Removed Next.js dependencies and scripts
Updated to use Vercel’s standalone functions approach
Configured scripts for Vercel development

User: Can we get the latest packages? @Web

Assistant updated dependencies to latest versions:

Updated OpenAI from 4.30.0 to 4.91.1
Updated Vercel from 33.2.0 to 41.4.1
Updated Node.js requirement from >=18.0.0 to >=20.0.0

The crystal ball project is now properly configured with updated dependencies and the correct API structure for Vercel deployment.

User: Can you add an animation to make the ball cloudy while it’s loading?

Assistant added a cloudy animation effect for the loading state:

Created a new CSS class and animation for the cloudy effect
Added SVG-based cloud patterns inside the crystal ball
Implemented JavaScript to toggle the cloudy state during loading

User: Can you make it a little smoother? It like turns on then off.

Assistant improved the animation smoothness:

Added CSS transitions for gradual changes between states
Created additional animations for subtle cloud movement
Adjusted JavaScript timing for a more natural transition
Extended animation duration for a more magical experience

(Side note: it’s still janky, but a little better after this)

New Chat w/ Rollover: User Engagement Features

User: Can we make it so they can only ask for one per day?

Assistant implemented a daily fortune limit using localStorage:

Added functions to track when users last received a fortune
Modified the UI to show “Return Tomorrow” when the daily limit is reached
Created a countdown showing hours and minutes until the next available fortune
Added persistence across page refreshes and browser sessions

User: How are you saving across refreshes?

Assistant explained the localStorage implementation:

Used browser’s localStorage API to persist data between sessions
Stored timestamp of last fortune request
Added date comparison logic to determine if it’s a new day
Highlighted that localStorage is widely supported and perfect for this use case

User: Can we add an inspired by link to @https://www.reddit.com/r/BenignExistence/comments/1jrw823/im\_a\_very\_really\_real\_and\_definitely\_not\_fake/?

Assistant added attribution to the Reddit post:

Added a styled attribution link in the HTML
Created CSS styling for the link to match the site’s aesthetic
Set the link to open in a new tab

User: This AI appears to be obsessed with socks given the system prompt.

Assistant identified and fixed the sock obsession in the generated fortunes:

Examined the API prompt and found it was generating too many sock-related fortunes
Modified the system prompt to explicitly avoid mentions of socks
Added instructions to use a wider variety of mundane topics
Increased the temperature parameter for more randomness

The crystal ball project now features smoother animations, daily fortune limits, proper attribution, and more varied fortunes without the sock obsession.

What I Had to Do Myself:

Setup the project in Vercel
Got a new API key and set the env var in Vercel
Added a cname and linked to my Vercel project

That’s it. Vibe coded in under an hour. Just an afternoon whimsy.

When LLMs meet Software Engineering

Monday Romelfanger — Sat, 05 Apr 2025 07:00:00 +0000

Hey, I’m Monday. I’m a software engineer exploring what it means to build software alongside LLMs, with a strong focus on process, reflection, and being human in the loop. This is my first post here on Dev.to—adapted from my personal blog—and it’s about where I’m starting from.

Last year, I made the Seattle -> Bay Area move, started at a young AI startup, which I left in February due to… let’s say, personality and value differences. As the political landscape shifted, many people in my life have had their lives disrupted. I'm trans, as are a lot of my social circle. One friend has left the country, another has discussed with her wife if they should get divorced so they can both stay present in their child’s life, and yet another is stretching themselves thin trying to support everyone around them. We’re all more stressed and more unsettled than we were before.

At the same time, tech is playing the oligarch game. CEOs at the inauguration, Zuckerburg’s masculine energy (GPT-4o suggested ”gladiator era,” and I’m dying 😂), Meta’s Jan. 7 hateful conduct update, the rollback and de-emphasis of DEI programs, and whatever the hell Elon Musk is doing today. The mood in tech has shifted. To many of us, our leaders and our funders no longer feel trustworthy—not that they necessarily were before, but more people are aware of their flaws. And with LLMs, the very fabric of our work is shifting beneath us.

When I left my last job, I didn’t know what I was going to do, and I still don’t know exactly. But after a bit of time away playing with some project ideas, I had two thoughts:

I’m using the LLM wrong for coding, but I’m not sure how, and
if LLMs are going to do all the coding in the future, what the heck am I supposed to be doing?

And that comes to what I want to do with this blog/notes/experiments thing. When I initially started Humans Build Software last year, I knew something was changing. The name is a mantra as much as a mission: humans—people, with needs, bodies, context, and passions—should drive software development. How we build and what we build are in the middle of a vast, industry-changing upheaval.

I’ve already collected a few threads worth sharing, like:

That time I discovered a much better UX through LLM simulation of a group conversation
LLMs are a mirror you can talk to
When Claude did my (Staff) job for me
How ChatGPT helped me navigate a situation where I was being gaslit
How using an LLM changes my workflow
🌶️ LLMs will make software engineering “women’s work” again 🌶️

As well as sharing notes from experiments I’m trying (some in partnership with Nic Galluzzo) –

Scaffold, a task management app for AuDHD
Quilt, a local, document-based context provider for LLMs
Collaborative AI, a team-oriented chat + document writing experience

I’ll finish out with a bit of call-to-action. What do you want to know about development with LLMs? What do you wish you had time to try out? How are your current tools and workflows failing you? How have LLMs changed your workflow? Let’s define a new world of software engineering that works for us.