Role
Software developer
How long does it take before a new person on the team makes their first meaningful change? That number says more about your code and your documentation than any quality metric.
Intro call
Four questions we would start with
How long does it take before a new person makes their first change?
If it is weeks, you pay the onboarding cost at every turnover - and turnover in this profession is a fact.
What do you put off first when a deadline is close?
Usually tests and tidying the code - which is what turns into debt that the next quarter repays.
Where does the knowledge of why something was done this way end up?
If it ends up in a conversation at code review, then in six months nobody will know whether it was a choice or an accident.
Which kind of task repeats most often?
Usually three or four patterns - and usually nobody has counted them.
We take over the repetitive work, you keep the design and the judgement
Understanding the context of the code, drafting repetitive changes, preparing tests and a first-pass review can be taken off the desk. Design decisions and the final judgement on the code stay with a person.
- Context arrives faster than by reading. - What this module does, who changed it and which changes are related to it - before the developer starts reading line by line.
- The review starts with what the linter and CI will not catch. - Formatting and tests you have almost certainly had under control for a long time. This is the layer above: whether the change touches places the author may not have noticed, and whether it repeats a solution rejected six months ago.
- Debt is visible rather than felt. - The places changed most often and those of the highest complexity are pointed out, so the conversation about refactoring has a basis.
Scope
What can be taken off a development team
Nineteen example tasks. Each one has a human approval point. Below is a selection, and the scope we fit to your stack and process.
Understanding the code and its context
- A description of what a module does, based on the code (verification: the developer)
- Pointing out places related to the fragment being changed
- The history of changes in the area with the reasons
- Pointing out the documentation covering the area
Writing the change
- A draft change for repetitive patterns (judgement and correction: the developer)
- A proposal of tests for the change written
- Pointing out places needing updating after the change
- A signal when a change breaks the agreed conventions
Code review
- A first-pass review before the human review
- Pointing out missing tests
- Pointing out changes touching related places the author may not have known about
- Changes to review ordered by risk (decision: the reviewer)
- A reminder about a review that is waiting
Tests and release
- A proposal of cases the existing tests do not cover
- Pointing out tests that stopped passing and the reason the behaviour changed
- Linking the change to the task and the release
Technical debt
- Pointing out the areas changed most often
- A summary of the places of greatest complexity
- Linking production bugs to areas of the code
A day's work
Today
- Before a change you read the module to understand what it does at all
- You find the related places by searching and by the team's memory
- You write the repetitive work by hand, although it looks the same every time
- The reviewer works out for themselves what else this change touches
- A review waits a day or two, because nobody knows it is waiting
- You talk about technical debt at the retrospective, with no data
With AI assistance
- You have the module description and the related places before reading the code
- A repetitive change has a draft, you judge it and correct it
- The tests for the change have a proposal
- Related places are pointed out with the change rather than searched for
- A waiting review reminds about itself
- Technical debt is pointed out with numbers, not with an impression
- Time to a first change
a new person gets into the code sooner
a module's context is available without reading all of it
- Time waiting for a review
changes do not sit in the queue unnoticed
reminders, and an order based on risk
- Review quality
the reviewer sees the reach of the change, not only the diff
the related places and the history of decisions sit with the change
- Visible debt
the conversation about refactoring has a basis in numbers
the areas changed often and the complex ones are pointed out
We start with context and review, because it is the least risky and the fastest to feel.
- Step 1
Code context and relationships
Descriptions of modules, the history of changes, related places.
- Step 2
First-pass review and tests before the human review
Conventions, missing tests, obvious mistakes before a person's eye.
- Step 3
Drafts of repetitive changes
Only the patterns that genuinely repeat, and always with the developer's judgement.
- Step 4
Visible debt
The areas changed most often, linked to production bugs. Last, because it needs history.
Common questions
Questions that come up at the first meeting
What about code we are not allowed to send anywhere?
That is a common condition and it is settled at the architecture stage, not in the content. Solutions running inside your own infrastructure are real; if they are not, the scope narrows to what can be done without sending code outside. That conversation is worth having beforehand, not afterwards.
This is the question the whole market is asking today: will AI replace programmers?
The honest answer: not within the scope described here, and we do not pretend to have an answer to the whole question. What we propose concerns the context of the code, repetitive patterns and the first-pass review, which is the work a developer considers least interesting anyway. Design decisions, judging trade-offs and accountability for what reaches production stay with the team. If we take over more than that, you lose by it, not us - and that is why the line is worth setting with the team rather than for them.
Does this fall under the AI Act?
Producing software is not a high-risk use. The only point needing care is that data about code changes is not used to compare the productivity of individual developers - we keep the summaries by area of code, not by author.
Still have a question that is not here? Book a call
Next step
How much time does your team spend reading code before changing it?
We will show you what a team's work looks like when the context arrives earlier and code review starts with the design decisions.