Benefits (and weaknesses) of agentic coding for new products

I have found agentic coding to be phenomenally productive. A solo developer building an entire product like Mock Machines in a couple of months is incredible. Especially when my skill is really in the modelling it is built to do, not core software engineering as such. That speed is not without risks and challenges, so I thought I’d take a morning to reflect on the work and the outcomes.

Note: if you’re interested in the structure and techniques I settled on, that is covered in a technical post. I used this approach most of the time, except when I didn’t. This seems to be a fairly standard attitude in changing times!

Quick summary

Upsides

Shipping a feature-rich product
Building the supporting website and docs

Downsides

Risk of technical debt
Risk of unrealistic expectations

The Tradeoff

My do: focus on target market of GTM users who respond to a compelling demo
My don’t: plan to maintain same pace of feature development

Two recurring opportunities for coding agents to improve

The code output: reduce my entropy
The developer experience: improve the communication skills

Top areas to work on in personal performance

Improved time blocking
Leveraging throwaway work

Upsides

Shipping a feature-rich product fast

This is a tangible outcome. My career is built on talking more sense than hype, so I’ll qualify the above by saying that I’ve built to alpha/beta quality, not a fully polished product. That gap is perhaps the most interesting topic in software right now: good enough to be useful, designed well enough to share, but with enough rough edges and technical debt to be, well, problematic.

For a bit of context, what is the product? What does “good enough to be useful” mean? Is there any value being created here?

Picture the tech sector’s customer-facing engineers around the world with targets to hit. Today alone, thousands of them are spending hours of expensive time trying to pull together a database or an API for a prototype. Some of the best are spending even more of their even more expensive time to make related content that “looks nice”. Millions of dollars of revenue rely on this work.

Mock Machines turns an AI prompt into an editable config file, driving a realistic simulation that generates data, a REST API, mocked-up documents, which can all be shared via branded landing pages. It is super fast. As you change the config, you instantly get updated data and API endpoints. It’s built to be a reliable tool for day-to-day work.

I may be wrong about whether my take is generally useful; that is for the market to decide. In terms of complexity of technology and potential business value, this article is about a very real product building experience.

Building the supporting website and docs

In the same timeframe that the product has been built, a complete website including a Call-To-Action has been built. There’s a waitlist function. A docs website for the product has been built. Both the web site and the docs could have been entire projects in their own right. This is phenomenal productivity.

Now, I’d expect a marketer to pick out any number of issues for why it won’t convert. I can point out any number of things that need to be refined in the docs. I’d still put this work alongside many a website or docs site I’ve seen from startups with more people and more time.

A mix of Claude Design and Claude Code really accelerates the flow here. It’s nice to have an idea like “I’d like to animate the logo” or “I want to try using shaders as a highlight color” and execute as a parallel side task, rather than anything that takes “real development time”.

It’s also really nice for creativity. Are “animate on hover” icons and “shader as brand color” going to be the next big thing? I doubt I’m about to become a web trend setter. It is still hugely enjoyable to be able to add some personality to a website so easily. It’s nice to think more about the concept, the design detail rather than the technical detail, and not have to research writing a shader.

Downsides

Is everything perfect and have we solved coding? Well, no. The phenomenal advances in automated coding have not yet translated to delivering a higher quality end result than a good engineer. That in itself is not a downside. These are powerful tools. Like any tool you need to consider your trade-offs to get the most out of them.

Building up a lot of technical debt

I committed nearly half a million lines of code over the course of a couple of months plus some evening/weekend work before I decided I had an idea worth building. 387 pull requests, 1,172 Linear issues. I haven’t tracked tokens, but if you want to quantify the cost, that’s a Claude Max subscription plus £263 overage in one particularly busy week.

I like what I’ve built. I have reasonable instincts, I think, for prioritisation. The sheer quantity of code is not reassuring, however. That pace has not been maintained by carefully considering all the generated text. No matter how you cut it: therein be dragons.

Frankly, that means the next phase of development is going to be about reducing code. Or rather, streamlining the code, since I’m not that interested in counting tokens, lines of code, PRs, or all the other developer vanity metrics flying around.

In terms of tangible outcomes, one way to express this is: I’m starting with a waitlist and I’ll be reaching out to my network to start. I do not want to test the user system, git integration, or sync to object storage, by letting anyone in the world sign up. In a very concrete sense, I have built a lot of features, but many are frankly half-assed.

In short, just as it has always been: you can move faster the more technical debt you are willing to build up. You just can’t sustain that speed forever.

Risk of unrealistic expectations

I’ve had a good career sitting at the boundary between expectations and reality. In both directions: dealing with the fallout of someone expecting too much, and also the opposite challenge of demonstrating to the skeptic that the tech does actually deliver. Expectations management is a big deal in day-to-day work.

Agentic coding has taken the idea of expectations management down a back alley and given it a severe beating. The pace at which you can appear to deliver is stunning. I’ve had many occasions where fast results were fast followed by re-work of something I thought was done.

