Redefining Software Engineering by Turning Business Understanding into your Superpower with Cursor

At Ballast Lane, we believe that truly impactful software engineering begins with understanding the business problems behind the code. This article explores how we’re using tools like Cursor, an AI-powered IDE, to bridge the gap between legacy code and business logic. While many AI tools promise to write better code, Cursor helps us understand our systems better. In this piece, I’ll walk through how we’ve been using it to untangle real-world challenges, speed up documentation, and elevate the role of business understanding in our development workflow.

Context is key to getting the best results from Cursor. Anyone familiar with generative AI knows that it tends to hallucinate, especially when there are gaps in information, which ultimately stem from a lack of context. This is where Cursor shines compared to tools like ChatGPT, Gemini, or other AI tools able to code: it excels at managing context.

Cursor can help you better manage business rules, even in an existing, legacy project. How? As I mentioned earlier, context is everything. So the key is to start bridging the gap between what’s in the code and what it actually means from a business perspective.

Over the past few months, we’ve been experimenting with a technique that starts by leveraging known behavior from a legacy system in production. Using that knowledge alongside access to the codebase, we began unraveling the internal logic to identify bugs and extend the system with new business rules.

Let’s say the feature in question is called feature_1. The first step would be to create a new file named feature_1_initial_description.md, and begin documenting everything you know, the business rules the feature is supposed to follow, and optionally, any issues or inconsistencies you've noticed. The more context, the better.

Once that file is in place, you’re ready to start unpacking the black box. Open Cursor’s chat (press CTRL+I or CMD+I, depending on your OS), switch to Agent mode, and write a prompt using your Markdown file as reference. You can begin with something like:

I want to document the business rules currently implemented in the codebase. Here are the business rules I already know and the issues I’ve observed. But for now, focus only on documenting how the feature is actually implemented in the code as it stands. Use @feature_1_initial_description.md as context and output the result to a new file called feature_1_documentation.md.

Trust me, you shouldn't rely 100% on the first output, especially not right away. What Cursor does is begin exploring your codebase and connecting the dots between the business rules you’ve outlined in the initial description and what’s actually implemented in the code.

This is where an experienced software engineer becomes essential. Because the initial outputs aren’t always reliable, you’ll need to validate the results and iterate on the documentation. A great way to do this is to use Cursor itself, either with the same model or even a different one, to validate your first draft. Try a prompt like this:

I have these business rules documented based on what’s in the code, and I want you to find the specific code segments that correspond to each rule. Can you extract them for me? Use @feature_1_documentation.md as context. Put the output in a new file called feature_1_technical_documentation.md. If you notice any inconsistencies or errors in the original documentation, please let me know so we can correct them.

Two things typically happen here:

• Cursor will analyze the documentation and begin identifying exactly where those business rules are implemented in the code. You can then follow along and verify that it all checks out.
• If the initial documentation is inaccurate or incomplete, Cursor will point out the gaps and help you improve it, giving you a more accurate reflection of the real business rules.

In short, you’re creating a feedback loop that lets you validate and iterate on the initial output.

Now, let’s say you’re reviewing the documentation and something feels off. You can zoom in on specific sections and ask Cursor focused questions like:

I think this part of the document is incorrect, because based on what I see in the code, it actually does X. Can you check this and, if needed, update the document accordingly? @feature_1_documentation.md

This back-and-forth is what turns AI into a real collaborative tool, especially when guided by your expertise. At this point, you’ve become a code-to-business-rules transformation expert. So what’s the real win here? It’s the ability to truly understand complex systems and identify their issues with clarity. With this skill, tackling isolated problems becomes much easier, and naturally, the next step is fixing them.

Of course, there's also the reverse process: translating business rules into code. It's a similar approach, but flipped, and definitely a topic worth exploring in the future.