I've been having good luck with fairly autonomous LLM coding with the following rules:
* TypeScript everywhere with extreme enforcement of the type system.
* No "as" casts, no "any" declarations, all code must understand the shape of its data
* All boundaries validated using a typed validation library. Many use zod, I prefer tjs. I also have strictly typed pg and express wrappers.
* No files longer than 300 lines
* All of these rules are enforced by an eslint configuration that runs in a pre commit hook.
Global state and classes could also be removed via eslint rules, that would be interesting, though I haven't found it to be an issue in practice once the types are strictly enforced.
Can't fully enforce that one, but I require only my specific HTTP router / SQL library to be used, and disallow the import of express / pg libraries via eslint. I also disable the use of JSON.parse via eslint. Combined with strong language in the CLAUDE.md, I haven't seen it get around my guard rails.
You can post-IPO - depending on liquidity. I don't think that'll be an issue here.
And if the thesis of "it's going to look good for the first 15 days" holds, you can indeed be very profitable by e.g. buying ATM puts. (The problem being that markets don't like sticking to time tables just to accommodate your investment thesis ;)
So yes, you'll be able to take a bearish position fairly shortly after the IPO.
Saying that becoming an EM is "moving away from tech" is crazy. As an EM you will be steeped in tech, just as you would be as an IC. It just may not be the tech you want to be steeped in. Again, same as an IC. In either case, unless you are working in AI, you will need to "play" with things like OpenClaw in your spare time.
The real reason not to become an EM in 2026 is because AI makes our jobs 10x harder.
> The real reason not to become an EM in 2026 is because AI makes our jobs 10x harder.
This is true, but our job was getting kind of boring anyway. Time to lead, not manage. We should be having just as much fun as the ICs, and the best I know are having the time of their lives.
I've created my own "claw" running in fly.io with a pattern that seems to work well. I have MCP tools for actions that I want to ensure human-in-the loop - email sending, slack message sending, etc. I call these "activities". The only way for my claw to execute these commands is to create an activity which generates a link with the summary of the acitvity for me to approve.
Nope! The summary is presented to the user via a link and once the user follows the link and approves, the action is implemented entirely outside of the agent, on a separate server.
The approval-link pattern for gating dangerous actions is something I keep coming back to as well, way more robust than trying to teach the agent what's "safe" vs not. How do you handle the case where the agent needs the result of the gated action to continue its chain? Does it block and wait, or does it park the whole task? The suspend/resume problem is where most of these setups get messy in my experience.
No, I'm quite confident that I'm very strong in these languages. Certainly not world-class but I write very good code and I know well-written code when I see it.
If you'd like some evidence, I literally just flipped a feature flag to change how we use queues to orchestrate workflows. The bulk of this new feature was introduced in a 1300-line PR, touching at least four different services, written in Golang and Python. It was very much AI agent driven using the flow I described. Enabling the feature worked the first time without a hiccup.
(To forestall the inevitable quibble, I am aware that very large PRs are against best practice and it's preferable to use smaller, stacked PRs. In this case for clarity purposes and atomicity of rollbacks I judged it preferable to use a single large PR.)
I built TJS over my holiday as a way to experiment and get better at agentic coding. I was astounded at how quickly software can be built when you have a full test spec like JSON Schema has.
The thing I'm most proud of is the TypeScript type inference. It automatically deduces the types from the JSON Schema. Try it out in the playground to see what I mean! https://sberan.github.io/tjs/#playground
I used similar techniques to build tjs [1] - the worlds fastest and most accurate json schema validator, with magical TypeScript types. I learned a lot about autonomous programming. I found a similar "planner/delegate" pattern to work really well, with the use of git subtrees to fan out work [2].
I think any large piece of software with well established standards and test suites will be able to be quickly rewritten and optimized by coding agents.
reply