AI Does More Than Just Applications: Collaborating with AI to Complete a Data Structure RFC and Multi-language Implementation
Using Rangeable RFC as an example, this records how AI participates in deeper technical research and design, from problem abstraction, algorithm selection, semantic definition to Ruby / Swift reference implementation.
Background
A few weeks ago, to redesign my personal website, I upgraded to Claude Code Max and later used AI with Google Apps Script to create a personal desktop Dashboard Deck, turning an old iPhone from junk into treasure. This week, I shifted my focus to a previous open-source project, using AI to refactor the original handcrafted code, optimize efficiency, add documentation, and complete tests.
TL;DR
First, I used AI to refactor the application layers of several open-source projects, which inspired me to dive deeper into foundational data structure design.
Linkyee— Your Own Link Page
A fully customized, 100% free, open-source LinkTree alternative — deployed straight to GitHub Pages.
The first optimization was for the previously made Linktree-like free open-source self-hosted version. I used AI to restructure the architecture, design several new themes, add more built-in plugins, introduce a Design AI Skill for easy user customization, and enhance the local testing environment.
ZMediumToMarkdown
Download Medium posts as clean Markdown, preserving structure, images, links, code blocks, and common embeds for plain Markdown or Jekyll workflows.
I will download all the article content, including images, embedded code, and YouTube links, and convert them into Markdown format. The images will be saved together in the ./assets folder.
The second is a project I have been using and maintaining for over four years — a tool to download and convert Medium articles into Markdown format. Since later on, I mostly treat Medium as a backend editor, the main use is to download and convert the original text with this tool and then upload it to my self-hosted website.
This project is a crucial bridge between my website and Medium that cannot be broken; the first version took me a lot of time and effort to develop. Over the years, I’ve been fixing minor issues, but it has been a long time since I thoroughly reviewed and optimized the design.
Starting with AI optimization for the application, besides asking it to refactor and add tests for the original manually written rendering logic, it also improved the Medium Cloudflare Anti-bot process. This allows users to gracefully log in through Chrome and automatically obtain cookies when Medium blocks the crawler, then execute automatically.
mcp-medium-reader
Finally, AI also built the Medium.com article Reader MCP service.
The basic conversion service ZMediumToMarkdown is already completed. MCP is just a wrapper that calls it to get the job done.
The problem solved is that AI like ChatGPT, Codex, Claude, and Claude Code are often blocked by Medium’s Cloudflare Anti-bot when trying to scrape content from Medium articles. As a result, AI cannot directly read the articles, and even if it can, it only reads HTML, which is not AI-friendly Markdown.
mcp-medium-reader Allows your AI to bypass blocks and read the Markdown version of Medium articles, saving tokens while improving AI comprehension.
Labeled Interval Set Problem
Back when I was working on ZMediumToMarkdown, I encountered this Foundation data structure design (algorithm) problem. At that time, I didn’t have the extra energy or ability to solve it, but now with AI, I thought I could try to use AI to solve this problem.
Case 1 — Medium Rendering Issue
The article content data returned by Medium.com’s GraphQL API is in the following format:
{
"text": "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.",
"markups": [
{
"type": "A",
"start": 169,
"end": 207,
"href": "https://zhgchg.li/posts/f6713ba3fee3/",
"anchorType": "LINK",
"userId": null,
"linkMetadata": null,
"__typename": "Markup"
},
{
"type": "STRONG",
"start": 0,
"end": 29,
"href": null,
"anchorType": null,
"userId": null,
"linkMetadata": null,
"__typename": "Markup"
},
{
"type": "EM",
"start": 15,
"end": 55,
"href": null,
"anchorType": null,
"userId": null,
"linkMetadata": null,
"__typename": "Markup"
},
{
"type": "STRONG",
"start": 69,
"end": 88,
"href": null,
"anchorType": null,
"userId": null,
"linkMetadata": null,
"__typename": "Markup"
}
]
}
Plain Language Translation:
[0,14] STRONG = Lorem ipsum dol
[15,29] STRONG + EM = or sit amet, co
[30,55] EM = nsectetur adipiscing elit,
[56,68] normal = sed do eiusm
[69,88] STRONG = od tempor incididunt
[89,168] normal = ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercit
[169,207] A = ation ullamco laboris nisi ut aliquip e
Expected Rendering Result:
Note: The meaning of “end” in the original Medium data should be converted according to the actual API definition; this article will use the closed interval meaning defined by the Rangeable RFC for explanation.
Problem
-
Range Overlapping
The same range can have multiple overlapping states, for example [15,29] is STRONG + EM -
Range Overlapping
In extreme cases, users may set overlapping styles, such as [0,29] being STRONG and [15,55] being EM.
- Continuous Interval Merging
Data may provide [0,12] as STRONG / [12,29] as STRONG and need to be merged into [0,29] as STRONG
Overlapping intervals and continuous merging are relatively easy to handle. The most troublesome part is managing intersecting and closing intervals. You can’t render them directly by index, as it would become **AA_AA**BBB_. You need to handle the open and close markers yourself to get **AA_AA_**_BBB_, which is the correct Markdown.
iOS developers who have used NSAttributedString attributes face the same issue, except Apple Foundation handles the interval merging and overlay for us.
At that time, I spent a long time thinking about it. I regretted not having studied more since I rarely practiced problems and had no tools when I actually needed them. I ended up using the most brute-force walkthrough solution, which was correct but had terrible performance and code quality.
Related LeetCode Problems
- Merge Intervals
56. Merge Intervals
57. Insert Interval
Usage: Merge STRONG [0,12], STRONG [13,29] -> STRONG [0,29].
- Sweep Line
253. Meeting Rooms II
731. My Calendar II
732. My Calendar III
1094. Car Pooling
1851. Minimum Interval to Include Each Query
Purpose:
STRONG [0,29]
EM [15,55]
A [169,207]
to
0 open STRONG
15 open EM
30 close STRONG
56 close EM
169 open A
208 close A
- Difference Array, but not just numeric differences
370. Range Addition
1109. Corporate Flight Bookings
1094. Car Pooling
Purpose: Maintain active markup set
- Interval Split / Segment Construction
Purpose:
STRONG [0,29]
EM [15,55]
to
[0,14] STRONG
[15,29] STRONG + EM
[30,55] EM
Other Used Problem Types and Data Structures:
-
Event Sorting
-
Interval Partition / Segment Split
-
Stack / Parentheses Matching
-
Binary Search
-
Ordered Set / LinkedHashSet
-
Canonicalization
Case 2 — AVPlayer Cache Segment Issue
The interval problem encountered above on Medium is actually similar to one I faced before, during the development of “AVPlayer local playback with caching”.
Because streaming data is discontinuous, AVPlayer may request discontinuous or overlapping data ranges such as [0,100] [300–500] [150, 200]… from a Data of Size: 1000.
As shown in the above diagram, assuming the current data segments are: [250,566] [850,959], ideally:
-
When AVPlayer requests [0,300]: [0,249] fetched from remote, [250,300] fetched locally
-
When AVPlayer queries [350, 920]: [350,566] fetched locally, [567,849] fetched remotely, [850,920] fetched locally
At that time, I encountered the interval calculation problem — Covered / Uncovered Interval Query — but it was simpler than the Medium problem because it only involved distinguishing between binary data 0 and 1, requiring just the calculation of results.
At that time, the issue was temporarily unresolved because developing the AVPlayer’s simultaneous playback and caching feature took most of the time; plus, the scenario involved audio files, which were not large; so we directly used the approach of fetching and overwriting the entire range if data was missing — for details, please refer to the original article “AVPlayer Local Cache Implementation Guide｜Using AVAssetResourceLoaderDelegate to Save iOS Music Streaming Data“.
Overall Collaboration Process
Implementing Foundation Data Structure Design with AI
Tools
-
Claude Code Max
-
Effort: Max
-
Model: Opus 4.7
Process
-
First, Have AI Plan Mode Draft the Research RFC Writing Proposal
-
Please have the AI start the research with two agent roles: one is a graduate student responsible for researching and writing the RFC, and the other is a professor who focuses solely on reviewing the algorithm’s efficiency and validity. (Review until approval)
-
The graduate student can start by experimenting with the Medium case and try developing it using Ruby.
-
Final Output RFC.md File
-
Delegating implementation to other Agents in various languages (I handle ZMediumToMarkdown in Ruby / AVPlayer in iOS Swift)
1. AI Research and Design of Data Structure RFC — Rangeable RFC
Prompt (Plan Mode):
/plan
Please use English and refer to academic papers to draft an RFC implementation document. This document will later be delivered for other languages to follow when implementing. During drafting, you can use Ruby as the experimental language.
You need to study all data structures and algorithms to find a balanced solution in terms of time and space efficiency to meet the requirements.
Tool name: Rangeable
Function: Calculate continuous and discontinuous sets of generic object combinations.
Example:
var strings:Rangeable<String> = []
strings.insert(Strong(), start: 2, end: 5) // 2-5 Strong
strings.insert(Strong(), start: 3, end: 7) // 3-7 Strong
strings.insert(Strong(), start: 9, end: 11) // 9-11 Strong
strings.insert(Italic(), start: 3, end: 8 ) // 3-8 Italic
// Usage:
Strong().getRange(from: strings) -> [{2,7},{9-11}]
Italic().getRange(from strings) -> [{3,8}]
//
strings[4].objs -> [Strong(), Italic()]
strings[8].objs -> [Italic()]
strings[10].objs -> [Strong()]
//
Please note Strong and Italic themselves are generic; this is just an example
//
During the actual RFC drafting, use sub-agents: one as a graduate student responsible for researching implementation methods and writing the RFC, and another as a professor focusing on academic or deeper algorithms to review the graduate student's output. If rejected by the professor agent, research and rewrite the RFC.
You can first create ./RubyRangeable for the Ruby implementation and ./SwiftRangeable for the Swift implementation.
Feel free to consume tokens and resources for research.
//
Provide a real-world use case: ../ZMediumToMarkdown in MarkupStyleRender.rb
Currently parses Medium GraphQL returned Paragraphs
{"id": "f30dc1c4fe6c_19", "name": "b2ba", "type": "BQ", "href": null, "layout": null, "metadata": null, "text": "A notification webhook is an endpoint you create on your server.\n通知型 Webhook 是你在自己伺服器上建立的一個端點(endpoint)。", "hasDropCap": null, "dropCapImage": null, "markups": [{"type": "EM", "start": 0, "end": 104, "href": null, "anchorType": null, "userId": null, "linkMetadata": null, "__typename": "Markup"}], "__typename": "Paragraph", "codeBlockMetadata": null, "iframe": null, "mixtapeMetadata": null},
{"id": "f30dc1c4fe6c_20", "name": "f2e8", "type": "BQ", "href": null, "layout": null, "metadata": null, "text": "This webhook endpoint receives HTTP POST requests from App Store Connect.\n這個 Webhook 端點會接收來自 App Store Connect 的 HTTP POST 請求。", "hasDropCap": null, "dropCapImage": null, "markups": [{"type": "EM", "start": 0, "end": 126, "href": null, "anchorType": null, "userId": null, "linkMetadata": null, "__typename": "Markup"}], "__typename": "Paragraph", "codeBlockMetadata": null, "iframe": null, "mixtapeMetadata": null},
{"id": "f30dc1c4fe6c_21", "name": "1725", "type": "BQ", "href": null, "layout": null, "metadata": null, "text": "The POST requests describe important events about your app.\n這些 POST 請求會描述與你的 App 相關的重要事件。", "hasDropCap": null, "dropCapImage": null, "markups": [{"type": "EM", "start": 0, "end": 89, "href": null, "anchorType": null, "userId": null, "linkMetadata": null, "__typename": "Markup"}], "__typename": "Paragraph", "codeBlockMetadata": null, "iframe": null, "mixtapeMetadata": null},
{"id": "f30dc1c4fe6c_22", "name": "3e9d", "type": "BQ", "href": null, "layout": null, "metadata": null, "text": "Use the webhooks notifications endpoint to configure the notifications for events happening to your apps.\n你可以使用 Webhook 通知端點，來設定當你的 App 發生各種事件時所要接收的通知。", "hasDropCap": null, "dropCapImage": null, "markups": [{"type": "EM", "start": 0, "end": 151, "href": null, "anchorType": null, "userId": null, "linkMetadata": null, "__typename": "Markup"}], "__typename": "Paragraph", "codeBlockMetadata": null, "iframe": null, "mixtapeMetadata": null},
Then render Markdown according to start and end, but currently no algorithm exists so a loop filling method is used.
2. After the plan is confirmed, the graduate student Agent starts research -> produces the first version of the RFC
3. Professor Agent Starts Review -> REJECTED
The main reason is that the professor found 6 MUST-FIX issues in the RFC, meaning specification/algorithm correctness problems that must be fixed to pass.
4. Graduate Student Agent Revisits Research and Revisions -> Produces Second Version of RFC
5. Professor Agent Re-Review -> APPROVED
6. Done
-
Time spent: About 1 hr 30 mins
-
Token usage: 178K (about 30% of Claude Code Max 5 hr quota)
Rangeable RFC
TL;DR
Rangeable<Element>is a generic data structure for managing “which elements are active within which integer closed intervals.” It automatically merges overlapping or adjacent intervals of the same element and supports querying which elements are active at a given index, as well as outputting open/close transition events within a range. It was originally designed to solve Medium Markdown markup rendering issues, such as determining which styles likeSTRONG,EM, orLINKare applied to a character. However, it can also be applied to calendars, game states, genome annotation, AVPlayer byte-range cache, and more. Its core value is abstracting “interval merging, active set querying, and boundary event generation” into a deterministic, cross-language consistent specification suitable for Ruby and Swift implementations.
The following RFC details can be skipped unless you are very interested. This section is also directly translated and summarized by AI.
Rangeable<Element> is a generic data structure that maps elements to multiple integer closed intervals and allows fast queries of which elements are active at a given position.
It doesn’t just solve a simple Range problem, but gives me many (element, start, end) tuples, and I need to be able to:
-
Find which merged ranges contain a specific element
-
Check which elements are active at a specific index
-
Find which open/close boundary events occur within a certain range
The RFC clearly defines Rangeable as a language-neutral, generic, integer-coordinate, closed-interval set container. Elements must be hashable and compared by value equality. It supports three types of queries: getRange, r[i].objs, and transitions.
Main Motivation
This RFC originated from the Medium markup rendering issue in ZMediumToMarkdown.
Inside Medium paragraphs, there will be markups like this:
STRONG: [2, 5]
STRONG: [3, 7]
EM: [4, 10]
Currently, rendering requires scanning each character to determine which tags are active, such as bold, italic, link, code, etc. The RFC mentions that the original approach converts markups into TagChar, sorts them by startIndex, and then scans all tags linearly for each character, with a worst-case complexity of O(L · m). Rangeable aims to abstract this into a general container, allowing the renderer to simply insert markups and then query using r[i].objs or transitions.
The RFC also extends this problem to other scenarios, such as:
The RFC clearly states the common problem: given many (eᵢ, lᵢ, hᵢ), when querying a position i, return all elements satisfying l ≤ i ≤ h.
Core Concept Translation
1. Rangeable<Element>
It can be thought of as:
Element -> [ClosedRange<Int>]
But it is not an ordinary Dictionary, because it can:
-
Automatically merge overlapping intervals of the same element
-
Automatically merge adjacent intervals
-
Preserve the order of elements based on their first insertion
-
Support fast queries of active elements at a specific index
-
Support output of open/close transition events
For example:
insert(STRONG, 2, 5)
insert(STRONG, 3, 7)
Finally, it will become:
STRONG -> [(2, 7)]
Because [2,5] and [3,7] overlap.
API Highlights
The main APIs defined by the RFC are as follows.
insert(e, start, end)
insert(e: Element, start: Int, end: Int)
The effect is:
R(e) = canonicalize(R(e) ∪ [start, end])
That is, add a new interval with element e to the existing set of intervals, then canonicalize: merge all overlapping or adjacent intervals and sort them. start > end must throw an InvalidIntervalError; inserting the same content repeatedly is idempotent, should not change the result, nor increase the version.
r[i].objs / activeAt(index:)
r[i] -> Slot
r.activeAt(index: i) -> Slot
Return the active elements at a given index.
For example:
insert(Strong, 2, 5)
insert(Italic, 3, 7)
Query:
r[3].objs
The result is:
[Strong, Italic]
The query complexity goal is:
O(log M + r)
Here, M is the total number of intervals after merging all elements, and r is the actual number of elements returned at that position.
getRange(of:)
getRange(of e) -> [(Int, Int)]
Return the canonical ranges currently merged for a given element.
For example:
insert(Strong, 2, 4)
insert(Strong, 5, 7)
Because [2,4] and [5,7] are adjacent on the integer coordinates, the result is:
[(2, 7)]
The RFC explicitly requires that the returned intervals must be sorted, non-overlapping, and non-adjacent.
transitions(over:)
transitions(over: ClosedRange<Int>) -> [TransitionEvent]
Return the open/close boundary events within a range.
For example:
insert(Strong, 2, 5)
insert(Italic, 3, 7)
Then the transitions will be:
[
(2, open, Strong),
(3, open, Italic),
(6, close, Strong),
(8, close, Italic)
]
Note that the close event position is hi + 1 because the external semantics use a closed interval [lo, hi], but the sweep-line internally uses the “first position no longer active” as the close coordinate. The RFC clearly states that transitions(over: lo..hi) will include the close event at hi + 1, making it easier to handle the right boundary.
Interval Semantics
1. end is inclusive
This RFC is very clear: insert(e, start: a, end: b) represents a closed interval [a, b], where b itself is also included in the active range.
That is to say:
insert(Strong, 2, 5)
Representative:
2, 3, 4, 5 are all active
Not [2, 5).
The reasons for choosing inclusive in the RFC include:
-
Historical Data Model Compatible with Medium Markup / ZMediumToMarkdown
-
More aligned with the human intuition of “whether this character is active”
-
Integer adjacency merge can be written as
hi + 1 == lo -
A single-point range
[k, k]can naturally represent a valid position.
2. Adjacent intervals should be merged
On integer coordinates:
[2, 4] + [5, 7] => [2, 7]
Because there is no integer position between 4 and 5 to represent “not active,” the RFC requires that adjacent integer intervals of the same element must be merged.
But:
[2, 4] + [6, 7] => [(2, 4), (6, 7)]
Because there is a gap of 5 in the middle.
3. start == end is a valid singleton interval
insert(e, 5, 5)
It means only index 5 is active. The RFC requires this to be a valid and non-empty range.
4. start > end must throw an error
insert(e, 10, 5)
Cannot automatically reverse to [5,10] nor silently normalize. The RFC requires throwing InvalidIntervalError, and the container state must not change.
Element equality semantics
Rangeable determines whether two elements are the same by using the language’s native value equality.
Ruby:
eql? + hash
Swift:
Hashable / Equatable
So:
Link("a") and Link("a") are considered the same element, intervals will merge
Link("a") and Link("b") are different elements, will not merge
Strong() and Strong() will merge if equality matches
The RFC requires equality to satisfy reflexive, symmetric, transitive, and hash consistency properties, and elements should not be externally mutated to break hash/equality after insertion.
Sorting Rules
This is a very important part of the RFC.
Active set sorting
The order of r[i].objs is not based on hash, alphabetical order, or range length, but rather:
The order in which elements are first inserted
For example:
insert(Strong, 1, 10)
insert(Italic, 1, 10)
insert(Code, 1, 10)
Then:
r[5].objs == [Strong, Italic, Code]
The RFC states that this approach ensures determinism, cross-language consistency, and aligns with Markdown nesting: styles that appear earlier are usually outer layers.
Merge does not change insertion order
For example:
insert(Strong, 1, 5) // Strong ord = 1
insert(Italic, 3, 7) // Italic ord = 2
insert(Strong, 4, 8) // Strong ranges merge into [1,8], but ord remains 1
Query:
r[6].objs
The result is:
[Strong, Italic]
Although Strong extends to index 6 only in the third step, its first-insert order is still earlier than Italic. The RFC uses this case to fix “the order of an element’s first appearance” as the sorting criterion.
Transitions Sorting
At the same coordinate:
-
.opencomes before.close -
Multiple
.open: ascending by insertion order -
Multiple
.close: in descending insertion order, which is LIFO
This complies with Markdown stack discipline:
** open
_ open
_ close
** close
The RFC clearly defines this tie-breaking to avoid inconsistent Ruby / Swift hash order causing different cross-language outputs.
Internal Data Structures
The core design chosen for the RFC is:
Map<Element, SortedList<Interval>>
+ insertion_order
+ lazy boundary-event index
+ version counter
1. Per-element sorted disjoint list
Each element has its own interval list:
intervals: Map<Element, SortedList<Interval>>
And it must maintain the canonical form:
-
Sort in ascending order by
lo -
Non-overlapping with each other
-
Non-adjacent to each other
-
Each interval satisfies
lo <= hi
The RFC calls this the I1 invariant.
2. Lazy boundary-event index
Rangeable does not rebuild the query index on every insert; it only builds it at the first query.
version: Int
event_index: EventIndex?
event_index contains:
events: SortedArray<Event>
segments: SortedArray<Segment>
version: Int
This design is meant to fit the “build-once-then-query-densely” workload: a large number of inserts followed by dense queries at each position. The RFC clearly states that a lazy index suits this pattern because the build phase does not require constant index rebuilding, and the query phase pays the O(M log M) cost only once.
Algorithm Highlights
Core Process of insert
The pseudocode of the RFC is roughly:
function insert(r, e, start, end):
if start > end:
raise InvalidIntervalError
e_frozen = freeze_for_insert(e)
if e not in intervals:
intervals[e] = []
insertion_order.append(e)
ord[e] = insertion_order.length
list = intervals[e]
lo = start
hi = end
Find the first interval that may overlap or be adjacent to [lo, hi]
while interval overlaps or is adjacent to [lo, hi]:
lo = min(lo, interval.lo)
hi = max(hi, interval.hi)
Remove the old interval
Insert the merged new [lo, hi]
If there is a real change:
version += 1
event_index = nil
Note that the RFC warns against using lo - 1 for checks because it can underflow when lo == Int.min; instead, use hi + 1 >= lo or an equivalent successor model.
Complexity
The reference structure chosen for the RFC is:
per-element sorted disjoint list + lazy event index
The complexity is roughly as follows:
Among them:
m_e = The number of merged intervals of a certain element itself
k = The number of old intervals absorbed/merged in this insert
M = The total number of merged intervals of all elements
r = The actual number of active elements at the query position
The RFC also points out that if there are truly m active elements at the same position, the output itself requires Ω(m), so O(log M + m) is already a reasonable output-sensitive bound.
Why not use Interval Tree / Segment Tree / Roaring Bitmap?
The RFC has a whole section comparing alternative solutions and ultimately chooses (a) Per-element sorted disjoint list + lazy event index.
Key points:
Three reasons for choosing the main structure in the RFC summary:
-
The term “per-element merge” is natural, and
getRangecan directly returnR(e). -
deterministic, cross-language reproducible
-
lazy index is well suited for build-once-then-query workloads
Features not included in v1
RFC clearly lists what v1 will not do:
remove(e, start, end)
remove(e)
clear
union / intersect / difference
persistent immutable snapshot
floating-point coordinates
multi-dimensional rectangle stabbing
r[lo...hi].objs range slot query like this
Please also have AI handle deletion and intersection in the RFC V2 implementation.
Ask AI to implement language versions based on Rangeable RFC
Process
-
Start with
/planPlan Mode, ask AI to carefully read the RFC and plan the implementation. -
Split the roles as developer/reviewer, one writes and the other reviews, until there are no issues.
-
Write Readme Documentation and Push to GitHub
The most difficult RFC specification research has been completed. As long as AI implements according to this specification, there will hardly be any issues in the later implementation.
Currently implemented languages are as follows
-
Ruby 3.2+ github.com/ZhgChgLi/RubyRangeable
-
Swift 5.7+ github.com/ZhgChgLi/SwiftRangeable
-
Python 3.10+ github.com/ZhgChgLi/PythonRangeable
-
TypeScript / JS (Node 18+) github.com/ZhgChgLi/JSRangeable
-
Kotlin / JVM 11+ github.com/ZhgChgLi/KotlinRangeable
-
Go 1.22+ github.com/ZhgChgLi/GoRangeable
Practical AI-Designed Development — Rangeable Foundation
After everything is ready, return to the original algorithm issue in the open-source project ZMediumToMarkdown. Have the AI apply this Lib to replace and remove the original complex walkthrough approach, optimizing the architecture + adding validation tests before and after application.
ZMediumToMarkdown 3.6.0
Performance
-
Micro-benchmark: 5.5× faster on the markup render hot path.
-
End-to-end on a real Medium article: 2.23× faster
(2073 µs → 930 µs per paragraph on average).
AVPlayer Local Cache Implementation Guide
The article also adds more examples of applying SwiftRangeable.
Admiring AI
Previously, AI was only used for application tasks, such as redesigning websites, personal dashboards, or fixing product issues at work; this was the first time it was asked to deeply research algorithm solutions and underlying data design.
The results exceeded my expectations. After roughly reading the RFC he wrote, both the format and content are as good as those produced by real researchers (at least definitely better than what I write). I observed what he was doing: he used Web Search to find public related papers or technical documents, then integrated and assessed the feasibility of the implementation. Splitting the roles into doer and reviewer was also very effective—the doer tends to focus too much on implementation, while the reviewer can take a broader and higher-level view to check if the doer’s work has any side effects. Finally, after the RFC was finalized, the AI implemented based on the document with almost 100% accuracy.
Reflections on AI Usage
However, there is no need to fear being replaced by AI. The key is problem-solving thinking, which AI is still weak at; for example, if you directly ask it to optimize ZMediumToMarkdown, it may only focus on the Medium scenario and the original code style. But humans know to abstract it into a Foundation, study the RFC first, and then implement it, which works much better. Of course, we can do it ourselves, but it takes time. AI helps us speed up this process, not replace us.
Comments