Reply to this topic and the rest of the forum opens for you. Three prompts. A sentence or two each is plenty.
- What you do. No company names.
- One thing you got an AI tool to do recently that you could not have done before, or would not have had time for.
- One thing that still fails every time you try it.
That third one matters. It is usually the start of a real question, and it tells the people building material here what to work on next.
One rule for this thread: if you can help with someone's number 3, do not answer it here. Start a topic in Questions and help and mention them. Intros stay intros.
Hi all. I write Python and Go for a logistics company, mostly route planning and the integration work around it. Twelve years in, six of them here.
Something I got done recently that I would not otherwise have bothered with: a shipping cost calculator with no tests at all, around 900 lines. I had Claude Code write a characterisation suite against the current behaviour before I refactored anything. Two afternoons instead of the week I had budgeted, and it turned up a rounding bug on the way.
What still fails is getting it to follow our conventions instead of generic ones. I have written them down twice and it still reaches for the generic version halfway through a long task.
Marcus, ops manager at a food distribution business in the north of England. I am not a developer. I run schedules, chase suppliers, and maintain far too many spreadsheets.
Recent win: our depot handover notes were free text in an email thread every night. I paste the thread in and get a structured summary against the same six headings, which the morning shift actually reads now.
Still failing badly on the stock spreadsheet. It gives me confident numbers that are wrong, and I cannot always tell which ones without redoing the work by hand, at which point what was the point.
Welcome. The characterisation test idea is interesting to me and I do not write code at all. Same shape as what I want for our spreadsheets: describe what the thing currently does before anyone is allowed to change it.
Your conventions problem sounds like a thread of its own rather than an intro reply.
Data analyst at a healthcare payer in Toronto. SQL, a lot of Excel, and some Python that a real developer would call untidy.
The thing it unlocked for me was documentation, of all things. I had thirty odd reporting queries nobody could explain. I walk through them one at a time now and get a plain English description of what each column means, then I correct it and put it in the wiki. About half the descriptions need correcting, which is fine. Correcting is faster than writing from nothing.
What does not work is asking it to write SQL against our warehouse. The schema is 400 tables with names like DIM_MBR_ELIG_2. It guesses joins that look right and are not.
Hello Priya. About half the descriptions need correcting is the most honest sentence I have read on this subject. People either say it is perfect or say it is useless, and it is neither.
DIM_MBR_ELIG_2 gave me a small shudder of recognition.
full stack dev at a 12 person agency, mostly php and vue for client sites. bogota.
best thing so far: it migrated 40 legacy shortcodes to blocks in a client theme. i would have quoted that as a week and instead it took a day and a half, most of which was me reading the diff.
what still breaks: it edits files i did not ask it to touch. i ask for one component and it helpfully reformats a config file, and if i am not paying attention that goes out with the commit. i have started making it list the files before it writes anything, but i do not think remembering to ask is a real fix.
Paralegal at a commercial property firm in Cape Town. Leases, mostly. Nine years of reading leases.
Recently I had it pull the same eight fields out of a stack of lease abstracts into a table. Break clause, rent review date, that sort of thing. It took an afternoon to get the brief right and then it went through 60 documents. I checked every row against the source and it was wrong on four, all wrong in the same way, which turned out to be the useful part.
The thing that never works is dates. Anything with a notice period counted backwards from a date, it will give me a confident answer that is off by a month.
welcome. four wrong rows all wrong the same way is the part i would actually trust. random errors are frightening, systematic ones you can go and hunt.
i have the date problem too in a completely different context, so at least it is not a lease thing.
Firmware engineer in Osaka. C, some C++, industrial sensor gear. The code I work on is older than a couple of my colleagues.
What I got out of it: our build system is a pile of makefiles that exactly one person understood, and he retired in March. I have been having Claude explain it back to me file by file, and I now have a diagram that matches reality. Not glamorous, but it unblocked three people.
What fails is anything touching the hardware. It cannot know what the board does, and it will invent a register name rather than say so. I only ask it things I can check against a datasheet I already have open.
Hej. I was a QA lead and now I mostly write test automation, Playwright plus a lot of Python glue. Gothenburg.
The win was flaky test triage. I feed it the last 200 CI runs and ask which failures cluster together, and it is genuinely better than me at spotting that four different looking failures are one timing problem.
What I cannot make work is reviewing changes it wrote. I get a 600 line diff and my review turns into skimming, which is worse than no review because I then believe it has been reviewed. Probably not the tool's fault. I just have not found a process that holds.
Welcome Sofia. Your third one is my third one, roughly. I skim as well, and I have started to suspect the answer is making the changes smaller rather than getting better at reading them.
Not going to get into it here, the pinned post is quite firm about that. Open it in Questions and help and I will say more.
Platform engineer at a mid-size insurer, based in Accra. Kubernetes, Terraform and the pager.
Good result: first drafts of about 30 runbooks, pulled out of our incident history. Drafts, not finished work. But a rough draft I can edit beats a blank page at 2am.
Bad result: our policy admin system is a Java monolith somewhere north of 400 thousand lines. Every time I ask something that spans more than a couple of packages the answer is plausible and wrong, because it never actually read the parts that mattered.
Welcome. Runbook drafts at 2am is a good example of the pattern I keep landing on, which is that it is useful in proportion to how easily I can check the output. A runbook you are about to follow step by step is about as checkable as work gets.
Data engineer for a retail group in Melbourne. dbt, Airflow, the usual.
Thing I did that I would never have found time for: our dbt project had 90 models and 11 of them documented. I went through in batches, had it draft descriptions and tests from the SQL, then fixed what was wrong. Two days of my time for something that had sat on the backlog for a year.
Still not working: schema changes. When I ask for a change that touches models downstream, it either misses half of them or rewrites things that were already fine.