I work in the B2B sector, so I’ll limit my comments to that. In B2B we’ll be able to adjust reasonably well to this new ability to create plausible-but-broken work. A lot of day-to-day decisions are based on experience and heuristics rather than detailed analysis, and there’s always been an advantage to being able to move quickly and then to course correct. The AI developments of the last few years have utterly shaken up our various rules-of-thumb. That will settle down, I think.

It’s going to become a sign of professionalism: have you adapted your approach to expectations management in the age of AI? Are you able to manage your own expectations? That’s going to be a big part of taking advantage of the new opportunities of AI.

The Trade Off

All product building is about trade offs. When someone says, “I just wrote half a million lines of code”, any engineer worth their salt is going to tell you that’s a problem. So why did I take on that tech debt? Here’s a trade off I was making on this project at this time:

My do: focus on target market of GTM users who respond to a compelling demo This product is aimed at a particular niche: tech sector go-to-market teams. They need to engage a skeptical audience, demonstrate the art of the possible, and handle a range of technical requirements. They’re under pressure to do this every single day. They have a strong instinct that great tech but a bad demo, does not win hearts and minds. I’ve picked the depth of feature set that my instinct/experience tells me is necessary.

As a counter-example, if I thought the main goal was the core engine, I’d have simplified the frontend, set aside the generation of mock documents and branded landing pages, and prioritised things like spatial queries instead.

My don’t: plan to maintain same pace of feature development Trade offs are also about sequencing: I’ve traded off feature development today against spending time clearing up the technical debt tomorrow. I’m comfortable with this; it’s standard for new product development. I know for Mock Machines that without an external driver saying otherwise, in the next phase I will get more mileage from firming up the foundations and refining the messaging. New features can pause for a while.

Two recurring opportunities for coding agents to improve

In general I try to follow the advice that you should build for the models we’ll have in six months, not for the models we have today. I’ve generally tried to settle on a lightweight approach. My choice of tooling and skills is covered here if you’re interested. As I focus more on streamlining the product, I’m probably due a refresh in re-examining harnesses, secure sandboxing, planning and tracking. All useful, but also to my mind things that go around the coding agent rather than within it.

I find there are two big recurring themes in the model itself that keep surviving through the waves of improvement. These are the areas where I simply do not care if I could do a better configuration or have a skills issue; I believe improvements here would be such a significant benefit to most users.

The code output: reduce my entropy

Simplify don’t complicate
Thoroughness
Structure
Security
Help me organise

Coding agents need to significantly reduce the amount of chaos and confusion they can add to a codebase if you’re not careful. Perhaps I shouldn’t want this, as the developer’s ability to add structure, simplicity and maintainability to the code is where the human engineer’s value really shines. Here’s some examples of where it can feel like I’m fighting the AI rather than working with it.

Simplify don’t complicate

This is something that crops up everywhere that developers gather to discuss AI generated code. The agents love to duplicate code, add little convenience wrappers, add inline styling to web pages. Data structures and function signatures can proliferate with subtle differences. Rarely is a function simply updated to meet new requirements; more often a new function or wrapper will be added. All of this is undoubtedly my biggest frustration with the code itself.

Thoroughness

The “completeness” of the work by an agent performing a large task is variable. They don’t have the quality of thoroughness that a human can bring to the table. Neither do many humans, it has to be said! It’s also true they will catch bugs, find security vulnerabilities, and generally assist you in being thorough yourself. Nonetheless, I will for example find myself reading through the chain of thought or the “Insights” from Claude Code, and find genuine issues identified where the agent then decided not to include them in the final report.

Structure

Agents are biased against adding structure. This is why “reduce my entropy” sprang to mind while reflecting on my experience. A significant amount of time in agentic coding can be the human adding energy and structure to counteract an agent seeking the lowest energy solution. As one example, I paid a lot of attention to the core engine (eg compilation, runtime, datastore) but less to the rest api. Consequently I had to focus for a couple of days on sorting out a large, flat plate of spaghetti that was the api code.

Security

One of the odd contradictions of coding agents is that they are very good at finding vulnerabilities, but also very good at introducing them. For instance, putting code in the browser client that should very much be kept on the server. It will then eloquently explain why that was a terrible idea and it shouldn’t have done it. Security is a great example of where the developer is responsible, but if only in terms of time and tokens spent, it would be nice to be able to worry less about any given task introducing unnecessary security risks.

Help me organise

I’ll say up front that the engineer is responsible for introducing structure, priorities, standards as appropriate to the situation. I’ve been developing solo, do I really need plans, tasks, commit messages, PRDs, pull request descriptions in GitHub, issues in Linear? No doubt I could streamline but worrying deeply about the perfect system is itself a burden. I simply get on with intelligent use of all those very standard texts.

Agents have a weak ability to distinguish between different contexts eg code comment vs. issue description. One example is putting references to issues or PRs directly in the code comments, and then failing at a new task because the now out-of-date reference confuses it. It can feel like being trapped in a meeting with one of those pedants that values process over outcomes, but also gets the process wrong.

