Changing your identity – how you look at yourself in the world – is hard.
Unfortunately, this is very often the key to making lasting improvements in your life.
If you have spent any time around experienced software developers, you’ll hear a lot of comments like this about using LLMs for coding:
They are useless – they make up functions left and right.
The code is terrible – buggy, slow, and hard to read.
It can’t work in a real codebase – it gets confused all the time.
I held the same opinions, actually.
But seeing more and more people out-shipping me (you know, with actually completed projects – even if they are small), got me worried.
And worry grew into despair.
Until I stumbled over Geoffrey Huntley’s article about leveraging Cursor.
You can teach the machine to get better?
The rate of improvement will increase?
Wow, that actually sounds exciting!
This rekindled the excitement that got me into programming in the first place.
Fast feedback loops, a steady stream of achievements delivered to your brain.
But now the level on which these achievements happen has changed.
Achievements, high and low
Accepting The New Way of developing software, I’ve found two things to be great sources of a sense of achievement and wonder:
getting better at steering models – “wow, it wrote code for 5 minutes without me watching, and I got a working solution”.
iterating on useful results, fast – the unit of work is now the completed, usable feature, not some kind of abstract programming artifact.
Here’s an example of the former:
This Cursor is generating multiple rules for itself, after I asked to generate one.
I provided enough of the right context so that it actually figured out what we wanted to achieve, so it proactively provided solutions 🤯
Seeing this created a euphoric feeling!
It’s the same dopamine rush as regular programming, just the source is different.
That’s cool, but I still don’t get good results
Neither did I for a long time!
What changed:
I started to visualize working with the LLM as working with a fresh hire,
they have zero context of what’s going on: what is the business about, what problems are urgent, how does the codebase look like, etc.
they are happy to learn and adjust their behavior to how things work around here.
Providing the right context is crucial.
For inspiration look here.
I’ll post more of my own workflows soon.
The point is: you need to experiment and learn.
Nobody has “figured it all out” yet.
Only practice can teach you.
You are your own obstacle
And that’s why the responsibility for results lies with you.
Too much context for the LLM to consider?
Maybe you don’t know the domain well-enough.
Or the codebase isn’t structured well enough to limit the necessary context.
The LLM can’t work its way out of a tricky situation?
I once had the LLM get stuck on working with multiple nested async context managers in Python.
I couldn’t help it out of that situation because I wasn’t familiar enough with that particular corner of Python.
Had I been, I could have guided it to the right solution.
Too many hallucinations – it’s building a house of cards!
Mmh, looks like you don’t have practical tests or other ways to give the LLM quick, automated feedback to arrive at a solution.
What’s next?
Experiment.
Learn.
Iterate.
If you don’t have a side-project you are working on, it is high time by now.