Rafal Kochanowski

One engineer, real answers, no theatre

[Rafal Kochanowski @rafalsoftware]

Software engineering depth combined with a business mindset and product view. Digging deeper, asking questions, focusing on what matters.

Most work doesn't need that. Some work needs it badly.
I offer services built around this experience and approach.

https://t.co/5ircd68xnp

[Rafal Kochanowski @rafalsoftware]

@iXon_fXury No, this is not a tool's use case. You can analyze one project to find duplicated logic to refactor.

[Rafal Kochanowski @rafalsoftware]

Code duplication detector for the hardest-to-detect clones.

Based on embedding models for finding similar code. The models were benchmarked to get the most out of it.

[Rafal Kochanowski @rafalsoftware]

Building the tool that uses embedding models to find the hardest-to-detect duplicated code was only one part.

Now that I've benchmarked the models, we can get the most out of it. The results surprised me.
https://t.co/NxzbEPLFdl

[Rafal Kochanowski @rafalsoftware]

@jona5nilsson It should be moved to constant like other variables. Mostly because of readability, not performance.

[Rafal Kochanowski @rafalsoftware]

Last year I built a legal AI app. This article explains one solution that improved RAG in a difficult legal domain.

I used the described formula again in my latest project, a code analyzer.
https://t.co/1ihkgY0h8Y

[Rafal Kochanowski @rafalsoftware]

@uwu_mrrp OK, I see the ambiguity in what I wrote. Hopefully, the second sentence clarifies this.

[Rafal Kochanowski @rafalsoftware]

@Stipe Yes, they will be flagged as duplicates, but this is by design. Next step in workflow is to ask AI coding agent discard that cases and they are pretty good in it.

[Rafal Kochanowski @rafalsoftware]

I built an open-source tool to help AI-assisted developers refactor code. It uses embedding models to find the hardest-to-detect duplicated code.

[Rafal Kochanowski @rafalsoftware]

@pasmichal_ It does static analysis (no code execution).

If you mean other tools, they are more deterministic, faster (no embedding calculation needed), have fewer false positives. Slopo targets problems that other tools miss but introduces its own trade-offs.

[Rafal Kochanowski @rafalsoftware]

There is a data.md file attached to the article with a list of included projects.
I don't know if developers use AI tools, the point was to observe any trend.

In the largest section, "Limitations and conclusions" I wrote what else can go wrong while doing such analysis. This is the main value of this research, not to prove something.

My goal was to get some real data instead of relying on what others believe and results were different than I expected. I used open source projects because I don't have access to anything else, and this is another limitation of those analyses.

[Rafal Kochanowski @rafalsoftware]

AI coding tools introduce duplication and everyone uses them, so code duplication should raise in general?

My analysis didn't show any trend, but it demonstrated how wrongly this research can be done and how misinterpreted the conclusions can be.
https://t.co/VG0DJ48ULX

[Rafal Kochanowski @rafalsoftware]

Should you allow team members to interrupt each other's work, or ensure uninterrupted, focused work? I suggest taking a step back and looking at this problem from a different perspective.

We know that uninterrupted work is good and frequent context switching is bad. We also know that interrupting your own work to improve the work of another team member is good, and prioritizing your own work at the expense of the team is bad. This issue provokes heated discussions, often leading to extreme opinions. In reality, both approaches can work, because it all depends on the team, individual differences between people, the problem we are solving, the specifics of the tasks, and the organizational culture.

In this post, I try to look at the problem from the perspective of real teamwork, rather than a set of rigid rules. When I write about "teamwork", I mean performing work in such a way that the team as a whole delivers as many high-quality results as possible. This work culture assumes that everyone is partly responsible for the team and the common result. Individual results are secondary.

If teamwork works, we don't need rigid rules. If someone's task depends on me (e.g., waiting for code review), I can interrupt my work to unblock it. But if I'm working on a key feature that the rest of the team's work depends on, I can be more assertive and focus on my task. Each time, I assess what effect my decision will have on the result of the entire team.

This level of self-organization is difficult and rare, so establishing rules regarding team member responsiveness may be the right solution.

If you would like to improve your team's self-organization, here are a few things to consider:

- How are people assessed, e.g., during evaluations or feedback sessions? Does it matter what a person delivered on time or whether they helped others? We are good at optimizing our work in terms of the metrics by which we are assessed.

- Are the team results sufficiently visible? My tickets are clearly visible, but the fact that I helped someone without bragging about it is not necessarily so.

- Does the organizational culture and communication support this approach? If someone refuses to help me immediately, I don't take it personally because I understand the reason.

- Are we aware of the differences between people? Some may be good at switching contexts but worse at working with sustained focus. Others may be able to work continuously on a task, but switching contexts is more detrimental to them.

- Are the team's priorities and goals known and understood by everyone?

- Do we know what other people are doing at any given time, and are we able to assess how important their tasks are in relation to the team's goals?

[Rafal Kochanowski @rafalsoftware]

@oriSomething @GergelyOrosz It's hard to guess without knowing the architecture and code quality. If, thanks to AI, they added more code and complexity than they would have before AI, the outcome is not obvious.

[Rafal Kochanowski @rafalsoftware]

@GergelyOrosz Human nature hasn't changed, and it still has a large impact on software engineering.

For example: preferring quick hacks, optimizing work for metrics, focusing on what is more visible, avoiding what is less comfortable.

[Rafal Kochanowski @rafalsoftware]

@Carl_Fr_Gauss3 It focuses only on one issue, code duplication.

Tools are only tools, they are intended to support humans, not replace them, IMO. To create clean code, agents should be steered, controlled, monitored by experienced developers.

[Rafal Kochanowski @rafalsoftware]

@GaneshKompella The model provider won't solve any problem AI wrappers solve. They die because it's too easy to build them. Domain knowledge and data are the hard parts that make a difference. Solving more local and narrow problems can also help survive.

[Rafal Kochanowski @rafalsoftware]

@agazdecki Planning with survival in mind, rather than just quick success, can be helpful, but who thinks about that? Focusing on low costs of running a startup, low costs of app maintenance are contrary to the advice we often hear (to move fast no matter what).

[Rafal Kochanowski @rafalsoftware]

Flow state is something different from deep focused work, even if both are similar and can feel good.

Flow is about performing activity/work we have at least some experience with, and the challenge is aligned with this level of experience. The work flows effortlessly, we lose awareness of time, etc.

AI coding is a new way of working, and maybe we are not experienced enough in it? It's like expecting to hit a flow state during our first year of learning to code.

[Rafal Kochanowski @rafalsoftware]

@gregorojstersek This shows us where we are in the transition. This is a normal thing, but more intense than the adoption of technologies like containerization or microservices in the past.