The document for my latest newsletter is 5,381 words long including:
- 963 word outline
- 1855 word first draft
- 1299 word second draft
- 1056 word final post
The final word count might not be a lot, but it's the result of a lot of work.
Read it here → newsletter.posthog.com/p/the-engine...
Engineering has escaped the codebase. The tools, mindset, and identity shape every function.
Spend time in startup circles and you’ll hear everything from design to support referred to as engineering.
I wrote about how this happened and why it matters to you.
newsletter.posthog.com/p/the-engine...
Read more in @matloka.com's post on 8 learnings from 1 year of agents below.
posthog.com/blog/8-learn...
8. Evals are not nearly all you need. Reality is gnarly. The team looks at raw evals, real usage, and production traces. This is critical for building successful agents.
7. Frameworks lock you into ecosystems but evolve much slower than LLM capacities. Abstractions and ways of thinking crumble when AI providers add new models and features. We are staying neutral and low-level.
6. We tried hiding the details that seemed to raw, but users constantly gave feedback that the process seemed to be a mystery. Showing every step, tool call, and reasoning token helps people trust the process and build confidence in what’s happening.
5. Context really matters because people define tasks in the most ambiguous ways. Core context massively improves agent trajectories. PostHog AI has a /init command that learns about your product or business (with web search) to give valuable project-level memory.
4. To-dos are superpowers. They are deceptively simple but keep the LLM on track when it’s time for next steps.
3. Even in an agentic loop, it's tempting to organize task execution into specialized subagents, but these abstractions cause context lose which washes away the ability to string tools together and self-correct. Subagents can work for parallelization though.
2. Graph-style workflows were once the way but not anymore. In a graph, LLMs can’t self-correct and context is lost too easily. Capability advancements enabled agents which can execute dozens of steps while continuously verifying output.
1. Model improvements are a bulldozer. Tool use has improved massively in a year. Frontier models make sense of complex tools with much greater reliability. Cost-effective reasoning models significantly improved and simplified complex query creation.
After 1 year of building AI agents for @posthog.com, here are the top 8 things our team learned:
You can find all this advice and more in his post on how he actually gets good advice → newsletter.posthog.com/p/how-i-actu...
5. Focus on diagnoses rather than solutions. The person giving you advice is not going to nail the solution every time, but they are pretty likely to nail the problem (because there are way more solutions than problems and problems don’t vary as much.
4. Start closer to home. If an option, he your team can be a great source of advice. For example, he interviewed every new sales hire about their background and what we should do differently at PostHog.
3. Do some legwork. Write a one pager with a summary of the company, team status, and specific questions you need help with. Sending this to them before the call is the single most important thing he’s done to get better advice.
2. Ask the “right” people. Looks for decent stint (5+ years) at good company.
1. Be intentional and casts a wide net. Picks a topic you don’t have strong conviction on, find 4 people who have done that things successfully, and get intros/cold message them. Multiple people will say different things, that’s ok.
I recently learned the reason why Charles is so good at his role as “generic executive”: He hops on a lot of quick calls (taking @j406.bsky.social advice to heart).
What does he do on those calls? He gets advice.
Here are his top 5 pieces of advice for doing this well:
To get all the details, check out my non-obvious pricing advice for startups → newsletter.posthog.com/p/non-obviou...
Predictable and transparent pricing is better than simple pricing. This lets you better charge for the value you provide while still being fair to customers.
Billing will become a bottleneck. We have always had engineers working on our billing system to let us charge how we want, handle corner cases, and makes it more accurate and reliable.
Frequently changing pricing is totally normal. Our pricing went from monthly subscriptions to usage-based pricing to having a huge free tier.
Charging anything is better than giving software away. It’s scary but not as scary spending months building something no one will pay for.
How you price is who you are. Pricing isn’t just how you make money, it defines your identity, how you market, and how you sell.
After weeks researching how we do pricing at
@posthog.com, I published a deep dive with all the non-obvious things I learned. Here are a few of the best ones:
I wrote about a bunch more benefits like this here -> newsletter.posthog.com/p/the-hidden...
Hiring people who contribute to their open-source project is beneficial to both parties:
1. Companies can find people who are familiar with their code and domain.
2. Companies can't lie when their work is in the open. This lowers the risk of their expectations not matching the reality of the job.
Benefits include:
- Attracting early employees
- Engineers know what they are getting into before they start.
- They know their code will see the light of day.
- They can contribute before they start.
Being an open-source startup has many benefits, but one that doesn’t get thought of: HIRING.
The fact that @posthog.com is open source has been instrumental to our hiring process from the earliest days until now.
