ChatGPT did not become another member of the team. It changed what our small team believed it could attempt.
Building an AI reading companion requires work across product design, software, electronics, manufacturing, child safety, privacy and operations. No small team is expert in all of those areas.
My background is in software and machine learning. That helps with some parts of the system, but it does not make me an electrical engineer, an acoustics specialist, a toy-safety expert or a manufacturing lead. The team brings complementary strengths, but the surface area of a physical AI product is still enormous.
ChatGPT has become the place where we make that surface area navigable. We use it to turn incomplete thinking into questions, to understand unfamiliar documents, to compare options and to prepare work that can be handed to a coding agent or a human specialist.
The important word is prepare. We do not treat its output as authority.
Where it fits in the day
Some uses are straightforward. I can paste a rough product idea and ask for the assumptions it contains. I can give it architecture documents and ask how a change might affect security, latency or the device lifecycle. I can use it to turn a conversation into a structured engineering task with acceptance criteria.
Other uses cross disciplinary boundaries. Hardware documents have a language of their own: power rails, tolerances, interfaces, component substitutions, thermal constraints and manufacturing test points. ChatGPT can help me construct a first mental model of a schematic or datasheet and identify the questions I need to ask. It cannot sign off the hardware, but it can make a conversation with the people who can much more productive.
We also use it for the less glamorous parts of building a product: structuring decision documents, preparing checklists and keeping a record of open questions. The value is often not the final prose. It is the ability to get from a messy pile of facts to a reviewable structure quickly.
A concrete example: rebuilding the voice path
Our first reading experience chained together several AI operations: speech recognition, page interpretation, response generation, text-to-speech and playback. It was an understandable architecture, but the accumulated latency made the interaction feel transactional.
ChatGPT was useful at several levels. It helped articulate the product symptom that the child is waiting too long, interruptions are awkward, page context is fragile, before discussing implementation. It helped compare a chained request model with a persistent realtime session. It helped turn that architectural decision into repository-level tasks for cloud, firmware and tests.
That does not mean it designed the right system in one answer. The useful process was iterative:
- describe the interaction we wanted;
- expose the current repository and constraints;
- ask for alternatives and failure modes;
- make a human decision;
- turn that decision into a bounded coding task;
- review and test the change on the real system.
The model reduced the cost of exploring options. We still owned the selection and its consequences.
Where ChatGPT is genuinely strong
It is very good at creating structure from incomplete thinking. A builder often begins with a sentence such as “the child should not have to restart the interaction on every page”. ChatGPT can expand that into session boundaries, a physical fallback, error states, privacy implications, test scenarios and metrics.
It is also good at connecting ideas across disciplines. A page-turn feature is simultaneously a product decision, a realtime protocol event, a camera trigger, a privacy boundary, a firmware-state change and an acceptance-test scenario. A model can help keep those relationships visible.
Finally, it is an excellent generator of first-pass questions. When I am looking at a component document, I do not need it to pretend to know the correct answer. I need it to ask whether the camera clock is defined, whether the audio sample rates match, whether the battery thresholds imply the expected pack and whether the test points are accessible during manufacturing.
Where it fails
The most dangerous failure mode is not nonsense. It is a plausible answer that silently fills a gap.
If a document says a component is “likely” a particular model, an AI response may drop the qualifier and repeat the model name as fact. If an older architecture document describes a feature, the model may present it as current even though the repository has moved on. If a prompt asks to simplify a state machine, a coding agent may remove a cross-cutting lifecycle path because it appears unrelated to the user-visible feature.
Models also optimise the task they are given. They do not automatically know which behaviours are sacred. In one major simplification, follow-on work was needed to restore a lifecycle-critical capability and then protect it with explicit checks. The lesson was that we had failed to make an important invariant impossible to miss.
There is another trade-off: AI can create more plans, code and documents than a small team can responsibly validate. Output is not the same as progress. A backlog full of plausible work can become a new form of waste.
The operating model that works for us
We get better results when we provide sources rather than summaries. That means the repository, relevant design documents, current tests and the precise user behaviour. We ask the model to distinguish facts, assumptions and proposals.
We separate ideation from implementation. An architecture conversation can be broad. A coding task should be narrow, with explicit files, invariants, tests and non-goals.
We require evidence. For a cloud change that may mean unit and integration tests. For firmware it means a build, resource checks and representative hardware testing. For a privacy-sensitive flow it means checking what is retained and logged, not accepting a reassuring paragraph.
We also ask a second question after the work appears complete: what did you delete, what did you assume, and what remains untested? That review prompt has caught issues that a success-oriented implementation prompt did not surface.
The bottleneck moves
AI reduces the cost of producing options and code. That is real productivity. It allows a small team to attempt an unusually broad product and to learn across disciplines faster than we could have done alone.
But the bottleneck moves from typing to judgement. Someone still has to decide which problem matters, which trade-off is acceptable, whether the evidence is sufficient and whether a feature should exist at all.
That is why I do not describe ChatGPT as a teammate. A teammate carries accountability, builds trust with other people and lives with the consequences of a decision. A model does none of those things.
It is, however, an extraordinary collaborator when used with context, boundaries and scepticism. It has expanded the range of work we can explore. Our responsibility is to ensure that exploration turns into a coherent, safe and supportable product.
Next in the series: the lifecycle lesson that changed how we write tasks for coding agents.
Tell Me Ted is an independent, pre-launch project that I work on outside my role at HubSpot. The views expressed here are my own and do not represent HubSpot.