←back to thread

68 points NotAnOtter | 1 comments | | HN request time: 0.377s | source

My company is increasingly pushing prompt engineering as the single way we "should" be coding. The CEO & CTO are both obsessed with it and promote things like "delete entire unit test file & have claude generate a new one" rather than manually address test failures.

I'm a 'senior engineer' with ~5 years of industry experience and am considering moving on from this company because I don't want

1. Be pushed into a workflow that will cause my technical growth to stall or degrade 2. Be overseeing a bunch of AI-generated spaghetti 2-3 years from now

Feel free to address my specific situation but I'm interested in more general opinions.

Show context
wrs ◴[] No.44469056[source]
I know with only 5 years experience this may not be obvious, but this is only the first of many “revolutionary” technologies making everyone around you lose their minds that you’ll have to deal with in your career. Like every other such technology, I recommend that you engage with it, understand it, relate that experience to what your employer does, and be the voice of knowledgeable pragmatism about where to use it. In other words, be an engineer.

If that can’t be done where you are, or isn’t valued, you’re in the wrong place.

I’ve been through this with (including but not limited to) PCs, OOP, client-server, SOA, XML, NoSQL, blockchain, “big data”, and indeed, multiple definitions of “AI”. Turns out all but one of those were actually somewhat useful in the end, when applied properly, but they didn’t eliminate the industry. Just roll with it.

replies(3): >>44469075 #>>44470591 #>>44474723 #
edanm ◴[] No.44470591[source]
> I know with only 5 years experience this may not be obvious, but this is only the first of many “revolutionary” technologies making everyone around you lose their minds that you’ll have to deal with in your career.

While this has some truth, the size of the current "revolution" makes all the others look tiny, especially in terms of how it affects a programmer's day job. Nor did most of those "revolutions" affect every field of programming at once, like this one does. The percent of programmers actually impacted by blockchain is probably in the low single-digits. The percent of programmers using some version of AI tooling 3 years into this is probably >50%, and the more impactful tools will be used more very soon is my gues.

replies(1): >>44473748 #
wrs ◴[] No.44473748[source]
Were you around for the OOP craze? It definitely affected a lot of peoples’ day job. I mean, quite a few people use C++ and Java, no?

In my list I didn’t even mention the internet, the web, smartphones, and the cloud, all of which had a very broad effect on programming and programmers, and had similar top-down edicts from the C-suite, e.g., declaring you must be “all-in on cloud”. Turns out those things were indeed quite transformative, but now that the hype has dissipated somewhat, we’ve absorbed them into the toolkit and just proceed with the engineering.

replies(2): >>44473988 #>>44474810 #
RaftPeople ◴[] No.44474810[source]
> Were you around for the OOP craze?

In the early 90's I was working for a large ERP company that went all in on OOP and distributed objects.

I was talking to one of the guys from the new team they created to re-write the entire system and had an entertaining conversation:

Tech guy that had drunk the kool-aid (TGTHDTKA): "...and the objects can just automatically interact with each other, like I can drop this person object on the phone object and it just automatically makes the phone call to that person"

Me: "Uh, but you still had to write specific code that causes that interaction to occur, you can't just do that with objects that haven't agreed on how to communicate"

TGTHDTKA: "No, it's all automatic because a person has a phone number and a phone uses a phone number to make calls, so you don't have to code anything special"

etc.

replies(1): >>44476438 #
1. wrs ◴[] No.44476438[source]
Now the MCP kool-aid is about how we’re finally going to make that work, because the computer on either end can literally read the field descriptions and intuit the interaction. MCP uses LLMs to supply the magic that the WSDL folks never admitted was necessary.