AI at work: what I built while everyone was debating

11 min read

82 % of developers use a generative AI every week. A randomized study on experienced developers measured −19 % productivity. 80 % of companies that invested in AI see no measurable gain.

These three numbers hold together. Public debate doesn’t: it swings between “AI will destroy work,” “AI is mass surveillance,” and “AI will 10× your productivity.” Three polarized narratives, three legitimate fears, that don’t tell the same story — and that deserve to be separated before anyone stakes out a position.

This article doesn’t try to settle the debate. It offers an experience report: while everyone was debating, I shipped, in four months and for about $1,000 of AI usage, six C libraries from scratch, four CLI tools, and a complete intranet infrastructure. This text is about what that taught me, what worked, and what I still refuse to delegate.

The three dominant fears

“AI will take my job”

The most media-covered fear. Numbers anchor it in something concrete: Goldman Sachs estimates 6 to 7 % of workers will be displaced during the AI transition over a decade, with a 0.6-point increase in the unemployment rate. McKinsey, in an analysis published late 2025, argues that 57 % of work hours in the United States could, technically, be handled by a sufficiently deployed AI system. The most exposed profiles: entry-level programmers, accountants, legal assistants, customer-service agents.

One often-cited nuance comes from the 2026 Crédoc Barometer for Arcep (France), conducted on 3,544 representative respondents: 63 % think AI will destroy jobs in general, but only 23 % fear that their own job will be replaced. Collective worry is almost three times as strong as personal worry.

That gap isn’t contradictory. It reflects an intuition: AI won’t replace a specific individual, it redraws the surface of professions. The most codified tasks disappear; those that require judgment, synthesis, decision, gain weight. My position, plainly: AI doesn’t replace a developer who knows how to think; it replaces the developer who doesn’t. That’s neither reassuring nor alarming — it’s upward pressure on what we expect from a professional.

“AI is surveillance”

This fear gets the least coverage but the most documentation. A 2025 MIT study estimates that 80 % of companies monitor their remote workers. 74 % of U.S. employers deploy activity-tracking tools (websites visited, applications, screenshots); 67 % collect biometric data — fingerprints, facial recognition. Employees in heavily surveilled environments report 45 % stress vs 28 % in lightly or unsurveilled ones. Nearly half of those surveyed consider resigning if surveillance increases.

The regulatory response is coming: the EU AI Act, fully enforceable in 2026, classifies employer use of AI as “high risk,” bans emotion recognition at work, and requires transparency and human oversight. In the United States, the CFPB has opened investigations into monitoring tools that collect data without consent.

This fear is legitimate, and I share it. But it deserves to be separated from “AI at work.” Office surveillance existed before LLMs — keyloggers, screen capture, mail scanning. What AI adds is an automated analysis layer that makes data previously drowned in noise actually exploitable. The problem isn’t the technology per se, it’s the choice of tools and of deployment each organization makes. The same language model can serve an independent developer at home, or a behavior-scoring platform in an open office. Not the same ethical question — same underlying brick.

“AI doesn’t make us productive — it’s hot air”

The most solid critique, because it rests on serious, contradictory studies.

For the defense: GitHub’s controlled Copilot experiment measured +55 % speed on standardized development tasks (statistically significant, 95 % CI between 21 % and 89 %). A Harvard Business School study showed +34 % productivity for novice workers — AI acts as an integrated coach. A meta-analysis of office tasks (writing, research, programming) places gains between 10 and 25 % depending on context.

For the prosecution: a randomized METR study, published in 2025, measured the effect of AI assistants on experienced open-source developers using Cursor Pro with Claude 3.5/3.7. Result: −19 % productivity. Developers felt faster; in reality, they spent their time guiding the model rather than producing. The 2026 NBER survey reports that 80 % of companies that invested in AI see no gain at the organizational level.

How to hold both sets of numbers at once? They measure different things. Individual gains in RCTs cover well-defined tasks, with an operator who knows how to use the tool. The absence of gain at the company level reflects the fact that individual value doesn’t automatically aggregate collectively: more code written doesn’t mean more product shipped, if the bottlenecks are elsewhere (review, QA, deploy, product alignment).

The real lesson, to my eye, fits in one sentence: AI amplifies existing skills; it does not create them. A beginner gains a lot because the floor was low. An expert gains little — or loses — because their bottleneck is no longer production speed, it’s judgment quality. If the tool distracts them from that judgment, it degrades the output.

What I built with this tool

The concrete part, and the reason I’m writing this rather than just citing studies.

