LLMs in the SDLC

What you'll learn

By the end of this hackathon you'll have taken a project from idea to release, utilising an AI agent to write most of the code, whilst ensuring adherence to the usual Software Development Lifecycle (SDLC) process. This section formally outlines the intended audience for the hackathon, and its intended learning objectives. Bloom's taxonomy is utilised to define both, and is a worthwhile thing to research for those unfamiliar with outlining lesson plans.

The intended audience

Below we outline the minimum set of skills required to attend the hackathon, though anyone operating at a more advanced level of each skill is more than welcome. No prior experience with AI coding assistants is required; that is what the hackathon is for.

1. Individuals who, at a minimum, are able to employ a programming language to construct computer programs.
2. Individuals who are able to identify the key steps of the SDLC.
3. Individuals who are able to use git to clone a repository, then commit and push changes.

Learning objectives

By the end of this hackathon, you will be able to:

• Compare human and AI actions at each stage of the SDLC
• Use an AI agent to produce a discrete plan of work for a project
• Summarise how usage of a ticketing system can help coordinate an AI agent's work
• Use an AI agent to deliver a plan of work for a project
• Identify common traps and pitfalls when utilising an AI agent to produce software code
• Contrast fully agentic and human-in-the-loop approaches to AI in the SDLC

How the learning objectives will be evaluated

• Teams will present their completed projects, talking facilitators through their tickets and plan of work, how the agent delivered work, and any traps or pitfalls they had to mitigate
• Teams will debate different approaches with each other on how to integrate AI into the SDLC
• Teams will have an open discussion with facilitators regarding the different approaches to AI integration in the SDLC

The software development lifecycle (SDLC)

The SDLC is the structured process by which we turn ideas into functional computer programs, deploy said programs, and then maintain and update them during operation. It has been a subject of research for decades, and as such there is a wide corpus of (sometimes conflicting) information available regarding it. Regardless of which model one uses, they all incorporate broadly the same phases, commonly described as the following six:

1. Plan: what is being built and, more importantly, why? Decompose the work into small units that may be delivered individually.
2. Design: for each unit, decide how it will be built.
3. Implement: build each unit as designed.
4. Test: check the implementation against the design's specification of what it should do, and confirm that it integrates with the other units.
5. Deploy: once enough units are bundled together, release a version of the product to the people and/or systems intended to use it.
6. Maintain: keep the software running, fix bugs, and ensure it remains fit for purpose as requirements change.

Hard problems are solved by breaking them down. An AI agent may speed up the individual steps, but the work must still be planned, designed, implemented, tested, deployed and maintained. One cannot simply point an AI agent at an idea and say "go"; producing anything of value still requires the SDLC.

The hackathon iterates through these phases in an agile manner, albeit at a smaller scale. Each team's project is a single ticket, planned as a series of small commits and delivered one commit at a time. By the end, each team will have delivered a small, working and, ideally, fun project.

Further reading

• The phases and models: AWS, What is SDLC?
• Agile: the Agile Manifesto
• Plan: DORA, Working in small batches
• Implement: trunk-based development, Google's code review guide and Conventional Commits
• Test: Martin Fowler, Continuous Integration
• Deploy: Semantic Versioning

Integrating LLMs into the SDLC

Different organisations will take different approaches to integrating LLMs into their SDLC. By far the most common methodology seen during Sudoblark's engagements, and thus the basis for this hackathon, is as follows:

1. Humans retain creative control; they come up with ideas, prioritise work, and design architectures.
2. AI is another tool utilised at every stage; human engineers utilise it to create outputs.
3. Humans control quality and deployment; the usual quality gates and processes for produced artefacts are hardened rather than negated.

Within such a methodology, AI can assist at every phase of the SDLC, but the decisions at each one remain with a human:

The importance of tickets for work tracking

