AI for Software Development

We have seen ChatGPT write code, but that is not how real software gets made. A more focused AI should take a human text about a product he wants to build, translate that into a more specific action description, then allow the next tool to use this data to get the job done. For now, I am gonna call this the language productivity tool chain. It should also be able to do the reverse, given a piece of software, it should provide a good description to enable FAQs, debugging, and future work.

In real software engineering, a large part is deciding what to build. That is why software engineers are often frustrated at this notion of working against a “moving target”. Because very often the decision makers have no idea what they want to build. And decision making is difficult, because very often in life there are no right or wrong answers, so there is a component of subjectivity here. When a large part of these discussions happen in either slack or zoom meetings, it is important to write down the plans, not only for documentation but also to take the time to reflect deeply about the decisions being made. This process is entirely manual right now, and it will take more than an AI notetaker to automate this.

When reflecting back on meetings of the past, there is usually a discovery portion and action planning portion. And the two portions are usually interweaved.

The Discovery portion usually involves outlining the problem, the constraints, the end goal, and the current architecture. Then the action planning portion usually emerges out of the discussion on discovery. The action plans are usually a set of solutions where the humans outline the pros and cons of each solution and further clarify product requirements.

In order for a LLM to be productive, it has to understand the discussions, document it for stakeholders, and help decision makers to refine the plan for action. Once engineering has assessed the plan, the LLM should facilitate the engineer at building the feature. Because the entire codebase is available, some code generation should be possible, perhaps copilot of the future. After shipping the feature, the LLM should update its understanding of the entire codebase and generate the necessary documentation for both engineers and end users. Because the software development cycle doesn’t just end with code shipped, but also with maintenance once it is in the end user’s hands. Product manager spends considerable time to collect both quantitative and qualitative feedback from end users, then update the company’s understanding of its end users. This job puts stress on the PM and should be automated by the LLM.

System flow Message conversations or transcripts to high level planning documents. From human discussions and meeting notes, llm should try to extract the meaning of the project in a very structured manner. Structure Problem Why this is important Constraints Alternatives Suggestion Missing context Clarifications that llm should be asking human
Execution plan Integrate human feedback From the planning document, llm needs to correctly breakdown the tasks to a project management tools, ie JIRA. Each ticket should have good description to enable easy execution, human can ask llm question about the ticket Execution; if we give the LLM access to the codebase and sample data, can it improve the productivity of an engineer? Once the engineer has delivered the requested feature, LLM should update its understanding of the entire codebase. It should be able to either support automated testing or customer support.