# Do AI coding assistants make developers faster? What the evidence says

> What controlled trials, DORA's research and developer surveys actually show about AI coding assistants: where they speed work up, where they slow it down, what they do to code quality and security, and how to adopt them with human review.

Source: https://authect.com/insights/blog/ai-coding-assistants-what-the-evidence-says

*R&D by Pranas Mickevicius, Chief Executive Officer, published 2026-11-04*

> What controlled trials, DORA's research and developer surveys actually show about AI coding assistants: where they speed work up, where they slow it down, what they do to code quality and security, and how to adopt them with human review.

AI coding assistants can make developers faster, but the size of the gain depends heavily on the task, the developer's familiarity with the codebase and the team's ability to review and test what the tools produce. Controlled studies range from large speed-ups on small, well-defined tasks to a measured slowdown for experienced developers on their own mature projects. The quality and security evidence is consistent: generated code needs the same, or more, scrutiny than human code, so the review and delivery system around the tool decides whether speed turns into value.

This write-up gathers the most useful public evidence as of late 2026: randomised experiments, Google's DORA research programme, the Stack Overflow developer survey, and academic security studies. We flag studies run or funded by tool vendors, because they are useful but not neutral. We did not run these experiments; what we add is an engineering studio's reading of what they mean in practice, and how we would set up measurement and review if you are adopting these tools in your own team.

## Why the evidence seems to contradict itself

Headlines about AI coding tools swing between "twice as fast" and "actually slower". Most of the contradiction disappears once you notice that studies measure different things in different settings. Four kinds of evidence dominate, and each answers a different question.

- **Lab tasks**: developers are randomly given the tool or not, then timed on the same small, self-contained task. Clean comparisons, but the task is rarely like a day's work on a real product.
- **Field experiments**: companies give the tool to a random subset of their own developers and compare output over weeks or months. Closer to reality, but output is measured with proxies such as pull requests or completed tasks, and the data is noisy.
- **Surveys**: thousands of developers report how they use the tools and how productive they feel. Excellent for adoption and sentiment, weak for measuring actual speed, because people are poor judges of their own time.
- **Repository and telemetry analysis**: researchers or vendors analyse large volumes of code changes. Good at spotting trends such as rising duplication, but correlational: it cannot prove the tools caused the change.

The tools have also changed quickly. Studies from 2022 and 2023 mostly tested inline completion: the assistant suggests the next few lines as you type. Later studies test chat assistants and agents that edit many files, run commands and open pull requests. A result about one generation of tooling does not automatically carry over to the next, in either direction.

## Controlled experiments: from much faster to measurably slower

