There is a particular kind of optimism in telling a machine to build your software. There is another, more seasoned kind in being willing to delete everything it gives you. Dylan Farnsworth practices both. From Burlington, Vermont, he runs Winter Green Solutions, serves as co-founder and CTO of Boardwalk Marketing, and works at the awkwardly interesting border where artificial intelligence can produce a great deal of code without assuming one ounce of responsibility for it.
Farnsworth's latest public case study begins with a family problem and an afternoon of tinkering. The experiment worked well enough to deserve a conversation, then a business plan, then a Sunday start. By Monday evening, after roughly 10 to 12 hours of development across two days, there was a functioning application. Two weeks later an outside user entered the system. Within a month, the product had an active closed beta, invitation and attribution tools, daily operations, and real people using it.
The tempting headline is the speed. Farnsworth's more useful point is the restraint. The application contained no hand-written code, but it did contain human decisions everywhere: what to build, how to describe it, which model to use, when to review, where to monitor, and whether a given agent session deserved to live another minute. Automation supplied the motion. Judgment chose the direction.
First, learn to hear the sour note
Long before Farnsworth was leading engineering and product work, he studied oboe performance at Florida State University. It is an excellent instrument for anyone who enjoys precision and has made peace with being noticed. An oboe can tune an orchestra, carry a melody and expose a careless entrance with merciless clarity. Software has its own versions of all three.
The leap from conservatory discipline to technical leadership sounds dramatic only if the habits are ignored. Both practices reward close listening. Both require a tolerance for repetition that would test the patience of a saint and several of the saint's neighbors. Both turn on timing. A brilliant note in the wrong measure is still wrong; an elegant feature that solves the wrong problem is merely a more expensive mistake.
Farnsworth spent more than 15 years learning that distinction across web engineering, fintech, payments, advertising technology and SaaS. At Cogo Labs he worked on sites and internal tools. At Sharp Action he served as Director of Engineering. PaymentWorks put him in application engineering and product leadership. CoreChain Technologies brought a vice presidency spanning engineering and product development. In 2023 he co-founded Boardwalk Marketing, whose software helps publishers and advertisers optimize what happens after a visitor does not take the expected action.
That résumé crosses enough departments to make ownership less a slogan than a reflex. At Winter Green Solutions, Farnsworth offers architecture, design, implementation and deployment as one continuous job. The pitch is not a crowd of specialists. It is one accountable builder who knows when specialist tools, including AI agents, need to be invited into the room.
“The AI makes the building fast. Experience makes it hold up.”Dylan Farnsworth
A product begins as prose
In Farnsworth's workflow, a feature does not begin with code. It begins as a short concept specification in ordinary language. An agent turns that description into an execution plan. For a complicated feature, separate agents may inspect the plan for security, performance and its fit with the wider product. Only then does implementation begin. A further agent creates tests and checks coverage.
The sequence is revealing. People often describe AI-assisted programming as if the model were the new author. Farnsworth behaves more like an editor, architect and stage manager sharing one desk. He is opinionated about the result, less precious about the exact syntax, and alert to the point when an apparently energetic session has started laying bricks in the wrong field.
From experiment to production use
Relative bars show milestones, not proportional hours. The point is the widening distance between making something work and making it ready for people.
He typically runs one to three AI processes at once. The tooling could handle more, he says, perhaps six to ten. His ceiling is human attention. Staying involved makes it possible to catch drift early. When a session is going badly, the answer is not to admire the volume of output. It is to throw that output away.
This is wonderfully unromantic. Traditional programming can make deletion feel costly because every line carries the memory of the hours spent writing it. Machine-generated code arrives without that sentimental protection. An agent can produce a fresh version at extraordinary speed, so the operator must become equally fluent in rejection. The cheapest bad code is the code that never reaches the repository.
AI processes usually run in parallel. Farnsworth limits the ensemble so he can stay close to each build, catch problems early and keep speed from becoming noise.
The room where the hype goes quiet
Earlier this year, Farnsworth stood beside a screen at a ChatBTV gathering and walked a room of local technologists through this process. The setting mattered. Burlington's AI meetups are presented as working conversations for developers and designers, with demos, questions and food, rather than a parade of pitch decks. In the event photograph, the audience is close enough to inspect the details and comfortable enough to interrupt.
Farnsworth's public argument about AI has the same workshop quality. He believes organizations should learn now, while subscriptions buy unusual amounts of experimentation and vendors still tolerate the rough edges of beta use. His case is economic as much as technological. Today's generous exchange of money, prompts and feedback will not necessarily last. Teams that postpone learning may face the same mistakes later, only with higher costs and less patience.
This is not an invitation to ignore failure. Farnsworth names security, code quality and product value as present obligations, not details to be repaired after the future arrives. His recent product uses monitoring at several points in its AI pipeline. Prompt changes were frequent. Model selection varied by task among commercial and local options. The system's speed did not erase review; it multiplied the places where review mattered.
“There are real failure modes with LLMs today. There are also very real wins.”Dylan Farnsworth
What remains stubbornly human
The software profession has often mistaken visible labor for valuable labor. A screen full of syntax looks industrious. Farnsworth's approach removes much of that evidence. If an agent types the code, the human contribution moves upstream into the specification and downstream into review. It appears in architecture, model choice, monitoring, test design and the decision to stop. These jobs are less theatrical than typing rapidly, but they are no less technical.
His career makes that migration believable. Product leadership teaches a person to ask whether the work should exist. Engineering leadership teaches whether it can survive. Founding a company adds the rude question of whether anyone will pay for the answer. Music training, meanwhile, offers the oldest lesson in the room: performance is the result of rehearsal, not a substitute for it.
Boardwalk Marketing provides a second view of the same instinct. Its premise is that the so-called average visitor conceals useful differences. A person who declines one offer has not evaporated; the next sensible path may simply be different. The company uses optimization and audience segmentation to test those paths. In product terms, this is a preference for response over assumption. Watch what happened, then adjust the sequence. It is also a tidy description of Farnsworth's own career, which has moved between engineering and product rather than insisting the two speak through committee minutes.
Winter Green Solutions makes that range explicit. Farnsworth works directly with founders on rapid builds, AI integrations and technical advice, including the unglamorous choices that decide a young product's fate: build or buy, hire or contract, preserve or start again. He presents the work as careful and finite, with a small number of advisory clients and short build windows. There is confidence in that offer, but also a boundary. One person can own the whole picture only by refusing to pretend that every picture belongs on the wall.
Farnsworth's one-month build does not establish a universal timetable. Products differ, constraints differ, and an experienced solo operator is not a representative sample. What it offers is a field report from a new division of labor. The implementation layer can compress dramatically. The responsibility layer does not. If anything, responsibility becomes more concentrated in the person who decides which agents act, what they know, and when their work is allowed to touch reality.
There is a small joke hidden here. For years, software teams used the word “orchestration” to make servers sound grand. Farnsworth actually studied orchestral performance. He knows that a conductor who merely demands louder playing has missed the profession. The task is balance, entrance, pace and interpretation. It is knowing which section should lead, and which should wait.
Now his ensemble includes models that never tire, never blush and can be confidently wrong before breakfast. He gives them room to move, but not the final word. That combination of curiosity and suspicion may be the useful posture for this moment: build quickly, inspect closely, and keep the delete key within easy reach.