A2X

AI methodology for deep-tech R&D teams

Individual AI gains are real. Team throughput stays flat until verification and method catch up. A2X builds the engineering methods that make AI stick for deep-tech R&D.

Book a call

Your developers got faster. Your team didn’t.

Your engineers already use AI coding tools. Many of them write and refactor faster than they did a year ago. That part is real.

What often does not move is the team’s delivery rate. Work still waits on review, on integration, on tests that catch what a model guessed wrong, and on the quiet rework that follows a confident but incorrect change. Verification, not prompt skill, is the bottleneck.

A2X exists for teams that have already adopted the tools and still feel stuck. For the longer argument, see the guide: Why AI made your developers faster but not your team.

throughput AI in the loop → verification ceiling individual output team, no method team, with method
Fig. 1 — The verification ceiling. Illustrative shape, not measured data.
Method

A method that runs every time.

One-off prompting fades. A workshop fades. A shared chat history fades. What lasts is a method the team can run on the next ticket, and the one after that.

A2X builds persistent engineering methods on both sides of the work:

On the human side

How specs are written, how review is done, which habits survive a busy week.

On the systems side

Where automation and autonomy belong so verification does not depend on heroics.

Then the method is tuned against how the team actually ships, not against a slide deck. The goal is not a better prompt. The goal is a way of working that still works when AI is in the loop every day.

Where that work is heading, as agents take on more of the implementation, is in the guide: Where R&D effort goes when AI writes the code.

Engagement

How an engagement runs.

Engagements are built for transformation, not a one-off diagnosis.

  1. Phase one · typically two weeks

    Work starts with a short diagnostic as phase one of the engagement (typically two weeks). That phase maps how the team already works, where AI helps, and where verification and process break under load. It is the first step inside the work, not a product on its own.

  2. Then · 3–5 months

    After that comes a 3–5 month implementation retainer: methods are installed, practiced, and adjusted with the team. Workshops are available when a focused skill or ritual needs a room of its own.

No prices on this page. The call is where fit and scope get concrete.

Fit

Fitted to your stack, not imposed.

Deep-tech teams already have a stack, a review culture, and often a preferred way to write specs. A2X starts there.

If the team already runs a form of spec-driven development, that becomes the backbone. If they prefer another process, the method is built around that preference instead of replacing it with a packaged playbook. Toolchains, languages, and constraints (including on-prem or air-gapped setups when they apply) shape the design.

The contrast is simple: many AI programs arrive with a fixed process and ask the team to bend. A2X bends the method to the team’s real work. More on how that looks for algorithm, computer-vision, and embedded groups is in the guide: Spec-driven development for algorithm, CV and embedded teams.

Audience

Who it’s for.

A2X is for deep-tech R&D groups whose work is algorithmic code, computer vision, or embedded and physical-systems software — primarily in Israel, and also remote teams or Israeli R&D centers of companies abroad. Typical readers are Heads of R&D, VPs of Engineering, and CTOs whose teams already use AI coding tools but have not yet seen team-level throughput move.

It is a poor fit for teams looking only for a tools training session, for companies whose main need is marketing or sales content with AI, or for groups that want a fixed vendor process with no change to how engineering actually runs.

About

About Tomer.

Tomer Harari Hamam, PhD, has spent his career where software has to work before it ships: autonomous driving, localization, real-time vision.

At Imagry he grew the motion planning and decision-making group from 4 to 12 engineers across three teams, moved it from rule-based methods to learned and optimization-based planning, and delivered the stack to a seven-vehicle test fleet. The change that mattered most was verification: he built the group’s first simulation environment so planning bugs were reproduced and regression-tested before road tests, not found in the car.

As co-founder and CTO of NeuronBox, an industrial AI startup, he ran development through an agent-based pipeline from specification to deployment, with evaluation harnesses deciding between competing designs. That is the method A2X brings to client teams.

PhD in Electrical and Computer Engineering, Georgia Tech. First-author work in IEEE Transactions on Signal Processing. Twelve years as an IDF Navy officer, retired as Major. Based in Haifa.

Questions

Questions

Why hasn’t AI made our R&D team faster?

Individuals often get faster with AI coding tools, but the team’s delivery rate depends on review, tests, integration, and rework. Those verification steps become the bottleneck when AI increases the volume of change. Until the team’s method catches up, personal speed does not turn into team throughput.

What is spec-driven development, and do we have to adopt it?

Spec-driven development means writing a clear, checkable specification before (and during) implementation so humans and AI tools share the same target. A2X uses it when it already fits the team, and builds around the team’s preferred process when it does not. You do not have to adopt a named SDD playbook to work with A2X.

How is this different from AI coding-tool training?

Tool training teaches people how to prompt and use products. A2X installs persistent methods for how the team specifies, verifies, and ships when AI is in the loop every day. Training can be part of an engagement; it is not the engagement.

How long does an AI enablement engagement take?

A typical engagement opens with a short diagnostic as phase one (typically two weeks), then a 3–5 month implementation retainer. Workshops can sit inside that arc when a focused skill needs them. Exact length depends on team size, stack, and how much process change is in scope.

Does this work for computer-vision, algorithm or embedded code?

Yes. Those are the core audiences: algorithmic code, computer vision, and embedded or physical-systems software in deep-tech R&D — primarily in Israel, and also remote or at Israeli R&D centers of companies abroad. The method is shaped around the team’s real stack and verification constraints, not around a generic web-app workflow.

Talk it through.

If the pattern above matches what you see on your team, the next step is a conversation, not a form full of qualifiers.

Book a call and we will talk through where AI is already helping, where verification is stuck, and whether an A2X engagement is the right shape.

Book a call