Keeping a well-maintained backlog of work has always been essential in the SDLC, allowing individuals in a team to collaborate on tickets and managers to track how work progresses towards agreed milestones. Within an AI-enabled workflow, tickets record the discrete plan of what is being built at an atomic level, progress towards said plan, and any other contextual information required for its delivery. Thus, any human, or a fresh AI agent, can read the ticket, pick up where the work left off, and know the exact state of play of a given task. Context surrounding tickets therefore persist beyond any single agent conversation.

Within this hackathon, tickets are simply files in the provided starter repository. In practice, any ticketing system may serve this purpose. In particular, Jira, one of the most widely used ticketing systems for software engineering work, has an easy-to-use Model Context Protocol (MCP) server that Claude and most other agents can use.

Why a human stays in the loop

The workflow outlined in this hackathon keeps a human in the loop at every phase of the SDLC. This is a deliberate choice: it reflects my view, and Sudoblark's position, that a human must remain in the loop at all times. All clients that Sudoblark engages with have two things in common:

1. They understand that technology is only useful if it drives business value.
2. They've got business value they want to achieve.

From these two points follows a simple truism: when something breaks, someone needs to be accountable. There is a quote, attributed to a 1979 IBM training manual, which puts the idea succinctly:

AI agents may aid in the SDLC, but they cannot be held accountable for the output. Furthermore, small, human-reviewed changes make for more stable delivery: DORA's research found that as AI adoption increased, delivery stability fell, and pointed teams back to fundamentals such as small batch sizes and robust testing.

Others hold a different view, favouring a fully agentic workflow in which agents move through the SDLC without human oversight. Research frameworks such as ChatDev already have agents playing roles from requirements analyst to test engineer build software between them, and the popularity of autonomous agents such as OpenClaw, which browse the web, edit files and run shell commands on their user's behalf, shows how appealing that idea is.

Setting up for the hackathon

Please complete the following before the hackathon, so that time on the night is spent building rather than installing.

Prerequisites

• A laptop that meets the Claude Code system requirements.
• A GitHub account, to push your copy of the starter repository to.
• A Claude Pro, Max, Team, Enterprise or Console account. The free Claude plan does not include Claude Code.
• An IDE of your choice.
• Ideally, a fun project idea of your own. Though several project ideas are provided to get you started.

Installation

1. Install Git.
2. Install an IDE, such as VS Code.
3. Install Claude Code by running the command for your system in a terminal, then run claude --version to confirm it worked. The Claude Code setup guide covers other install methods and troubleshooting.

# macOS, Linux or WSL
curl -fsSL https://claude.ai/install.sh | bash

# Windows PowerShell
irm https://claude.ai/install.ps1 | iex

Setup

1. Create a new, empty repository in your GitHub account, without a README or licence.
2. Clone the starter repository, and push it to your new repository:

git clone https://github.com/sudoblark/sudoblark.ai.sdlc-hackathon.git
cd sudoblark.ai.sdlc-hackathon
git remote set-url origin https://github.com/<your-username>/<your-repository>.git
git push -u origin main

3. Open the folder in your IDE, run claude in a terminal there, sign in when prompted, and trust the folder when asked.
4. Check the skills have loaded: typing / should list /log-ticket and /start-ticket.
5. Run /permissions to see the rules the repository applies, such as the agent being denied git commit and git push.
6. Pick a starter ticket from the work folder, or ask the agent to log your own idea, then run /start-ticket with its number, such as /start-ticket TKT-01.

An example project built in 2 hours

To test the hackathon before running it, I built one of the starter tickets provided - TKT-05, an ASCII Dungeon Crawler - from scratch, following the same workflow a hackathon attendee is expected to take. The core project, and some of the stretch goals, took 2 hours. I then allowed myself another hour of tinkering after getting a bit carried away.

• The starter repository given to every team as a basis for the hackathon.
• The finished game created from the starter repo.

Below is a video of me playing (on easy mode):

Previous and upcoming events

Events where I've run this, or will, with links to each event and its recording where there is one.