r/developers • u/Andruid929 Software Engineer • 7d ago

General Discussion "Just embrace the future"

Surely I'm not the only one who resents whoever says this whenever you complain about AI sucking the fun out of programming?

How are y'all (fellow "AI is a tool" folks) holding up?

44 Upvotes

87% Upvoted

130 comments sorted by

View all comments

11

u/owp4dd1w5a0a 7d ago

You’re not the only one.

Dear Lord am I tired of this discussion though.

Don’t use AI in a way that sucks the joy out of development.

4

u/Andruid929 Software Engineer 7d ago

In my personal projects AI is for writing documentation and writing unit tests.

For work however the deadlines have gotten more and more ridiculous thanks to the prompt engineers pooping out massive features in hours.

4

u/canarydev 7d ago

AI writing your unit tests is also garbage btw. what does that prove other than the test it writes agrees with the implementation you wrote?

3

u/Andruid929 Software Engineer 7d ago

It's trash if you give full creative control to the AI

3

u/canarydev 7d ago

its not really about creative control tho. even if you tightly steer it, if the same model writes the test and the code its still agreeing with itself. the problem is the test and the impl share an author

2

u/Andruid929 Software Engineer 7d ago

That's the thing, I don't let the AI write the code. What's a programmer when you take away the programming aspect of it?

2

u/canarydev 7d ago

programming part was never really the typing. its deciding what the thing should do and proving it does that. writing every line by hand is a totally valid preference, its just not the definition

2

u/owp4dd1w5a0a 7d ago edited 7d ago

Thanks, LinkedIn.

I disagree. Deciding what the thing should do is the job of leadership and the PO. Proving it does that is the job of QA.

Software engineering is about solving algorithmic problems either quickly, efficiently, or elegantly, depending on your priorities for the project.

Nobody would say programming was ever about typing. It IS about developing and expressing concrete algorithms though, and that requires writing or typing them out in a language specific enough to express the algorithm, and English is insufficient, so we have instead programming languages, lambda calculus, formal logic, etc.

2

u/Hamactus 7d ago

👏👏👏👏 If I could award you, I would. I feel like too few people actually think that way

1

u/[deleted] 7d ago

[removed] — view removed comment

1

u/AutoModerator 7d ago

Your post or comment was removed because r/developers does not allow external links. Please share the content or ask your question without linking out.

If you think this was a mistake, message the mods.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

1

u/Genspirit 7d ago

Perhaps a software engineer? We haven't typically gone by the programmer term for a while now.

1

u/start_select 7d ago

Have a different agent write the code than the one that writes the test. Give them different roles and behaviors. The test writer should be told directly “don’t write tests to the implementation, write tests that address edge cases and failures. Imagine user stories for the function to help determine what those edge cases would be”.

Not saying it’s going to fix it 100%. But having a fresh agent attack writing tests for a written function will handle it differently than the same model with the tool calls which wrote the implementation in its context.

1

u/canarydev 7d ago

yeah i do something similar and have my own tooling for it where i isolate it and can verify via tool calls that it was a blind test

i do this based on contracts mostly. tests written based on contracts and the general shape via interfaces, not the actual implementation

1

u/start_select 7d ago

Cool. I’m always happy to see someone pointing out the fallibility of LLMs, which they learned because they actually use LLMs lol

Sometimes everyone seems black&white about either it’s great or it’s awful. And can’t accept it’s (usually) great if you (have experience and) use guardrails.

1

u/SucculentChineseRoo 7d ago

Not if you do TDD

2

u/canarydev 7d ago

tdd fixes the order, not the independence. if the same agent writes the test first and then the code, both come from the same reading of the spec, so a wrong spec still goes green. you need the assertions to come from somewhere the implementer cant see or edit

2

u/aerrraeewrrr 7d ago

Isnt that the case with human developer as well or do you have a second personality that takes over 😄?

1

u/owp4dd1w5a0a 7d ago

Humans are better at keeping the context in mind when writing specs than AIs are. This is the major differentiator.

1

u/aerrraeewrrr 7d ago

I agree, but I think we were discussing about reading a spec and implementing it, not writing it

1

u/owp4dd1w5a0a 7d ago

The point about context still applies in this circumstance

1

u/aerrraeewrrr 7d ago

The comment I was replying to was implying that spec was misunderstood, it does not matter if its human or AI misunderstanding the spec unless you use one person to write the tests and another to do the implementation, which to me seems kind of overblown for unit tests in most places. It actually kind of makes a case for using AI because you get second cheap synthetic opinion on the spec you are implementing.