What does it actually mean for a company to be AI-native? Not that leadership mentions it in all-hands. Not that engineers use Copilot. It means the tools have changed how the work gets done across every role, every department, every week.
At Mad Devs, that is exactly where we landed, and the evidence is in how people actually spend their days.
Delivery managers run their entire pre-sales workflow through LLMs and cut proposal cycles from two days to four hours. Our CEO built a production tool herself. A project manager shipped four features to production without a developer. A copywriter publishes technical guides that engineers actually read. And none of this came from a top-down initiative: it came from people who found a better way to do their work and ran with it.
This is what that looks like in practice.
We actively drive this – because the market demands it
Mad Devs actively promote LLM use across the company because the market expects it, our clients need it, and we are not willing to fall behind.
That means structural investment. We run weekly AI adoption talks, sessions where employees present how they are using LLMs in their actual work, followed by an open discussion. No invited speakers, no theoretical frameworks: someone from the team takes a specific tool or workflow they have been using, shows what it looks like in practice, and the group picks it apart. Attendance is voluntary, which means the people in the room are genuinely curious, and the presentations tend to be honest about what did not work as much as what did.
Recent sessions have covered the pitfalls of vibecoding and how to work with it more deliberately. For example, recent topics covered agent orchestration through Maestro, and combining MixedBread embeddings with NotebookLM for knowledge work.
I did the Maestro session because I had spent two weeks figuring it out and wanted to save everyone else the same two weeks. What surprised me was how many people in the room were already running into the same orchestration problems from completely different directions.
The range reflects how broadly experimentation is happening across the team: these are not conference-talk topics, but working solutions pulled from real projects, from small internal tools to large client engagements.
The talks are where practice gets shared. To build the underlying fluency, we also run an internal course, published on GitHub, covering how to work with LLMs effectively: prompt construction, task decomposition, knowing when to trust the output, and when to push back.
The result is a team where AI fluency is a baseline, not a bonus skill. Different people use different tools for different problems. What is consistent is the habit: when you hit friction, you try something. When it works or doesn’t work, you share it.
Where LLMs live in our daily work
LLMs are now embedded across the company’s day-to-day workflows. The changes show up in delivery, engineering, project management, content, recruiting, and sales. In each case, the tools have not replaced expertise – they have extended its reach and how quickly they can act.
Delivery managers: from proposals to prototypes
The pre-sales and project scoping process at a software consultancy involves a significant amount of skilled writing under time pressure: commercial proposals, contracts, scope documents, and timelines. It is the kind of work that used to require a full one to two days per engagement. It now takes around four hours, including feedback rounds, because the entire pre-sales workflow is done through LLMs.
The starting point is the commercial proposal itself. A DM works in ChatGPT, which, over time, has absorbed their preferred structure, tone, and level of detail. The model flags gaps in a draft: missing sections, vague scope language, anything a client is likely to push back on – before the document leaves the building. The same workflow produces contracts with appendices: a template plus a tailored development plan, ready for client review.
Client enablement is built into the same process. Instead of waiting for a client to produce a spec and fixing it later, the DM sends them a structured guide, generated and refined with AI, that explains how to write a technical specification that an engineering team can actually execute. The client uses their own tools to draft it, working from that structure — and what comes back is consistently more actionable than a spec written without it.
And once the specification comes back in a more structured form, the next step becomes easier as well: estimating the scope. Scope estimation no longer requires engineers to join manual sessions. The DM describes the scope and team composition (seniority levels and headcount) and prompts the model to produce a timeline estimate that the client can review and approve or challenge.
About project estimation, here is one special example. One of our DMs, Alisa Jang, took this further and built a dedicated estimation tool for the whole team: xtremio.xyz. The tool takes a project description or requirements file, asks clarifying questions to fill in the gaps, and outputs a complete development plan – recommended tech stack, team composition by role and seniority, budget breakdown, timeline with milestones, and a commercial proposal ready to send. What used to require multiple sessions with engineers and a senior DM now takes minutes.
Once the spec is signed off, AI breaks the full scope into epics and user stories, which transfer directly into Jira. The team has a structured backlog from day one.
Then come the prototypes. Using Codex and Pencil, DMs generate working interface mockups directly from a spec, but the prompts themselves are crafted with ChatGPT first. It is because getting a non-generic result requires specificity: UX flows, screen states, localized placeholder content (Aidarbek Aidarbekov in the mock, not John Smith, if the market is Central Asia), and features that were not in the spec but make obvious sense – like an admin panel the client had not thought to ask for.
Walking into a client meeting with a prototype of something they did not know they wanted yet changes the tone of the conversation. It moves the discussion from "can you do this?" to "how soon can we start?"
I showed up to that call with a prototype of their admin panel. They hadn't asked for it. The client went quiet for a second and then said – Okay, this is exactly what we need. Can we add it to the scope? That conversation used to take three meetings. It took twenty minutes.
This is creativity as a new operational capability – not design outsourced to a tool, but a delivery manager who can now think visually, prototype quickly, and bring something unexpected to a client conversation.
The lesson from delivery is straightforward: when the first draft, the estimate, and the prototype all move faster, the client conversation changes too.
Engineering and development
Our engineers use LLMs across the full development lifecycle. Architecture discussions, test writing, pre-review self-checks before code reaches a colleague, debugging unfamiliar codebases – all of it. The time savings are measurable, but the more significant shift is what happens to engineers who are still building domain expertise: they can move with more independence, explore solutions without needing to escalate every uncertainty, and deliver work that is closer to production-ready on the first pass.
Senior engineers benefit differently. Less time explaining fundamentals means more time on the problems that actually require their level of thinking.
The part I didn't expect was how much faster I can work in an unfamiliar codebase now. I used to need days to get oriented. Now I get there in hours. That's changed how I think about taking on new projects.
The effect is not just more output. It is better-shaped work because the team arrives at review with more context and fewer avoidable mistakes.
🧠 Building AI into your product? Mad Devs works with companies that are ready to move beyond proof-of-concept – from LLM-powered features to fully autonomous agent systems. Learn about our AI Agent Development practice.
The CEO, who got tired of manual work, built her own fix
Alla is the CEO of Mad Devs. She is not a developer, but she has enough technical background to build when needed. In this case, she built a production tool that our team now relies on every day.
The problem was a familiar one. Anyone who tracks time in Jira knows the routine: at the end of the week, you open your calendar, piece together what actually happened, and manually convert each event into a worklog. Task names have to be copied, durations adjusted, and entries matched to the correct project one by one. None of it is especially hard. It is just tedious enough to steal twenty unplanned minutes from the week. So she built a tool to do it instead.
The tool pulls events from her corporate Google Calendar – either all of them or only those marked with a specific color – and maps them to the right Jira instance. For our company, running multiple Jira projects under one corporate email, it handles all of them. The tool pulls events from her Google Calendar, maps them to the right Jira project by task ID (in the format ABC-1234), and queues them as worklogs. Before anything is submitted, the log text and duration can be edited — so what lands in Jira reflects what the work actually was, not just what the calendar entry said.
Alla built it herself. No engineering ticket, no sprint, no waiting. Just a problem she wanted to solve and a tool that helped her and her team solve it.
That is the version of AI-native leadership that actually matters – not a strategy deck about AI transformation, but an executive who learned enough to ship something useful on a random workday.
Project managers: crossing into shipping
Project management is usually where coordination meets software reality, but at Mad Devs, it has also become a place where non-developers can touch actual code. That shift matters because it changes how problems are understood, not just how quickly they are resolved.
One of the clearest examples of role boundaries shifting happened at Enji, the AI-powered engineering analytics platform Mad Devs co-founded. When a project manager decided to work through tasks that had been sitting in the backlog – not because they were hard, but because they were never urgent enough to displace bigger engineering priorities.
The tasks were small but useful: a notification badge for an approvals section in the sidebar, an employee type filter in a reporting view, a duplicate-record bug in the project creation flow, and a follow-up fix for when the badge stopped refreshing after rejection.
The PM opened Cursor, described each issue in plain behavioral terms, what the system should do, what it was doing instead, and worked through the fixes. The process was messy in the best possible way. The first badge implementation caused a white screen and a console error because a computed property was being called as a function. That was fixed. Review then flagged a deprecated color variable and a missing error handler. Fixed again. The staging build broke on a TypeScript issue. Fixed, with Cursor extracting a proper interface. Three PRs for one badge.
The follow-up bug, the badge not updating after rejection, was diagnosed by Cursor running a git command the PM would not have known to write: comparing the local file against the staging branch and finding that a single function call had been dropped between merges. The fix was one line.
That small incident pointed to a larger truth. Four features shipped through real code review, real QA, and real staging builds, not just because AI made the work faster, but because the codebase itself made that kind of collaboration possible. Its documented conventions and clear service boundaries gave the model enough structure to operate productively. In that sense, AI scales whatever foundation it is given, and a well-organized codebase gives non-developers somewhere to stand.
After the third PR for that one badge, I stopped being frustrated and started being curious. I wanted to understand why it kept breaking. By the time it shipped, I understood the component model well enough to estimate similar tasks myself. That's not something I expected to get out of it.
The lasting effect was not the autonomy or the speed. It was the understanding. When you follow a problem from the user-facing symptom to the specific line of code causing it, you frame tasks differently. You estimate more accurately. You talk to engineers differently – not because you have become one, but because you have seen what they actually deal with.
Marketing and content: technical depth without a technical background
One shift LLMs have made possible at Mad Devs is letting technical specialists focus on what actually requires their depth. Engineers spend less time explaining fundamentals in documentation and more time on the problems only they can solve — because the writing work around their expertise has become something the broader team can handle with the right tools and close collaboration.
Our marketing team publishes content that targets working developers — deep dives on infrastructure, tooling, browser APIs, and machine learning deployment. Each piece is built through close collaboration between writers and engineers: the technical depth comes from subject matter experts, the clarity and structure from people who know how to make complex material accessible. The result is content that developers actually read.
The most direct example: our copywriter produced a comprehensive technical guide on running AI models locally in the browser using WebGPU and WebAssembly: a piece that covers browser inference vs. server-side execution tradeoffs, WebGPU API specifics, performance benchmarking methodology, and corrected code samples. It required understanding enough about the domain to ask the right questions, recognize when an explanation was off, and shape the material into something a developer would find genuinely useful rather than superficially plausible.
LLMs made that possible. The author used them to get up to speed on unfamiliar territory quickly, validate technical claims, test whether an explanation held up under scrutiny, and generate and debug code examples. The engineering reviewers signed off on the technical content. The writing itself was handled without them.
This matters for Mad Devs specifically because technical credibility is a client-facing asset. When a prospect reads a piece on our blog that demonstrates genuine fluency with the technology they are evaluating, that changes what kind of company they think they are talking to.
The same pattern applies across the rest of the team: once the gap between curiosity and competence narrows, more people can contribute to work that used to sit in specialist silos.
HR and recruiting
Our HR team uses LLMs throughout the full recruiting cycle, and the impact is most visible in the work that once required specialist domain knowledge just to get started.
Sourcing rare technical profiles used to mean constructing complex Boolean search strings by hand, something that takes experience and time to do well. LLMs generate them in seconds. More usefully, they help recruiters think through the search itself: testing different job-title framings, identifying adjacent roles that might surface the right profile, and generating hypotheses about where a particular type of engineer tends to appear online before committing time to a search that might not work.
Boolean search used to take me an hour for a rare profile – getting the logic right, testing combinations, missing things. Now I generate a starting query in two minutes and spend the rest of the time actually looking at people. The search got better and faster at the same time.
And that same pattern extends well beyond sourcing. Job descriptions are drafted and refined with AI. Candidate communications (rejections, follow-ups, offer letters) are consistently written to be precise, neutral, and considerate in tone, without the variability that comes with drafting under pressure. Hiring funnel analysis, reasons for drop-off, and channel effectiveness: all are increasingly handled with AI assistance rather than manual aggregation.
There is also an emerging dynamic on the other side of the table. As candidates use LLMs to prepare for interviews, optimize CVs for ATS filters, and in some cases get real-time assistance during technical assessments, our recruiters have had to develop new judgment: recognizing when AI-assisted answers differ in texture from genuine expertise, and knowing when that distinction matters. It is a skill set that did not exist in this form three years ago, and today it is simply part of the job.
Recruiting becomes more strategic when the repetitive parts shrink, because the team can spend more time evaluating fit and less time assembling the first draft of the search.
What this actually gives us
This is where the operational impact becomes visible. What matters most is how the company uses LLMs to reshape execution: what gets done, how quickly, and by whom. The result is a shift in speed, capacity, and role boundaries that compounds across the organization.
Speed where it compounds
The obvious gain is time. Proposals drafted in four hours instead of two days. Prototypes in an afternoon instead of a sprint. Content that would have taken a week of research was compressed into a day of focused work. But the less obvious gain is that speed compounds: when the cost of trying something is lower, people try more things. Iteration cycles that used to take a week happen in a day. That changes not just how fast the team moves, but how many ideas actually get tested.
Operational load that disappears
The work that LLMs absorb – reformatting, summarizing, first-drafting, estimating, generating boolean strings, writing candidate communications – is not trivial. It is the kind of work that fills hours without producing the outcomes people were actually hired to generate. When that load shrinks, the people doing it do not just have more time. They have more mental space for the judgment calls that cannot be automated.
Scalability without proportional headcount
Traditionally, doing more meant hiring more. More proposals required more delivery managers. More content requires more writers. More candidates require more recruiters. LLMs break that equation. The same team now handles a volume of work that would have previously required significantly more people because the repeatable, formulaic parts of each role have been largely automated. That is what scalability looks like at the team level, and it compounds as the tooling improves.
Roles that expand
The PM who ships features. The copywriter who writes developer documentation. The DM who arrives at a client meeting with a prototype. The CEO who builds her own internal tool. These are not anomalies or special cases. They are what happens when the gap between "I have an idea" and "I can execute this" narrows enough that more people cross it. LLMs do not replace expertise – they let it travel further.
A team that experiments by default
When trying something new is cheap, the question shifts from "should we try this?" to "why haven't we tried this yet?" That is the cultural change we have noticed most: a default orientation toward building and testing rather than planning and waiting. The weekly AI Adoption talks exist because enough is happening across the team to be worth sharing every single week. That would not be true if adoption were slow.
The strategic picture
We build AI-powered products for clients. That means our credibility is as much operational as it is technical. Clients who are evaluating AI integration want partners who have done it themselves, who understand the failure modes from experience, and who can give advice that is grounded in something more than vendor documentation and conference talks.
When we tell a client what it actually takes to integrate an LLM into a production workflow – the prompt engineering, the edge case handling, the evaluation, the places where it breaks – we are drawing on something real. Every function in this company has been through some version of that process.
That is also a talent story. Engineers and knowledge workers who want to stay at the edge of how their profession is changing want to work somewhere that takes that seriously. We do. The weekly talks, the internal course, the expectation that everyone finds smarter ways to work – these are not perks. They are how we stay competitive as an employer in a market where the best people have options.
We are not finished. The way we use LLMs today is almost certainly not the way we will use them in twelve months, because the tools are changing too quickly for any workflow to stay fixed for long.
What matters now is not locking in one perfect system. It is building a team that can keep learning, keep testing, and keep turning new tools into working habits.
That is what we are building.