One of the biggest gifts in life is to find a true passion. And for every passion there are two sides to the coin - the joy and the suffering. The agony and the ecstasy. It’s a gift to care so much; and it inspires.
Yes. For someone who’s already financially comfortable, it’s nice to be able to stay in the game, keep working with great people, and make some money without having to deal with burnout.
Lots of people in tech like their jobs; they just like other things too. Personally I don’t know why I would want to stop working completely. It sounds boring. I love to build. Why ever stop?
Claude code does utilize both the full Sonnet model and the lighter Haiku model in an automatic way. When you exit a Claude code session, it gives you the stats (tokens, cost, etc). I expect there’s a way to get this in-session as well.
In the US, “Junior” pilots typically work as flight instructors until they have built up enough time to no longer be junior. 1500 flight hours is the essential requirement to be an airline pilot, and every hour spent giving instruction counts as a flight hour. It’s not the only way, but it’s the most common way. Airlines don’t fund this; pilots have to work their way up to this level themselves.
I feel the same way about code generation vs code review. Everyone knows there are deep problems with LLM generated code (primarily, lack of repo understanding, and proper use of library functions).
Deep, accurate, real-time code review could be of huge assistance in improving quality of both human- and AI-generated code. But all the hype is focused on LLMs spewing out more and more code.
In my experience working on JB extensions, Rider is the most different of the IDEs. Most people think of just IntelliJ and that’s the same code base as eg PyCharm. But Rider seems substantially different.
This is what’s needed to get the most out of these tools. You understand deeply how the tool works and so you’re able to optimize its inputs in order to get good results.
This puts you in the top echelon of developers using AI assisted coding. Most developers don’t have this deep of an understanding and so they don’t get results as good as yours.
So there’s a big question here for AI tool vendors. Is AI assisted coding a power tool for experts, or is it a tool for the “Everyman” developer that’s easy to use?
Usage data shows that the most adopted AI coding tool is still ChatGPT, followed by Copilot (even if you’d think it’s Cursor from reading HN :-))
I wrote a SWE bench solver. The SWE bench issues are on mature projects like Django.
The objective of my solver was to get good solutions using only RAG (no embeddings) and with minimal cost (low token count).
Three techniques, combined, yielded good results. The first was to take a TDD approach, first generating a test and then requiring the LLM to pass the test (without failing others). It can also trace the test execution to see exactly what code participates in the feature.
The second technique was to separate “planning” from “coding”. The planner is freed from implementation details, and can worry more about figuring out which files to change, following existing code conventions, not duplicating code, etc. In the coding phase, the LLM is working from a predefined plan, and has little freedom to deviate. It just needs to create a working, lint-free implementation.
The third technique was a gentle pressure on the solver to make small changes in a minimum number of files (ideally, one).
AI coding tools today generally don’t incorporate any of this. They don’t favor TDD, they don’t have a bias towards making minimal changes, and they don’t work from a pre-approved design.
Good human developers do these things, and this is a pretty wide gap between adept human coders and AI.
Sports is entertainment. It inspires people and brings joy. It brings people together. It sets positive examples of the rewards that can come from consistent effort and teamwork. Athletes are people making the most of the gifts they’ve been given. This is all laudable.
I like how you put the context and prompts into the foreground. In so many tools, it’s invisible. We all know that context and prompts are there - the operation of LLMs is well known. Yet tools try and hide this and pretend that they are magic, instead of exposing control points and handles for the developer to use.