Baseline Prompt
WeakBuild a CRUD REST API in Go.
The starting point was intentionally simple. The AI had the broad task, but many implementation decisions were left unspecified.
Case Study . 01
Task API
From "Build a CRUD API" to an engineeres prompt.
GoREST APICRUDAI-assisted engineering
01 . Overview
A CRUD assignment became an experiment in engineering with AI.
The Task API was built as part of my backend engineering work during Week 2 of the FlyRank AI internship.
The project started with a straightforward goal: build a CRUD API. I used the assignment as an opportunity to explore a different question - what changes when an AI system is treated as an engineering collaborator rather than simply a tool for generating code?
The result became an experiment in improving the instructions given to the AI and evaluating the implemnetation that came back.
02 . The problem
A working answer is automatically an engineered solution.
A request such as "Build a CRUD API" communicates a goal, but it leaves many implementation decision unspecified.
When working with an AI coding assistant, those missing details matter. The quality of the result depends not only on the model, but also on how clearly the engineering problem is communicated.
That led to the central question behind this project:
What happens when you stop treating AI like a code generator and start treating it like an engineering collaborator?
03 · Prompt ladder
From a one-line request to a reusable engineering specification.
I progressively added context, structure, output expectations, and quality requirements to the prompt. Each version was designed to reduce ambiguity and make the expected implementation clearer.
Add Clear Goal
Version 1Build a CRUD REST API in Go that allows users to create, read, update, and delete tasks.
The API now had a specific purpose instead of leaving the AI to infer what the CRUD resource should be.
Add Technology Stack
Version 2Use Go, the standard net/http package, Gorilla Mux for routing, and in-memory storage.
The implementation was constrained to the technologies I actually wanted rather than allowing the AI to choose frameworks.
Add Project Structure
Version 3Organize the project into handlers, models, and main.go.
The generated project followed a clearer organization, making the code easier to maintain.
Add Output Format
Version 4Include complete source code, setup instructions, and Swagger documentation.
The AI was no longer asked for code alone. The expected deliverables became explicit and consistent.
Add Quality Requirements
Final reusable promptFollow RESTful conventions, return proper HTTP status codes and JSON responses, document every endpoint, and follow Go best practices.
The final prompt added quality expectations and produced an implementation much closer to the intended engineering standard.
04 · Honest reflection
Not every prompt improvement produced the improvement I expected.
One of the most useful observations came from Version 2. Simply specifying the programming language made the implementation Go-specific, but the generated project was still fairly generic.
The bigger improvement came from explaining how I wanted the project organized. Giving the AI structural context had a more noticeable effect on the maintainability of the generated solution.
The lesson was not simply "add more detail." The useful detail was the detail that reduced important engineering ambiguity.
05 · Engineering outcome
The final prompt produced a more complete engineering deliverable.
The final reusable prompt moved beyond simply asking the AI to generate CRUD code. It defined the expected architecture, API behavior, documentation, setup instructions, and quality standards.
RESTful conventions
The API was expected to follow established REST conventions rather than simply exposing CRUD operations.
HTTP status codes
Responses were expected to use appropriate HTTP status codes for different API outcomes.
JSON responses
The API contract included consistent JSON responses rather than leaving response formatting unspecified.
Swagger documentation
Every endpoint was expected to have Swagger documentation as part of the deliverable.
Project structure
The implementation was organized into handlers, models, and main.go.
Setup instructions
The deliverable included instructions for getting the project running.
Result
The final prompt generated code that was much closer to production quality and required considerably less editing.
06 · What I learned
Better AI output starts with better engineering context.
This exercise changed how I think about prompting AI for software development. The goal is not simply to write a longer prompt. The goal is to provide the context that helps the AI understand the engineering problem clearly.
01
Context
Give the AI enough context to understand what is actually being built.
02
Structure
Define important project organization and implementation expectations instead of leaving them ambiguous.
03
Quality
Specify the output and quality requirements that determine whether the result is actually useful.
I learned that effective AI-assisted engineering is less about asking AI to write code and more about giving it a clear, reusable engineering specification.
07 · Evidence
Explore the implementation and the full story.
The case study summarizes the engineering thinking behind the project. The repository contains the implementation, while the Medium article documents the full Week 2 journey and prompt-engineering experiment.
Repository
Task API on GitHub
Explore the Go implementation and project source code.
View repository →Article
Week 2 Journey on Medium
Read the complete story behind the prompt ladder, model comparison, and lessons from the experiment.
Read the article →Gonet/httpGorilla MuxREST APICRUDJSON