DEV Community: Lars Faye | Confident Coding

My AI workflow seems to be the opposite of what the industry is encouraging, and I don't care.

Lars Faye | Confident Coding — Sun, 29 Mar 2026 19:32:00 +0000

The general consensus is that you should spec out your project, requirements, generate a bullet-proof plan, and then implement it via some kind of agent workflow. I've attempted this numerous times, and yes, it works...sort of. It can produce an application to the spec, but the main issue I continuously run into is that it's really hard to think about all the nuances and caveats ahead of time, and its not until I see something start to come together where I realize I need to think about things differently. Any ambiguity and the LLMs fills in with assumptions (or hallucinations).

I can just keep iterating with the agents, but its just more token usage, more code churn, more disconnection from the codebase, and more potential complexity as I am needing to trust the agent to refactor appropriately. It can be done, but I personally find it exhausting and rather annoying.

Lately, I've started to do the opposite, which I'm sure the AI bros would balk at: I use the LLM to generate the plan, and I do the implementation. Especially starting from scratch, deciding how to architect and plan an app out can be challenging, and I often like to see examples of other architectures to help me decide how I want to structure things. In the past, I'd often look for starter repos as inspiration and then begin putting things together after getting some initial direction.

With these AI tools, I can work with them to tailor an architecture and structure that suits my exact needs, plan the entire app, and then...build it myself.

Sure, I use these AI tools alongside to delegate tasks to and implement features on an as-needed basis, but its highly incremental and I'm still "manually" coding a good 50% of the project.

This flies in the face of how I think the industry is hyping things and seemingly the opposite of the "let AI do the coding, you only do the planning & review" workflow, but I really don't care. Anytime I've done that, I could feel the atrophy of my critical thinking setting in within a few days, and feeling like I inherited a codebase rather than helped create one.

Thinking in and working through the project in code isn't just drudgery; it forces you to think about things on a technical level that involves everything from security to performance to user experience to maintainability. Trying to do that while staying in the "natural language" mindset doesn't get specific enough, and specificity is absolutely essential to doing this work successfully.

I'm thinking of putting together a course that focuses on webdev troubleshooting and debugging.

Lars Faye | Confident Coding — Tue, 24 Mar 2026 21:00:48 +0000

I've been in the industry a while (back when tables were used for layout) and I've learned most of what I know through reverse engineering and breaking things/putting back together. I've always had a knack for it, and have helped a lot of developers over the years with tips and tricks I picked up along the way. I've had instances where I've found the solution in minutes that other developers were spending hours on. It's not like I was a better developer, it just seemed I had a process and mental framework whereas they would get overwhelmed on where to start.

My theory is: if developers can be more confident they can troubleshoot problems, they're less likely to feel imposter syndrome. I find I'm at my happiest when I'm being helpful and working with other developers, so I'm moving on something that I've wanted to do for over a decade and put the course together.

I'm working on content, and I'm still proving the concept out, so curious what you guys think. I want to focus on frontend workflows, although IMO, debugging skills are pretty universal.

Landing page: https://confident-coding.com/

Everyone Can Delegate Now | AI is enabling every knowledge worker to learn management skills.

Lars Faye | Confident Coding — Mon, 23 Mar 2026 23:30:32 +0000

Delegating was once reserved for managerial positions.

The ability to effectively delegate and outsource tasks was the primary role of a manager, who had, ideally, already spent time "in the trenches" doing the work they now assign to others.

Compiling data and generating reports, creating slideshow presentations, implementing features per client requirements...this delegation process flowed from the project managers and was distributed across the team.

Delegation was a skill that had to be honed and refined. You would move up the chain and take on higher-level work, orchestrating, rather than doing.

AI tools can empower individuals to learn delegation.

Because of their general ease of use, AI tools have proliferated quickly and we're still trying to pin down exactly what role they can effectively play, and how integrated they should be. The major shift that I have observed in the workplace, however, is that their introduction has created an opportunity where now everyone has the ability to leverage them for delegation, no matter the type or scope of task.

The ability to delegate is an empowering skill to practice. It offers a sense of freedom to the individual who might be facing down an exhaustive list of tasks: they don't have to do it all themselves. They can learn how to manage a workload efficiently because there's a way to relieve some of the pressure.

Tasks that were once required to be completed by an individual (e.g. populating a spreadsheet, drafting an email) can now be outsourced to a system which can loosely emulate human interaction. AI tooling has zero interface learning curve. Anybody can type into a chatbox. Just upload your request, requirements, and documents, and get a response. A draft of a report could be generated while you are on your lunch break, or article topics could be researched while you respond to emails.

Using AI tooling for delegation is different from delegating directly to humans, but there are core similarities:

Analyzing one's own workload and learning how to prioritize effectively
Breaking up large tasks into smaller, actionable pieces
Deciding what can be completed oneself versus what can be assigned to "someone else"

In the past, all these tasks would sit on someone's desk until they were able to get to them. If there wasn't enough time in the day, the work didn't get done (and the backlog grew).

AI delegation is a skill that needs to be learned.

While it's an empowering skill, delegating doesn't come naturally to everyone, and we should not conflate the ease of use of the tool with mastery over delegation as a skill. Delegating to AI in particular comes with some extra "gotchas", as well:

I've witnessed individuals not providing enough guidance and context, resulting in half-baked and incorrect results (this isn't all that different with humans, either!)
I've seen people blindly using responses without verification because they are delegating work outside their domain of expertise
I've worked with people who didn't understand the nature of context window limitations and how to break their task up into smaller pieces, eventually being forced to abandon it and start over

So, while the interface for an AI tool does not have a learning curve, these tools have an element of unpredictability & unreliability, and the responsible party needs to heavily scrutinize the outputs. If someone is not careful, it could end up proving to be more time consuming than doing the task manually (and you end up being more of a "micro-manager" than a "delegator").

Now that everyone has a potential delegatee they can assign work to, this is a skill that will need to be learned by everyone who is in a knowledge work role. The ability to offload some of their responsibilities and tasks and mitigate some overhead can teach essential lessons around management and leadership.

Efficiency breeds expectation.

Still, there are legitimate concerns that it won't reduce workload. When personal computers were rolled out into office spaces in the 70s/80s, the role of the secretary, with the narrow discipline of answering phones and taking messages, transformed to include word processing, electronic filing, spreadsheet management, and print queues. This resulted in a higher workload and more skills to learn.

