Hacker News Reader

Comment by jakub_g | Hacker News Reader

100% agree. Someone (who?) had to take time and write the detailed requirements. In real jobs you rarely get good tickets with well defined expectations; it's one of most important developer's jobs to transform fuzzy requirement into a good ticket.

(Side note: I find that many people skip this step, and go straight from fuzzy-requirement-only-discussed-on-zoom-with-Bob to code; open a pull request without much context or comments; and then a code reviewer is supposed to review it properly without really knowing what problem is actually being solved, and whether the code is solving a proper problem at all).

View on HN

So what happens when OpenAI releases TicketFixer 0.8 which synthesizes everything from transcripts of your meetings to the comments to the JIRA ticket to the existing codebase and spits out better tickets to feed into the programming side?

Yup, I hope that'll happen. Then engineers would just end up being done at a higher level of abstraction closer to what designers do with wireframes and mockups.

Kind of the opposite of the way graphic design has evolved. Instead of getting more involved in the process and, in many cases, becoming front-end developers, it'll become more abstract where humans make the decisions and reason about what to include/exclude, how it'll flow, etc.

Even TicketFixer wouldn't be able to do more than offer a handful of possible solutions to design-type issues.

Yeah, we need our TicketFixer to also include the No_Bob 0.2 plugin that figures out that a decent percentage of the time whatever "Bob" is asking for in that meeting is not what "Bob" thinks he is asking for or should be asking for and can squash those tickets. Without that we're gonna somehow end up with spreadsheets in everything.

Haha, yeah, there's that, but there are also things like "adding a dark mode." There are a dozen ways to accomplish that kind of thing, and every company's solution will diverge when you get down to the details.

Take my money.

Is the next step in the evolution of programming having the programmer become the specifier?

Fuzzy business requirements -> programmer specifies and writes tests -> AI codes

That's all we've ever been since we invented software.

First we specified the exact flow of the bits with punch cards.

Then we got assembly and we specified the machine instructions.

Then we got higher level languages and we specified how the memory was to be managed and what data to store where.

Now we have object oriented languages that allow us to work with domain models, and functional languages that allow us to work data structures and algorithms.

The next level may be writing business rules, and specifying how services talk to each other, who knows, but it will be no different than it is now just a higher level.

If its anything like my job

while(1) { Fuzzy business requirements -> programmer specifies and writes tests -> AI codes }

Maybe the problem transformation will be both the beginning _and_ end of the developer's role.

But it's easy to create AI conversation that will refine problem.

Reply on news.ycombinator.com