Pillar 01
AI for Software Engineering.
Also known as AI-SDLC or AI4SE. The active research frontier (ICSE, FSE, ASE are full of it) and the practical question every IT organization is now facing. How do you get from "we bought Copilot for a few teams" to AI as a structural part of how engineering ships? And once you have got to 10, how do you roadmap to 100?
The hard problem: legacy modernization
The interesting work isn't faster boilerplate. It is LLM-assisted legacy modernization of the systems that have been resistant to every previous wave of transformation. Concretely:
- Decomposing monoliths. Cutting apart applications and stored-procedure layers that no one has dared touch in fifteen years, with the model doing the structural reading and the senior engineer making the calls.
- Refactoring legacy data models. Untangling the monolithic schemas underneath the monolithic code, including the parts where business logic is hiding in views, triggers, and procedures.
- Documenting undocumented systems. Producing the documentation that should have existed for fifteen years, generated from the code itself and reviewed by the people who own the systems.
This is where AI's leverage on enterprise IT is highest, and where the off-the-shelf vendor playbook is least useful. It is also where most of our hands-on R&D effort sits.
What we do
Adoption strategy and roadmap
We help leadership team frame the question correctly (current capability, candidate pilots, guardrails, measurement) and design a phased adoption plan that does not collapse on first contact with regulated reality. The early signals are deliberately small and visible within weeks; the maturity model behind them is full-cycle.
Workshops and training
Executive workshops that build the business case. Hands-on engineering workshops covering prompting techniques, spec-driven development, agentic-centric development cycles (ACDC), context architecture, and AI-augmented security workflows. Tailored to the audience: your CIO needs a different session than your senior engineers.
R&D sprints and live prototypes
A typical engagement is a structured set of sprints: documentation generation, AI-driven unit test generation, vulnerability remediation combining LLMs with SAST, integration and data-model analysis. The output is not a slide deck. It is working prototypes, meta-prompt libraries, fix-pattern catalogues, and measurement instrumentation that the organization keeps and extends.
Impact analysis and Agile re-engagement with the business
AI-augmented delivery means IT can engage the business differently: much shorter feedback cycles, live prototypes instead of static specs, real-time impact analysis when a change is proposed. We help redesign the operating cadence and the artifacts that move between IT and the business, so the productivity gains translate into delivered outcomes rather than slack capacity.
From 10 to 100
Once a pilot has proven out, the scaling work begins: Center-of-Excellence design, enablement programs, internal AI assessments, role-evolution guidance, and the measurement layer that distinguishes real adoption from theater.
Who this is for
IT organizations that have moved past the "buy some seats and see what happens" phase. Especially relevant for financial services and other regulated industries where the standard rollout playbook does not fit, but not limited to those sectors.
Curious whether an engagement makes sense? Get in touch.