Philipp Steinrötter
788 posts
Philipp Steinrötter
@psteinroe
cofounder @hellomateode • hacking on a postgres language server • os hobbyists • postgres fan
Berlin, Germany Katılım Şubat 2022
658 Takip Edilen872 Takipçiler
Philipp Steinrötter retweetledi
All the best programmers I know are starting to write code by hand again
English
Philipp Steinrötter retweetledi
A common dynamic I observe with AI: it feels most impressive when you don’t know much about the subject, don’t care or don’t have a clear idea of what the you want.
This applies across design, code, legal, and more. If I don’t know code very well, every piece of code it writes feels very impressive.
Once you know what something should feel or look like, it becomes almost impossible to guide AI there. And you definitely can’t one-shot it.
English
Philipp Steinrötter retweetledi
great post by @badlogicgames
mariozechner.at/posts/2026-03-…
English
offline for three weeks for the first time in years. can attest the single best way to get rid of ai psychosis is to slow down and touch grass
English
@SanfordMarshal @tannerlinsley same issue! „solved“ by forcing a reload. only happens sometimes and not with every deployment though. did you find a proper fix?
English
Idk what to do anymore, @tannerlinsley one of the side effects of migrating from Next to TanStack Start + Vite(8) is this. Some users hit this error on new pages and it crashes. Does anyone else have this problem?
English
@jarredsumner what do you need from me to reproduce and fix this?
English
i am going crazy with claude code recently. it consistently does not start to work until i interrupt and send the same prompt again. the status does update when its done and i have to 'esc' again.
GIF
English
i’ve been fighting a bit of “ai brain fry” lately and realized it mostly comes down to discipline.
as a tech leader, the roi for certain tech debt projects has dropped because coding agents make things possible that i probably would not have started before.
as a developer, there are tasks i am genuinely happy to give to agents. they are great at resolving merge conflicts, updating dependencies, and chipping away at tech debt.
they are also incredibly useful when building and designing systems because they speed up early iteration, help retrieve knowledge quickly, and can write down ideas faster than i can.
but when it comes to validating ideas, creating a system and shipping a product, it takes a lot of discipline not to skip over the details, especially when time is limited.
it feels a bit like playing age of empires with cheat codes. it is fun for a few minutes when a blue shelby runs over everyone, but the game quickly stops being interesting and you feel disconnected from it and learn nothing about it.
Mo@atmoio
I was a 10x engineer. Now I'm useless.
English
@SanfordMarshal @tan_stack @tannerlinsley we have a separate backend. the 800$ were for their managed build pipeline.
English
@psteinroe @tan_stack @tannerlinsley What did you do for your bill to go to 0? Do you also run your backend on Vercel? My bills are getting expensive 😭😭😭😭😭😭
English
we were still on next 14 and decided to switch to @tan_stack instead of upgrading.
results:
• hmr: 2–10s → almost instant
• fixed several long-standing issues during migration because it nudges you toward better patterns
• vercel bill: $800 → $0
thanks @tannerlinsley! 🏝️
English
@tyteen4a03 @MoodiSadi @tan_stack @tannerlinsley ah lol yeah true. still improving my ai detection skills 🥲
English
English
@tyteen4a03 @MoodiSadi @tan_stack @tannerlinsley spent my morning coffee answering everyone with my own hands. 🥲 why does it feel generated to you?
English
@psteinroe @MoodiSadi @tan_stack @tannerlinsley Guy is chatgpt hooked up to a twitter account lol, look at all his replies
English
@ward_lavrijsen @tan_stack @tannerlinsley we still host on vercel! sorry, I did not make that clear enough. The 800$ were for their hosted builders. We moved it into our blacksmith.sh-hosted gh runners now. it has much better cache locality for the monorepo packages and barely adds anything to our cpu time.
English
@psteinroe @tan_stack @tannerlinsley Where did you move the hosting to and what are you paying for the new hosting?
English
@greypixel_ @tannerlinsley @tan_stack I used both mainly because I needed both limits 😅 but in general I find codex smarter. claude is great for crunching through repeated tasks though.
English
@psteinroe @tannerlinsley @tan_stack Might give it a go.
Re: Claude vs codex - if you used both do you have any general “x is best for this part” advice?
English
@ugbahisioma i think thats the tweet with the highest engagement for me
English
well.. that struck a nerve apparently
Philipp Steinrötter@psteinroe
we were still on next 14 and decided to switch to @tan_stack instead of upgrading. results: • hmr: 2–10s → almost instant • fixed several long-standing issues during migration because it nudges you toward better patterns • vercel bill: $800 → $0 thanks @tannerlinsley! 🏝️
English
@greypixel_ @tannerlinsley @tan_stack there are two ways to do this: wrap all next runtime apis and do it incremental, or lock yourself in a room with Claude Max and Codex Pro and brute-force it. We did the latter, but it depends.
x.com/psteinroe/stat…
Philipp Steinrötter@psteinroe
let me try to remember the steps: preparational work made sure every page was a single "app" component upgraded all dependencies that were at risk of causing cjs issues created an empty app with the root + routing + i18n + auth setup to learn patterns and document them set up tanstack start mcp, /agent-browser, and a custom skill based on the migration guide in the tanstack docs did a few days of dry runs to see where coding agents struggled and created a messy tasks document for the actual migration (~1 day by 1 person with codex pro and claude max) applied the next2tanstack codemod for the mechanical pieces (route file structure, next/link, next/image, next/use-client) and fixed some of the things it missed migrated all routes. 95% of them were just a hoc + a single app component, so this was basically a one-shot handled the remaining next-specific migrations (next/lazy, next/script, next/image → unpic/react) migrated off nuqs (no tanstack adapter yet) removed or replaced the remaining next-specific packages then fixing the things that broke, mostly server/client boundaries for the few things we do on the server dependencies that do not support esm, or should not run during ssr, were causing crashes. most of them were fixed quickly by upgrading to the latest version, using a vite plugin, or switching to clientonly / lazy imports we did ~2 days of reviewing and testing, and had our support team work in the new app for a day until we were confident enough to release it. it was quite messy, and this approach was really only possible because of coding agents, weekend work, and a small committed team. in larger teams (we are 6 devs), i would first wrap the next/ apis and do it incrementally.
English
English
let me try to remember the steps:
preparational work
made sure every page was a single "app" component
upgraded all dependencies that were at risk of causing cjs issues
created an empty app with the root + routing + i18n + auth setup to learn patterns and document them
set up tanstack start mcp, /agent-browser, and a custom skill based on the migration guide in the tanstack docs
did a few days of dry runs to see where coding agents struggled and created a messy tasks document
for the actual migration (~1 day by 1 person with codex pro and claude max)
applied the next2tanstack codemod for the mechanical pieces (route file structure, next/link, next/image, next/use-client) and fixed some of the things it missed
migrated all routes. 95% of them were just a hoc + a single app component, so this was basically a one-shot
handled the remaining next-specific migrations (next/lazy, next/script, next/image → unpic/react)
migrated off nuqs (no tanstack adapter yet)
removed or replaced the remaining next-specific packages
then fixing the things that broke, mostly
server/client boundaries for the few things we do on the server
dependencies that do not support esm, or should not run during ssr, were causing crashes. most of them were fixed quickly by upgrading to the latest version, using a vite plugin, or switching to clientonly / lazy imports
we did ~2 days of reviewing and testing, and had our support team work in the new app for a day until we were confident enough to release it.
it was quite messy, and this approach was really only possible because of coding agents, weekend work, and a small committed team. in larger teams (we are 6 devs), i would first wrap the next/ apis and do it incrementally.
English
@psteinroe @tannerlinsley @tan_stack Philipp this is exactly my situation. A nextjs 14 pages router app. Live SaaS, mid size.
Planning to migrate to tanstack.
Would you mind sharing the most helpul resources you used?
Any guidelines would help. Thank you!
English
@Jordi_Up @tan_stack @tannerlinsley i did not do a 1:1 comparison, but they went from 8 minutes on vercel to 2–3 minutes on blacksmith.sh-hosted gh runners. it's not an entirely fair comparison because we are building more in parallel on the gh runners, so turborepo cache locality is much better in our monorepo.
English
English
@gill_kyle @tan_stack @tannerlinsley performance is one thing, but tanstack start also feels like a sane framework built by sane people. it nudges you toward writing better react and gets out of your way. next 14–16 made me feel like the community is part of an experiment it didn’t sign up for.
English
@psteinroe @tan_stack @tannerlinsley Ain't it beautiful. Did the same thing last year: kylegill.com/essays/vite-vs…
Turbopack has gotten a lot better the last bit but Vite is still the undefeated champion.
English