I’m a solo developer. Over four months, with help from an AI assistant, I shipped and deployed:

  • A complete intranet infrastructure: authoritative DNS with BIND and catalog-zones synced across two nodes, HTTPS reverse proxy Caddy with ACME certificates, WireGuard VPN with an admin interface, Prometheus + Grafana monitoring stack, Keepalived active/passive failover (VIPs shared between two servers), btrfs RAID1 storage replicated between nodes via btrfs send/receive, NFSv4 exported to workstations.
  • An ecosystem of six C libraries from scratch (bc-core, bc-allocators, bc-containers, bc-io, bc-concurrency, bc-runtime): foundations with no external dependency, all tested with cmocka, benchmarked, run under sanitizers (ASan, UBSan, TSan) and cppcheck. Each library has its own git repo, CI, Debian packages.
  • Four C CLI tools (bc-hash, bc-duplicate, bc-seek, bc-count): parallel file-tree hashing, duplicate detection, parallel find(1) alternative, and a generalized wc(1). Benchmarked against fclones, jdupes, find, and fd — often faster at scale, with reproducible numbers published on the site.

Total AI usage cost across those four months: about $1,000.

All open-source (GPLv3 for tools, LGPLv3 for libraries), versioned, documented, maintained. Not a repo abandoned after a burst of enthusiasm — software that runs, that I use, that serves someone (at least me).

Now, the part that has to be said plainly, because it’s exactly what public debate misses: the code was written by AI. The docs too. For most of the projects above, I did not type the majority of the final lines. That’s not a confession or an affectation — it’s an operational fact, and it’s the point of the tool: produce code fast.

What stayed entirely my work:

  • Architecture. Layered ecosystem, library contracts, threading models, deployment strategy, dependency choices (none external).
  • Design. Algorithm choices (three-pass pipeline for duplicate detection, strict barrier between walk and process for hashing), data structures, performance-vs-readability trade-offs, naming conventions.
  • Final judgment. No commit goes to production without me understanding every line. If I don’t understand, I refuse. This rule is not negotiable.

And above all, the invisible part: steering the assistant.

That’s the point nobody tells. An out-of-the-box AI assistant that doesn’t know my conventions, hasn’t read my internal docs, isn’t constrained by my project rules, produces very different output from one that works inside my configured environment. I’ve spent months tuning this setup: system prompts, per-project instruction files (a dedicated instruction file in each repo), shared technical-pattern documents, style rules, hooks that block certain actions, accumulated preference memory conversation after conversation. That steering layer is probably as much work as the code shipped — and it’s the only reason output stays coherent from one project to the next.

Without that layer, most of the time with AI is spent correcting it. With it, most of the time is spent precisely formulating what I want. Because the real bottleneck is almost never the model’s ability to produce code — anyone gets code out of an LLM in five minutes. The real bottleneck is getting code that’s nearly error-free in a codebase with its own conventions, under performance and security constraints that don’t tolerate approximation. That result is not delivered by the model; it’s earned through rules, guidance, examples, iteration. It’s most of the work — and the part no marketing demo shows.

What works, what doesn’t

A plain report, two columns.

What works well:

  • Exploring an unfamiliar domain. An obscure syscall, a strange kernel bug, a 200-page RFC — AI digests it fast and gives me a precise entry point.
  • Writing technical documentation. Turning raw notes into a structured README, a man page, a clean changelog.
  • Review and error detection. Read cold, AI flags obvious errors (off-by-one, leaks, race conditions) that I miss after three hours on the same file.
  • Systematic refactoring. Applying the same transformation to 50 files, uniformly, without misses.
  • Throwaway prototypes. Testing an idea in 20 minutes instead of two hours.

What works less well:

  • Non-trivial architectural design. AI converges toward the average patterns, the ones dominant in its corpus. For non-standard architecture, it struggles and drifts back to the norm.
  • Performance decisions. It cannot measure. So it proposes what looks fast in theory, which can be exactly the opposite in practice on given hardware. On bc-hash, several optimizations tried at its suggestion regressed the benchmarks — I called it from the numbers.
  • Critical code without human review. Subtle hallucination: a call to a function that doesn’t exist, a flag whose semantics changed between versions. Always catchable on a read-through, never without one.

My position, straight

Nuance went into the previous sections. Here’s the call.

  • AI doesn’t replace a worker who knows how to think. It replaces the worker whose job doesn’t mobilize enough judgment to justify it being done by a human. The employment fear is legitimate but mistargeted.
  • The surveillance fear is legitimate, but separate from the AI topic. It calls for deployment regulation, not model regulation. The EU AI Act is a good start.
  • The collective productivity-loss fear is the truest one. The tool is powerful but mass adoption without method creates over-activity, not value. That’s what the 80 % of gainless companies are reporting.
  • The lever is both method and configuration. Know what you want. Know when to refuse. Keep control of judgment. Read what the tool produces before accepting. Never commit what you don’t understand. And invest in steering the assistant as much as in the code it produces — that’s where the real work hides, the part no demo shows.

