AI in software delivery
From AI licences to a shared way of building software.
Your developers have AI tools, but everyone uses them differently and it's hard to say what has actually changed. I help engineering teams build their own approach to delivering software with AI across the whole process: domain and requirements, project context, implementation, review, testing and release.
We start with an audit of how you work today. Then we move step by step: workshops, a shared setup, pairing on real work, and longer-term support if it helps.
- For
- Product companies and software houses with scattered AI use
- Starts with
- An audit of how you deliver software today
- Format
- Workshops and pairing in person, at your office
First step
A short email: how big your team is, how it uses AI today, and what you’d like to change.
bartek@bartekwitczak.com
Does this sound familiar?
What engineering leaders often describe
- Everyone got licences for Claude, ChatGPT, Gemini or Copilot, but you don't see a difference, or can't tell because nothing is measured.
- Every developer uses different commands, agents and workflows. What works for one person stays with that person.
- The only shared AI practice in the team is an expensive review bot.
- Developers have seen poor AI-generated code and don't want to use it. The codebase may not be prepared for this kind of work.
- You want to invest in AI, but nobody has time to keep up with how fast tools and models change.
None of this means AI isn't helping. It means it's hard to tell whether it is, and hard to build on what works.
My view
Code is only one part of delivery
Better tools can't make up for missing domain knowledge, unclear requirements, weak tests or a process nobody has agreed on. If those are the real constraint, generating code faster just moves the problem, usually to review.
More AI usage, more generated code or more agents are not goals in themselves. The goal is better delivery.
What we work on
The audit shows which areas matter most. We don't change everything at once.
Product, domain and requirements
- Start before the code: what needs to be built, and why
- Developers who understand the product and domain, not just the tickets
- Requirements clear enough to guide both people and AI
- Where it helps, rethink who does what
Context and ways of working
- Project rules, conventions and docs the agents can follow
- Coding tools and agents set up for your repositories
- Capturing what the team learns, so it’s reused
- Small, targeted changes that are easy to review
Verification and delivery
- A testing strategy and CI/CD that support safe, frequent change
- Valuable tests rather than many tests
- Review based on what the change was meant to do
Feedback from production
- Later, if useful: agents with access to monitoring to spot and report problems
- Only with clear permissions, human approval and an owner on your side
How we work together
Start with an audit, build from there
Each step builds on the previous one, but you decide whether to continue.
Audit
I talk with engineering and product leaders and with developers, and look at your repositories, tools, the path from requirement to release, and how AI is used now.
→ The current state, main constraints, prioritised recommendations, where to start (for example a pilot team), and how to tell whether changes help.
Workshops
In-person workshops for developers, and for leaders where needed, based on the audit and run on your own code.
→ A team that shares a vocabulary and has practised the new way of working.
Shared approach and setup
Project context and rules, tool configuration, review and testing practices, usually starting with one pilot team. We decide together what is shared and where teams keep flexibility.
→ A working setup in your repositories and a written approach the team agrees on.
Pairing and mentoring
I work alongside your people on real tasks, so the approach becomes part of daily work, not just a document.
→ People who can apply the approach on their own and pass it on.
Long-term support
Refining the approach, spreading it to more teams, and checking new tools and models against what you actually need.
→ An outside partner who knows your context, at a pace we agree together.
Each step is separate. After the audit you can stop, continue with me, or carry on yourselves. The order isn't fixed: some teams need workshops early, others the setup first.
What you end up with
Your own approach, owned by your team
- A shared, written way of working with AI across delivery
- Project context, rules and tool setup in your repositories
- Review, testing and verification practices that fit your changes
- A plan for what to improve next, and how you'll judge it
- People who can run and develop the approach without me
That's why we need an owner on your side from the start.
Is this a good fit?
Usually yes, if the process is on the table
Usually a good fit
- Your development team’s AI use is scattered or disappointing
- A leader with authority over delivery is involved
- You're willing to look at the process, not just add a tool
- People who know the product, code and constraints can take part
- Someone on your side will own the changes
Probably not a fit
- You want to roll out a tool without changing how you work
- You need a guaranteed speed-up figure before you start
- You need a security audit or compliance certification
- You're looking for an outsourced team to build your product
Boundaries
What this is not
- Not installing a tool or handing out licences.
- Not a promised speed-up. We agree up front how to judge whether changes help: quality, rework, delivery time, cost.
- Not a security audit or compliance certification.
- Not an outsourced development team. I work with your people; I don't take over delivery.
- Not one standard forced on every team.
Not sure?
This or the developer workshop?
If you’d like to start small, the developer workshop works on its own.
Why work with me
Bartek Witczak
Software architect and principal engineer with over 15 years building business-critical products. I can talk about architecture with developers and about priorities with leadership.
I work hands-on with AI every day, in legacy and new codebases. I've set up project rules, design systems and my own setups for AI-assisted work, and I build my own products with AI.
I've helped teams improve how they deliver. As a consultant and principal engineer I worked on architecture, engineering standards, mentoring and hiring.
I teach developers. Since 2017 I've run in-person workshops, often 2–3 days long, including for large companies.
AI in software delivery is new for everyone, so I don't sell a finished framework. We build an approach that fits your team, test it on real work, and keep what proves useful.
Questions
FAQ
+Do we have to commit to the whole process?
No. We start with the audit. Each later step is agreed separately, and you can stop at any point or carry on yourselves.
+How long does the audit take, and what does it cost?
That depends on the size of your team and process. After a short call I send a proposal with scope, timeline and price.
+Does it have to be in person?
Workshops and pairing happen in person, at your office. In my experience that's far more effective than remote sessions for changing how people work.
+Which AI tools do you recommend?
I don't sell any tools. We choose them based on your needs, rules and budget.
+Do you work with software houses or product companies?
Both. Product companies with their own development teams are a particularly good fit.
+How will we know it's working?
At the start we agree what “better” means for you: for example quality, rework, delivery time, cost and how the team actually works. We check those over time, rather than mistaking activity for improvement.
+What happens when you're no longer involved?
Your team owns the approach and keeps developing it. That's the goal from day one.
+Can we start with just a workshop?
Yes. The developer workshop is a standalone service and a lighter way to begin.
Next step
Send me a short email.
A few sentences are enough:
- · How big your development team is, and what you build
- · How AI is used in the team today
- · What you'd like to change, or what worries you
I reply, we schedule a short call, and if it fits I send a proposal for the audit with scope, timeline and price.
bartek@bartekwitczak.com
Need something different?
Each of these is a separate service, not a next step you're expected to take.
External AI advisor
AI that genuinely improves how your business works.
AI workshops for business teams
Your team knows how to use AI in its everyday work.
AI workshops for developers
From one-off prompts to a way of working you can rely on.