At $WORK, we have a bot that integrates with Slack that sets up minor PRs. Adjusting tf, updating endpoints, adding simple handlers. It does pretty well.

Also in a case of just prose to code, Claude wrote up a concurrent data migration utility in Go. When I reviewed it, it wasn't managing goroutines or waitgroups well, and the whole thing was a buggy mess and could not be gracefully killed. I would have written it faster by hand, no doubt. I think I know more now and the calculus may be shifting on my AI usage. However, the following day, my colleague needed a nearly identical temporary tool. A 45 minute session with Claude of "copy this thing but do this other stuff" easily saved them 6-8 hours of work. And again, that was just talking with Claude.

I am doing a hybrid approach really. I write much of my scaffolding, I write example code, I modify quick things the ai made to be more like I want, I set up guard rails and some tests then have the ai go to town. Results are mixed but trending up still.

FWIW, our CEO has declared us to be AI-first, so we are to leverage AI in everything we do which I think is misguided. But you can bet they will be reviewing AI usage metrics and lower wont be better at $WORK.

You should periodically ask Claude to review random parts of code to pump your metrics.

> we are to leverage AI in everything we do

Sounds like the extremely well-repeated mistake of treating everything like a nail because hammers are being hyped up this month.

It took me a while to realize you were using "$WORK" as a shell variable, not as a reference to Slack's stock ticker prior to its acquisition by $CRM.

> it wasn't managing goroutines or waitgroups well, and the whole thing was a buggy mess and could not be gracefully killed

First pass on a greenfield project is often like that, for humans too I suppose. Once the MVP is up, refactor with Opus ultrathink to look for areas of weakness and improvement usually tightens things up.

Then as you pointed out, once you have solid scaffolding, examples, etc, things keep improving. I feel like Claude has a pretty strong bias for following existing patterns in the project.

> FWIW, our CEO has declared us to be AI-first, so we are to leverage AI in everything we do which I think is misguided. But you can bet they will be reviewing AI usage metrics and lower wont be better at $WORK.

I've taken some pleasure in having GitHub copilot review whitespace normalization PRs. It says it can't do it, but I hope I get my points anyway.

This is a great response, even for a blue collar worker understanding none of its complexities (I have no code creation abilities, whatsoever — I can adjust parameters, and that's about it... I am a hardware guy).

My layperson anecdote about LLM coding is that using Perplexity is the first time I've ever had the confidence (artificial, or not) to actually try to accomplish something novel with software/coding. Without judgments, the LLM patiently attempts to turn my meat-speak into code. It helps explain [very simple stuff I can assure you!] what its language requires for a hardware result to occur, without chastising you. [Raspberry Pi / Arduino e.g.]

LLMs have encouraged me to explore the inner workings of more technologies, software and not. I finally have the knowledgeable apprentice to help me with microcontroller implementations, albeit slowly and perhaps somewhat dangerously [1].

----

Having spent the majority of my professional life troubleshooting hardware problems, I often benefit from rubber ducky troubleshooting [0], going back to the basics when something complicated isn't working. LLMs have been very helpful in this roleplay (e.g. garage door openers, thermostat advanced configurations, pin-outs, washing machine not working, etc.).

[0] <https://en.wikipedia.org/wiki/Rubber_duck_debugging>

[1] "He knows just enough to be dangerous" —proverbial electricians

¢¢

The risk is that lay people read comments like this and conclude "ergo, we need fewer programmers."

Nothing that the LLM is outputting is useful in the hands of somebody who couldn't have done it themselves (at least, given a reasonable amount of time).

The most apt analogy is that of pilot and autopilot. Autopilot makes the job of the pilot more pleasant, but it doesn't even slightly obviate the need for the pilot, nor does it lower the bar for the people that you can train as pilots.

The benefits of LLM programming are mostly going to be subsumed by the operator, to make their lives easier. Very little is gonna go to their employer (despite all the pressure), and this is not due to some principal-agent breakdown; it's just intrinsic to the nature of this work.

I think your experience matches well with mine. There are certain workloads and use cases where these tools really do well and legitimately save time; these tend to be more concise tasks and well defined with good context from which to draw from. The wrong tasking and the results can be pretty bad and a time sink.

I think the difficulty is exercising the judgement to know where that productive boundary sits. That's more difficult than it sounds because we're not use to adjudicating machine reasoning which can appear human-like ... So we tend to treat it like a human which is, of course, an error.

The CEO obviously wants one of those trophies that chatgpt gives out.