samjewell

then pivoted to being, ah, its okay for it to be a terminator type entity.

Isn’t that the opposite of what he’s saying? He’s saying it could become that powerful, and given that possibility it’s incredibly important that we do whatever we can to gain more control of that scenario

Is there any way to read this article without subscribing?

I tried https://web.archive.org/web/20250506064408/https://www.natio... but I still hit the paywall.

In fact, you should commit your LLM dialogs along with your code.

Wholeheartedly agree with this.

I think code review will evolve from "Review this code" to "Review this prompt that was used to generate some code"

I work at Grafana. Can you say more about what specifically you don’t recommend?

What happened to the girl you had a crush on? Did your effort to distance yourself from computers bear any fruit in any way? Do you have any regrets with that part of your story?

I'm amazed that the author doesn't recommend Pair-programming as one of the techniques to avoid "Doing too much before looping in others"

He mentions: > an engineer on a project should never go more than a week without showing something, and usually it should be more like a day

But in my experience by pairing you can shorten this feedback loop to seconds.

A few other people have commented about pairing: It's clear people have different preferences and that it's wise to use pairing at the right moments, but it still seems a glaring omission from the article to me.

Thanks

Perhaps we should invest some of these energies thinking about getting on our bicycles instead

I’ve worked my whole career in the UK (7 years software eng, plus a bit in other jobs). Sounds from your comment like you’ve had better experiences in other countries. Is that right? Which ones, and how?

Thanks for the comments - they're already very useful.

To explain our process: We have a single designer, and when designs are reviewed it's usually by one of the devs

In the past we've done wireframes (Sketch) and interactive prototypes (InVision) We were frustrated that: 1. Lots of issues didn't surface until we started coding, when a raft of problems/edgecases would appear. 2. It was too easy to ignore existing UI components/css, so that each design featured new component styles and css.

For approx the last month our designer branches from `master` and hacks on top of that to create designs. He then creates a PR for design-review, alongside a spec with some screenshots in Dropbox Paper. Some advantages of this: 1. We get visual diffs from Percy, so we can see what's changed easily 2. We get versioning more easily built into designs (via git)

Then just before development we'll break a story down into tasks / subtasks and log those into JIRA for development. We have trouble with: 1. Letting the designer make changes once the subtasks are created and development has started (devs sometimes chasing a 'moving-target' spec) 2. Design not knowing the current state of development