A project can feel surprisingly close to moving forward and completely stuck at the same time. There is an idea worth pursuing, a backlog full of plausible tasks, and more than enough tools to implement any of them. The problem is not an inability to write the next piece of code; it is not knowing which piece of code deserves the next few days of work.
This is the point where many projects begin to drift. Should the next step be a small feature that might validate the idea, a technical improvement that will make later work easier, or a conversation with users before any more implementation? All three can sound reasonable in isolation, but choosing one means postponing the others.
AI has made the implementation side of this work much faster. It can generate a component, suggest a schema, explain an unfamiliar API, or help trace a failing test. What it cannot decide without meaningful context is whether that component, schema, integration, or test is the most useful thing for the project right now.
The difficult part of building software is often not producing code. It is making the decision that gives the code a purpose.
It would be a mistake to dismiss what coding assistants have changed. They are useful for the parts of software development that are often repetitive or slow: exploring an unfamiliar library, producing a first version of a component, writing tests, translating between languages, or narrowing down a bug. Used well, they reduce the time between an idea and a working experiment.
That speed is valuable, but it can also make an unresolved decision easier to postpone. When producing code is cheap, it becomes tempting to implement several possibilities rather than decide which one best serves the project. A fast implementation of the wrong feature is still time spent moving in the wrong direction.
The questions that matter most are usually less precise than a coding task. Is this feature necessary for the first release, or are we adding it because it is easy to imagine? Does this service boundary solve a problem we have today, or one we may never have? Is the right next step a technical change at all, or should we first learn whether anyone needs the outcome we are building toward?
These are not questions with universal answers. They depend on the project's users, constraints, current stage, and the consequences of being wrong. A language model can contribute useful options and challenge assumptions, but it cannot supply the context or make the trade-off on the developer's behalf.
The distinction matters because implementation and judgment require different kinds of support. One helps us produce an answer quickly; the other helps us decide whether we are asking the right question.
In mentoring conversations, the recurring difficulty was rarely "How do I write this?" More often it was "Should I build this at all?", "Is this enough architecture for now?", or "What should I do next?" Those questions can look less urgent than a failing build or an unfinished feature, but they shape almost every hour that follows.
The cost of a weak decision is not limited to the first implementation. A feature that was unnecessary still needs to be maintained. A complicated abstraction still influences every later change. A premature infrastructure choice can turn a simple product question into a technical migration before there is evidence that the product needs it. Even when the code is clean, the time and attention spent on the wrong problem are difficult to recover.
There is also a momentum cost. When the next step is unclear, developers often respond by choosing work that feels concrete: refactoring, reorganising a backlog, adding flexibility, or building a feature that might be useful later. None of those actions is inherently wrong, but they can become a way of avoiding the harder decision about what the project needs now.
The most expensive mistakes are often not dramatic failures. They are reasonable-looking choices repeated for several weeks without a clear connection to an outcome. By the time the mismatch becomes visible, there is more code, more context to unwind, and less willingness to revisit the original assumption.
This is why making a decision explicit matters. It does not guarantee that the decision will be right, but it makes the reasoning visible enough to challenge, test, and change when new evidence arrives.
The goal is not to turn every product choice into a workshop. Most decisions do not need a long document, and a framework should not become another way to delay work. The useful version is small enough to write in a few minutes, but specific enough that someone else could understand why you chose a direction.
Before starting a meaningful piece of work, I find it useful to make five things explicit.
Start with the change you want to create, not the feature you are tempted to build. "Add team roles" describes an implementation; "allow an account owner to control who can access sensitive project data" describes an outcome. The distinction matters because an outcome leaves room for simpler solutions.
A clear outcome also gives you a way to evaluate the work later. If the feature ships but the user's situation does not improve, it is easier to see that the implementation may have been correct while the decision was not.
Every project has constraints, even when they are not written down. Time to validate an idea, the number of people maintaining the system, an existing technology choice, reliability requirements, and the cost of a mistake all affect what a proportionate solution looks like.
Making those constraints visible prevents an abstract discussion about the "best" approach. There is rarely one. There is only an approach that is sensible for this project, with these limits, at this point in time.
Write down two or three credible alternatives before committing. This does not mean generating a catalogue of every possible architecture; it means avoiding the assumption that the first workable approach is automatically the right one.
For example, an MVP that needs basic access control might consider a single owner/member distinction, a small set of fixed roles, or a fully configurable permissions system. Each option has a different cost, level of flexibility, and risk of becoming difficult to change later. This is usually the hardest question: what is the smallest decision that is safe and useful for the current stage? A mature product with complex enterprise requirements may need a flexible permission model. An early product trying to learn whether teams will collaborate at all may only need to distinguish an owner from everyone else.
"Good enough" is not an excuse for careless work. It is an acknowledgement that completeness has a cost, and that a decision should be proportionate to the evidence available today. The important part is to state what the solution deliberately does not cover and what evidence would justify revisiting it.
Finally, ask how difficult the choice will be to undo. Some decisions are cheap experiments: a copy change, a temporary workflow, or a limited feature flag. Others create data models, public APIs, operational dependencies, or user expectations that become expensive to unwind.
A decision that is easy to reverse does not need the same level of certainty as one that will shape the project for a year. This is a useful way to avoid both extremes: treating every choice as permanent, or treating a consequential choice as though it were a harmless experiment.
Applied to the permissions example, the reasoning might be simple: the immediate outcome is to let an account owner invite one collaborator; the constraint is a short validation window; the alternatives are owner/member roles or a configurable permission system; good enough is the owner/member model; and the decision is reversible if the data model does not assume there will only ever be two roles. That is not a perfect answer, but it is a decision with a visible rationale.
Writing this down does not make uncertainty disappear. It makes uncertainty concrete enough to discuss, challenge, and revisit. That is often more valuable than moving directly from a vague concern to a confident-looking implementation.
This is not an argument for using less AI. It is an argument for using it at a point where it has a better chance of being useful. Once the outcome, constraints, options, and level of reversibility are clear, an AI assistant can help examine the decision instead of filling a vacuum with a plausible-looking answer.
Consider the difference between asking:
"Design the architecture for my SaaS."
That request contains almost none of the information that makes an architecture decision meaningful. The assistant has to invent the product's needs, scale, constraints, team, and tolerance for operational complexity. It may produce a detailed answer, but detail is not evidence that the recommendation fits the project.
A more useful request gives the decision its context:
"I am building an MVP for independent consultants who need to share project updates with clients. I need to validate whether they will use it within four weeks. I am working alone and want to keep operational complexity low. I am deciding between a single application with a relational database and a separate event-driven service for notifications. Which option is proportionate for this stage? What risks am I missing, and what would justify revisiting the decision later?"
The second prompt is not better because it uses more words. It is better because it states what is being optimised for and what trade-off is actually under consideration. It gives the model enough material to identify assumptions, compare alternatives, and point out risks that the developer may have missed.
There are several useful roles for AI at this stage. It can challenge whether the stated outcome is specific enough, generate alternatives that deserve consideration, explain the consequences of each option, and help turn a choice into a short decision record. It can also identify questions that should be answered by users, measurement, or a small experiment rather than by technical reasoning alone.
None of this turns an LLM into a source of authority. The developer still needs to judge whether the context is accurate, whether the advice applies, and whether the resulting change is safe to make. The value is in making the reasoning more explicit and easier to examine - not in delegating responsibility for the decision.
This gap is what led me to build Hakkle. I kept returning to the same question: if implementation tools are becoming faster and more capable, what would help a developer make the decisions around that implementation with more clarity?
The hypothesis behind Hakkle is not that an AI should make those decisions for someone. It is that a project-aware technical coach could help a developer keep track of goals, constraints, prior choices, and open questions, then use that context to examine the next decision. The aim is to support planning, prioritisation, architecture discussions, and trade-offs without reducing them to a stream of isolated prompts.
It is still an early idea, and the distinction matters. A general-purpose LLM plus good notes may already be enough for many people and many projects. I am trying to learn where persistent project context and a more deliberate decision process provide real value, and where they simply add another tool to maintain.
For now, I am treating Hakkle as a validation exercise as much as a product. The useful outcome is not proving that every developer needs a technical coach; it is understanding which decisions developers find most difficult, how they currently work through them, and whether a tool can help without creating false confidence or additional friction. The conversation around AI often focuses on how quickly we can build. That is an important improvement, but speed only becomes valuable when it is applied in the right direction. Writing code has become cheaper than it has ever been. Time, attention, and good judgment have not.
Most successful projects are not defined by a single brilliant architectural decision or perfectly generated implementation. They are shaped by hundreds of small choices about what to build now, what to postpone, what assumptions to test, and what complexity can wait. Those decisions remain difficult because they depend on context, constraints, and goals that no model can infer on its own.
AI is an excellent partner for exploring ideas, comparing options, and accelerating execution once the problem is understood. But before asking it to write the next function or design the next service, it is worth spending a few minutes making the decision itself explicit. A clear question almost always leads to a better answer.
Better software does not come from generating the most code. It comes from making the next decision clearly enough that the code has a purpose. AI can accelerate implementation; the harder work is still deciding what deserves to be implemented.