How We Started with Prompt Engineering
Part 1 of our Claude Code journey: what prompt engineering gave a 25-year-old software house, where it broke, and the lesson that pushed us forward.
Part 1 of 3 — the Busoft Claude Code journey.
Twenty-five years of building software teaches you to respect any tool that changes how software gets made. When Claude Code entered our daily work, the first skill everyone reached for had a new name and an old spirit: prompt engineering — say it better, get better software.
What prompt engineering gave us
It worked, and quickly. We learned to be specific instead of vague, to show an example of the output we wanted instead of describing it, to state constraints — the framework version, the coding standards, the things that must not change — up front. We learned to give the model a role and a definition of done. A well-written request produced in minutes what used to take an afternoon.
For a team like ours the surprise was how familiar it felt. Writing a good prompt is writing a good ticket: context, intent, constraints, acceptance criteria. Engineers who were good at briefing a junior developer were suddenly good at briefing a model.
Where it broke
Then the tasks got longer, and the cracks showed. On a big refactor the model would honor a constraint in the first file and forget it by the fifth. Every new session started from zero, so we found ourselves pasting the same background again and again. Prompts turned into folklore — "use these magic words, they work" — which is exactly the kind of engineering-by-superstition our industry spent decades escaping.
The conclusion, once we said it out loud, was obvious: a prompt is an interface, not a program. You cannot fit a company's knowledge, a project's history and a task's guardrails into one well-phrased paragraph. Something bigger than phrasing was needed.
Three lessons that survived
1. Specificity beats cleverness — plain, complete instructions outperform any trick. 2. Examples beat descriptions — one real sample of the desired output is worth a page of adjectives. 3. The prompt is only the front door — everything the model can and cannot see decides the outcome. That third lesson has a name, and it is where part 2 of this series goes: context engineering.
The foundations are public and worth reading: Anthropic's prompt-engineering guide is the canonical starting point. In the Busoft Academy we teach it in one session — because the sessions after it are about everything the prompt cannot do alone.