Promptless (YC) | Founding Docs Practice Lead | San Francisco (Onsite) | Full-time | $140k–$200k + equity
Promptless builds AI agents that automatically update customer-facing documentation. Startups, CNCF projects, and Fortune 500 companies use us. YC-backed with a seed round from top VCs and angels.
This is a one-of-one role. You'll own the documentation practice at Promptless: onboarding customers onto the platform, building the methodology for AI-assisted documentation, and growing our reputation as the company that makes docs teams more effective. Think practice lead at a top consulting firm, except the domain is docs and the leverage is AI.
You should have deep experience in technical documentation (developer docs, API references, support content), be comfortable reading code, and be excited about pushing the boundaries of LLM-assisted writing. You'll be building this function from scratch, so an entrepreneurial mindset is key.
Ha, this is funny (also sad for me because I failed to explain on website clearly) because you have described exactly what it does as an example of what it can't do.
The core loop is more like a truffle-hunting pig than a ghostwriter. Promptless watches for signal that your product is behaving differently from the live documentation. It watches PRs opened/merging, Slack threads, support tickets. Then like a pig alerting on a truffle it shows up like "hey, this section over here doesn't match what the code/product does anymore."
Now of course we'll also generate a first draft of a suggested fix, but I want to say 40% of tech writers just like knowing when things changed.
Its a proper union find algorithm, where every suggestion links back to the source that triggered it, but multiple source do get linked up to just a single canonical suggestion. So you don't get duplicate alerts if people keep talking for weeks about a fix going out in the next release.
Obviously I've got some more work to do on the website again but c'est la vie.
It's already happened to me. I've started to have dreams where instead of some sort of interpersonal struggle the entire dream is just a chatbot UI viewport and I'm arguing with an LLM streaming the responses in. Which is super trippy when I become aware its a dream. In the old days I'd dream about playing chess against myself and lose which was quite bizzare feeling because my brain was running both players. But thats totally normal compared to having my brain pretend to be an LLM inside a dream.
The literal writing of the code was hard. This revisionism about how we were all secretly shakespeare typing monkey scammers pulling the wool over the eyes of the economy drives me nuts. Choosing which words to put in the editor, how to express all these ideas in a limited syntax. That was the big skill.
Sure, writing a program that makes a machine kind of do something was easy. Lots of people can do that. But then you ship a mobile app to a billion users and discover that people are genuinely wired differently.
different cultures, different mental models, different expectations
Now you have to accommodate and express all of that complexity in a language whose only reader is a machine that tolerates zero ambiguity. And you have to do it in a way that other engineers can read, reason about, and build on top of without the whole thing exploding. That's not requirements gathering. Its literally writing it down
You're doing the thing where you read code like a fish breathes water and conclude it was easy to write. You can read a Nobel Prize novel in a weekend too. The readability is the achievement, not evidence it was trivial.
I program for 20 years. More than half of my life. Some people forget how they felt as beginners, I did not. Which I know, since I teach programming as well.
As a beginner syntax is the hard thing, remembering how to write a thing. As a beginner you don't even think about structure, how to write maintainable or testable code — you're just happy it eventually works for you. Depending on the beginners character they might fall into the trap of thinking more complicated code using more advanced language features is a sign of a genius programmer.
When you're getting better you realize that writing the code is indeed the easy part and that you should avoid writing code that is too clever unless it is well localized and neatly tucked away. Writing clever code is something that does not impress you at all — quite the opposite as it is usually just unnecessary bragging. The hard part after all isn't writing clever code, it is finding good abstractions, staying consistent, writing maintainable and testable code without being too smart. It is understanding and then solving the real world problem in an elegant way. It isn't writing what the customer think they want, it is writing whst they truly need.
That does not mean actually writing the code isn't specialized work that requires skill. But it just isn't the hardest part of the job. Just like knowing how to use the tools isn't the hardest part for a car mechanic. Making sure that the car drives reliably, you chose the right parts, you did it fast and efficiently is.
I think we’re agreeing and likely have different understandings of what’s meant by “code wasn’t the hard part”. What you’re describing is what I’m calling the hardest part: building a system. To me that’s different from “coding”. This isn’t engaging in revisionist history. It’s why I’m referencing a book written 51 years ago, almost two decades before I was born,[0] and referring to a joke about systems design from ‘99[1].
Edit: This also isn’t to say that _millions_ around the world aren’t employed just to write code. This isn’t to say LLMs aren’t hugely disruptive. This isn’t even to say they aren’t also good at the hard parts. It’s just to say there’s a difference between coding and systems design and one is harder than the other in most cases in most jobs.
>That’s not evidence the task was easy. That’s evidence it was so hard...
Are humans starting to adopt LLM patterns or was this was ironically written with an LLM?
That said, I'm surprised you didn't bring up Marx in your essay in the later sections. I vaguely remember he had some thoughts about derivation of value from labor vs "ideas/capital". Whether or not you agree, this debate is reminiscent of that just moved up one level to white-collar workers.
You've described PMs running circles around you and you still can't see it. They didn't need to praise you or pressure you. They seem to have all caught on that your button is let you feel smarter than them. You did their job, did a bunch of physical typing they would otherwise have to do themselves, and walked away thinking you won.
Meanwhile they're pulling the same or greater comp, working half the hours, and "drinking beers with important people" is an accepted part of their job. The status hierarchy you're describing where they suck isn't real. It's a useful fiction that keeps you grinding while they harvested your output.
Everyone becoming a PM is a good thing precisely because PMs don't work as hard. Wouldn't a job be more pleasant if you could meet expectations by lunch? Imagine how psychologically freeing that would be. Dreadful future my ass.
Considering every time they left not a single thing changed, as though they were never there, because I was the one actually organizing the projects, I doubt they were running circles around me. Likely dicking around with Jira for 5 hours to siphon money from our company instead of actually organizing the project.
> Meanwhile they're pulling the same or greater comp, working half the hours, and "drinking beers with important people" is an accepted part of their job
You took the words right out of my mouth. Almost like it's a made up job and not the real work that needs to get done.
Thats what we call a Staff level engineer. Proven ability to learn, implement and validate is basically the "it factor" businesses are looking for.
If you are thinking about this from an academic angle then sure its sounds weird to say "Two Staff jobs in a row from the University of LinkedIn" as a degree. But I submit this as basically the certificate you desire.
No, this is not at all being a staff engineer. One is about delivering high-impact projects toward a business's needs, with all the soft/political things that involves, and the other is about implementing and validating cutting-edge research, with all the deep academic and technical knowledge and work that that involves. They're incredibly different skillsets, and many people doing one would easily fail in the other.
Counter argument: people invest in bonds. Quite a lot of bonds in fact.
Picking up pennies in front of a steam roller and counterparty risk seem to be perennial favorites of youth, but I hazard to guess only a minority in the market have flesh yet untouched by fire.
Well, I've been using it more than two weeks (though I did just spend a month in Tokyo) so ... not sure how to answer that :)
Do you mean generally though - how many facts does it extract from a typical document of X length? Or do you mean what my own personal corpus currently is?
Size of your personal corpus is a rough signal of usefulness. If you've been using it a while and you have 500 facts, thats very different from 5000 facts.
My crappy personal system is a telegram channel "Today I Learned" that grows at roughly 5 messages per day. The search is obviously much worse than your tool.
The design of no rewrites for facts storage was an approach I have not seen from any of my friends' agent memory setups, so that difference struck my curiosity for how well its working in practice.
If you're talking about the "Fastrecall" part of it, it's clamped to around 3000 entries. Beyond that...I mean...it's just a JSON file. How much do you hate yourself? lol :)
I use mine as intended (well, by me) as a short term memory store with a TTL of 14 days. Right now it has...350ish stored facts with different expiration dates. You can play around with the settings and max resets (touches), but if ctx > max_items, janitor rolls in and the oldest get pruned anyway.
If you're talking about the chat bloat control part (cut the crap), I set mine to keep the last 2 user/assistant pairs and a soft cap of 2000 characters. That middle part obviously decays during the chat. I like to keep my chatty fast.
If you're asking about the KB (attach) system: generally speaking, the SUMM function seems to generate a summary of upto about 1500 characters. That's what...250 words? Short and sweet...because again, potato pc + smart grep = don't be stupid.
In theory, the KB thing is limited by you SSD and pain tolerance. I have about 1500 items I query against and it's still in the sub-secondish range.
Mentats / vault? Scales via Qdrant.
Does that answer it? None of this shit is enterprise grade; it's purely for personal use.
Promptless builds AI agents that automatically update customer-facing documentation. Startups, CNCF projects, and Fortune 500 companies use us. YC-backed with a seed round from top VCs and angels.
This is a one-of-one role. You'll own the documentation practice at Promptless: onboarding customers onto the platform, building the methodology for AI-assisted documentation, and growing our reputation as the company that makes docs teams more effective. Think practice lead at a top consulting firm, except the domain is docs and the leverage is AI.
You should have deep experience in technical documentation (developer docs, API references, support content), be comfortable reading code, and be excited about pushing the boundaries of LLM-assisted writing. You'll be building this function from scratch, so an entrepreneurial mindset is key.
Read more: https://promptless.ai/jobs#founding-docs-practice-lead
Email us directly: founders@promptless.ai (mention HN!)
--- ALSO ---
Promptless (YC) | Founding Engineer | San Francisco (Onsite) | Full-time | $140k–$200k + equity
As a Founding Engineer, you'll build the core product—AI agents, integrations, and infrastructure that powers automatic documentation updates.
Read more: https://promptless.ai/jobs#founding-engineer
Same deal. Email us directly: founders@promptless.ai (mention HN!)
reply