The best-known early result is a GitHub experiment in which 95 professional developers were randomly split and asked to write an HTTP server in JavaScript. According to [GitHub's write-up of the study](https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/), those with Copilot finished 55% faster on average (1 hour 11 minutes against 2 hours 41 minutes), with a 95% confidence interval of 21% to 89%, and 78% of them completed the task against 70% without it. The [accompanying paper by Peng and colleagues](https://arxiv.org/abs/2302.06590) puts the figure at 55.8%. Two caveats matter: the study was run by the tool's maker, and the task was a small greenfield exercise with a clear specification, which is close to the best case for code generation.

Field experiments inside companies give a more modest number. [Cui, Demirer, Jaffe, Musolff, Peng and Salz](https://www.microsoft.com/en-us/research/?p=1148213) analysed randomised rollouts of an AI coding assistant at Microsoft, Accenture and an anonymous Fortune 100 company. Pooled across 4,867 developers, they estimate a 26.08% increase in completed tasks among developers using the tool, with a standard error of 10.3%, and they note that each experiment on its own was noisy. Less experienced developers adopted the tool more and gained more. Several authors are Microsoft researchers and the tool was GitHub Copilot, so this is not independent of the vendor, although it was published as academic research.

Google ran its own randomised trial with 96 of its engineers on a complex, enterprise-grade task. [Paradis and colleagues report](https://arxiv.org/abs/2410.12944) that AI shortened time on task, with a best estimate of about 21%, while noting a large confidence interval. Developers who spent more of their day on coding activities benefited more. Again, a company studying its own internal tools.

The most cited counter-result comes from METR, an independent research organisation. In its [early-2025 randomised trial](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/), 16 experienced open-source developers worked on 246 real issues in large repositories they had contributed to for years; each issue was randomly assigned to allow or disallow AI tools, mainly Cursor with Claude 3.5 and 3.7 Sonnet. With AI allowed, issues took 19% longer. METR is explicit that this does not show AI fails to help most developers: the setting (deep familiarity with large, mature codebases with high quality standards) is one where an assistant has the least to offer and the most to get wrong.

METR's [February 2026 update](https://metr.org/blog/2026-02-24-uplift-update/) is just as instructive. A larger follow-up with 57 developers, 143 repositories and more than 800 tasks reports, in METR's words, an estimated "speedup of -18%" for returning developers (confidence interval -38% to +9%) and -4% for newly recruited ones (-15% to +9%). Both intervals include no effect. METR says that, based on conversations with participants, developers are likely more sped up by AI tools now than in early 2025, but treats its own numbers as very weak evidence: many developers declined to take part because they did not want to work without AI, some said they had withheld tasks they did not want to do unaided, and time tracking broke down for people running several agents at once. In other words, measuring AI's effect on real work has become harder precisely as the tools have improved.

| Study | Setting | Who ran it | Headline result |
|---|---|---|---|
| [Peng et al. / GitHub](https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/) | 95 developers, one small JavaScript task | Tool vendor | 55% faster on average |
| [Cui et al.](https://www.microsoft.com/en-us/research/?p=1148213) | 4,867 developers at three companies, weeks of normal work | Academic and vendor-affiliated researchers | 26.08% more completed tasks (SE 10.3%) |
| [Paradis et al.](https://arxiv.org/abs/2410.12944) | 96 Google engineers, one enterprise-grade task | Google, on its own tools | About 21% less time on task |
| [METR, early 2025](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) | 16 experienced developers, 246 issues in their own repositories | Independent research organisation | 19% longer with AI |
| [METR, 2026 update](https://metr.org/blog/2026-02-24-uplift-update/) | 57 developers, 800+ tasks, 143 repositories | Independent research organisation | Reported "speedup of -18%" (CI -38% to +9%); METR calls it very weak evidence |

Read together, the pattern is coherent. Gains are largest on well-specified, self-contained work and for developers who are newer to the language, framework or codebase. They shrink, and can reverse, on complex changes in large systems that experts already know well, where the work is mostly understanding constraints rather than typing code.

## What large surveys say: near-universal adoption, limited trust

Google's DORA programme surveys technology professionals every year and models how practices relate to delivery performance. In the 2024 report, [more than 75% of respondents relied on AI for at least one daily responsibility](https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report). DORA estimated that a 25% increase in AI adoption was associated with a 7.5% increase in documentation quality, 3.4% in code quality and 3.1% in code review speed, but also with an estimated 1.5% decrease in delivery throughput and a 7.2% reduction in delivery stability. Those are associations from survey data, not measured causal effects, but the direction was a warning: individuals felt more productive while the delivery system got shakier.

The [2025 DORA report](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report) found that 90% of respondents use AI at work and more than 80% believe it has increased their productivity, while 30% report little or no trust in AI-generated code. Unlike 2024, AI adoption now had a positive relationship with software delivery throughput and product performance, but it continued to have a negative relationship with delivery stability. Google's [summary of the survey](https://blog.google/technology/developers/dora-report-2025/) adds that it covered nearly 5,000 professionals, that the median respondent spends two hours a day working with AI, and that 59% report a positive influence on code quality.

The [2025 Stack Overflow Developer Survey](https://survey.stackoverflow.co/2025/ai) tells a similar story from a different angle. 84% of respondents use or plan to use AI tools and 51% of professional developers use them daily, yet favourable sentiment fell to 60%. More developers distrust the accuracy of AI output (46%) than trust it (33%). The most common frustration, cited by 66%, is "AI solutions that are almost right, but not quite", and 45.2% say debugging AI-generated code is more time-consuming.

"Almost right" is the phrase to remember. Code that is obviously wrong gets rejected quickly. Code that compiles, passes the happy path and is subtly wrong in an edge case is the expensive kind, because it moves the cost from writing to reviewing, debugging and, if it escapes, operating.

## The perception gap: why self-reported speed-ups are unreliable

The most striking number in the METR study is not the slowdown. Before starting, developers [forecast that AI would make them 24% faster](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/); after finishing, they still believed it had made them 20% faster, even though the measured effect was the opposite. Working with an assistant feels faster: there is less blank-page effort, more activity on screen and less typing. Time spent prompting, waiting, reading and correcting output is easy to underestimate.

> If your evidence that AI is helping is that your developers say it is, you have measured how the work feels, not how long it takes or how well the result holds up.

None of this makes developer sentiment worthless. Satisfaction and reduced drudgery matter for retention and focus, and DORA's surveys consistently link AI use to better individual experience. But sentiment cannot be the business case. Any team that wants to know whether the tools are paying off needs measures from the delivery system itself, taken before and after adoption.

## Code quality and maintainability

Speed is only half of the question. The other half is whether code written with assistants costs more to maintain. The evidence here is thinner and mostly observational. GitClear, which sells code analytics tools, analysed [211 million changed lines from 2020 to 2024](https://www.gitclear.com/ai_assistant_code_quality_2025_research) and reports that lines classified as copy/pasted (cloned) rose from 8.3% in 2021 to 12.3% in 2024, while lines associated with moving and refactoring code fell from 25% to under 10%. It cannot prove AI caused the shift, and it is a vendor's analysis, but the direction matches what reviewers often see: assistants make it cheaper to add new code than to find and reuse what already exists.

DORA's finding that AI adoption is associated with lower delivery stability in both 2024 and 2025 points the same way at the system level. The [2025 announcement](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report) puts the mechanism plainly: AI accelerates development, and without strong automated testing, mature version control and fast feedback loops, an increase in change volume leads to instability. That is a description of a review and testing bottleneck, not of bad tools.

- **Duplication**: assistants generate a fresh implementation rather than calling the helper three folders away. Over time, the same logic lives in five places with five slightly different bugs.
- **Larger changes**: when code is cheap to produce, pull requests grow. Large changes are reviewed less carefully and fail more often, which is why DORA's long-standing advice on small batches matters more now.
- **Plausible but shallow tests**: generated tests often assert what the code does rather than what it should do, so they pass and protect nothing.
- **Dependency sprawl**: suggesting a new package is easier than reading the ones already installed.
- **Lost understanding**: when nobody on the team fully understands a module because it was generated and skimmed, the cost appears months later, during an incident or a change of direction.

## Security: generated code is untrusted input

Security researchers started testing assistants early. In [Asleep at the Keyboard?](https://arxiv.org/abs/2108.09293), Pearce and colleagues prompted Copilot with 89 scenarios built around high-risk weaknesses from MITRE's CWE Top 25 and found that approximately 40% of the 1,689 programs it produced were vulnerable. That was an early model, and models have improved at writing code that runs. Whether they have improved at writing code that is secure is less clear.

A user study by [Perry, Srivastava, Kumar and Boneh](https://arxiv.org/abs/2211.03622), published at ACM CCS 2023, found that participants with an AI assistant wrote significantly less secure code than those without one, and were more likely to believe their code was secure. Participants who trusted the assistant less and engaged more critically with it produced code with fewer vulnerabilities. That combination, worse code and more confidence, is the core risk for any team without strong review.

More recent vendor research points the same way. Veracode, which sells application security testing, tested more than 100 language models on 80 coding tasks and reports that [generated code introduced security vulnerabilities in 45% of cases](https://www.veracode.com/press-release/ai-generated-code-poses-major-security-risks-in-nearly-half-of-all-development-tasks-veracode-research-reveals/), with Java failing more than 70% of the time, and models failing to defend against cross-site scripting in 86% of relevant cases and log injection in 88%. Its most useful finding is qualitative: security performance stayed flat as models got better at syntax, and larger models did not perform significantly better than smaller ones.

Assistants also introduce supply-chain risks that did not exist before. [Spracklen and colleagues](https://arxiv.org/abs/2406.10279), in a paper for USENIX Security 2025, generated 576,000 code samples with 16 models and found that recommended packages were hallucinated at least 5.2% of the time on average for commercial models and 21.7% for open-source models, producing 205,474 unique non-existent package names. An attacker who registers one of those names gets their code installed by anyone who accepts the suggestion without checking.

Agents that read issues, documentation and web pages, run commands and push code add a further class of risk. The [OWASP Top 10 for LLM Applications 2025](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) lists prompt injection first, including indirect injection through external content such as files and web pages, and recommends least privilege for the model, human approval for privileged actions and clear separation of untrusted content. For a coding agent, that means scoped credentials, no direct access to production secrets, and a human approving anything that merges, deploys or changes infrastructure. Our [guide to cybersecurity services](/insights/blog/what-are-cybersecurity-services) covers the wider controls.

## Where assistants help and where they hurt

Across the studies, the same factors predict whether an assistant helps: how well specified the task is, how much hidden context it depends on, how easily the result can be verified, and how costly a subtle mistake would be. The three main modes of use sit differently on those factors.

**Inline completion**

Suggests the next lines as you type. Low risk and low ceremony: the developer sees every suggestion in context and accepts or rejects it immediately. Most useful for boilerplate, repetitive patterns, test scaffolding and unfamiliar syntax. The main risk is accepting a plausible line without reading it, especially in security-sensitive code such as input handling, queries and authentication.

**Chat assistant**

Answers questions, explains code, drafts functions and proposes changes that the developer applies. Strong for learning an unfamiliar codebase or library, writing first drafts of documentation, and exploring options. Weaker when the answer depends on context the model has not seen, such as business rules, past incidents or conventions that live in people's heads. Treat answers as a colleague's suggestion, not as documentation.

**Coding agent**

Plans and makes multi-file changes, runs tests and commands, and can open pull requests. The largest potential gain and the largest blast radius. Works best on tightly scoped tasks with good test coverage and clear acceptance criteria: dependency upgrades, mechanical refactors, adding tests, well-specified features. Needs sandboxing, scoped permissions, small pull requests and a reviewer who understands the change as well as if they had written it.

| Usually a good fit | Use with care | Usually a poor fit |
|---|---|---|
| Boilerplate, scaffolding and repetitive code | Business logic with many edge cases | Security-critical code reviewed by nobody with security expertise |
| Tests for existing, well-understood behaviour | Changes across many modules of a large, mature system | Work where nobody can verify the output |
| Explaining unfamiliar code and libraries | Database migrations and data transformations | Choosing architecture or dependencies without human judgement |
| Mechanical refactors and upgrades with good test coverage | Performance-sensitive paths | Agents with production credentials or unreviewed merge rights |
| First drafts of documentation and comments | Code in regulated areas such as payments or health data | Replacing understanding of the system with generated code |

## How to measure the effect in your own team

Public studies tell you what is possible. Only your own data tells you what is happening in your codebase. The good news is that you do not need a research programme: you need a baseline, a few delivery measures you already trust, and the discipline to compare like with like.

1. **Take a baseline first.** Record at least a few weeks of delivery data before a broad rollout. Without a baseline, every later number is an opinion.
2. **Measure the delivery system, not the keyboard.** DORA's measures (lead time for changes, deployment frequency, change failure rate and time to restore service) capture whether faster coding turns into faster, safer delivery. Our [guide to DevOps services](/insights/blog/what-are-devops-services) explains them.
3. **Watch review and rework.** Track pull request size, time waiting for review, number of review rounds and how often code is reverted or rewritten within a few weeks. These show whether effort has moved from writing to reviewing.
4. **Track escaped defects and security findings.** Count bugs found after release and issues raised by static analysis, dependency scanning and penetration tests, before and after adoption.
5. **Ignore vanity metrics.** Lines of code, suggestion acceptance rates and the percentage of code "written by AI" measure activity, not value. More code is not a goal.
6. **Compare like with like.** If you can, roll out to some teams or some kinds of work first and compare against similar work without the tool. If not, at least compare the same team across similar periods.
7. **Ask developers too, but separately.** Survey satisfaction and perceived productivity, and treat it as its own outcome rather than as evidence of speed.

Expect the measurement to be noisy. Even the large field experiments needed thousands of developers to get a usable estimate. For a single team, the aim is not a precise percentage; it is to notice early if review queues are growing, change failure rates are climbing or the same bug keeps reappearing in duplicated code.

## A review policy that holds up

The common thread in the quality and security evidence is that the human review step decides the outcome. Perry's participants who engaged critically wrote safer code; DORA's teams with strong testing and version control turned AI speed into throughput rather than instability. A workable policy is short and specific.

- **The author owns every line.** Whoever opens the pull request is accountable for generated code exactly as if they had typed it, and must be able to explain it.
- **A second engineer reviews every change.** No AI-generated change merges on the author's approval alone, and an AI reviewer can assist but never replaces the human one.
- **Keep changes small.** Set a soft limit on pull request size and split agent output into reviewable pieces. DORA's [AI Capabilities Model](https://cloud.google.com/blog/products/ai-machine-learning/introducing-doras-inaugural-ai-capabilities-model) names working in small batches and strong version control practices among its seven capabilities.
- **Tests are written or checked against the requirement, not the implementation.** A reviewer should be able to see which acceptance criterion each test protects.
- **New dependencies need a human decision.** Verify that the package exists, is maintained and is the one intended before installing it.
- **Sensitive areas get specialist review.** Authentication, authorisation, payments, personal data handling and cryptography are reviewed by someone with the relevant expertise, whatever wrote the code.
- **Automate the checks humans miss.** Static analysis, secret scanning, dependency scanning and type checks run on every change, so reviewers can focus on logic and design.
- **Agents run with least privilege.** Sandboxed environments, scoped tokens, no production secrets, and human approval for merges, deployments and infrastructure changes.

None of these rules is specific to AI. They are ordinary good engineering practice that many teams relaxed because writing code used to be the slow part. When generation becomes cheap, review and verification become the constraint, and the teams that invest there get the benefit. Independent [quality assurance](/services/quality-assurance) and periodic [software audits](/services/software-audit) are the backstop for code that has grown quickly.

## A practical adoption plan

DORA's 2024 report recommended orienting AI adoption towards reducing toil, setting clear guidelines for use and giving developers dedicated time to experiment, and its 2025 capabilities model puts a clear, communicated stance on AI first. In practice, a sensible rollout looks like this.

1. **Decide and publish your stance.** Which tools are approved, what data and code may be sent to them, what the review rules are, and who to ask. Check licensing and data-processing terms with the vendor, especially for client or regulated code.
2. **Fix the delivery basics first.** If tests are thin, pipelines slow or pull requests already wait days for review, AI will amplify those problems. DORA's 2025 framing of AI as an amplifier of existing strengths and weaknesses is the most useful single idea here.
3. **Start with low-risk, high-toil work.** Tests for existing behaviour, documentation, migrations of well-covered code, internal tools. Build habits and review discipline before moving to core product code.
4. **Give context deliberately.** Assistants do better with repository conventions, architecture notes and examples of good code. DORA's capabilities model highlights AI-accessible internal data for the same reason.
5. **Measure for a quarter, then decide.** Compare the delivery, review and defect measures above against the baseline, and talk to the developers. Expand where the data supports it and pull back where it does not.
6. **Revisit as the tools change.** Re-check the policy when you adopt a new class of tool, particularly when moving from completion and chat to agents with write access.

A note on when not to push adoption: if your product is small, stable and maintained by people who know it intimately, the METR results suggest the gain may be small or negative for core changes. That is a reasonable place to use assistants for documentation and tests and leave the rest to the people who understand the system.

## How Authect approaches AI-assisted delivery

We use AI tools throughout delivery, and an engineer reviews every line before it ships. Every project is led by a senior engineer, teams are small, and clients own the code, infrastructure and designs from day one, so anything generated is held to the same standard as everything else in a codebase the client will keep. The approach is the one described above: small changes, human review, automated checks and tests tied to requirements. We explain how founder-led teams make those calls in [what founder-led delivery changes](/insights/blog/what-founder-led-delivery-changes), and our [guide to AI development services](/insights/blog/what-are-ai-development-services) covers building AI into products rather than into the development process. If you want a second opinion on how AI is being used in your own codebase, [talk to us](/contact).

## The short version

- Controlled studies show real speed-ups on well-specified tasks and for less experienced developers, and small or negative effects for experts working in large codebases they know well.
- Developers consistently overestimate how much faster AI makes them, so self-reported productivity is not evidence of speed.
- AI use is associated with lower delivery stability unless testing, version control and review are strong.
- Generated code has a well-documented security problem that larger, newer models have not solved, and agents add prompt-injection and supply-chain risks.
- Measure the delivery system against a baseline, keep changes small, and make a human accountable for every line.

## FAQs

### Do AI coding assistants actually make developers more productive?

Often, but not always. Randomised studies show large gains on small, well-specified tasks and moderate gains in company field experiments, while an independent study of experienced open-source developers on their own projects measured a slowdown. The effect depends on the task, the developer's familiarity with the codebase and how well the team reviews and tests the output.

### Why did the METR study find developers were slower with AI?

The developers were experts working in large, mature repositories they had contributed to for years, a setting where an assistant has the least to add and its mistakes are costly to correct. Time spent prompting, waiting and reviewing output outweighed the time saved. METR itself cautions that the result does not show AI fails to help most developers, and in its 2026 follow-up it says developers are likely more sped up now, while calling its newer data very weak evidence.

### Is AI-generated code less secure?

The research consistently finds that generated code often contains common vulnerabilities, and one user study found developers with an assistant wrote less secure code while feeling more confident about it. Treat generated code as untrusted input: review it, run static analysis and dependency scanning, and have security-sensitive areas checked by someone with the relevant expertise.

### What should we measure when adopting AI coding tools?

Measure the delivery system rather than code volume: lead time for changes, deployment frequency, change failure rate and time to restore service, plus pull request size, review time, rework and escaped defects. Take a baseline before rollout and compare similar work over similar periods. Avoid lines of code and suggestion acceptance rates as success measures.

### Can an AI tool review code instead of a human?

AI review tools can catch some issues and speed up reviews, but they should support a human reviewer, not replace one. The evidence on subtle errors, security flaws and duplicated logic is exactly the kind of problem that needs someone who understands the system and the requirements, and who is accountable for the change.

### Are coding agents riskier than autocomplete?

Yes, because they act rather than suggest. An agent can edit many files, run commands and open pull requests, and it can be steered by instructions hidden in content it reads. Give agents sandboxed environments and scoped credentials, keep production secrets out of reach, keep their changes small and require human approval for merges and deployments.

### Should a small team adopt AI coding assistants at all?

Usually yes, for the right work: tests, documentation, boilerplate and exploring unfamiliar code are low-risk wins. Before relying on them for core product changes, make sure you have solid tests and a review habit, publish simple rules on what may be sent to the tools, and check over a few months whether delivery and defect measures actually improve.

## About Authect

- Authect is a founder-led software development studio: clients talk to the founders who build their project, never a salesperson.
- Every project is led by a senior engineer. Delivery is AI-accelerated, and an engineer reviews every line before it ships.
- Clients own their code, infrastructure and designs from day one, with no lock-in.
- Legal entity: AUTHECT - FZCO, Trade License No. 70505 (IFZA). Registered office: Building A1, Dubai Digital Park, Dubai Silicon Oasis, Dubai, United Arab Emirates.
- The team works in Dubai (Dubai Marina, Business Bay, Dubai Silicon Oasis) and in Spain (Madrid and Marbella), and works with partners in Lithuania.
- Clients across Europe, the Middle East and beyond; areas served include Dubai, Madrid, Marbella, Málaga, United Arab Emirates, Spain, Lithuania, Sweden, Norway, Denmark.
- Founders: Pranas Mickevicius (Chief Executive Officer), Oscar Arson Saiz (Chief Technology Officer).
- Cooperation models: fixed-price projects, monthly sprints, and support and evolution.
- Contact: info@authect.com, +971 50 246 5223, or https://authect.com/contact. A founder replies within one working day.
- Profiles: LinkedIn https://www.linkedin.com/company/authect/, Instagram https://www.instagram.com/useauthect/, X https://x.com/useauthect, TikTok https://www.tiktok.com/@useauthect, Facebook https://www.facebook.com/profile.php?id=61581141524137.