You just need good compaction and a memory system with decent project layout and documentation. If you don't have that 1M tokens won't really save you either.
Very eager to read through your code! I read the first version and incorporated several of its ideas into our own internal elixir agent framework. (We make use of your ReqLLM package, thanks much for that!)
- Claude Code + worktrees (manual via small shell script)
- A root guardrails directory with a README to direct the agent where to look for applicable rule files (we have a monorepo of python etls and elixir applications)
- Graphite for stacked prs <3
- PR Reviews: Sourcery + Graphite's agent + Codex + Claude just sorta crank 'em, sourcery is chatty but it's gotten a lot better lately.
(editor-wise, most of us are nvim users)
Lots of iteration. Feature files (checked into the repo). Graphite stacks are amazing for unblocking the biggest bottleneck in ai assisted development which is validation/reviews. Solving the conflict hell of stacked branches has made things go much, much faster and it's acted as downward pressure on the ever increasing size of PRs.
Yet another developer who is too full of themselves to admit that they have no idea how to use LLMs for development. There's an arrogance that can set in when you get to be more senior and unless you're capable of force feeding yourself a bit of humility you'll end up missing big, important changes in your field.
It becomes farcical when not only are you missing the big thing but you're also proud of your ignorance and this guy is both.
Another way to look at this is that using LLMs and agents in your business function takes a while to master. It's a skill and it's a good move to push teams to incorporate AI into their workflows before immediately reaching for a new hire. There will be job functions that will be eaten away, I'm sure, but Jevons and his paradox are still undefeated.
Funny. I lived in Seattle for 5 years before I moved to Sydney, where I lived for 5 years. That was a different era though, tech wasn't the industry it is now and the internet still felt new. I moved down in 2003 and my American accent helped me land a job I wasn't qualified for (having self taught myself some php and java in Seattle, mostly working as a bartender though). In 2005 I started a small software shop with some friends. Back then (2003) the Ruby user's group was too small to get a reservation at a pub so we'd have to partner up with the Smalltalk guys. Rails came out a year or so later and that changed.
I got back into web stuff when I moved to the states and have been up and down the stack many times since, but I have a ton of nostalgia for the stuff we did back then. Web 2 was an annoying new buzzword and we were still mostly writing software for kiosks, device drivers in C, bridging that with Lua, and using Flash for the interface b/c everybody else in the space was using shitty C++ Motif interfaces. . . . memory lane.
Imagine that Newtown and the Inner West are a lot different than when I lived there, but I do miss that time.
What a weird argument. There are many, many apartments in New York that people want to live in so badly that they'll pay millions upon millions of dollars to do so.
1. You certainly need to know SQL
2. Composition is very different than concatenation and the differences become apparent as a project increases in complexity
3. I'd recommend checking out the current SOTA, especially with kysely (or Ecto if you ever get into Elixir projects)
I've been at it for a bit over 25 years as well and have worked on everything from telco billing projects to complex consumer applications. Query builders and ORMs are not the same thing, and it's odd that you conflate them.
The project that I happen to be on now has a mid sized db (~70 ish) tables with quite a few custom functions and complex queries. I have been untangling a mess of slonik queries and there's an objective difference in the quality of the code and the maintainability between that and the kysely code that's replacing it.
The people I see drift toward things like slonik tend to be journeyman level developers and they often end up over their skis. Smart folks a lot of the time, but inexperienced.
Slonik does _not_ make it possible (let alone trivial) to write composable queries. You're just doing string concatenation and string concatenation will bite you when things get complex enough.
There is also a big difference between an ORM and a query builder. Knex (and kysely, which is the only thing I'd use these days) allows you to write SQL that's just as complex as anything you'd write raw, complete with escape hatches if you need them. The criticisms of ORMs tend to be spot on, they are nice until they run into a wall, but that same thing simply does not apply to a robust query builder.
I'm using kysely with a database that has quite a few complex functions, etc. Lots of queries that require CTEs and so on. It's fantastic. Type safety with the codegen is amazing and catches a tremendous amount of simple bugs and typos which are super easy to make in raw SQL strings.
People talking about writing raw SQL have never maintained a large project. Once you start string concatting queries and trying to remember which table aliases are which you're halfway to writing a custom, buggy query builder without type safety. It's a trap for young players.