My infrastructure, one diagram

What I’ve accumulated, to make “build with” concrete:

              LAN 192.168.11.0/24 — lan.unmanaged-bytes.com
                                │
         ┌──────────────────────┴──────────────────────┐
         │     HTTPS reverse proxy (Caddy + ACME)      │
         │     VIP .21 — Keepalived failover vrid 52   │
         └──────────────────────┬──────────────────────┘
                                │
      ┌──────────┬──────────────┼──────────────┬──────────┐
      │          │              │              │          │
  ┌───┴────┐ ┌───┴─────┐  ┌─────┴──────┐  ┌────┴────┐
  │  DNS   │ │  VPN    │  │ Monitoring │  │ Other   │
  │  BIND  │ │WireGuard│  │ Prometheus │  │services │
  │dns-01/02│ │ VIP .20 │ │ + Grafana  │  │         │
  │catalog │ │ vrid 51 │  │            │  │         │
  └────────┘ └─────────┘  └────────────┘  └─────────┘
                                │
      ┌─────────────────────────┴──────────────────────────┐
      │ srv-prod-01 ◄── btrfs send/receive ──► srv-prod-02 │
      │   (MASTER)           replication         (BACKUP)  │
      │   Incus containers — Debian 13 — btrfs RAID1       │
      └─────────────────────────┬──────────────────────────┘
                                │
                      NFSv4 (LAN + VPN)
                                │
      ┌─────────────────────────┴──────────────────────────┐
      │ ws-desktop-00 + ws-laptop-00                       │
      │ /mnt/storage/* mounted, unified data access        │
      └────────────────────────────────────────────────────┘

Two Debian 13 nodes, several Incus containers, five Keepalived VIPs, a btrfs RAID1 tree replicated between the two nodes, a WireGuard VPN, an HTTPS reverse proxy with automatic ACME, an authoritative DNS with catalog-zones, Prometheus/Grafana monitoring — all exposed via internal FQDNs on lan.unmanaged-bytes.com.

I would not have had time to build this alone in one quarter. With a disciplined AI assistant — one that doesn’t write code I won’t read, and doesn’t decide anything I won’t approve — I did, in four months.

My list of shipped projects

To make it even more concrete, here’s what’s published and accessible:

Six C libraries (foundations, no external dependency):

  • bc-core — core primitives: memory, SIMD search, checked arithmetic, hardware hashing
  • bc-allocators — pool, bump-pointer arena, slab, typed-array allocators with leak reporting
  • bc-containers — vector, hashmap, set, ring buffer
  • bc-io — open/close, path/inode, mmap, buffered stream with posix_fadvise
  • bc-concurrency — worker pool, lock-free MPMC queue, signal-safe shutdown coordination
  • bc-runtime — application lifecycle, layered config, structured logging, metrics, CLI framework

Four CLI tools:

  • bc-hash — parallel file-tree hashing with io_uring, adaptive dispatch (SHA-256, CRC32C, xxh3)
  • bc-duplicate — duplicate detection via a size → fast-hash → full-hash pipeline
  • bc-seek — parallel find(1) alternative, 10× faster than find on a 1M-file tree
  • bc-count — generalized wc(1): lines, words, bytes, UTF-8 codepoints, pattern occurrences, directory entries (alpha)

Everything is open-source (GPLv3 for tools, LGPLv3 for libraries) and published at github.com/Unmanaged-Bytes.

Conclusion

Four months. About $1,000 of AI usage. Six C libraries, four CLI tools, one full intranet.

82 % of developers use a generative AI every week. On experienced devs, a randomized study measured −19 % productivity. 80 % of companies see no gain. The three numbers coexist, and none of them is wrong.

The tool is real, it is useful, it is imperfect. It is not magical, it is not neutral. What it does to my craft depends on what I let it do, what I refuse to let it do, and how seriously I check every line that reaches production.

The rest is debate. Useful, necessary — but it ships nothing.

Read. Understand. Master. Repeat.

Numbered sources: Stack Overflow Developer Survey, METR — Measuring the Impact of LLMs on Experienced Developers, NBER 2026 — The AI productivity paradox, Baromètre du numérique 2026 — Crédoc/Arcep, Goldman Sachs — How Will AI Affect the US Labor Market, McKinsey — Superagency in the workplace (2025), GitHub Copilot RCT (arXiv 2302.06590), MIT 2025 workplace monitoring study.