The developer experience: improve the communication skills

The opportunities for improvement in the code output seem to me the most impactful. There’s also a few areas where they could be better at communicating with grumpy, impatient Scottish engineers. This is more subjective, although I consider “grumpy Scottish engineer” to be a good quality bar. Perhaps it is better solved with improving the project standards and guidelines. Nonetheless these are areas where I’d benefit from agents being better trained towards my particular tastes (although I doubt my tastes are a priority for the model builders!).

Naming
Structured responses
Word choice

Naming

This could be considered a code improvement, but a symbol is a symbol as far as code is concerned. It feels more important as a developer experience issue, and not necessarily a code quality issue. I like how a coding agent can pick names, let’s say for a variable or function. It can suggest multiple names to pick from. On larger tasks, really you want to rely on the agent to pick names consistently. As an example, at one point I was looking at code that said issue.Issue(). It’s pretty difficult to figure out what’s going on there, and obvious options such as issue.New() or issue.NewIssue() would have been fine.

Structured responses

You can definitely use prompts and skills and such to get the kind of structure you’re looking for. I’ve got a project-status skill whose output I find super useful. Even so, I feel there’s a tendency towards narrative, editorialising, compressing lists in to single lines, etc, that frequently makes it difficult to comprehend. If Claude Code was on my team, I’d be gently hinting that constantly tagging summaries with “one thing worth flagging”, completely separate to where it naturally fits in the summary, adds unnecessary friction.

Word choice

I’ll indulge in one rant. I don’t mind that any given agent has a few linguistic preferences. Claude talks about “load bearing seams” all the time, and I’m down with that. I find that term meaningful. Training Claude to have an obsession with the word “honesty” is not, at best it’s a “leaky training abstraction”. At worst, it’s the worst product decision in the history of computing. I pray Anthropic throws a billion or two at fixing whatever training processes are causing this.

There must be huge pressures to deliver quality code, reduce hallucinations, and also communicate to the public that those are high priority goals. If that is the root cause of the “honesty” obsession, I sympathise. Nonetheless if you’re in a conversation with someone where they go through multiple points of view, all contradictory, and the only one they don’t call “honest” was their first instinct — you ain’t gonna conclude they’re honest. Please teach them to use “revised” or “hypothesis” or something. It would sound less like a con artist, and also be using words with relevant meaning. Knowing what words mean is a big expectation I have of a language model.

Top areas to work on in personal performance

The previous section was about where the agents could improve. These are a couple of thoughts of where I’ll be putting some time into.

Improved time blocking
Leveraging throwaway work

Improved time blocking

Agentic coding is difficult to get your head around in terms of managing your time and focus. There’s a few different ways I’ve been working: parallel tracks with multiple agents, interactive building for fast iteration on a design, firing off side tasks to do research that I’ll read later, overnight tasks where I see what a one-shot gets me.

It’s also difficult when in a single session, there’s a huge variance in how long a response will take. It’s easy to go from under-engaged to over-engaged and back again in the course of a few hours. It’s harder to reliably predict that’s how your morning is going to go. I suspect the challenge of predicting your daily and weekly outcomes is an even bigger deal in big teams.

In the same way that it feels to me like reducing entropy is the big theme in where the coding agents can improve, time blocking (or estimation, or time management) feels like the big theme for the developer. Multi-agent orchestration, loops, spec-driven development, and whatever new cycle comes around next month, a lot of it feels like fundamentally we have yet to learn how to predict how much time will be involved in delivering any given piece of work.

Leveraging throwaway work

I’ve been finding that a lot of the time, I get results not so much from planning, but from throwaway work. Design is the simplest example of this: with little effort, you can get an agent to mock up a couple of dozen different designs exploring a variety of ideas. Keep the ideas you like, throw everything away, then start a more effort-full planning and building process.

Relating this to the “time blocking” concept, something that has worked well for me in a few cases is setting an overnight task to one shot a feature. Or even to one shot three different versions. The less I have clarity on the what or the how of what I need to build, the more I find this can be a good alternative to iterating on a planning doc.

There is nothing new in what I’m saying above. Good product specs have always come after you started building, not before. AI really drives that old truism home, though. There are many product leaders who will insist on written PRDs, maybe a Figma mockup, before handing work to their engineers. Even if their task tracking is reliable, it introduces weeks of delay. They’re not going to perform well against teams that can simultaneously research the idea, test out different implementations, try out different designs.

Wrapping up

Once all is said and done, the value that can be delivered from agentic coding today is phenomenal.

I know just from my own work that millions of dollars in revenue have depended on prototypes where it took me at least a day to get the data or API that I needed. Expand that to include all the colleagues I know who have done the same thing, and there is a real need. This tool would never have been built pre-agentic-coding. Product teams are focused on product, GTM teams are focused on targets. There’s no time to build tooling like this internally. Being able to build a solid v1 in just some weeks of solo effort is really quite something.