101–110 of 112 posts
1. clean structure means the AI can predictably work because i want deterministic output.
2. basic things like following SRP leads naturally to layered code which makes testing new features and fixing bugs super simple.
3. reviewing code is simpler, because i see ai agents as "servants" i command to do something and thus an overseer is still required
One trick I've found that works well is to tell it to refactor, e.g for Python: Refactor the Python code to make it more Pythonic, e.g. fewer classes/singletons, especially if it will provide a speedup. The Python code **MUST** follow code organization standards expected of popular open-source Python packages code without causing any benchmark performance regressions. A variant I've used for Rust code: The Rust codeb…
I can totally see doing this incrementally, but this seems extremely risky to do for the entire codebase in one shot on anything in production. Especially if you don’t have really thoughtful e2e tests of the whole system.
Earlier quoted context omitted.
The word you are looking for is "you're". (Can we not play language police? It's boring and doesn't lead to interesting discussion.)
I think in this context it is actually important to share exact wording that causes the AI to perform well. My favorite is "Do not use your own knowledge."
Earlier quoted context omitted.
I think in this context it is actually important to share exact wording that causes the AI to perform well. My favorite is "Do not use your own knowledge."
That's positively incoherent. You can't even interpret an instruction without relying on prior knowledge. Not to mention LLM's are in essence made of knowledge.
Earlier quoted context omitted.
You don't need the pre commit hooks if you can make the harness hooks.
Belt and suspenders. What if you make a manual code edit? What if your harness hook malfunctions?
> what if your harness hook malfunctions?
That’s a bug in the harness and should be enforced
In my experience everything that affects engineers affects an agent. Good abstractions, reasonably sized methods, good names, principled (intra & inter) service architecture, unit tests, etc. All of these things have historically been the job of engineers, because it helps other people contribute to the code. Now it helps other people and other agents contribute to the code.
If only we cared so much for junior developers.
Interesting question to study, but I'm extremely skeptical of the experimental design. They used Opus 4.6 to synthetically produce "degraded" or "cleaned" code bases for relative comparison in the experiment. Worse, they don't control for breaking the application's tests. > Pass rate scores the agent’s final state against the hidden tests we wrote for each task. We do not check whether the agent broke unrelated tests…
If you're measuring a sloppy project against a well structured one with regard to how many tests fail, that'll bias success towards the sloppy codebase, which likely has worse test coverage and less robust testing in the first place. You'd essentially need to write a single test suite that works for both projects in each pair to compare fairly. That's not to say the study is good, but I can respect their decision bec…
That's pretty much what we did. We start with a repository, and
- (vibeclean pipeline) make changes to clean analyzer issues (some of them involve moving big code chunks around to reduce cognitive complexity), and tweak the existing test sets when needed.
- (slopify pipeline) inverse, add analyzer issues and increase complexity, add dead code etc.
In both cases, we ensure that the test coverage remains the same, and the tests are passing, before we start our experiments.
At work we had largely moved off of some old hardware but kept partial support for it in the code because normally that would be zero cost. But the constant overhead of bullying, bribing, and threatening the LLMs to leave that code alone was way more work than just excising it and reimplementing it if needed.
In my experience, the delta in agent performance is substantial if the codebase is littered with dead code, redundant code, unreachable fallbacks, leaking abstractions and half-baked design patterns vs if the code is well-organized, with clear data flow, with good encapsulation and clean architecture. Like, I've seen all the frontier models have to do several rounds of code review / QA and fix when the code is bad vs…
Some of the issues mentioned above like dead code removal, code duplication, unreachable code are already solved using deterministic linters for quite a while now for most language ecosystems. You can get the LLM to run a script which checks for all of these and also enforce them by running the same script as a pre-commit hook. Setting this up religiously in every code base I work on has been what's given me the most…
The reason is quite obvious if you have dealt with such a huge code basis in production with thousands of developers contributing for decades to it coming from different vendors and countries.
Code has a meaning attached to it. And paradoxically being able to cleanly cut out such dead code raises my suspicion. There is a reason why such code exists in there often times and since almost always stakeholders give a damn about documentation, and developers traditionally have a hard time writing even JavaDocs, JSdocs, whatever and not to mention maintaining them.
In earlier times CPU time was precious and comments were deliberately left off due to space and processing considerations.
So why is this all important?
Because until you cannot find the one guy who uses this code for a good reason, I would never kill it. Good reasons in these cases are almost always so called application owner, an app admin and hosts, who serves according to ITIL specs as deployment and production person.
Dead code can be actually quite lively under the right circumstances. And since sometimes people have to be very creative to serve regulation requirements and compliance, sometimes release pressure or missing tools can make such code an important script or deployment tool or fix for a reboot or whatever.
Believe me, dead code isn't. What you can do is, watch it at least over a period of two years.
Here is why.
Most processes have yearly deadlines. Many fall on the 1.1. of each year, while others somewhere at the end of the year. Some processes need to be served once a year due to compliance to laws.
And why two years then? As I said, human beings. Maybe that one time a guy had an exception running for it or there is a maintainer, who uses a different method - his own dead code so to say - because these scripts are rarely shared and maintainer's best kept secrets. The lesser a company knows, the more important these last line folks feel and they are blackboxes when something is or isn't working. (I hated this, this was not way of working and I changed it. It is not their company and a keeper is a Red Flag for me.)
But rarely the same person will serve the process two times in a row. Vacation times vary as well as positional changes.
Hence the two years period and even then, there are smarter, more easier ways than to use linters.
Hint: it is the frontend first paradigm.
How do I know? Because I invented it. Proof: Huge international Bank. dbCORE.