Using AI to amplify value
AI in software engineering sets out Exalynt's stance: AI amplifies software engineering. It does not replace it. This page is what that means for you. Use AI, use it well, and turn the speed it gives you into value the client can see and rely on.
Use it
We encourage every Exalynt engineer to use AI wherever it helps. You don't need anyone's permission, and you never need to hide it. The only limits are the client's own policies and the care with client code and data described below.
Places it often helps:
- Understanding: exploring an unfamiliar codebase, library, or domain, and drafting the questions worth asking the client.
- Exploring: sketching alternatives, spiking an approach, or building a prototype to put in front of the client early.
- Building: routine implementation, boilerplate, migrations, refactors, and infrastructure.
- Verifying: generating tests and edge cases, reviewing your own changes, and hunting for possible bugs and security issues.
- Explaining: documentation, release notes, and checkpoint summaries in the client's language.
Try new tools and workflows. The tools change quickly, and the engineers who keep experimenting are the ones who find what actually works.
Amplify value, not volume
Blocks already reward using time well, and AI fits that model directly. Your payout for a block is fixed, and you dedicate at least the minimum to direct value for the client. AI makes that time go further:
- More of the right thing in the minimum. A more complete slice of the feature, a better-explored design, or a recommendation backed by a working spike instead of a guess.
- Better quality in the rest. When the value came easily, the remaining time goes to tests, monitoring, documentation, hardening, and helping other engineers. AI speeds those up too, so the client gets sturdier software from the same block.
What amplifying value doesn't mean:
- More code. Lines generated aren't value. A smaller change the client can rely on beats a larger one nobody fully understands.
- More scope. Features the client didn't ask for still need review, testing, and maintenance, and they still stay inside the purchased capacity.
- Bigger reviews. Dumping a large generated change on a reviewer moves the work instead of doing it. Keep changes reviewable.
And measure rather than assume. Research has found that experienced developers sometimes feel faster with AI while actually being slower in a given setting (details). Notice where AI genuinely helps your work and where it doesn't, and adjust.
You own what you ship
AI changes how the work gets done. It doesn't change who is responsible for it. Whoever or whatever wrote the code, the engineer who ships it owns it.
- Understand every line you ship. You should be able to explain what it does and why it's built that way, at review and at the checkpoint. If you can't explain it yet, it isn't ready.
- Review AI output like a colleague's pull request. Check its assumptions, edge cases, failure modes, error handling, and security. Watch for answers that are almost right but not quite: they're the most common frustration developers report, and the easiest to miss.
- Verify to the level the work claims. Generate freely for a Prototype the client will react to and probably throw away. Work at Beta or GA needs the verification its stability level promises, whoever wrote it. Reviewers calibrate by the label, not by the author.
- Check what AI adds to the project. Confirm that suggested packages exist, are the ones you meant, are maintained, and have compatible licenses, as the checklist expects.
- Own mistakes the same way. When AI-assisted work has a bug, it's handled like any other: own it, fix it, and improve how you work so the lesson compounds. "The AI wrote it" explains how a bug got in; it doesn't move the responsibility.
Protect client code and data
Clients trust us with their code, their data, and their users' data. Using AI doesn't change that trust.
- Follow the client's policies. If a client restricts or prohibits AI tools for their code or data, their policy wins. If you're unsure whether they have one, ask at the start of the engagement.
- Keep the security and privacy baseline in prompts too. The checklist keeps secrets and real client data out of code, mocks, and demos at every level. Keep them out of prompts and AI tool context the same way.
- Choose tools you could explain to the client. Use tools and settings whose handling of code and data you'd be comfortable describing to the client. If you're unsure whether a tool is appropriate, ask Exalynt before using it on client work.
Be open about it
Being honest and transparent applies to how the work was done, too.
- Tell clients how you work when they ask. You don't need to annotate every line AI helped with, but if a client asks how AI was used, tell them plainly.
- Never misrepresent the work. Don't describe something as reviewed, tested, or verified unless it was, whoever produced it.
- Name the gaps. If AI-generated work hasn't been checked to the level its label suggests, say so, just as you would for anything else.
Welcome clients' AI work
We encourage clients to use AI too, technical or not, and Using AI with Exalynt suggests how. Expect them to bring problem descriptions, research, mockups, examples, and sometimes prototypes they built themselves.
- Treat it as valuable input. A client's AI-built prototype often shows what they need more clearly than any description. Take it seriously, and never make anyone feel foolish for building it.
- Label it honestly. Like any early work, it starts at Prototype. Recommend whether to build on it, harden it, or use it as a reference, and explain what it would take to move it up.
- Help them use AI well. If a client's AI-assisted research or feedback is almost right but not quite, help them see the gap kindly, and point them to what would make it more useful next time.
Share what works
AI makes every engineer faster. Sharing what works makes all of us faster. That's how we succeed together.
- Share workflows, prompts, and setups that help, along with what they're good and bad at.
- Share failures, too. A tool that confidently got something wrong is worth warning others about.
- Turn repeated wins into reusable tooling, so the next engagement starts ahead.
Keep growing your judgment
AI handles more of the mechanics every year, which makes judgment the part of the job that matters most: understanding problems, weighing tradeoffs, anticipating failure, and verifying results. Use AI to learn faster, such as having it explain unfamiliar code or compare approaches, not to skip understanding. If you're earlier in your career, keep building the fundamentals AI is standing on, and lean on reviews and pairing with more experienced engineers. Levels reflect demonstrated capability and judgment, not how much code you produce.
Frequently asked questions
Do I need permission to use AI tools on client work?
No. Exalynt encourages it. The limits are the client's own policies on AI tools, and keeping secrets and real client data out of prompts. If you're unsure whether a tool is appropriate for a client's code, ask Exalynt first.
If AI makes me faster, can I spend less time on a block?
Dedicate at least the minimum to every block, as always. AI makes that minimum deliver more for the client, and if the value comes easily, the remaining time goes to quality, as described in Producing value in a block. Your payout for the block doesn't change either way.
Who is responsible for a bug in code AI wrote?
The engineer who shipped it, exactly as if they had typed it. Handle it like any other mistake: own it, fix it, and improve how you work so it doesn't happen again. It's never a reason for blame.
Can I paste client code into an AI tool?
Only when the client's policies allow it and the tool's handling of code and data is something you'd be comfortable explaining to the client. Never include secrets or real client data. If you're unsure, ask Exalynt before you do it.
Do I have to tell clients I used AI?
You don't need to label every line AI helped with. Be open about how you work, answer plainly if a client asks, and never describe work as reviewed or verified unless it was.
What if AI slowed me down on a task?
That happens, and research has found it even among experienced developers. Notice where it helps and where it doesn't, adjust how you use it, and share what you learn so other engineers can avoid the same trap.