https://chatgpt.com/share/6a335e58-e364-83e8-9f1f-71db45a2f009
# SWE vs Regular Writing
**User:** Anonymous
**Created:** 6/18/2026 10:31:17
**Updated:** 6/18/2026 10:56:25
**Exported:** 6/18/2026 11:02:15
**Link:** [https://chatgpt.com/c/6a33579d-dd50-83ee-8777-4f6bd0efcc76](https://chatgpt.com/c/6a33579d-dd50-83ee-8777-4f6bd0efcc76)
## Prompt:
6/18/2026, 10:31:16 AM
i am asking about writing skill to SWE people vs Regular people. The following sentences are about explaining what should do about designing agents and making some examples. For me as a SWE engineering background, I would summarize more concise sentences. Like don't list out info, but instead, provide your intents as inputs to the agents. What do you think?
== here are the sentences ==
Choosing the right tools for agents
More tools don’t always lead to better outcomes. A common error we’ve observed is tools that merely wrap existing software functionality or API endpoints—whether or not the tools are appropriate for agents. This is because agents have distinct “affordances” to traditional software—that is, they have different ways of perceiving the potential actions they can take with those tools
LLM agents have limited "context" (that is, there are limits to how much information they can process at once), whereas computer memory is cheap and abundant. Consider the task of searching for a contact in an address book. Traditional software programs can efficiently store and process a list of contacts one at a time, checking each one before moving on.
However, if an LLM agent uses a tool that returns ALL contacts and then has to read through each one token-by-token, it's wasting its limited context space on irrelevant information (imagine searching for a contact in your address book by reading each page from top-to-bottom—that is, via brute-force search). The better and more natural approach (for agents and humans alike) is to skip to the relevant page first (perhaps finding it alphabetically).
We recommend building a few thoughtful tools targeting specific high-impact workflows, which match your evaluation tasks and scaling up from there. In the address book case, you might choose to implement a search_contacts or message_contact tool instead of a list_contacts tool.
Tools can consolidate functionality, handling potentially multiple discrete operations (or API calls) under the hood. For example, tools can enrich tool responses with related metadata or handle frequently chained, multi-step tasks in a single tool call.
Here are some examples:
Instead of implementing a list_users, list_events, and create_event tools, consider implementing a schedule_event tool which finds availability and schedules an event.
Instead of implementing a read_logs tool, consider implementing a search_logs tool which only returns relevant log lines and some surrounding context.
Instead of implementing get_customer_by_id, list_transactions, and list_notes tools, implement a get_customer_context tool which compiles all of a customer’s recent & relevant information all at once.
## Response:
6/18/2026, 10:31:17 AM
I think your instinct is aligned with how many experienced SWE readers internalize ideas.
The original text is written for a broad audience. It spends many paragraphs explaining *why* and gives concrete examples. But for engineers, the underlying principle can often be compressed into a design intent.
For example, I would summarize the entire section as:
> **Design tools around user intents and workflows, not around raw APIs or data structures. Return only the information needed for the task, and encapsulate multi-step operations behind higher-level actions.**
Or even more tersely:
> **Expose intents, not primitives.**
The examples then become manifestations of that principle:
| API-centric | Intent-centric |
|--------------|----------------|
| `list_contacts()` | `search_contact()`, `message_contact()` |
| `list_users()`, `list_events()`, `create_event()` | `schedule_event()` |
| `read_logs()` | `search_logs()` |
| `get_customer_by_id()`, `list_transactions()`, `list_notes()` | `get_customer_context()` |
### Why this abstraction works for SWE readers
As an engineer, you probably naturally see several ideas hidden beneath all those examples:
1. **Optimize for the agent's context window.**
- Avoid exposing large raw datasets.
2. **Expose semantic operations instead of CRUD primitives.**
- Provide "what" rather than "how".
3. **Encapsulate common workflows.**
- Hide multiple API calls behind one tool.
4. **Return relevant context, not exhaustive state.**
- Retrieval > enumeration.
5. **Think in affordances.**
- Tools should correspond to actions the agent naturally wants to take.
So I might compress the whole section into something like:
> **Treat tools as capabilities rather than API wrappers. Design around the agent's intent and workflow, minimizing context consumption and hiding low-level operations.**
Or, if writing for senior SWE/AI engineers:
> **Expose affordances, not endpoints.**
That one sentence captures almost all the examples:
```
Bad:
list_contacts()
list_users()
read_logs()
get_customer_by_id()
Good:
message_contact()
schedule_event()
search_logs()
get_customer_context()
```
In fact, I'd argue that the author's real thesis is not
> "More tools don't always help."
but rather
> **"An agent's tool interface should represent intentions, not the underlying software architecture."**
That is probably the sentence I would put at the top of the section if the audience were experienced software engineers.
## Prompt:
6/18/2026, 10:41:55 AM
great. following your thoughts above, please give your prompts that I could use when next time I could give to LLM for summerizing some posts for me.
## Response:
6/18/2026, 10:41:56 AM
Since you have an SWE background, I would optimize the prompt not for producing a nice summary, but for extracting the **design principles** and **compressing examples into abstractions**.
Here are several prompts I personally would use.
---
## 1. Principle-Oriented Summarization
```text
Summarize this article for an experienced software engineer.
Do not summarize paragraph by paragraph.
Instead:
1. Identify the author's core thesis.
2. Extract 3-7 design principles.
3. Compress examples into higher-level abstractions.
4. Replace long explanations with concise statements.
5. Prefer "intent over implementation" style wording.
6. If multiple examples illustrate the same idea, unify them into one principle.
At the end, provide:
- One-sentence thesis.
- Key principles.
- Memorable aphorisms.
```
---
## 2. Senior SWE Mode
This is probably my favorite.
```text
Assume your audience is senior software engineers.
Ignore beginner explanations and examples unless they reveal a deeper principle.
For each section:
- What is the author's real point?
- What abstraction unifies the examples?
- What design philosophy is implied?
- Can this be expressed in one sentence?
Output:
# Core Thesis
# Design Principles
# Mental Models
# Memorable One-Liners
```
---
## 3. Distill Examples Into Intent
```text
Do not repeat examples.
Instead, infer the intention behind the examples.
Transform:
example → pattern → principle
For every example shown by the author, answer:
- Why is this example here?
- What general rule does it illustrate?
- What would be true even if the example changed?
Produce the smallest set of principles necessary to reconstruct all examples.
```
---
## 4. Compress Like a Distinguished Engineer
```text
Summarize this post as if writing notes for distinguished engineers.
Rules:
- Remove storytelling.
- Remove beginner explanations.
- Remove repeated examples.
- Compress paragraphs into principles.
- Replace concrete APIs with abstractions.
- Prefer nouns and verbs over prose.
Output:
## Thesis
## Principles
## Tradeoffs
## Anti-patterns
## Memorable sentences
```
---
## 5. Recover the Hidden Philosophy
This one is very powerful.
```text
Every article contains:
- surface examples
- design principles
- underlying philosophy
Ignore the surface examples and recover the deeper philosophy.
For each section:
1. What problem is the author trying to solve?
2. What assumptions are they making?
3. What philosophy explains the recommendations?
4. What sentence best captures the whole section?
Produce:
# Philosophy
# Principles
# Patterns
# Anti-patterns
# One-sentence takeaways
```
---
## 6. Extract Engineering Aphorisms
```text
Read this post and produce:
- 5-10 engineering aphorisms.
Good aphorisms are concise and reconstruct the whole article.
Examples:
- Expose affordances, not endpoints.
- Optimize workflows, not APIs.
- Retrieval beats enumeration.
- Return relevance, not completeness.
- Intent is the interface.
Avoid explanations.
```
---
## 7. My Favorite (Meta-Prompt)
This is probably the one I'd actually use:
```text
Summarize this post for an experienced software engineer.
Assume I can understand examples myself.
Your job is not to repeat information but to compress it.
For each section:
1. Identify the author's intent.
2. Infer the underlying design principle.
3. Generalize examples into abstractions.
4. Remove redundancy.
5. Produce memorable one-line statements.
Output:
# Core Thesis
(one sentence)
# Principles
(3-7 bullets)
# Anti-patterns
(what the author argues against)
# Memorable Sentences
(short aphorisms that reconstruct the article)
# Hidden Philosophy
(what worldview or assumptions drive these recommendations)
```
---
I suspect you'd especially like an even more aggressive prompt, inspired by how senior engineers read papers:
```text
Assume examples are merely evidence.
Ignore evidence and recover the theory.
Compress the article until only the ideas remain.
If several paragraphs can be replaced by one sentence, do so.
If several examples share one abstraction, name the abstraction.
Output only:
- Thesis
- Principles
- Tradeoffs
- Anti-patterns
- Aphorisms
```
The difference between "regular-reader summarization" and "SWE summarization" is essentially:
> **Regular readers preserve information; engineers compress information into reusable mental models.**
That mindset itself can be turned into a prompt.
---
Powered by [ChatGPT Exporter](https://www.chatgptexporter.com)
