[ambicapter]

Obviously I'm an AI-tools skeptic, but this is hilarious:

> 1. Prepare issues with sufficient context

> Start by ensuring each GitHub issue contains enough context for agents to understand what needs to be built and how it integrates with the system. This might include details about feature behavior, file locations, database structure, or specific requirements such as displaying certain fields or handling edge cases.

> You can’t do half-hearted prompts and fix as you go, because those fixes come an hour later.

> Skills That Become More Important > Full-stack understanding > Problem decomposition > Good writting skills > QA and Code Review skills

This is just software engineering?!?

edit: On the other hand, maybe I can convince people in my org to get better at software engineering by telling them its for the AI to work better.

[DetroitThrow]

>This is just software engineering?!?

Absolutely. The existence of vibe coding does not mean production code is going to be engineered without the same principles we've always used - even if we're using AI to generate a lot more code than before.

Any crowd suggesting that this was not the case has lost the plot, imo.

[Aeolun]

People find it a lot more palatable when the AI requires all this information than when software engineers do though. If I ask for clear requirements I’m asked to just figure it out. But if the AI implements nonsense without clear requirements that the fault of the specs.

[tjr]

I am amazed at how suddenly people are on board with writing clear design documentation now that it means AI can generate the code rather than humans.

I wonder how much better humans would be at generating code given the same abundance of clearly-written design documentation?

[dzhiurgis]

My workplace was always pretty good at writing requirements so I call myself a chatgpt wrapper now.

[lazide]

Well, that’s because the software engineers are irritating when they push back and say ‘no’ or ‘wtf’.

When the AI does it, it’s being polite and stuff. /s, kinda.

[ambicapter]

You're right. That's an excellent observation! I will make sure to use those language patterns in all my professional communications going forward.

/s but not really?

[sfn42]

I consider it my job to figure out the requirements. The fact that they aren't specified in detail allows me to do what I think is best rather than being bound by often arbitrary specifications.

I judge which decisions I make and which ones I bring up to my team/PO/whatever. Most of the time I just do what I think is best, some times I'll do something and then bring it up later like "I did this this way but if that doesn't work I can change it", typically for things that will be easy to change later. Some things I ask about before I do them because they won't be easy to change later.

I'll often take technical liberties with frontend designs, for example I'll use a html select rather than reinventing the drop-down just to be able to put rounded corners on the options. I'll style scrollbars using the very limited options css provides rather than reinvent scrollbars just to follow the design exactly. Most of the time nobody cares, we can always go back later and do these types of things if we really want a certain aesthetic.

I have never had the impression that my questions bother people, rather the opposite. I've had multiple designers say they appreciate the way I interact with them, I respect their work and their designs but I ask them if something looks like an oversight or I'm not exactly sure what their intention is. POs and such are always happy to answer simple questions, I make it easy for them: here's a decision we need to make, I want you to make it. Maybe I have a suggestion for what I would prefer and some reasons why I prefer that solution.

I don't expect them to think of everything and answer all my potential questions in advance, that's just unnecessary and difficult work.

[skhameneh]

> On the other hand, maybe I can convince people in my org to get better at software engineering by telling them its for the AI to work better.

Really good engineering practices are fundamental to get the most out of AI tooling. Convoluted documentation, code fragmentation, etc all pollute context when working with AI tools.

In my experience, just having one outdated word (especially if it's a library name) anywhere in code or documentation can create major ongoing headaches.

The worst part of it is trying to avoid negative assertions. When the AI tooling keeps trying to do "the wrong thing" it's sometimes a challenge to rephrase instructions for "the right thing" to frame a positive assertion.

[wrs]

Yeah, it’s funny, we may finally have a way to get developers to write documentation for other developers, it’s just that the other developers aren’t human!

[shiroyasha]

Yes. AI assisted software engineering is still software engineering. I don't see that part changing anytime soon.

[pvtmert]

> This is just software engineering?!?

Indeed yes. Although most places shipping software in a "software development" and/or "programming" fashion for many years.

Many, many places certainly do not do the engineering part, even though resulting product is a software.

[mensetmanusman]

I tend to agree with English being the new programming language. Those with English communication struggles will struggle to code this way.

[rukuu001]

Yes, the ability to clearly and unambiguously communicate what's required works on both humans and machines.

[electroglyph]

lmao, "good writting skills" =)

[ambicapter]

[sic]

[ScotterC]

I lol'ed too but then thought - at least he actually wrote this!

[shiroyasha]

Heh, damn. Made a typo at the worst spot

[tanseydavid]

Oh I see. They actually meant "good knitting skills."