I'm using a code review agent which sometimes catches a critical big humans miss, so that is very useful.
Using it to get to know a code base is also very useful. A question like 'which functions touch this table' or 'describe the flow of this API endpoint' are usually answered correctly. This is a huge time saver when I need to work on a code base i'm less familiar with.
For coding, agents are fine for simple straightforward tasks, but I find the tools are very myopic: they prefer very local changes (adding new helper functions all over the place, even when such helpers already exist)
For harder problems I find agents get stuck in loops, and coming up with the right prompts and guardrails can be slower than just writing the code.
I also hates how slow and unpredictable the agents can be. At times it feels like gambling.
Will the agents actually fix my tests, or fuck up the code base? Who knows, let's check in 5 minutes.
IMO the worst thing is that juniors can now come up with large change sets, that seem good at a glance but then turn out to be fundamentally flawed, and it takes tons of time to review
I'm thinking of using it to replace an analytics pipeline at my job, which now uses expensive batch jobs.
If the tech is solid, we would have instant and incremental updates, instead of recomputing everything every X hours.
This would simplify things a lot.
I think Materialize offers a similar product, but last I checked it was only available as a SaaS solution.
I hope to do a proof of concept soon, to compare both solutions
Immutability removes so much accidental complexity, it makes whole classes of mistakes dissapear. I'd also take immutability over types.
Clojure sort of guides you to simplicity, building everything out of functions and simple datastructures has big advantages when testing and reasoning about code.
I do find that in larger code bases, Clojure lack of types causes friction (spec is just a bandaid, not a fix).
There are languages with immutability and types (like Haskell), but these don't have the get-shit-done factor I seek.
Interesting! I did an internship where I tried to use transducers for fast information extraction.
In theory, you can use FST's for fast approximate parsing.
I didn't really work out, but I had lots of fun implementing a libary to compose FST's and explore cool algorithms to compose them. Not much business value was delivered, but I learned a lot.
This year I switched to a new job, using programming languages that I was less familiar with.
Asking a LLM to translate between languages works really well most of the time.
It's also a great way to learn which libraries are the standard solution for a language. It really accelerated my learning process.
Sure, there is the occasional too literal translation or hallucination, but I found this useful enough.
'Serverless' has it's uses, but not for everything
- Serverless can get very expensive
- DevEx is less than stellar, can't run a debugger
- Vendor lock-in
- You might be forced to update when they stop supporting older runtime versions
The difference is in how easy it is to detect the cause of problems.
Mistakes like wrong function names are mostly easy to find and fix.
Mistakes when using core.async can be very hard to track down.
It was completely correct and I realized LLM are capable of generalizing beyond their training sets