Fractional CTO · AI-Native Engineering

Code is becoming abundant. Judgment, context and operating leverage are not.

I'm Giulio De Luise. I help product companies and engineering firms redesign how they work as agents take on more of the execution: the harness agents work within, the organisation around them, and the controls that make them trustworthy in production.

Hands-on, on real work, one to three days a week—until the capability belongs to your team.

01 — What I do

Redesign the system around the agents, not just the output.

/01

Engineer the harness

AI-native development is not just faster code generation. Agents need an environment they can reliably work within: clear intent, usable context, the right tools and fast feedback.

Humans define the outcome, constraints and acceptance criteria. Agents take on more of the execution loop. When failures repeat, improve the system around the agent—not just the generated output.

  • Repositories structured for both people and agents
  • Versioned specs, architecture and operating context
  • Shared tools, skills, checks and CI feedback
  • Evals against explicit quality, cost and performance baselines
/02

Organise for agent-native work

As implementation becomes cheaper, human attention becomes the constraint. Engineering shifts upstream: understanding the problem, decomposing it well, specifying intent, designing the system and judging the result.

That capability has to live in the organisation, not in individual prompting habits.

  • Clear ownership of intent, specification and acceptance
  • Analyse and de-risk before committing to implementation
  • Build reusable context, tools and feedback loops across teams
  • Hire and develop for judgment, systems thinking and agent orchestration—not simply coding capacity
/03

Operate agents as production systems

An agent that works in a demo is not necessarily an agent you can trust in production. Autonomous behaviour needs explicit boundaries, continuous evaluation and a clear path to intervention and recovery.

Define what the agent may decide, what requires approval and how you know when its behaviour has degraded.

  • Explicit permissions, authority and escalation boundaries
  • Evals and observability from the start
  • Quality, latency and cost tracked in production
  • Rollback, recovery and auditability by design
  • Human accountability for consequential decisions

02 — About

25 years of turning technical decisions into working systems.

I started in enterprise software, then built products, platforms and data systems for high-growth companies. I've led engineering and data organisations, founded companies and worked through the consequences of technical decisions long after the architecture diagram was finished.

I still build.

AI-native engineering changes quickly, and redesigning how a team works requires understanding the work firsthand—not just advising from the outside.

03 — When to call me

Your engineering changed. Your operating model needs to catch up.

Building a product

  1. 01

    Agents are producing more code, but not yet more confidence

  2. 02

    A prototype works; you need to make it reliable in production

  3. 03

    Delivery is accelerating and your existing roles and controls no longer fit

  4. 04

    You need experienced technical leadership before you need a permanent CTO

  5. 05

    You want AI-native engineering to become a repeatable capability, not a collection of individual prompting habits

Delivering engineering for clients

  1. 01

    You want to sell outcomes, but your delivery model still depends on hours

  2. 02

    Each engagement rebuilds the same context, tooling and practices from scratch

  3. 03

    Rework is eroding fixed-price margins

  4. 04

    AI usage is widespread, but cycle time, quality or margin have barely moved

  5. 05

    You need a delivery model in which improvements compound from one project to the next

04 — Questions

What people ask before we start

Do you write code?

Yes, when building is the fastest way to test an assumption or make a decision.

But the engagement is not additional engineering capacity. It is about improving the system your engineers work within.

Will agents replace my engineers?

That is not the operating assumption.

As agents take on more implementation work, engineering effort shifts toward problem definition, architecture, specification, context, evaluation and review. The objective is greater leverage from the team you have.

We already have a CTO. Does this still help?

Yes. The CTO is usually one of the people I work with most closely.

The aim is to strengthen the engineering system, not create a parallel one.

How much of your time do I get?

Typically one to three days a week, depending on the stage and scope of the work.

What does it cost?

Usually a monthly retainer agreed before we start.

Where outcomes can be defined and measured clearly, part of the engagement can be linked to results.

Cash or equity?

Mostly cash. In some situations, both.

What happens when you leave?

The operating model is yours.

Decisions are documented, ownership is clear, and the specifications, tools and practices live inside your organisation. There is no dependency on me to keep it running.

Remote or on-site?

Primarily remote from London. On-site when being in the room materially improves the work.

05 — Contact

If agents can do more of the execution, redesign everything around it.

The useful question is not how much code AI can produce.

It is what your product, engineering organisation or delivery model should look like when implementation is no longer the constraint it used to be.

Tell me what is changing and where the current model is breaking.

If there is a useful engagement, we will start with the smallest one that can prove it.

giulio.deluise@algolambda.io LinkedIn