When building a platform or tool for developers there are two extreme schools of thoughts:
When you provide Sharp knives you provide powerful (but dangerous) tools to your users, and trust them to do the right thing. The tools will make their job easier, but could also cause serious problems.
Safety by design is the other extreme end, the user is not given powerful tools, but simple and safe tools that they can’t shoot themselves in the foot with.
Finally, LLM-generated prose undermines a social contract of sorts: absent LLMs, it is presumed that of the reader and the writer, it is the writer that has undertaken the greater intellectual exertion. (That is, it is more work to write than to read!) For the reader, this is important: should they struggle with an idea, they can reasonably assume that the writer themselves understands it — and it is the least a reader can do to labor to make sense of it.
So our guideline is to generally not use LLMs to write, but this shouldn’t be thought of as an absolute — and it doesn’t mean that an LLM can’t be used as part of the writing process. Just please: consider your responsibility to yourself, to your own ideas — and to the reader.
http://rfd.shared.oxide.computer/rfd/0576
A theme I’ve been exploring recently is the concept of Centaurs and Reverse Centaurs.
A Centaur is Human brain on a horse’s body, harnessing the intelligence of a human and the tireless nature of a horse. It’s someone using AI to automate not just the boring stuff, but the harder more interesting problems as well. It’s a chess player using a powerful AI to make them a better player, letting AI show them the best moves that they otherwise would not be able to find.
A “centaur” is a human being who is assisted by a machine (a human head on a strong and tireless body). A reverse centaur is a machine that uses a human being as its assistant (a frail and vulnerable person being puppeteered by an uncaring, relentless machine). Like an Amazon delivery driver, who sits in a cabin surrounded by AI cameras, that monitor the driver’s eyes and take points off if the driver looks in a proscribed direction … The driver is in that van because the van can’t drive itself and can’t get a parcel from the curb to your porch. The driver is a peripheral for a van, and the van drives the driver…. – Cory Doctorow
keithRozario.com is now on Hugo
This year, I managed to complete the entire problem set of advent of code. Last year, I could only complete 43 out of 50 problems. So there was ... progress!
If you're unfamiliar, Advent of Code is a series of daily coding challenges released during the season of advent (the period just before Christmas). I encourage you to try these challenges for yourself. None of them are easy (at least to me), but all of them solvable with enough elbow grease and time.
The METR study is wild!
It's methodoloty is unlike any other. While previous studies went 'wide', the METR study went 'deep', focusing on 16 developers (instead of hundreds or thousands), but deeply analyzing the effect on AI on those 16 developers in a way 'wide' studies could not.
METR first identified 16 developers who were maintaining high quality open source repositories. These repositories had an average of 22k stars on Github, and ~1 million lines of code. 22k stars is probably 6-7 standard deviations above average on Github. To put a football perspective, these developers were maintaining the football equivalent of Real Madrid, while your average Enterprise app code base is Toa Payoh FC or Scunthorpe United.
If you have 3 apples, you take away 2, how many apples do you have?
1 of course!
But then again, you took away 2, so therefore you should have 2. The question is ambiguous depends on how you interpret the words 'have' and 'take-away'.
Compare that to something like this:
I was "inspired"by this post.
In it, Philip Su, an E9 (Distinguished Engineer) from Facebook explains how he progressed in his career, which includes an impressive stint at Microsoft that saw him promoted every year for 8 years straight.
If you have that kind of accelerant so early in your career -- you're bound to be "Successful", or at least air-quotes successful.
Distinguished engineers at a FAANG company (Facebook, Amazon, Netflix, Google..etc) are the highest technical individual contributors in companies that value (and pay) their technical folks LOTS of money. There are fewer Distinguished Engineers at FAANGs than there are NBA players, that level of elite requires immense dedication.
I'm not as "successful" as Philip. I started my career as a Business Analyst in Shell, I was promoted (sort-of) twice in my 9 years there, then bounced around a bit, and joined Amazon as a L6. I left 4 years later at the very same level, promoted a grand total of ZERO times. Now I'm a partner engineer at Google -- a peon in the giant machinery that is Google Cloud. So I've worked at FAANG companies, but at more ground-level stuff, than in the stratosphere that Philip operating in.
But, I'm happy where I am, and pretty happy with my journey so far.
In Software delivery there's a famous saying: Good, Fast, or Cheap -- pick 2.
There's always trade-offs.
Fast and cheap can be measured easily. How much money and how much time are very simple questions to answer. You might think it's expensive, or slow -- but the objective hours and dollars are easy measurements.
It's not the same for 'Good' though. How do you measure 'Good'?