Giving every individual the ability to delegate their work could create a situation where the increased amount of the 'resource' (an individual's productivity) ends up being consumed at an equal rate, negating any efficiency gains or resulting in burnout.

Delegation is likely to evolve the workforce.

The ability for workers to delegate is a skill that is going to have to be continuously refined over the years to come. For the employer, it should not be an excuse to merely shoehorn more work into a workday, but to reduce stress on the individual and to create space to do better work.

For the employee, whether a manager or a team member, individuals need to be mindful about what they are offloading. If someone delegates all of their workload to others (or to AI tools), they will end up in a "placeholder" role, rendering their own position all the more easy to replace (and creating their own potential cognitive atrophy).

These tools also offer tremendous opportunity in shaping how we can not just get more work done, but get better work done, as the ability to delegate can hone critical thinking, build managerial skills, and give every individual a sense of personal power.

Your Indispensable Value in the AI Era

Lars Faye | Confident Coding — Sat, 21 Mar 2026 18:23:37 +0000

"In a world where the cost of answers is dropping to zero, the value of the question becomes everything."
— Brit Cruise, the AI Paradox

LLMs and their adjacent AI tools have provided us with something truly novel: the ability to ask anything, at any time, and receive an answer. We might have thought Google was playing this role, until these tools showed us that what we had before was a ubiquitous digital encyclopedia, and what we have now resembles a librarian who will attempt to answer any question, regardless of the complexity or the absurdity.

When you have a tool that has all the answers, what value do you have to bring?

It turns out: a whole lot. More than you probably thought, too.

The Question is the Value

If I were asked by someone to describe what it's like be a developer (or programmer, or coder, whatever you identify with), I would describe it as a state of being in which one is ceaselessly asking questions:

Why doesn't this work?
Why does this work?
Is there a better way to approach this?
How can I build this feature?
Should I refactor this code?
What happens if I change X?
How does it behave when I move Y?
What happens if I remove Z?

Turning Blue to Purple

Many moons ago, circa 2010, I was hired to build an eCommerce site using CS Cart, a platform that was still in its infancy (even eCommerce was not that old by that point). During the checkout process, I got an obscure mySQL error, and I wasn't super experienced with SQL at the time, nevertheless something specific to CS Cart.

Off to Google I went, hoping to find an easy answer (spoiler: nope). I quickly turned every blue link I found to purple, with no clear resolution. So, I kept asking.

Each time I reformulated the question, I would get slightly different results, which led to refining the question. I was piecing together jigsaw puzzle without the picture, and each piece showed me the shape of the next piece I should begin sifting through the box for. Each reformulation of the question was another potential shape that could fit.

Eventually, after creating page after page of purple links, I gathered together enough pieces to formulate the actual question that I needed to answer. And once I had that question, the answer was immediate, and self-evident. After a solid day of searching (punctuated with many walks around the block), I found the answer!

Or, more accurately: I found the question.

The answer was the result of the labor, it was the outcome. As Brit Cruise also said in his scintillating video, finding the question itself is the work.

Nothing Is Becoming Simpler

From the introduction of GPT 3.5 to the latest models and tooling, answers are now abundant. Whether or not they are the correct answers...that is a problem that remains unchanged even with the latest frontier models. And it's a problem that is only solveable by those that know the power of asking the right questions.

I realize that with modern troubleshooting tooling and the assistance of AI models, that particular debugging session would have likely been resolved differently, and likely quicker. This is a wonderful turn of events; this is how progress works. That is that is applying an old problem to new tooling, though. The problems we face now are very different, and the challenges we face at any point in time, scale to the complexity of industry.

Programming and development are far more complicated in modern times than they were in 2010, if not just due to the sheer number of abstractions we've created for even the simplest features.

I recently found a great article by Paul Herbert who demonstrates this so effectively:
The Incredible Overcomplexity of the Shadcn Radio Button

For example, troubleshooting a Docker issue is orders of magnitudes more complex than anything I encountered in 2010, because the state of technology to support something like Docker did not exist then, but it does now.

As the tools grow in capability, the complexity grows. And as things get more complex, we encounter novel problems. We'll need more people who are able to approach these novel problems to help solve them, who know how to ask questions, how to research, and how to formulate new questions to navigate these new problems.

AI Cannot ask the Question For You

It's been a few years now and it's quite apparent that LLMs and AI tools are not going to simplify anything about what it means to program and create software. Peruse OpenAI's Harness engineering write-up, and it's clear to see that the new way to approach programming, seems to still be the same fundamentals as programming, but with more abstractions between you and the result, and with potential higher complexity due to the sheer volume of code that can be generated in shorter amounts of time. Which will lead to more complex software, which leads to more complex issues. Software is not a static industry, and we constantly scale the capabilities of the software to the capabilities of the tools.

What remains is the most valuable discipline that you can cultivate: how to ask effective, productive questions. And once you receive an answer to that question, how to take that answer to reformulate the next question, performing this process recursively until clarity comes. This is the process of "critical thinking", but that phrase handwaves away the mechanics of what it means to do just that. Being able to distill a general question into a highly specific one involves relentless scrutiny, ongoing experimentation, and being comfortable residing in a state of unknowing for an unspecific amount of time. This is the true job description of the programmer.

AI models cannot think for you, and they cannot formulate the question for you. They can certainly be a tool that helps you on your research path, but they are still bound by their training data, and they cannot escape the weighted dice that determines their paths which drive to their outputs. Their ability to generate answers is unmatched, but those answers are highly sensitive to the original input & context, and fundamentally untrustworthy by their very nature. That's OK, because they still have tremendous value, but only when someone is present and capable to sift through the noise, distill the truth, and verify the answer (or perhaps, the next question).

The Answers are Cheap Now

As Brit Cruise stated in a beautifully succinct manner: in an era where AI tooling has dropped the cost of answers to near zero, the value resides in asking the right questions. And while AI tools have exacerbated this situation, I would postulate that the value has always been in asking the right questions.

And when you have an infinite answer machine, your ability to ask good questions becomes infinitely more valuable.

View the article at: https://larsfaye.com/articles/the-question-is-the-work

Interesting in learning how to ask better questions? Check out Confident Coding

Your AI generated code is "almost right", and that is actually WORSE than it being "wrong".

Lars Faye | Confident Coding — Fri, 20 Mar 2026 15:13:02 +0000

"Almost right" will make it past reviews.
"Almost right" will pass tests and linters
"Almost right" will make it in your codebase, and wait for the right mix of reasons to create a potential catastrophe.

Yes, AI tools enhance your work and empower you to "punch above your weight". You also need discipline and practice, and you can give yourself permission to slow down and learn what is happening on a deeper level.

While the industry is pushing relentlessly for handing over control to “agents,” I propose a more measured approach, and recommend that the default mode when working with LLMs should always be scrutiny and skepticism. The trust needs to be earned, not granted.

When working in areas where the training data is robust and plentiful and the requests are clearly architected with proper context, they have a fairly high accuracy rate. Nevertheless, the real work happens in the nuance and the details, and they are renowned for introducing application-breaking issues through seemingly innocuous additions or changes. Every response should have a “trust, but verify” approach.

Anthropic themselves support this approach:

A security engineer highlighted the importance of experience when Claude proposed a solution that was “really smart in the dangerous way, the kind of thing a very talented junior engineer might propose.” That is, it was something that could only be recognized as problematic by users with judgment and experience.

It's only by knowing how to code, and practicing your coding on a regular basis (and your debugging, which I'm starting a course on), will you learn the skills to be able to catch those "almost right" solutions that these models provide, and be able to vet them properly, and ensure you're not pushing up a time bomb to your repo! 💣