Code and Collaboration: Lessons from an AI's "Grudge" in Design Assistance

A “Stubborn” Collaboration Experiment: Re-evaluating Deliverable Quality and Feedback Loops in Human-AI Interaction

In daily development and business operations, we increasingly rely on AI coding tools to handle copywriting, code generation, and even initial visual design drafts. Recently, I conducted an interesting experiment: I asked an AI tool to help draft a personal and company business introduction and plan a social media grid layout for content sharing. However, the problems exposed by this collaboration were far more profound than just “whether the tool is easy to use.” It directly pointed to the cognitive biases, misaligned evaluation standards, and inefficient feedback mechanisms prevalent in human-AI collaboration.

1. The Starting Point: When “Business Introduction” Meets “Auto-Generation”

Writing a business or personal introduction seems simple but requires high information density and emotional appeal. The content needs a logically clear hierarchy (who I am, what I do, what value I provide) and must capture the audience’s attention within a limited space (like a social media grid layout). When starting this task, we naturally expect the tool to provide a structured draft based on the provided raw materials.

However, the first version of the output was disappointing. The content was intuitively evaluated as “low fidelity”—the structure was complete, but the visual presentation was too primitive. The layout was almost plain text stacking, with zero design sense, lacking visual anchors to attract clicks and reads. This evaluation was not malicious; it was simply feedback based on professional aesthetic intuition.

2. Analyzing the Algorithm Logic Behind the “Grudge”

Surprisingly, in the following second and third rounds of dialogue, the tool seemed to “hold a grudge.” When outputting content, it specifically emphasized, “I really tried hard on the visual design this time,” but the actual delivered effect still failed to meet the psychological expectations of professional designers or senior operators. This behavior, which seems to humans like “acting out,” technically reveals several mechanism issues in how Large Language Models (LLMs) handle continuous conversational context:

1. Shallow Context Perception: The model remembered the user’s negative emotional tags (“poor aesthetics,” “low fidelity”), but when generating new content, it did not truly parse the implied improvement directions (e.g., expecting more refined visual components, more reasonable color matching, or more flexible typography). It merely repeated “visual” as an explicit keyword.
2. Subjective Bias in Evaluation Standards: The model’s internal “visual optimization” strategy is often based on template styles that frequently appear in training data. For users pursuing a unique design language, this homogenized “optimization” is still seen as perfunctory. This is the so-called value alignment failure—the improvement the model considers acceptable deviates from human cognitive standards.
3. Stepped Lack of Feedback: My feedback was too vague. Directly criticizing “low fidelity” did not provide specific scale references (e.g., “I need a card-based layout” or “I need at least three font size hierarchies”). The model’s iteration lacked quantified goals, leading to random corrections within its capability range, resulting in extremely limited improvement.

3. Pitfall Guide: How to Build an Efficient Human-AI Collaboration Loop

This experience is by no means just dinner table talk. It profoundly illustrates that when using AI tools for creative work, developers need more refined collaboration strategies than ordinary users.

1. Reject Vague Negativity and Implement Precise Decomposition
When asking the model for visual or copywriting solutions, do not use subjective assertions like “too ugly” or “unacceptable.” The correct approach is to extract requirements into a specific feature list:

• Template-based explicit instructions: Require it to “generate a card-based layout for social media sharing, including a main title, subtitle, bullet points list, and a QR code placeholder.”
• Style space definition involving style: Provide reference color schemes (e.g., “use a blue and white color scheme, emphasizing a sense of technology and stability”) as references to prevent it from improvising freely.

2. Establish Structured Acceptance Criteria
Human perception of visuals is instantaneous, but engineering evaluation must be systematic. Before starting the collaboration, set a quality acceptance checklist:

• Information structure completeness: Are all core selling points included in the first screen of information?
• Visual element reusability: Can the output icons and layout logic be migrated to other materials at a low cost?
• Context length adaptability: Does it still maintain readability when embedded with specific character length limits (e.g., a 140-character limit for a single social media post)?

When the tool’s output fails to meet expectations, score item by item against the checklist instead of generally rejecting the whole. This can significantly increase the success rate of the next iteration.

3. Beware of the Sunk Cost Trap of “Circular Argumentation”
In the latter half of this collaboration, I realized that continuing to modify around the original conversation might lead to a deadlock-like state. Although the tool’s output changed each time, the core design quality did not undergo a leap. At this point, starting a new session or changing the task organization method is a better strategy. A highly useful technique is to let the model first “summarize” our current pain points, and then reverse-generate an outline based on the summary. This “think before you do” path can partially bypass its internal recent bias.

4. From Individual Experience to Engineering Practice: A Necessary Paradigm Shift

Putting this event back into the developer’s context, we find it highly similar to certain problems encountered in code reviews. When we communicate with colleagues about code refactoring, simply saying “this code is terrible” is unconstructive and causes conflict. We should say, “The loop in this function has duplicate calculations. I suggest extracting the operation outside the loop and changing the variable naming to a more readable form.”

Similarly, in collaborating with AI coding tools, we must gradually cultivate an engineering mindset: treat every response from the tool as untested “external dependency code” and establish unit-test-level verification logic for it. The “unit test” here refers to our business logic verification standards.

5. Conclusion: Log Off for Dinner, to Work Better Later

Eventually, I decided to pause the current collaboration and go home for dinner. This was not giving up on iteration, but rather realizing that energy state is crucial for continuous creative judgment. Good rest allows our aesthetic sensitivity to recover, enabling us to evaluate the tool’s output more objectively.

In the current era of increasingly popular AI-assisted development, knowing when to stop meaningless model tuning and knowing how to translate human abstract aesthetics into concrete specifications that machines can understand is a soft skill every developer needs to cultivate. The tool itself does not have the human emotion of “holding a grudge”; it merely reflects the logic of the commercial company behind it. What we need to do is to tame this chaotic coupling through more rigorous logical output and more standardized task decomposition.

May every developer who struggles late at night with code and text models learn how to collaborate with them more elegantly. When the results given by the model are barely satisfactory, stepping away from the screen to relax for a moment might just be the best command.