Sphera
Data Developer
Cut production build time by 30% by rewriting the SQL an ORM was silently generating
C# and Entity Framework mapping specifications, rewritten so the generated SQL looked like something a DBA would actually recommend. Verified data integrity before and after so the win didn't quietly change behaviour.
The problem
Production builds were slow enough to hurt developer productivity across the team. The existing data-access layer was making more round-trips than the queries required, and the default query shape Entity Framework generated was not the shape a DBA would have written by hand.
Why it was hard
The ORM had shipped years of accumulated conventions. Changing one mapping cascaded into places nobody remembered writing. Every rewrite had to be walked back through the callers to prove nothing else moved.
'Faster' and 'still correct' are not the same test. A query that returns the same row count with slightly different ordering can silently break a downstream report. Behavioural equivalence, not speed, was the actual bar.
The team was on a shipping cadence. Optimisation work had to land in small pieces without pausing feature development. That meant no big-bang rewrite ever, only surgical mapping-by-mapping changes with a rollback plan each time.
The approach
Developed mapping specifications in C# using Entity Framework to optimise the data access pattern.
Read the SQL Entity Framework actually generated behind the scenes, rewrote the mappings so the output looked like something a DBA would sign off on, and used efficient SQL to maintain and verify the data.
Verified data integrity before and after every change so the optimisation did not quietly change behaviour.
The outcome
Production build time down 30%.
Overall software development efficiency improved.
Behavioural equivalence held across the changed data-access surface.
You have this problem if
- Your build or test suite has slowly gotten slower over years and nobody knows what regressed when
- The data-access layer is on autopilot: the framework generates the queries and nobody reads them
- A performance optimisation once broke a report because equivalence was assumed rather than verified
- You need speed wins in a shipping codebase without a scheduled 'refactor sprint' the business will never approve
What I take from this
ORMs quietly generate the query they are going to generate whether the shape is right or not. The 30% came from reading the actual SQL, not the C# that produced it. The same lesson applies to LLM-generated code today: read the output, not just the prompt.
How this shows up in my work today
Read the diff, not the prompt. That single sentence generalises the Sphera lesson to every LLM-integrated project I take on. The AI wrote code that type-checks; the SQL Entity Framework emitted also compiled. In both cases the correct next step was to open the actual output and read it. The 48h demo path is built around exactly that reading discipline: I hand you what the model produced, and I've already read it.