Before diving into new tools, it’s important to ask: why do we need these tools in the first place? What real problems in development do they help us solve?
Discussing tools without first understanding the challenges and core approaches of software development would be missing the point. Tools are only effective when they are integrated into the right process and address specific needs.
In some branches of engineering, things are much more predictable and linear. If you build a bridge, you can’t just roll it back while everyone’s asleep, repaint it a different color for a few minutes, or toss the finishing touches into a never-ending backlog.
But in the world of software development, everything is different: requirements and technologies change constantly. That’s why it’s so important to understand the development process itself — so we can consciously choose and implement tools like LLMs where they truly make a difference.
Core stages of development that stay with us
Developers operate in an environment where everything changes: requirements,
technologies, ecosystems. Yet, despite this, there are fundamental stages
that have remained unchanged for decades — from the first programming textbooks
to modern methodologies.
- Requirements analysis. Understand the business goals of the project, gather functional and non-functional requirements, assess risks, and create an action plan. This is the stage where the entire project direction can change.
- System design. Here, abstract ideas turn into architecture, diagrams, and specifications. It’s the moment when the team aligns on the rules of the game and formalizes them.
- Implementation. Only after this do ideas come to life in code, hypotheses are tested, and the product is prepared for real-world use.
These stages are like the laws of gravity. They don’t disappear, even in the era of Agile, DevOps, and CI/CD. But the environment of software development introduces its own unique challenges.
At any of these stages, we may encounter countless problems. Let’s pause to look at a few that are especially characteristic of software development:
1. The invisibility of results
You can’t touch a finished software product. There’s no concrete, no steel reinforcement — only lines of code and interactions between services. Even if everything seems to work perfectly, dozens of hidden factors can surface later: from unstable APIs to server overloads.
2. Flexibility as a source of chaos
In software, you can roll back a release, add testing, or switch frameworks on the fly. At first glance, that seems like a plus. But the same flexibility breeds chaos: dependency mismatches, library instability, endless bug fixes.
In bridge construction, there’s no such luxury — and maybe that’s why civil engineers sleep more peacefully.
3. The rise of multidisciplinarity
Once, a full-stack developer could do it all. Today, frontend engineers must understand how the backend and infrastructure work, while DevOps needs to know what the client side requires. Without understanding the full cycle, it’s impossible to create a high-quality product.
These stages greatly influence the problems, which in turn
interfere with subsequent stages. And we can’t escape the law of software entropy:
if we don’t address emerging issues, soon our development
will simply stop being cost-effective.
Now we’re finally getting closer to new tools and how they can help us, freeing us from routine and the mental overhead of keeping everything in our heads.
We’ll go through all the stages and see what can be achieved at each one in the context of an existing project or system.
Step 0. Setup and preparation
Our goal is to extract the maximum amount of
automated, useful information from our assistant.
To work effectively, we need to verify and configure
our tool so it understands the project context. For this, we need:
- an indexed codebase;
- uploaded rules, templates, project code style, and custom use cases;
- links to external and internal documentation, libraries, and frameworks;
- configured MCP servers for tools that support them, to improve speed and usability.
- For example, frontend rendering is still a weak spot: most projects require custom solutions that a model can’t fully account for. But even this step can be improved soon, with MCP server capabilities like those in Figma.
- or Swagger MCP
All of the above is easy to configure in a dedicated environment.
That’s why I use Cursor — especially since it offers excellent setup documentation.
But I believe most agents and LLM-based solutions today can provide the majority of these settings.
Step 1. Design: from specifications to architecture
At this stage, our task is to establish the necessary context.
This is no different from laying the foundation for future system design:
we create context and documents that our colleagues can refer to.
With a model, the case is almost identical.
During analysis, we may accumulate various documents and drafts:
meeting notes with stakeholders, personal sketches, diagrams, acceptance criteria, use cases.
This can all be scattered and difficult to assemble, especially when there are “needed yesterday” tasks, endless calls, and little time left.
But now we can consolidate this data into a single system of artifacts — I call them raw specifications.
Raw specification
A raw specification is a set of files prepared manually and analyzed by humans.
These might be created by system analysts, senior developers, or architects.
It’s not yet the final version of the specification but already includes key analytical details.
From these files, we generate a technical specification that will be:
- well structured;
- generated using our specification templates to ensure a unified style;
- prepared for tokenization and LLM processing;
- ready to hand off to developers or even another model to start design work;
- containing use cases in a format suitable for QA teams and for writing tests;
- including acceptance and delivery criteria;
- describing data types for specific programming languages;
- listing system participants and their interactions.
Example of such an analysis file in GitLab
Once the raw specification evolves into a technical one, the team gains a map of the terrain:
data models, properties, actors, interaction scenarios, links to directories and APIs.
Step 2. Generating models and service templates
Now we can move forward to design and implementation.
A technical specification isn’t just a handy artifact to read on the weekend; it’s
a tool for defining the model’s context boundaries and guiding its focus.
From this specification, we can generate:
- Data models and types — the core of all business logic;
- Mock data based on types — used in tests and development while real data is unavailable;
- basic CRUD operations and API integration points;
- for client apps, generate stories in Storybook;
- service templates with method sets or client APIs, generated using predefined templates and our data models;
- based on our use cases and spec criteria, generate unit/e2e tests;
- after task completion, collect diff metadata for handoff to other teams: content managers, translators, or SEO specialists.
All the examples above were generated from the specification.
Of course, they’re not production-ready code,
but that’s why we carefully configure the model’s context and analyze the task to get more accurate outputs. Moreover we’ve got part of project that can be run and test!
At the end of these stages, the team gets:
- the analysis, technical specification, and use cases;
- testing and acceptance criteria for tasks;
- a solid foundation for handing the project over to another developer or even another model;
- integration, e2e, and visual tests (depending on the focus area).
Naturally, tasks won’t be fully completed for us,
but at this stage of technological progress, we don’t expect them to be.
We can already get a significant productivity boost for the project (unless we’re talking about an MVP or prototype).
LLM: an assistant, not a magic executor
It’s worth emphasizing again: behind all the automated and generated information,
there’s still a foundation created by humans.
Don’t forget this and leave critical decisions to the model’s discretion.
It lacks intuition, experience in undocumented edge cases, communication skills for gathering additional information, and the ability to make critical decisions. By strengthening your base and automating routine tasks, you unlock enormous potential for developing other skills and diving deeper into both the project and your area of expertise.
Conclusion
During the process of writing and researching this post, I realized that many companies and developers are now starting to adopt this approachю Some of them are even creating tools, like Amazon’s kiro and publishing developer articles to support and promote this way of working. I’m sharing a few links below for those who want to dive deeper into this topic and explore how the industry is moving in this direction: