Page 3 of 7

Unfiltered thoughts of an FDE founder

Anusheel BhushanAnusheel Bhushanco-founder of PlankFollow on LinkedIn 

July 2026

Plank

Founders must pick between being a virus or a dinosaur

As a startup founder, you only have two paths. Be a virus or be a dinosaur - both are apex predators in nature. Path 1: Be a dinosaur. Your goal is to keep getting bigger and bigger. The idea is simple - you can keep upselling more things to your existing customers. Companies like Salesforce have executed this strategy well. Path 2: Be a virus. You stay laser-focused on a single product or line of business, and you keep your org and core team extremely small and lean. Cursor and Instagram are examples - both built massive businesses with tiny teams. There's no wrong answer. But you have to pick one.

Coding agentsSoftware architecture

Coding models should be trained for concept minimalism

I hope OpenAI and Anthropic include elegance and concept minimalism as a metric to train against in post training for coding models. These models require a lot of guardrails to be put in the harness else you end up with a cambrian explosion in concepts in your code very quickly. And once that happens, it is hard to backtrack. In the meantime, I recommend people to add a couple of these steps in your harness pipeline: - as one of the adversarial review steps, ask to count the number of new concepts added and critically evaluate if they are absolutely needed. - in systems that involve AI prompts code and software code, don't let the deterministic code be over-engineered. When in doubt, rely on the AI prompts vs hard-coded code. - be clear in your agents.md and claude.md that you like simplicity and elegance. In the coming days, I will share more about my harness where I have this working. In the meantime if you're interested, DM me and happy to show you.

June 2026

Coding agents

The joy of figuring out how software works may be lost

This was beautiful to read - the joy of understanding how something works, reverse engineering a piece of software or debugging something for hours and the joy of "figuring it out" is something that might become a lost art in the decades to come. I feel this will cause us to spend a lot more time introspecting - what do we really want, dig into the motivations behind our want and the guardrails around what are we ok with. unix.foo/posts/last-people-who-know-how-it-works

Coding agents

PostHog's 70x faster SQL parser built with Claude Code

Robbie Coomber from PostHog rewrote PostHog's SQL parser using multiple long-running Claude Code sessions in parallel. The result was 16K lines of "hand"-rolled parser code, 5K lines of tooling, a few more K of tests, and a ~70x speed up! Thats awesome. There really is no excuse to not ask Claude or Codex to optimize your codebase. Of course it requires providing the right evals and harness so that it has a way to measure correctness in an objective way. Also I love that they have a formal declarative grammar for the parser using ANTLR .g4 format. Read more here: posthog.com/blog/sql-parser

Software architecture

Microsoft pg_durable and keeping everything in the database

Microsoft open sources pg_durable - this allows durable task execution within PostgreSQL. I personally really like the pattern of keeping everything within the database and avoid external queues, multiple databases to manage state, locks etc. Every additional architecture module introduces complexity that might not be needed. In most applications if you keep everything within the DB, it makes each individual flow fast, clean, contained. And re: scaling, just scale vertically and then shard as needed. That works for most b2b apps. github.com/microsoft/pg_durable

Each post links to the original on LinkedIn. Posts are republished as written; quoted posts are shown as an excerpt with a link to their author. Back to the newest posts.