Representative results only · all C code here is synthetic · no TI code is included or displayed details
Results are representative and informational only. Under Texas Instruments' C2000 software license terms, real TI SDK source code is confidential and licensed for internal use only, so no TI code is included, displayed, processed, or emitted here. All C code on this site is synthetic, written for this demo, with invented names and values that resemble typical power-converter firmware. The generated headers compile against this demo's sample firmware in CI; the "legacy" files used for the audit are illustrative and not guaranteed to compile on any target. Product ratings come from public IntelliPower data sheets; all circuit values and gains are invented. Independent demo, not affiliated with or endorsed by AMETEK, IntelliPower, or Texas Instruments. TI, C2000, and Code Composer Studio are trademarks of Texas Instruments.
AI practice
The posting asks for more than two tools: AI best practices across the organization, AI agents and productivity tools, and results presented to business and technical leaders. This page shows how I already work that way, and how I'd run it at IntelliPower.
Spec first. A written plan (docs/PLAN.md in the repository) was approved before any code. Claude Code then built the tool in milestones over about a day of directed sessions, each step a small commit with its own tests. I chose the problem, approved the plan, and reviewed and redirected the work; the AI wrote most of the code.
Gates on AI output. Every change passes the test suite before it ships: generated files must match a fresh generation, typeset math must equal the computed values, and the generated C code must build and pass known-answer tests. One early commit went out with stale generated headers; the freshness test caught it, and since then every commit waits for the test run.
AI reviewing AI. An AI reviewer, prompted to act as a power-electronics firmware lead, found a real physics error: the timed RMS overload was wired to the fast hardware comparator. A second review found five more issues (a 60 Hz-only input window on a 50/60 Hz unit, "fixed-point" code doing float math, an include-order hazard, stale corpus notes, overstated AI wording). All were fixed, and each code fix got a test so it can't come back.
Where it's used. Drafting what each unexplained constant in legacy firmware is: its category, units, whether it's typed or derived, and which spec rule it corresponds to. A person reviews every draft. Generating firmware never calls a model.
Measured before trusted. A blind answer key and a bar set before any model ran (≥ 90% category, ≥ 85% units). Over 3 recorded runs, gpt-5.4-nano mapped constants to the right rule 99% of the time and got units right 95% of the time, but category only 83% against its 90% bar: below it, reported as is (units clear their 85% bar; no bar was set for rule mapping). About $0.0042 per run. The very first run scored 39% because of two bugs in my harness, found by reading the raw responses before trusting the score.
Data sheets. AI read the three data sheet PDFs and drafted the structured rows, each with its page citation. The consistency gate then flagged an inconsistency in every one of the three sheets. Details are on the Audit page.
A proposal from the outside. The first month exists to replace my guesses with your data.
| Days | Work | Result |
|---|---|---|
| 1–30 | Map. Interview teams; list repetitive, document-heavy work with rough hours and risk. Classify data (public, proprietary, export-controlled or defense, vendor-confidential) and decide which models may touch which. | Workflow map, data rules, ranked pilot list |
| 31–60 | Pilot. Run about three pilots, each with a success measure set before it starts and a person approving every output. | Measured results; each pilot kept or stopped |
| 61–90 | Scale or stop. Turn what worked into documented tools with owners and training; write the AI best-practice guide. | Playbook and a results presentation |
Candidate pilots (to confirm in the first month):
- Engineering: firmware constants from specs (this demo); data sheet consistency checks; paperwork for qualifying alternate parts.
- Operations: summaries and trend flags from test reports; keeping specs and procedures in sync across versions.
- Business: first drafts of quotes and RFQ answers from the product catalog; searchable answers from internal documents.
Guardrails: classify data before choosing tools; defense, export-controlled, and vendor-confidential data only on approved or local models; a person reviews every AI output; every pilot is measured against a bar set in advance; costs are tracked.